Lapack: सभी एकल सटीक कार्यक्षेत्र प्रश्नों में सटीकता का नुकसान, निहित और स्पष्ट

मुझे लगता है कि उस समय यह समझ में आया होगा (कार्य सरणी सूचक के माध्यम से आकार वापस करने के लिए), लेकिन मुझे आश्चर्य है कि हमें आकार विनिर्देशक को इन/आउट चर में बदलने और सटीक मान को वापस पास करने से क्या रोकता है? एक "आधुनिक" कॉलर तब पहले इसकी जांच करेगा और वर्क ऐरे सदस्य का सहारा तभी लेगा जब lwork अभी भी -1 था, एक "पुराने" कॉलर को कोई बदलाव नहीं दिखाई देगा।

इसके अलावा शायद आवश्यक LWORK वापस इस समस्या को मारने के लिए शारीरिक रूप से बहुत बड़ा था और ilp64 ने इसे स्पष्ट कर दिया। मैं उन दिनों का सपना देख रहा हूं जहां दो कॉल योजना के बजाय रनटाइम पर एनबी मूल्य प्राप्त होता है।

इससे संबंधित दो चर्चा सूत्र यहां दिए गए हैं:
https://icl.cs.utk.edu/lapack-forum/viewtopic.php?t=1418
http://icl.cs.utk.edu/lapack-forum/archives/lapack/msg00827.html

यह विशेष रूप से एल्गोरिदम के लिए एक मुद्दा है जिसके लिए ओ (एन ^ 2) वर्कस्पेस की आवश्यकता होती है। एल्गोरिथ्म के लिए जिसके लिए O(n*nb) कार्यक्षेत्र की आवश्यकता होती है, यह किसी समस्या से कम नहीं है।

हाँ, यह एक डिज़ाइन दोष है।

@ मार्टिन-एफआरबीजी: सी _वर्क इंटरफ़ेस के लिए आपका प्रस्तावित परिवर्तन कैसे होगा? हमारे पास केवल वहां इनपुट के रूप में LWORK है। LWORK को INPUT/OUTPUT में बदलने से एक बड़ा बदलाव आया है। क्या आपके पास इस मुद्दे को हल करने का कोई विचार है? देखो:
https://github.com/Reference-LAPACK/lapack/blob/aa631b4b4bd13f6ae2dbab9ae9da209e1e05b0fc/LAPACKE/src/lapacke_dgeqrf_work.c#L35

मैं सोच रहा था कि हम LAPACK_dgeqrf__workspace_query() जैसे कुछ कार्यक्षेत्र आवंटन सबरूटीन भी बना सकते हैं और यह आवश्यक कार्यक्षेत्र वापस कर देगा।

वेलप, मेरी चालाक योजना वास्तव में काम नहीं करती है जब शांत हो ...
लेकिन ये वास्तव में दो समस्याएं हैं जो मुझे लगता है, एक काम का आकार एक लैपैक_इंट से बह रहा है और दूसरा "केवल" सीमित परिशुद्धता के कारण एक गलत बयानी है - मुझे आश्चर्य है कि बाद की कीमत पर बाद की उम्मीद करने के लिए गणना किए गए आकार को गोल करना संभव होगा या नहीं "कुछ" अप्रयुक्त स्मृति?

हाँ, यह एक डिज़ाइन दोष है।

मैं यहां 2 अलग-अलग खामियां देख सकता हूं:

1. LAPACK पर: रूटीन वास्तविक चर का उपयोग करके कार्य आकार लौटाते हैं।
2. LAPACKE पर: दिनचर्या LAPACK से दोष का प्रचार करती है।

@ मार्टिन-एफआरबीजी का विचार (1) का एक अच्छा समाधान है। नया फोरट्रान कोड काम (1) के बजाय LWORK के वापसी मूल्य का उपयोग कर सकता है। हम प्रतिस्थापन के लिए कुछ (अर्ध-) स्वचालित प्रक्रिया के साथ कोड को संशोधित करने का प्रयास कर सकते हैं। उदाहरण के लिए, ssyevd.f , हम प्रतिस्थापित कर सकते हैं

  ELSE IF( LQUERY ) THEN
     RETURN
  END IF

द्वारा

  ELSE IF( LQUERY ) THEN
     LWORK = LOPT
     RETURN
  END IF

LAPACKE_dgeqrf__work_query() जोड़ना, जैसा कि @langou सुझाव देता है, हल करता है (2), हालांकि इस संशोधन से जुड़े बहुत सारे काम हैं।

एलवर्क को इन/आउट में बदलना मूल रूप से एक अच्छा समाधान होगा, लेकिन यह पीछे की ओर संगत नहीं है। तब एप्लिकेशन को यह जानना होगा कि क्या LAPACK संस्करण <= 3.10 (कहना) या> 3.10 था, यह जानने के लिए कि lwork कहां से प्राप्त करें। इससे भी बदतर, ऐसे उदाहरण हैं जहां एप्लिकेशन एक कॉन्स वैल्यू में पास होते हैं - यह उम्मीद करते हैं कि यह स्थिर रहेगा - इसलिए LAPACK अपने व्यवहार को बदलने के लिए उस मान को ओवरराइट करने के लिए बहुत हानिकारक (यूबी) होगा। उदाहरण के लिए, मैग्मा में:

    const magma_int_t ineg_one = -1;
    ...
            magma_int_t query_magma, query_lapack;
            magma_zgesdd( *jobz, M, N,
                          unused, lda, runused,
                          unused, ldu,
                          unused, ldv,
                          dummy, ineg_one,  // overwriting ineg_one would break MAGMA
                          #ifdef COMPLEX
                          runused,
                          #endif
                          iunused, &info );
            assert( info == 0 );
            query_magma = (magma_int_t) MAGMA_Z_REAL( dummy[0] );

समाधान जो मैंने कुछ साल पहले प्रस्तावित किया था और मैग्मा में लागू किया गया था, वह केवल sgesdd, आदि में है, काम में लौटाए गए lwork को थोड़ा ऊपर करने के लिए, इसलिए लौटाया गया मान हमेशा> = इच्छित मूल्य होता है। https://bitbucket.org/icl/magma/src/master/control/magma_zauxiliary.cpp देखें और करें। (जेनरेट किए गए एकल-सटीक संस्करण के लिए एक रिलीज़ देखें।) मूल रूप से प्रतिस्थापित करें

    WORK( 1 ) = MAXWRK

साथ

    WORK( 1 ) = lapack_roundup_lwork( MAXWRK )

जहां फ़ंक्शन lapack_roundup_lwork इसे थोड़ा ऊपर उठाता है, जैसा कि magma_*make_lwork करता है। मैग्मा में, मैंने एकल-सटीक ईपीएस का उपयोग करके, लेकिन गणना को डबल में करते हुए, (1 + ईपीएस) से गुणा करके गोल किया। तब मौजूदा एप्लिकेशन अपने कार्यक्षेत्र प्रश्नों को बदलने की आवश्यकता के बिना सही ढंग से व्यवहार करेंगे।

अधिक परीक्षण के बाद, मैंने lwork> 2^54 के लिए पाया, इसे LAPACK परिभाषा slamch ("eps") = 5.96e- के बजाय epsilon = 1.19e-07 (उर्फ ulp) की सी/सी ++/फोरट्रान परिभाषा का उपयोग करने की आवश्यकता है। 08 (उर्फ यूनिट राउंडऑफ़, यू)। यदि ulp का उपयोग किया जाता है, तो ऐसा लगता है कि गणना एकल में की जा सकती है।