128 बिट पूर्णांक के लिए इंटेल विंडो कंपाइलर क्या करता है? विंडोज़ पर MT1993 की तुलना में MSVC के साथ PCG64 कितना धीमा है? मुझे संदेह है कि आगे कूदने की सुविधा का व्यापक रूप से उपयोग किया जाएगा, इसलिए इसे डिफ़ॉल्ट रूप से रखना अच्छा हो सकता है।

128 बिट पूर्णांक के लिए इंटेल विंडो कंपाइलर क्या करता है?

पूरी तरह से निश्चित नहीं; मुझे नहीं पता कि अगर ABI के निहितार्थ हैं कि ICC द्वारा बाध्य होने की परवाह की जाएगी। अगर हम सिर्फ जनरेट किए गए असेंबली के किसी भी विचार को प्राप्त करना चाहते हैं, जिसका हम उपयोग कर सकते हैं, तो यह एक आसान संसाधन है: https://godbolt.org/z/kBntXH

मुझे संदेह है कि आगे कूदने की सुविधा का व्यापक रूप से उपयोग किया जाएगा, इसलिए इसे डिफ़ॉल्ट रूप से रखना अच्छा हो सकता है।

क्या आपका मतलब है सुलझने वाली धाराएँ, बल्कि? यह एक अच्छा बिंदु है, लेकिन मुझे आश्चर्य है कि अगर यह दूसरा रास्ता नहीं काट सकता है। यदि डिफ़ॉल्ट रूप से हमारी पसंद वास्तव में बहुत मायने रखती है, तो हो सकता है कि अगर हम इनमें से एक और अधिक पूरी तरह से चित्रित PRNGs को चुनते हैं, तो लोग उन विशेषताओं का उपयोग पुस्तकालय कोड में बिना दस्तावेज के अधिक व्यापक रूप से करेंगे कि उन्हें "उन्नत" सुविधाओं की आवश्यकता होती है, क्योंकि, आखिरकार, वे उपलब्ध हैं "मानक"। लेकिन फिर अगर कोई अन्य उपयोगकर्ता गति या अन्य कारणों से उस लाइब्रेरी का उपयोग कम BitGenerator के साथ करने की कोशिश करता है, तो वे ईंट की दीवार से टकराएंगे। No default या MT19937 दुनिया में, पुस्तकालयों को उन उन्नत सुविधाओं के बारे में सोचने और दस्तावेज़ करने की अधिक संभावना होगी, जिनकी उन्हें आवश्यकता होती है।

चपेट में आने पर, उस घटना को BitGenerator s बिना सेलेबल स्ट्रीम कम वांछनीय लगेगा, और मैं _do_ आगे बढ़ने की धारणा की तरह है जो उस दिशा में सबसे अच्छा अभ्यास माना जाता है (व्यक्तिगत रूप से शुद्ध; मुझे नहीं लगता; NumPy-in-project शेयर कि धारणा बनाने के लिए एक दायित्व)। यह उन कुछ गालियों से बचने में मदद कर सकता है, जिन्हें मैं अपने कोड के बीच में .seed() ing के साथ देखता हूं। लेकिन फिर से, सभी इस धारणा पर समर्पित हैं कि एक डिफ़ॉल्ट होने से लोगों के व्यवहार में काफी बदलाव आएगा, इसलिए इन सभी चिंताओं की काफी संभावना है।

विंडोज़ पर MT1993 की तुलना में MSVC के साथ PCG64 कितना धीमा है?

# 13163 में @bashtage द्वारा पोस्ट किए गए बेंचमार्क में, PCG64 MT19937 की लगभग आधी गति है, जो MSVC और दोस्तों के लिए बहुत निराशाजनक प्रदर्शन है। यह लिनक्स पर 23% तेजी से तुलना की जाती है।

128 बिट पूर्णांक के लिए इंटेल विंडो कंपाइलर क्या करता है?

क्लैंग, जीसीसी, और इंटेल कंपाइलर जैसे अन्य कंपाइलर 64-बिट सिस्टम पर 128-बिट पूर्णांक को लागू करते हैं उसी तरह वे 32-बिट सिस्टम पर 64-बिट पूर्णांक को लागू करते हैं। सभी समान तकनीकों की जरूरत नहीं नए विचारों के साथ। Microsoft ने MSVC के लिए ऐसा करने की जहमत नहीं उठाई, इसलिए संकलक द्वारा सीधे समर्थित 128-बिट पूर्णांक नहीं हैं।

परिणामस्वरूप, MSVC के लिए # 13163 हैंड-इम्प्लीमेंटेशन्स 128-बिट गणित में PCG64 के मौजूदा कार्यान्वयन को Microsoft के आंतरिक भाग में x86_64 में _mulx_u64 जैसे समकक्ष और अधिक पोर्टेबल इंटेल इंट्रिंसिक्स भी कर सकता है)। इस प्रकार कोडिंग क्या जीसीसी, क्लैंग और इंटेल संकलक खुद करेंगे। सबसे बड़ा मुद्दा यह है कि Microsoft के कंपाइलर इन इंट्रिनिक्स को बहुत अच्छी तरह से ऑप्टिमाइज़ नहीं करते हैं (उम्मीद है कि वे कम से कम इनलाइन हैं)। यह संभव है कि हैंड-कोडेड असेंबलर तेजी से आगे बढ़े लेकिन कंपाइलर के लिए उचित फिक्स इतना शैतानी खराब न हो।

मुझे संदेह है कि आगे कूदने की सुविधा का व्यापक रूप से उपयोग किया जाएगा, इसलिए इसे डिफ़ॉल्ट रूप से रखना अच्छा हो सकता है।

मुझे खुशी है कि आप आगे कूदना पसंद करते हैं, लेकिन मैं उत्सुक हूं कि आपको क्यों लगता है कि इसका व्यापक रूप से उपयोग किया जाएगा। (व्यक्तिगत रूप से, मुझे वास्तव में distance , जो आपको बताता है कि दो PRNG कितने अलग हैं। यह PCG के C ++ संस्करण में है, लेकिन C एक नहीं है। हालांकि इसे जोड़ने के लिए यह काफी तुच्छ होगा। ब्याज।)

मुझे खुशी है कि आप आगे कूदना पसंद करते हैं, लेकिन मैं उत्सुक हूं कि आपको क्यों लगता है कि इसका व्यापक रूप से उपयोग किया जाएगा।

वर्तमान शब्दावली से संभवतः अपरिचित है। मेरा मतलब है कि आसानी से स्वतंत्र धाराएँ प्राप्त की जा सकती हैं जिनका उपयोग समानांतर में सिमुलेशन चलाने के लिए किया जा सकता है। मुझे नहीं पता कि कितनी सिमुलेशन समस्याओं को समानांतर किया जा सकता है, लेकिन मुझे संदेह है कि यह बहुत कुछ है और इन दिनों एक चिप पर लोगों की संख्या को देखते हुए, जो आसानी से एक गति नुकसान के लिए बना सकता है।

Microsoft ने MSVC के लिए ऐसा करने की जहमत नहीं उठाई, इसलिए संकलक द्वारा सीधे समर्थित 128-बिट पूर्णांक नहीं हैं।

ताकि हमारे पहियों को नुकसान होगा, OTOH, विंडोज पर कई लोगों को एनाकोंडा या उत्साहित से उनके पैकेज मिलते हैं, जिनमें से दोनों इंटेल का उपयोग करते हैं, और जो लोग वास्तव में प्रदर्शन के बारे में परवाह करते हैं वे शायद लिनक्स, मैक, या शायद एआईएक्स पर हैं।

संपादित करें: और शायद अगर माइक्रोसॉफ्ट का संबंध है, तो वे समस्या को ठीक करने के लिए एक इनाम दे सकते हैं।

एफडब्ल्यूआईडब्ल्यू, यहां असेंबली है कि clang महत्वपूर्ण फ़ंक्शन के लिए उत्पन्न होगा, जिसमें बिट्स को uint128_t uint64_t s की संरचना में रीपैक्स / रीपैकेज करने की आवश्यकता है: https: // godbolt.org/z/Gtp3os

बहुत मस्त, @rkern। कोई भी मौका आप वही देख सकते हैं जो हाथ से लिखे गए 128-बिट कोड के साथ MSVC कर रहा है?

बहुत मस्त, @rkern। कोई भी मौका आप वही देख सकते हैं जो हाथ से लिखे गए 128-बिट कोड के साथ MSVC कर रहा है?

यह उह, सुंदर नहीं है। ~ https://godbolt.org/z/a5L5Gz~

ओह, -O3 जोड़ना भूल जाते हैं, लेकिन यह अभी भी बदसूरत है: https://godbolt.org/z/QQhd

यह काफी बुरा नहीं है। आपके पास अनुकूलन नहीं था, इसलिए इसने कुछ भी इनलाइन नहीं किया। मैंने /Ox (शायद एक बेहतर विकल्प है?) जोड़ा है। मैंने कोड को अंतर्निहित इंट्रेंसिक ( _rotr64 ) का उपयोग करने के लिए भी तय किया था क्योंकि जाहिरा तौर पर MSVC सी रोटेट मुहावरे को देखने में असमर्थ है।

अभी भी एक ट्रेन के मलबे की तरह हालांकि। लेकिन मुझे लगता है कि यह कहना उचित है कि थोड़ा ध्यान से, PCG64 कोड को MSVC में संकलित किया जा सकता है, जो हर किसी के लिए पूरी तरह से शर्मनाक नहीं है।

बाकी सब को मर्ज करने की अनुमति देने के लिए, अब "डिफ़ॉल्ट नहीं" क्यों चुना जाए? यह हमें अनुकूलता को तोड़ने के बिना बाद में डिफ़ॉल्ट (बाद में एक या एक से अधिक रिलीज एस) पर निर्णय लेने के लिए स्वतंत्र छोड़ देता है।

हमारे अधिकांश उपयोगकर्ता यादृच्छिक संख्या विशेषज्ञ नहीं हैं, हमें उनके लिए चूक प्रदान करना चाहिए।

अभियोजन से परे "अब उन्हें अधिक कोड टाइप करने की आवश्यकता है", जब हम कुछ बदलते हैं तो क्या होता है? उस मामले में जहां बिटगेंनेटर हार्ड कोडेड होता है, (क्योंकि हमने कोई डिफ़ॉल्ट प्रदान नहीं किया है), प्रत्येक गैर-परिष्कृत उपयोगकर्ता को अब अपना कोड रिफलेक्टर करना होगा, और उम्मीद है कि उनकी पसंद की बारीकियों को समझें (ध्यान दें कि हम खुद के लिए भी सहमत नहीं हो सकते हैं) श्रेष्ठ है)। हालाँकि, यदि हम एक डिफ़ॉल्ट प्रदान करते हैं, तो हम उनके परीक्षणों को तोड़ सकते हैं क्योंकि नया डिफ़ॉल्ट या नया संस्करण बिट-स्ट्रीम संगत नहीं है।

इस धारणा के बीच कि बिट-स्ट्रीम हमेशा बनाम इस धारणा के बीच स्थिर रहेगा कि NumPy डेवलपर्स को पता है कि वे क्या कर रहे हैं और डिफ़ॉल्ट मान सबसे अच्छा-ब्रांड होना चाहिए, मैं दूसरी धारणा के पक्ष में, भले ही वह पहले तोड़ता है।

संपादित करें: स्पष्ट करें कि कौन से डेवलपर्स को पता होना चाहिए कि वे क्या कर रहे हैं

हमारे अधिकांश उपयोगकर्ता यादृच्छिक संख्या विशेषज्ञ नहीं हैं, हमें उनके लिए चूक प्रदान करना चाहिए।

खैर, हम निश्चित रूप से सिफारिशों का दस्तावेजीकरण करेंगे, भले ही हमारे पास डिफ़ॉल्ट हो या क्या हो, इसकी परवाह किए बिना, बहुत कम से कम सिफारिशों का दस्तावेजीकरण किया जाएगा।

अभियोजन से परे "अब उन्हें अधिक कोड टाइप करने की आवश्यकता है", जब हम कुछ बदलते हैं तो क्या होता है?

आप "कुछ" के बारे में क्या सोच रहे हैं? मैं आपके तर्क का पालन नहीं कर सकता।

अभियोजन से परे "अब उन्हें अधिक कोड टाइप करने की आवश्यकता है", जब हम कुछ बदलते हैं तो क्या होता है?

आप "कुछ" के बारे में क्या सोच रहे हैं? मैं आपके तर्क का पालन नहीं कर सकता।

@mattip डिफ़ॉल्ट बिट जनरेटर को बदलने की बात कर रहा है।

यह वॉडल उन उपयोगकर्ताओं को बनाता है, जिन्होंने इसे पागल बना दिया है, और कौडल को कुछ कोड परिवर्तन की आवश्यकता होती है।

उदाहरण के लिए, यदि आपने उपयोग किया है

g = Generator()
g.bit_generator.seed(1234)

और अंतर्निहित बिट जनरेटर को बदल दिया गया था, फिर यह गलत होगा।

यदि आपने अधिक समझदार काम किया और उपयोग किया

Generator(BitGenerator(1234))

तब आप इसे नहीं देखेंगे।

IMO, जब डिफ़ॉल्ट की पसंद पर विचार करते हैं, तो हमें यह तय करना चाहिए कि जब तक अंतर्निहित बिट जनरेटर में कोई घातक दोष नहीं पाया जाता है या इंटेल अपने चिप्स में एक QUANTUM_NI जोड़ता है, जो यादृच्छिक प्रदर्शन में कई OOM सुधार पैदा करता है।

मुझे लगता है कि मैं यहां एक बाहरी व्यक्ति हूं, लेकिन मुझे नहीं लगता कि यह उम्मीद करना उचित है कि जो PRNG डिफ़ॉल्ट विकल्प है वह हमेशा के लिए तय हो जाता है और कभी नहीं बदलता है। (सी ++ में, उदाहरण के लिए, std::default_random_engine कार्यान्वयन के विवेक पर है और रिलीज से रिलीज तक बदल सकता है।)

बल्कि, पूर्व परिणामों को पुन: पेश करने के लिए एक तंत्र होने की आवश्यकता है। इस प्रकार एक बार किसी विशेष कार्यान्वयन के मौजूद होने के बाद, इसे बदलना बहुत ही बेकार है (उदाहरण के लिए, MT19937 _is_ MT19937, आप इसे अलग-अलग आउटपुट देने के लिए ट्वीक नहीं कर सकते हैं)। [और यह पहले से मौजूद एक कार्यान्वयन को हटाने के लिए भी बेकार है।]

जब डिफ़ॉल्ट बदल जाता है, जो लोग पुराने परिणाम को फिर से जारी रखना चाहते हैं, उन्हें नाम से पिछले डिफ़ॉल्ट के लिए पूछना होगा। (आप एक पूर्व रिलीज से संबंधित डिफ़ॉल्ट का चयन करने के लिए एक तंत्र प्रदान करके बना सकते हैं।)

अगर आपने किसी और चीज़ के लिए डिफ़ॉल्ट जनरेटर को स्वैप करने की अनुमति दी है, तो भी, यह वास्तव में कड़ाई से बेहतर होना चाहिए - डिफ़ॉल्ट जनरेटर में मौजूद कोई भी विशेषता भविष्य में उस सुविधा का समर्थन करने के लिए एक प्रतिबद्धता का प्रतिनिधित्व करती है। यदि आपके डिफ़ॉल्ट जनरेटर में कुशल advance , तो आप वास्तव में बाद में उसे दूर नहीं ले जा सकते। (आप संभवतः इस समस्या से बचने के लिए डिफ़ॉल्ट जनरेटर में उन्नत कार्यक्षमता को बंद कर सकते हैं।)

सारांश में, यह सुनिश्चित करने के तरीके हैं कि उपयोग करने के लिए आपके खुद को एक अनुबंध में बंद करने की कोशिश के बिना प्रतिलिपि प्रस्तुत करने योग्य परिणाम हो सकते हैं जहां डिफ़ॉल्ट हमेशा के लिए अपरिवर्तित रहता है। यह आपके द्वारा किए गए चुनाव के लिए दांव भी कम कर देगा।

(Fwiw, यह है कि क्या मैं पीसीजी में किया था। डिफ़ॉल्ट पीसीजी 32-बिट PRNG वर्तमान में XSH-आरआर संस्करण [के रूप में पहुँचा है pcg_setseq_64_xsh_rr_32_random_r सी पुस्तकालय में और pcg_engines::setseq_xsh_rr_64_32 सी में कक्षा ++ पुस्तकालय], लेकिन सिद्धांत रूप में यदि आप वास्तव में भविष्य-प्रूफ प्रतिलिपि प्रस्तुत करना चाहते हैं, तो आपको XSH-RR को स्पष्ट रूप से निर्दिष्ट करना चाहिए, बजाय pcg32_random_r या pcg32 जो उपनाम हैं और सिद्धांत रूप में कुछ और में अपग्रेड किया जा सकता है। ।)

यह वास्तव में हमेशा के लिए नहीं है (यह पूरी परियोजना 90% एक वास्तविक, वास्तविक और हमेशा के लिए सम्मानित किया गया है जो लगभग 14 साल पहले किए गए वादे से प्रेरित है), लेकिन जैसा कि आप कहते हैं, स्विचिंग की जरूरत है (ए) बदलने के लिए एक आकर्षक कारण और (बी) कम से कम कुछ साल ले लो मूल्यह्रास चक्र।

आज जितना संभव हो उतना करीब से कोशिश करना बेहतर है।

एक चीज़ जो प्रतिबंधित नहीं है, निश्चित रूप से, लॉगन के बाद PRNG कोड में सुधार कर रही है क्योंकि यह समान मानों का उत्पादन करता है। उदाहरण के लिए, यदि हम एक PRNG के साथ जाते हैं जो uint128 का उपयोग करता है, तो हम MS को एक भविष्य के संस्करण में Win64 के लिए uint128 समर्थन (वसा मौका) या असेंबली जोड़ने दे सकते हैं।

उदाहरण के लिए, यदि आपने उपयोग किया है

g = Generator()
g.bit_generator.seed(1234)

और अंतर्निहित बिट जनरेटर को बदल दिया गया था, फिर यह गलत होगा।

ठीक है, कि "नो डिफॉल्ट" विकल्प के लिए, @ eric-wieser के साथ बहस हो रही है, जिसे मैं प्रारंभिक विवरण के साथ वर्ग नहीं कर सकता हूं "हमारे अधिकांश उपयोगकर्ता यादृच्छिक संख्या विशेषज्ञ नहीं हैं, हमें उनके लिए चूक प्रदान करना चाहिए। । "

पूरी तरह से डिफ़ॉल्ट नहीं मानने वाले डिफ़ॉल्ट और अनुकूल के बीच, मैं हमेशा बाद वाला चुनूंगा:

अभी:

Generator() # OK
Generator(DefaultBitGenerator(seed)) # OK
Generator(seed) # error

_मेरी प्राथिमिकता:

Generator(1234) == Generator(DefaultBitGenerator(1234)
Generator(*args**kwargs) == Generator(DefaultBitGenerator(*args, **kwargs))

अब मुझे नहीं लगता कि इसमें प्रवेश होने वाला है, लेकिन मुझे लगता है कि रैंडमस्टेट के उपयोग को लंबा करने का एक तरीका यह है कि यह केवल उन उपयोगकर्ताओं के लिए उपलब्ध हो जो महसूस करते हैं कि वे थोड़ा जनरेटर चुनने के लिए पर्याप्त विशेषज्ञ हैं।

सारांश में, यह सुनिश्चित करने के तरीके हैं कि उपयोग करने के लिए आपके खुद को एक अनुबंध में बंद करने की कोशिश के बिना प्रतिलिपि प्रस्तुत करने योग्य परिणाम हो सकते हैं जहां डिफ़ॉल्ट हमेशा के लिए अपरिवर्तित रहता है। यह आपके द्वारा किए गए चुनाव के लिए दांव भी कम कर देगा।

हाँ, हमारे पास ऐसा है। उपयोगकर्ता नाम से BitGenerator s हड़प सकते हैं (जैसे MT19937 , PCG64 , इत्यादि) और उन्हें बीज के साथ तत्काल। BitGenerator ऑब्जेक्ट्स यूनिफ़ॉर्म यूनिफ़ॉर्म PRNG अल्गोरिदम को यूनिफ़ॉर्म [0..1) float64 s और पूर्णांक (साथ ही साथ जो भी मज़ेदार कूदहेड / स्ट्रीम क्षमताएं हैं) के लिए एक सीमित सेट के साथ लागू करते हैं। । Generator जिस वर्ग के बारे में हम बात कर रहे हैं वह प्रदान की गई BitGenerator वस्तु लेता है और गैर-समान वितरण, गॉसियंस, गामा, द्विपद, आदि के सभी प्रदान करने के लिए हमारे चारों ओर लपेटता है। BitGenerator s के लिए सख्त स्ट्रीम अनुकूलता की गारंटी देता है। हम किसी से छुटकारा नहीं पा रहे हैं (जो इसे जारी करने के लिए बनाते हैं), और न ही उन्हें बदल दिया जाएगा।

डिफ़ॉल्ट के बारे में केंद्रीय प्रश्न "क्या g = Generator() , बिना किसी तर्क के, क्या करता है?" अभी, पीआर में, यह एक मनमाना राज्य के साथ एक Xoshiro256 BitGenerator बनाता है (यानी /dev/urandom जैसे अच्छे एंट्रोपी स्रोत से तैयार)। "कोई डिफ़ॉल्ट" विकल्प यह नहीं होगा कि त्रुटि हो; उपयोगकर्ताओं को स्पष्ट रूप से BitGenerator नाम देना होगा जो वे चाहते हैं। @ eric-wieser का कहना है कि "नो डिफॉल्ट" पहली रिलीज के लिए स्पष्ट रूप से _safe_ विकल्प है। डिफ़ॉल्ट रूप से बाद में रिलीज़ करने से उसी तरह समस्याएँ उत्पन्न नहीं होंगी जैसे मौजूदा डिफ़ॉल्ट को बदलना।

@ क्रेंक , यदि आप केवल उन तर्कों के मामले में परवाह करते हैं, जहां बीज को उपलब्ध एन्ट्रापी से स्व-प्रतिरक्षित किया जाता है, तो यह वास्तव में बहुत मायने नहीं रखता है कि अंतर्निहित जनरेटर क्या है - यह प्रति घंटा के आधार पर बदल सकता है क्योंकि परिणाम कभी भी प्रजनन योग्य नहीं होंगे ( अलग-अलग रनों को अलग-अलग बीज मिले)।

इसके विपरीत, @bashtage एक डिफ़ॉल्ट जनरेटर के बारे में परवाह करता है जो एक बीज के साथ प्रदान किया जाता है।

@rkern , यदि आप केवल

इसके बनने के बाद आप BitGenerator पुनर्निमाण कर सकते हैं। तो अगर Generator() काम करता है, तो मैं पूरी तरह से होने की उम्मीद कर रहा हूं कि जो लोग एक वरीयता प्राप्त PRNG चाहते हैं, वह अगली पंक्ति में इसे बीज देगा, जैसा कि @bashtage के उदाहरण में है:

g = Generator()
g.bit_generator.seed(seed)

यह कुछ हद तक थकाऊ है, यही वजह है कि मैंने शीर्ष पर सुझाव दिया कि शायद ज्यादातर लोग Generator(PCG64(<seed>)) वैसे भी चुनते हैं, क्योंकि यह केवल सुविधाजनक टाइपिंग-वार के रूप में है। हालाँकि, @bashtage सही ढंग से नोट करता है जब एक अतिरिक्त निर्णय लेने का सामना करना पड़ता है।

इसलिए मुझे लगता है कि हम _also_ हमारे सामने एक व्यापक सवाल रखते हैं: "वे सभी तरीके क्या हैं जो हम चाहते हैं कि उपयोगकर्ता इनमें से किसी एक को तत्काल भेज दें? और यदि उन तरीकों में डिफ़ॉल्ट सेटिंग्स हैं, तो उन चूक क्या होनी चाहिए?" हमारे पास Generator(<seed>) या Generator(DefaultBitGenerator(<seed>)) लिए कुछ खुले डिज़ाइन स्पेस और @bashtage का सुझाव अभी भी संभावनाएं हैं।

@bashtage आपको कितना लगता है कि प्रलेखन मदद करेगा? यही है, अगर हमने शीर्ष पर कहा " PCG64 हमारी पसंदीदा डिफ़ॉल्ट BitGenerator " है और सभी उदाहरणों में Generator(PCG64(seed)) लगातार उपयोग किया है (जब विशेष रूप से अन्य एल्गोरिदम का प्रदर्शन नहीं किया गया है)?

मैं default_generator(<seed>) _function_ Generator(<seed>) या g=Generator();g.seed(<seed>) होने पर अधिक आश्वस्त हो सकता हूं। फिर अगर हमें वास्तव में इसे बदलने की जरूरत है और सामान नहीं तोड़ना चाहते हैं, तो हम सिर्फ एक नया फ़ंक्शन जोड़ सकते हैं और पुराने को चेतावनी जोड़ सकते हैं। मैं इसे पहले रिलीज के लिए experimental के रूप में चिह्नित करने की सिफारिश कर सकता हूं, जिससे हमें कुछ प्रतिबद्धता देने से पहले जंगली में इस बुनियादी ढांचे को देखने का कुछ समय मिल सके।

क्या वास्तव में एक DefaultBitGenerator ऑब्जेक्ट बना रहा है जो इसकी आंतरिक स्थिति के किसी भी विवरण को उजागर नहीं करता है? यह अन्य बिट जनरेटर वस्तुओं में से एक के लिए एक प्रॉक्सी होगा, लेकिन सिद्धांत रूप में उनमें से किसी को भी लपेटा जा सकता है - उत्पन्न संख्याओं के अपने विशिष्ट अनुक्रम के अलावा। यह उपयोगकर्ताओं को उम्मीद है कि वे डिफ़ॉल्ट बिटगेटर के साथ क्या कर सकते हैं, इसके बारे में प्रोग्राम संबंधी धारणा बनाने से हतोत्साहित करते हैं, जबकि हमें अभी भी एक बेहतर एल्गोरिदम का उपयोग करने की अनुमति देता है।

मैं @bashtage से सहमत Generator , जैसे, np.random.Generator(1234) तर्क के रूप में समर्थन करने के लिए अधिक अनुकूल होगा। यह निश्चित रूप से DefaultBitGenerator ।

Generator लिए दस्तावेज़ीकरण में, हम एक पूरा इतिहास दे सकते हैं कि NumPy के प्रत्येक पिछले संस्करण में डिफ़ॉल्ट बिट जनरेटर क्या था। यह मूल रूप से @imneme का सुझाव है, और मुझे लगता है कि यह प्रजनन योग्य उद्देश्यों के लिए पर्याप्त होगा।

(अभी यह एक पूर्व टिप्पणी के लिए संपादित देखा)

ओह, -O3 जोड़ना भूल जाते हैं, लेकिन यह अभी भी बदसूरत है: https://godbolt.org/z/QQhd

MSVC के लिए, यह -O3 , यह /O2 या /Ox (लेकिन /O3 !) नहीं है।

Generator लिए दस्तावेज़ीकरण में, हम एक पूरा इतिहास दे सकते हैं कि न्यूपे के प्रत्येक पिछले संस्करण में डिफ़ॉल्ट बिट जनरेटर क्या था। यह मूल रूप से @imneme का सुझाव है, और मुझे लगता है कि यह प्रजनन योग्य उद्देश्यों के लिए पर्याप्त होगा।

वास्तव में, और भी बेहतर एक स्पष्ट शामिल करने के लिए किया जाएगा version तर्क, जैसे अचार के protocol तर्क , में Generator / DefaultBitGenerator । तब आप np.random.Generator(123, version=1) जैसा कुछ इंगित करने के लिए लिख सकते हैं कि आप चाहते हैं कि "संस्करण 1" यादृच्छिक संख्याएं (जो कुछ भी हो) या np.random.Generator(123, version=np.random.HIGHEST_VERSION) (डिफ़ॉल्ट व्यवहार) यह इंगित करने के लिए कि आप नवीनतम / महान बिट जनरेटर चाहते हैं (जो कुछ भी है)।

संभवतः version=0 MT19937 जो कि NumPy ने अब तक उपयोग किया है, और version=1 जो भी नया डिफ़ॉल्ट हम उठा सकते हैं।

क्या वास्तव में एक DefaultBitGenerator ऑब्जेक्ट बनाने के बारे में जो अपने आंतरिक राज्य के किसी भी विवरण को उजागर नहीं करता है? यह अन्य बिट जनरेटर वस्तुओं में से एक के लिए एक प्रॉक्सी होगा, लेकिन सिद्धांत रूप में उनमें से किसी को भी लपेटा जा सकता है - उत्पन्न संख्याओं के अपने विशिष्ट अनुक्रम के अलावा। यह उपयोगकर्ताओं को उम्मीद है कि वे डिफ़ॉल्ट बिटगेटर के साथ क्या कर सकते हैं, इसके बारे में प्रोग्राम संबंधी धारणा बनाने से हतोत्साहित करते हैं, जबकि हमें अभी भी एक बेहतर एल्गोरिदम का उपयोग करने की अनुमति देता है।

हममम। यह अपील कर रहा है। यह _feels_ जैसा कि यह चीजों को ओवरकॉम्प्लिकेट कर रहा है और इस गॉर्डियन गाँठ में एक और लूप जोड़ रहा है (और यह कि _should_ हमारे लिए अधिक अलेक्जेंडर-एस्क स्ट्रोक उपलब्ध है), लेकिन यह वास्तव में एकमात्र बुरी बात है जो मुझे इसके बारे में कहना है। यह _does_ शेष निर्णयों को आसान बनाता है: हम सांख्यिकीय गुणवत्ता और प्रदर्शन पर ध्यान केंद्रित कर सकते हैं।

दरअसल, इससे भी बेहतर $ # $ 1 $ # $ $ $ $ $ $ # $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ version pickle Generator DefaultBitGenerator ।

मैं इसका बहुत कम प्रशंसक हूं। pickle केस के विपरीत, इन चीजों के सार्थक नाम हैं जिनका हम उपयोग कर सकते हैं, और हमारे पास पहले से ही लागू तंत्र है।

मैं इसका बहुत कम प्रशंसक हूं। pickle मामले के विपरीत, इन चीजों के सार्थक नाम हैं जिनका हम उपयोग कर सकते हैं, और हमारे पास पहले से ही लागू तंत्र है।

एक विशिष्ट NumPy उपयोगकर्ता के दृष्टिकोण से निम्नलिखित पर विचार करें:

• np.random.Generator(seed, version=0) बनाम np.random.Generator(seed, version=1)
• np.random.Generator(MT19937(seed)) बनाम np.random.Generator(PCG64(seed))

मुझे लगता है कि यह मान लेना सुरक्षित है कि हमारे अधिकांश उपयोगकर्ता RNG एल्गोरिदम के सापेक्ष गुणों के बारे में बहुत कम जानते हैं। लेकिन यहां तक ​​कि किसी भी डॉक्स को पढ़ने के बिना, वे सुरक्षित रूप से अनुमान लगा सकते हैं कि version=1 (नया डिफ़ॉल्ट) version=0 तुलना में ज्यादातर मामलों में बेहतर होना चाहिए। अधिकांश उपयोगकर्ताओं के लिए, वास्तव में वे सभी जानना आवश्यक है।

इसके विपरीत, MT19937 और PCG64 जैसे नाम वास्तव में केवल विशेषज्ञों के लिए सार्थक हैं, या ऐसे लोग जो पहले से ही हमारे दस्तावेज़ पढ़

आपके उपयोग के मामले में, कोई भी version का चयन नहीं कर रहा है कि वे _want_। वे केवल version चयन करते हैं, ताकि वे ज्ञात संस्करण के परिणामों को दोहराने के लिए _need_ हो। वे हमेशा एक विशिष्ट मूल्य की तलाश में होते हैं जिसका इस्तेमाल किया गया था (स्पष्ट रूप से, क्योंकि हमने इसे निहित होने की अनुमति दी) उन परिणामों में जो वे दोहराना चाहते हैं; उन्हें कई मूल्यों के बीच संबंध के बारे में तर्क करने की आवश्यकता नहीं है।

और किसी भी मामले में, क्रॉस-रिलीज़ रिप्रोड्यूसबिलिटी का स्तर कुछ ऐसा है जिसे हमने एनईपी 19 में

डिफ़ॉल्ट पर कुछ विचार:

• 99.9% उपयोगकर्ताओं को अंतर्निहित एल्गोरिदम के बारे में परवाह नहीं है या जानना नहीं चाहते हैं, वे बस यादृच्छिक संख्या चाहते हैं। तो डिफ़ॉल्ट के लिए एक राय बनाने के लिए +1, कृपया उपयोगकर्ताओं को न चुनें।
• dSFMT MT19937 तुलना में बस एक तेज़ संस्करण लगता है (डॉक्स में यह बताकर अच्छा होगा कि कितनी तेजी से और "SSE2" हटा दें)। चूंकि हम किसी भी तरह से बिटस्ट्रीम प्रजनन की गारंटी नहीं दे रहे हैं, आंतरिक स्थिति अंतर बहुत दिलचस्प नहीं है और dSFTM को MT19937 से अधिक पसंद किया जाना चाहिए, भले ही यहां जीतने वाला तर्क "लेख समीक्षा के दौरान जीवन को आसान बना दे" ।
• उपयोगकर्ता आधार के एक महत्वपूर्ण अंश के लिए प्रदर्शन मायने रखता है। जनरेटर के सांख्यिकीय गुण केवल उपयोगकर्ताओं के _very_ छोटे अंश के लिए मायने रखते हैं। सभी शामिल जनरेटर सामान्य उपयोग के मामलों के लिए ठीक हैं। तो डिफ़ॉल्ट के रूप में सबसे तेज़ एक को चुनने के लिए +1।

कहने के लिए क्षमा करें - लेकिन 32-बिट अभी भी विंडोज पर मायने रखता है - देखें https://github.com/pypa/manylinux/issues/118#issuecomment -481404761

मुझे लगता है कि हमें सांख्यिकीय गुणों के बारे में बहुत ध्यान रखना चाहिए, क्योंकि हम डेटा विश्लेषण में रिसैमलिंग विधियों के अधिक उपयोग की दिशा में एक बड़ी पारी की प्रक्रिया में हैं। यदि पायथन को इस मामले पर थोड़ा मैला होने के लिए प्रतिष्ठा मिलती है, भले ही यह केवल डिफ़ॉल्ट रूप से हो, जो कि डेटा विश्लेषण के लिए पायथन पर विचार करने वाले लोगों द्वारा आगे बढ़ना एक बाधा हो सकती है। मुझे बहुत खुशी होगी अगर पायथन उन लोगों के लिए पसंद का पैकेज था जो क्रमपरिवर्तन और सिमुलेशन को गंभीरता से लेते हैं।

मुझे लगता है कि तेजी से नहीं अत्याधुनिक एल्गोरिदम की पेशकश करना ठीक है, लेकिन डिफ़ॉल्ट रूप से नहीं, जिस हद तक हम इसे टाल सकते हैं और बैक-संगतता बनाए रख सकते हैं।

कुछ फोरेंसिक और चर्चा के लिए, देखें: https://arxiv.org/pdf/1810.10985.pdf

पाठ्यपुस्तक ऐसी विधियाँ देती हैं जो स्पष्ट या स्पष्ट रूप से मानती हैं कि PRNG को वास्तविक IIDU [0,1) चर के लिए प्रतिस्थापित किया जा सकता है, बिना सामग्री त्रुटि [20, 7, 2, 16, 15]। हम यहां दिखाते हैं कि MATLAB, पायथन के रैंडम मॉड्यूल, R, SPSS और Stata सहित कई आमतौर पर इस्तेमाल किए जाने वाले सांख्यिकीय पैकेजों में एल्गोरिदम के लिए यह धारणा गलत है।

@kellieotto , @pbstark - क्या आप के बारे में एक राय है कि PRNG को हमें यहां से क्या चुनना चाहिए, ताकि क्रमपरिवर्तन और बूटस्ट्रैप के लिए सर्वोत्तम संभव आधार दिया जा सके?

मुझे लगता है कि हमें सांख्यिकीय गुणों के बारे में बहुत ध्यान रखना चाहिए, क्योंकि हम विश्लेषण के तरीकों में पुन: नमूनाकरण के अधिक उपयोग की दिशा में एक बड़ी पारी की प्रक्रिया में हैं।

माना। जब तक वे गुण कुछ वास्तविक दुनिया के उपयोग के मामलों के लिए प्रासंगिक हैं, तब तक यह बहुत महत्वपूर्ण है। आमतौर पर जो चिंताएँ सामने आती हैं, वे हमेशा बेहद अकादमिक होती हैं।

कुछ फोरेंसिक और चर्चा के लिए, देखें: https://arxiv.org/pdf/1810.10985.pdf

बहुत ही रोचक लेख। यह निष्कर्ष निकालता है कि NumPy एकमात्र पुस्तकालय के बारे में है जो R, पायथन stdlib & co के विपरीत इसे सही (पृष्ठ 9 के ऊपर) प्राप्त करता है।

कागज की तुलना में और भी अधिक ठोस उदाहरण प्राप्त करना बहुत उपयोगी होगा। यदि हमारा वर्तमान डिफ़ॉल्ट जनरेटर भी किसी बिंदु पर टूट जाता है, तो वह कब है? आर के sample फ़ंक्शन जैसे उदाहरण ~ 1.7 बिलियन नमूने ड्राइंग करते समय 40% संख्या और 60% विषम संख्याएं उत्पन्न करते हैं। यहाँ बूटस्ट्रैपिंग / पुनःसमर्पण क्या है?

आर (3.6) की नवीनतम रिलीज ट्रंकेशन बनाम यादृच्छिक बिट्स दृष्टिकोण को ठीक करती है
यादृच्छिक पूर्णांक उत्पन्न करने के लिए। Mersenne ट्विस्टर डिफ़ॉल्ट रहता है
PRNG, यद्यपि।

@ केली ओटोबोनी [email protected] और मुझे लगता है कि डिफ़ॉल्ट PRNG इन है
वैज्ञानिक भाषा और सांख्यिकी पैकेज क्रिप्टोग्राफिक रूप से होने चाहिए
सुरक्षित (एक CS-PRNG, उदाहरण के लिए, काउंटर मोड में SHA256), गिरने के विकल्प के साथ
कम तेजी से लेकिन कम गुणवत्ता (जैसे, मेर्सेन ट्विस्टर) के लिए वापस
अगर गति की आवश्यकता है।

हम पायथन के लिए एक CS-PRNG पर काम कर रहे हैं:
https://github.com/statlab/cryptorandom

प्रदर्शन बहुत अच्छा नहीं है (अभी तक)। अड़चन टाइप रूपांतरण होने लगती है
बाइनरी स्ट्रिंग्स (हैश आउटपुट) को पूर्णांक के रूप में डालने के लिए पायथन के भीतर। हम कर रहे हैं
कार्य को सी पर अधिक कार्य करने वाले कार्यान्वयन पर कार्य करना।

चीयर्स,
फिलिप

सोम, 27 मई, 2019 को सुबह 6:27 बजे राल्फ गोम्मर्स नोटिफिकेशन @github.com
लिखा था:

मुझे लगता है कि हमें सांख्यिकीय गुणों के बारे में बहुत ध्यान रखना चाहिए, क्योंकि हम हैं
में resampling तरीकों के अधिक से अधिक उपयोग की दिशा में एक बड़ी पारी की प्रक्रिया में
डेटा विश्लेषण

माना। जब तक वे गुण कुछ वास्तविक दुनिया के उपयोग के लिए प्रासंगिक हैं
मामलों, यह बहुत महत्वपूर्ण है। आमतौर पर जो चिंताएँ सामने आती हैं, वे हैं
हमेशा बेहद अकादमिक।

कुछ फोरेंसिक और चर्चा के लिए, देखें:
https://arxiv.org/pdf/1810.10985.pdf

बहुत ही रोचक लेख। यह निष्कर्ष निकालता है कि NumPy केवल के बारे में है
पुस्तकालय जो इसे सही बनाता है (पृष्ठ 9 के ऊपर), आर, पायथन stdlib & co के विपरीत।

की तुलना में और भी अधिक ठोस उदाहरण प्राप्त करना बहुत उपयोगी होगा
कागज। यदि हमारा वर्तमान डिफ़ॉल्ट जनरेटर भी किसी बिंदु पर टूट जाता है,
कब है वो? आर के सैंपल फंक्शन जैसे उदाहरण 40% भी उत्पन्न करते हैं
संख्या और 60% विषम संख्या जब ड्राइंग ~ 1.7 बिलियन नमूने हैं। क्या है?
यहाँ बूटस्ट्रैपिंग / रेज़ोमलिंग बराबर है?

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें
https://github.com/numpy/numpy/issues/13635?email_source=notifications&email_token=AANFDWJJEIA4CTLLHVZZKKVPVPUU5CNFSM4HPX3CHKYY3PNWH8H8H8646H8&hl=hi&hl=hi
या धागा म्यूट करें
https://github.com/notifications/unsubscribe-auth/AANFDWJW445QDPGZDGXMPA3PXPOUFANCNFSM4HPX3CHA
।

-
फिलिप बी। स्टार्क | एसोसिएट डीन, गणितीय और भौतिक विज्ञान |
प्रोफेसर, सांख्यिकी विभाग |
कैलिफोर्निया विश्वविद्यालय
बर्कले, सीए 94720-3860 | 510-394-5077 | आँकड़ों ।berkeley.edu/~stark |
@philipbstark

उपयोगकर्ता आधार के एक महत्वपूर्ण अंश के लिए प्रदर्शन मायने रखता है। जनरेटर के सांख्यिकीय गुण केवल उपयोगकर्ताओं के _very_ छोटे अंश के लिए मायने रखते हैं। सभी शामिल जनरेटर सामान्य उपयोग के मामलों के लिए ठीक हैं। तो डिफ़ॉल्ट के रूप में सबसे तेज़ एक को चुनने के लिए +1

सबसे पहले, "सबसे तेज़" लेने का कोई तरीका नहीं है। @bashtage ने # 13163 में वर्तमान कोड पर

मुझे यह भी आश्चर्य है कि गति की परवाह करने वाले उपयोगकर्ताओं का "महत्वपूर्ण अंश" कितना बड़ा है। पायथन ही सी के मुकाबले लगभग 50 × धीमा है । NumPy उपयोगकर्ता के किस अंश को PyPy पर चलाया जा रहा है (जो 4 × गति को बढ़ावा देगा)? कुछ, निश्चित रूप से, लेकिन मुझे संदेह है कि बहुत अधिक संख्या नहीं है।

और उस "महत्वपूर्ण अंश" के लिए, जो गति के बारे में परवाह करता है, ऊपर दी गई सभी परिवर्तनशीलता को देखते हुए, जो आपके लिए सिर्फ यह शब्द ले जा रहा है कि डिफ़ॉल्ट PRNG उनके आवेदन के लिए सबसे तेज़ चलेगा? करने के लिए एक समझदार बात (यह भी काफी मजेदार है और अधिकांश उपयोगकर्ताओं की पहुंच के भीतर) विभिन्न उपलब्ध PRNGs को बेंचमार्क करना है और देखें कि कौन सा सबसे तेज है _ उनके लिए_।

इसके विपरीत, यद्यपि वे दस्तावेज़ीकरण में सुराग पा सकते हैं, लेकिन सांख्यिकीय गुणवत्ता विशेष PRNG पता लगाना, जैसा कि आप ध्यान दें, अधिकांश उपयोगकर्ताओं के रडार पर नहीं (और विशेषज्ञों के लिए भी चुनौतीपूर्ण है)। अधिकांश को यह भी पता नहीं होगा कि उन्हें कब देखभाल करनी चाहिए या नहीं। मेरा तर्क है कि यह कुछ पितृदोष के लिए एक जगह है - तथ्य यह है कि अधिकांश उपयोगकर्ता कुछ के बारे में परवाह नहीं करते हैं इसका मतलब यह नहीं है कि अनुचर को इसकी परवाह नहीं करनी चाहिए।

यह सच है कि सभी शामिल PRNG अधिकांश उपयोग के मामलों के लिए ठीक हैं, लेकिन यह काफी कम बार है। यूनिक्स सिस्टम ने सी-लाइब्रेरी PRNGs के स्मोर्गास्बोर्ड के साथ भेज दिया है जो सभी सांख्यिकीय रूप से भयानक हैं और फिर भी दुनिया भर में व्यापक रूप से अपनी धुरी के बिना उपयोग किए गए हैं।

सांख्यिकीय गुणों से परे, ऐसे अन्य गुण हैं जो उपयोगकर्ता स्वयं के लिए नहीं जानना चाहते हैं, लेकिन मैं उनके लिए चाह सकता हूं। निजी तौर पर, PRNGs के एक प्रदाता के रूप में मैं तुच्छ भविष्यवाणी से बचना चाहता हूं - मैं नहीं चाहता कि कोई व्यक्ति PRNG के कुछ आउटपुट देखें और फिर भविष्य के सभी आउटपुट क्या होंगे, यह कहने में सक्षम होंगे। अधिकांश संदर्भों में जहां NumPy का उपयोग किया जाता है, भविष्यवाणी की समस्या नहीं है - ऐसा कोई विरोधी नहीं है जो अनुक्रम की भविष्यवाणी करने में आसानी से सक्षम होने से लाभ उठाएगा। लेकिन कोई व्यक्ति कहीं न कहीं NumPy के PRNGs का उपयोग करने जा रहा है, क्योंकि उन्हें आँकड़ों को करने के लिए NumPy की आवश्यकता नहीं है, बल्कि इसलिए कि उन्हें पहले जहाँ PRNG मिल चुके हैं; यह कोड एक वास्तविक विरोधी का सामना कर सकता है जो PRNG की भविष्यवाणी करने में सक्षम होने से लाभान्वित होगा। इस विकट स्थिति के खिलाफ मजबूती से बीमा करने के लिए बहुत अधिक (उदाहरण के लिए, गति का महत्वपूर्ण नुकसान) का भुगतान करना इसके लायक नहीं है, लेकिन मामूली बीमा इसके लायक हो सकता है।

कुछ फोरेंसिक और चर्चा के लिए, देखें: https://arxiv.org/pdf/1810.10985.pdf

पाठ्यपुस्तक ऐसी विधियाँ देती हैं जो स्पष्ट या स्पष्ट रूप से मानती हैं कि PRNG को वास्तविक IIDU [0,1) चर के लिए प्रतिस्थापित किया जा सकता है, बिना सामग्री त्रुटि [20, 7, 2, 16, 15]। हम यहां दिखाते हैं कि MATLAB, पायथन के रैंडम मॉड्यूल, R, SPSS और Stata सहित कई आमतौर पर इस्तेमाल किए जाने वाले सांख्यिकीय पैकेजों में एल्गोरिदम के लिए यह धारणा गलत है।

एफडब्ल्यूआईडब्ल्यू, बायलेम के बिना एक सीमा में कुशलता से संख्या उत्पन्न करने पर अच्छा पेपर है। मैंने अपने स्वयं के लेख में कुछ बेंचमार्क भी तलाशने और चलाने के लिए एक जंपिंग पॉइंट के रूप में उपयोग किया। (64-बिट्स उत्पन्न करते समय, Lemire की विधि धीमी-बिट 64-बिट विभाजन से बचने के लिए 128-बिट गुणा का उपयोग करती है, सभी परिचित मुद्दों के साथ जो MSVC उपयोगकर्ताओं के लिए उठा सकते हैं।)

@pbstark @kellieotto मैंने आपके पेपर को दिलचस्पी के साथ पढ़ा जब यह arXiv पर दिखा। मैं BIDS में कुछ दोस्तों का दौरा कर रहा था, और उन्होंने आपके काम का उल्लेख किया था। चर्चा खंड में लिखा गया है कि "अब तक, हमने MT19937 के लिए O (10 ^ 5) प्रतिकृति में पाए जाने वाले बड़े पूर्वाग्रह के साथ एक आंकड़ा नहीं पाया है। क्या आपने अभी तक एक पाया है? क्या आपको PCG64 जैसे 128-बिट PRNG के लिए एक ठोस उदाहरण मिला है? यह मुझे व्यावहारिक प्रासंगिकता का एक उचित सीमा प्रतीत होता है, जहाँ यह विचार दूसरों (IMO) को पछाड़ने के लिए शुरू हो सकता है, कम से कम एक सामान्य-उद्देश्य डिफ़ॉल्ट का चयन करने के उद्देश्य से।

हमारे नए PRNG फ्रेमवर्क # 13163 की अच्छी विशेषता यह है कि यह किसी को भी अपना BitGenerator प्रदान करने की अनुमति देता है जिसे केवल प्लग इन किया जा सकता है। इसके लिए लोगों को अपने सुपी में इसका उपयोग करने के लिए पर्याप्त मात्रा में होना भी आवश्यक नहीं है। कोड। मैं आपको cryptorandom को BitGenerator C के रूप में लागू करने के लिए प्रोत्साहित करने के लिए प्रोत्साहित करूंगा ताकि हम इसे अन्य विकल्पों के साथ सिर से सिर की तुलना कर सकें।

व्यक्तिगत रूप से, मैं उन लोगों से उम्मीद करता हूं कि वास्तव में गति के बारे में परवाह करने पर अतिरिक्त मील जाता है यदि आवश्यक हो (यह यहां बहुत अधिक नहीं है)। हमें सुरक्षित डिफॉल्ट्स प्रदान करना चाहिए, और मेरा वर्तमान सबसे अच्छा अनुमान यह है कि इसका मतलब क्रिप्टोग्राफी के अपवाद के साथ सभी उद्देश्यों के लिए सुरक्षित डिफॉल्ट्स हैं (डॉक्स में शायद हमें इस बारे में चेतावनी होनी चाहिए)। कई उपयोगकर्ता गति के बारे में परवाह करते हैं, लेकिन स्पष्ट रूप से यही कारण है कि मैं इसे बहुत अधिक प्राथमिकता देने से कतराता हूं।
वह लेख जहां नेम्पी ने अच्छा काम किया था (शायद यह सही होने के लिए रॉबर्ट को कुदोस लगता है!), लेकिन वास्तव में नमूना है बिट जनरेटर नहीं।

@pbstark शायद आप इसे BitGenerator के रूप में लागू करना चाहते हैं, जो numpy / randomgen के साथ संगत है? यह संभव है कि दोनों इसे गति देने और इसे अधिक उपयोगी रूप में व्यापक दर्शकों के लिए उपलब्ध कराने का सबसे आसान तरीका हो। चूंकि ऐसा लगता है कि आप और केली ओटोबोनी बर्कले में हैं, इसलिए हम कुछ समय के लिए मिल सकते हैं? (बस एक प्रस्ताव, मुझे पहले कोड पर खुद को करीब से देखना चाहिए)।

उस के बारे में _Random नमूनाकरण: अभ्यास बनाता है Imperfect_ कागज, यह एक अच्छा पढ़ा है, लेकिन यह याद रखने योग्य है कि यदि हमारे पास 1 ट्रिलियन कोर 100 साल के लिए प्रति नैनोसेकंड में एक संख्या का उत्पादन होता है, तो हम 2 ^ 102 नंबर से कम उत्पन्न करेंगे।

तुच्छ रूप से अनुमानित PRNGs (Mersenne Twister जैसे बड़े राज्य रिक्त स्थान वाले भी) के लिए, हम वास्तव में यह जान सकते हैं कि क्या कुछ विशिष्ट आउटपुट अनुक्रम कभी भी उत्पन्न हो सकते हैं (और यदि यह मौजूद है तो बीज को उत्पन्न कर सकते हैं या अगर यह नहीं लगता है तो इसे महसूस कर सकते हैं) ), लेकिन अन्य गैर-तुच्छ-पूर्वानुमेय PRNGs के लिए हम (आसानी से) यह नहीं जान सकते हैं कि कौन से आउटपुट अनुक्रम कभी भी उत्पन्न नहीं हो सकते हैं और कौन से हैं, लेकिन पर्याप्त दुर्लभ हैं कि हम गायब होने की संभावना है कि उन्हें कभी भी खोज में नहीं मिलेगा। (जैसा कि आप जानते हैं, मेरे पास एक PRNG है जो मुझे पता है कि 2 ^ 80 आउटपुट के भीतर इसमें _Twelth Night_ के साथ एक ज़िप फ़ाइल थूक दी जाएगी, लेकिन सौभाग्य कभी इसे खोज रहा है।)

यदि आप वास्तव में एक क्रिप्टोकरंसी चाहते हैं तो आधुनिक हार्डवेयर पर एकमात्र विकल्प है
एईएस के बाद से इसमें एक समर्पित निर्देश है। @ ब्लेयर में एक कार्यान्वयन है
यहाँ https://github.com/lemire/testingRNG/blob/master/source/aesctr.h
नॉनट्रिप्टो जनरेटर के रूप में तेजी से है। चचा 20 भी है जो जा सकता है
SIMD के साथ उपवास। हालांकि पुराने हार्डवेयर पर दोनों कुत्ते धीमे होंगे। तीन बार और
फिलॉक्स पहले से ही शामिल हैं और क्रिप्टोलाइट काउंटर प्रिंज हैं।

IMO क्रिप्टो लागत लाभों के संदर्भ में ओवररेटेड है। मुझे किसी की जानकारी नहीं है
माउंट के साथ PRNG समस्याओं के कारण महत्वपूर्ण वापसी, जो मुझे लगता है
10e6 प्रकाशित पत्रों के क्रम में उपयोग किया जाता है। केवल अनुप्रयोगों मैंने देखा है
जहां PRNG वास्तव में समस्याग्रस्त थे, ऐसे मामले थे जहां अवधि इतनी थी
छोटा है कि जनरेटर ने पूरा चक्र पूरा किया। यहां तक ​​कि एकमात्र
प्रभाव अध्ययन के नमूने के आकार को कम कर रहा था, जिसने मुख्य को दोहराया
एक बार एक बड़ी अवधि के साथ सिस्टम पर फिर से परिणाम।

सोम पर, 27 मई, 2019, 19:50 रॉबर्ट कर्ने नोटिफिकेशन @github.com ने लिखा:

@pbstark https://github.com/pbstark @kellieotto
https://github.com/kellieotto जब मैंने आपके पेपर को रुचि के साथ पढ़ा
ArXiv पर दिखाया गया है। मैं BIDS में कुछ दोस्तों का दौरा कर रहा था, और उनके पास था
अपने काम का उल्लेख किया। चर्चा अनुभाग नोट करता है कि "अब तक, हमने नहीं किया है
लगातार पूर्वाग्रह के साथ एक आँकड़ा पाया गया जिसका पता लगाया जा सके
O (10 ^ 5) "MT19937 के लिए प्रतिकृति" क्या आपने अभी तक एक पाया है?
PCG64 जैसे 128-बिट PRNG के लिए एक ठोस उदाहरण? मुझे ऐसा लगता है
व्यावहारिक प्रासंगिकता का एक उचित सीमा हो, जहां यह विचार है
कम से कम चयन करने के उद्देश्य से दूसरों (IMO) को पछाड़ना शुरू कर सकते हैं
एक सामान्य उद्देश्य डिफ़ॉल्ट।

हमारे नए PRNG फ्रेमवर्क की अच्छी विशेषता # 13163
https://github.com/numpy/numpy/pull/13163 यह है कि यह किसी को भी अनुमति देता है
अपने स्वयं के BitGenerator प्रदान करें जो अभी प्लग किए जा सकते हैं। यह नहीं है
यहां तक ​​कि लोगों के लिए उनके खसरे कोड में इसका उपयोग करने के लिए संख्यात्मक रूप से होना चाहिए। मैं
C में BitGenerator के रूप में क्रिप्टोकरंसी को लागू करने के लिए प्रोत्साहित करें
इसलिए हम इसे अन्य विकल्पों के साथ सिर से सिर की तुलना कर सकते हैं।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें
https://github.com/numpy/numpy/issues/13635?email_source=notifications&email_token=ABKTSRO5PKW4MRFSBGUFUNTPXQUQUOLA_NFSM4HPX3CHKYY3PNVWKWH3LFDFDLFDLFDLFDLFDFDLFDFDLFDFDLFDFDLFDFDLFDFDLFDFDLFDDFDLFDLFDRFDRFDRFDBHBHBHBHBHBHBFBHBRBDBKBBJBDBDJDBDB-दिन -र्षवे की दिशा में जोडnा हो सकता है ।
या धागा म्यूट करें
https://github.com/notifications/unsubscribe-auth/ABKTSRMRIHC4OYDR52HLTHDPXQUOLANCNFSM4HPX3CHA
।

मुझे यह भी आश्चर्य है कि गति की परवाह करने वाले उपयोगकर्ताओं का "महत्वपूर्ण अंश" कितना बड़ा है। पायथन ही सी। की तुलना में लगभग 50 × धीमा है। नुमाइपी यूजरबेस का कौन सा अंश इसे PyPy पर चला रहा है (जो 4 × गति को बढ़ावा देगा)? कुछ, निश्चित रूप से, लेकिन मुझे संदेह है कि बहुत अधिक संख्या नहीं है।

मुझे संदेह है कि आप एक नियमित उपयोगकर्ता नहीं हैं :) NumPy ज्यादातर हुड के नीचे सी है, और सी में अपनी चीज़ करने के रूप में तेज़ है (अच्छी तरह से, ज्यादातर तेजी से)। इसके अलावा, PyPy वैज्ञानिक अनुप्रयोगों के लिए तैयार नहीं है, और किसी भी मामले में धीमा है (क्योंकि यह CPPthon API का उपयोग करने के लिए सीमित है जिसे NumPy उपयोग करता है, इसलिए यह अपने JIT के लाभों को प्राप्त नहीं कर सकता है)।

किसी भी तरह से, यह ऑफ टॉपिक है। यह कहना कि गति का मामला विवादास्पद नहीं है।

@imeme हम
बिना किसी विरासत या मूल्यह्रास के साथ नए सिरे से शुरुआत करने के लिए हमने कड़ी मेहनत की है
अच्छा एल्गोरिदम।

सोम पर, 27 मई, 2019, 19:46 imneme सूचनाएँ @ithub.com ने लिखा:

कुछ फोरेंसिक और चर्चा के लिए, देखें:
https://arxiv.org/pdf/1810.10985.pdf

पाठ्यपुस्तकें ऐसे तरीके देती हैं जो स्पष्ट रूप से या स्पष्ट रूप से मान लेते हैं कि PRNGs कर सकते हैं
सामग्री को पेश किए बिना IIDU [0,1) चर के लिए प्रतिस्थापित किया जाए
त्रुटि [२०,,, २, १६, १५]। हम यहां दिखाते हैं कि यह धारणा गलत है
MATLAB सहित कई आमतौर पर इस्तेमाल किए जाने वाले सांख्यिकीय पैकेजों में एल्गोरिदम,
पायथन का यादृच्छिक मॉड्यूल, आर, एसपीएसएस और स्टाटा।

FWIW, @lemire द्वारा एक अच्छा पेपर https://arxiv.org/abs/1805.10941 है
https://github.com/lemire कुशलता से एक सीमा में एक संख्या उत्पन्न करने पर
पक्षपात के बिना। मैंने इसका इस्तेमाल कुछ को तलाशने और चलाने के लिए एक जंपिंग पॉइंट के रूप में किया
मेरे अपने लेख में भी मानक
http://www.pcg-random.org/posts/bounded-rands.html (जब
64-बिट, लेमायर की विधि धीमी से बचने के लिए 128-बिट गुणन का उपयोग करती है
64-बिट डिवीजन, सभी परिचित मुद्दों के साथ जो MSVC के लिए उठा सकते हैं
उन।)

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें
https://github.com/numpy/numpy/issues/13635?email_source=notifications&email_token=ABKTSRKNAQAK4WIXG5SVLO3PX3P5XV3X5PNFM4HPX3CHPY3CHWYVOQHULVOH52H8H5&hl=hi&hl=hi
या धागा म्यूट करें
https://github.com/notifications/unsubscribe-auth/ABKTSRKV3KYKRLNMBKNU4JLPXQUA3ANCNFSM4HPX3CHA
।

हमें _safe_ चूक प्रदान करनी चाहिए, और मेरा वर्तमान सबसे अच्छा अनुमान यह है कि इसका अर्थ क्रिप्टोग्राफी के अपवाद के साथ सभी उद्देश्यों के लिए सुरक्षित चूक है

इससे बहस करना मुश्किल है। मेरा सवाल है - क्या सुरक्षित है? विभिन्न गुणों के साथ अर्ध-यादृच्छिकता की अलग-अलग डिग्री है। अब तक मैंने किसी को ठोस उदाहरण देते हुए नहीं देखा, न ही यहां अन्य मुद्दों, पीआर या थ्रेड्स में। बस अमूर्त सांख्यिकीय गुणों के बारे में बात करना उपयोगी नहीं है।

मेरी समझ में यह है कि PCG64 एक अच्छा डिफ़ॉल्ट होगा। एनाकोंडा एट का उपयोग करने वाले लोगों के लिए विंडोज पर गति का नुकसान स्पष्ट नहीं होगा। अल।, और कुछ बिंदु पर तय होने की संभावना है। समानांतर निष्पादन के साथ पायथन में नई बात होने के साथ, मुझे यह भी लगता है कि बसने योग्य धाराएँ एक वांछनीय संपत्ति है।

मुझे अत्यधिक संदेह है कि विज़ुअल स्टूडियो के तहत PCG64 स्पीड पेनल्टी कुछ ऐसा है जिसे मिटाया नहीं जा सकता।

क्या यह कहीं ध्यान से मूल्यांकन किया गया था?

यह कहना कि गति का मामला विवादास्पद नहीं है।

मेरा सवाल है - क्या सुरक्षित है?

तर्क को लगातार लागू करें: "तेज क्या है"? मुझे इस बात का बहुत अच्छा अंदाजा नहीं है कि एक महत्वपूर्ण अड़चन के रूप में BitGenerator का प्रदर्शन वास्तव में क्या है। यदि मैं BitGenerator उपयोग करता हूं जो कि दोगुना है, तो क्या मुझे अपनी पूर्ण गणना में 5% गति प्राप्त होगी? शायद वह भी नहीं। पायथन-नॉट-एज़-ए-फास्ट-ए-सी मुद्दा नहीं है; यह सिर्फ इतना है कि यहां तक ​​कि PRNG- भारी कार्यक्रम जो वास्तव में उपयोगी हैं, वे BitGenerator में एक बड़ी राशि खर्च नहीं करते हैं। संभवतः उपलब्ध विकल्पों में से कोई भी पर्याप्त है।

मुझे अत्यधिक संदेह है कि विज़ुअल स्टूडियो के तहत PCG64 स्पीड पेनल्टी कुछ ऐसा है जिसे मिटाया नहीं जा सकता।

अप-थ्रेड मैं दिखाता हूं कि कैसे clang PCG64 को असेंबली में संकलित करता है जिसे हम 64-बिट MSVC के लिए चुरा सकते हैं, इसलिए नहीं, मुझे नहीं लगता कि 64-बिट विंडोज पर MSVC एक अचूक समस्या है।

क्या हो सकता है 32-बिट सिस्टम पर PCG64 ट्रिक हो, जिसमें से केवल 32-बिट विंडोज अभी भी हमारे लिए व्यावहारिक रूप से महत्वपूर्ण हो सकता है। उस मामले में यह MSVC के बारे में 32-बिट ISA के लिए खुद को प्रतिबंधित करने की तुलना में कम है।

क्या @Kellie ओटोबोनी [email protected] और मुझे लगता है कि है
यहां तक ​​कि मामूली आकार की समस्याओं के लिए, एमटी का राज्य स्थान लगभग बहुत छोटा है
वर्दी क्रमपरिवर्तन (n <2100) या वर्दी यादृच्छिक नमूने (n = 4e8, k = 1000)।

जो कि बूटस्ट्रैप से लेकर एमएमसीएमसी के क्रमपरिवर्तन परीक्षणों तक सब कुछ प्रभावित करता है।
इच्छित वितरण और वास्तविक के बीच का अंतर
वितरण मनमाने ढंग से बड़े हो सकते हैं (कुल भिन्नता दूरी
2)। यह बड़ा है और यह गंभीर है।

हमने एमटी को "सांख्यिकीय" कार्यों पर तोड़ने में कोई प्रयास नहीं किया है
दो तीन साल। मुझे पूरा यकीन है कि इसे तोड़ने का एक व्यवस्थित तरीका है
(चूंकि वितरण दूरी इतनी बड़ी है)।

चीयर्स,
फिलिप

सोम, 27 मई, 2019 को दोपहर 12:26 बजे रॉबर्ट कर्ने नोटिफिकेशन @github.com
लिखा था:

यह कहना कि गति का मामला विवादास्पद नहीं है।

मेरा सवाल है - क्या सुरक्षित है?

तर्क को लगातार लागू करें: "तेज क्या है"? मेरे पास एक महान विचार नहीं है
वास्तव में किन कार्यक्रमों में बिटगनर का प्रदर्शन होता है
एक महत्वपूर्ण अड़चन। अगर मैं एक बिटगैनेर का उपयोग करता हूं जो दो बार तेज है,
क्या मुझे अपनी पूर्ण गणना में 5% गति प्राप्त होगी? शायद वह भी नहीं।
पायथन-नॉट-एज़-ए-फास्ट-ए-सी मुद्दा नहीं है; यह सिर्फ इतना भी है
PRNG- भारी कार्यक्रम जो वास्तव में उपयोगी हैं, की एक बड़ी राशि खर्च नहीं करते हैं
BitGenerator में समय। संभवतः उपलब्ध विकल्पों में से कोई भी हो
पर्याप्त।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें
https://github.com/numpy/numpy/issues/13635?email_source=notifications&email_token=AANFDWKSMPAG3GFUCUFRXCDPXQYY5CNNMM4HPX3CHKY3NVWKWH52&hl=hi&hl=hi&hl=hi
या धागा म्यूट करें
https://github.com/notifications/unsubscribe-auth/AANFDWIDCPAJJ6DJ3RO332LPXQYVRANCNFSM4HPX3CHA
।

-
फिलिप बी। स्टार्क | एसोसिएट डीन, गणितीय और भौतिक विज्ञान |
प्रोफेसर, सांख्यिकी विभाग |
कैलिफोर्निया विश्वविद्यालय
बर्कले, सीए 94720-3860 | 510-394-5077 | आँकड़ों ।berkeley.edu/~stark |
@philipbstark

@pbstark मैं जो देखना चाहता हूं, वह समस्या का एक ठोस कार्यान्वयन है (कृत्रिम हो सकता है, लेकिन बहुत अधिक नहीं है) जिससे एमटी या 128-बिट PRNG विफल हो जाता है और cryptorandom काम होता है। क्या आप एक डेटासेट को इंगित कर सकते हैं जहां रेज़मैप्लिंग विधि 128-बिट PRNG के साथ गलत इंफ़ेक्शन देती है और cryptorandom साथ सही इंफ़ेक्शन देती है?

PCG64 में जाने से समस्या का आकार कम होता है,
चूंकि इसका राज्य स्थान MT से भी छोटा है। बेशक, यह कर सकता था
अभी भी "बेहतर" यादृच्छिकता उत्पन्न करता है कि यह एक उपसमूह का नमूना ले सकता है
एमटी से अधिक समान रूप से क्रमचय समूह। लेकिन इससे पहले ही टूट जाना है
500 10 चुनें, और 21 से पहले!।

चीयर्स,
फिलिप

सोम, 27 मई, 2019 को दोपहर 12:30 बजे रॉबर्ट कर्न नोटिफिकेशन @ithub.com
लिखा था:

मुझे अत्यधिक संदेह है कि विजुअल स्टूडियो के तहत PCG64 स्पीड पेनल्टी है
ऐसा कुछ जिसे मिटाया नहीं जा सकता।

अप-थ्रेड मैं दिखाता हूं कि क्लैंग ने पीसीजी 64 को असेंबली में कैसे संकलित किया है कि हम चोरी कर सकते हैं
64-बिट MSVC के लिए, इसलिए नहीं, मुझे नहीं लगता कि 64-बिट विंडोज पर MSVC एक है
दुर्गम समस्या।

क्या मुश्किल हो सकता है 32-बिट सिस्टम पर PCG64 है, जिनमें से केवल 32-बिट है
विंडोज अभी भी हमारे लिए व्यावहारिक रूप से महत्वपूर्ण हो सकता है। उस मामले में यह कम है
MSVC के बारे में 32-बिट ISA के लिए खुद को प्रतिबंधित करने के बारे में।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें
https://github.com/numpy/numpy/issues/13635?email_source=notifications&email_token=AANFDWJFCINQCYGFCI7ULI3PXLZGLA5CNFSM4HPX3CHKYYPPNPLEW8H8H8648648######### ।
या धागा म्यूट करें
https://github.com/notifications/unsubscribe-auth/AANFDWK6QTB65Z4TJU76XKTPXQZGLANCNFSM4HPX3CHA
।

-
फिलिप बी। स्टार्क | एसोसिएट डीन, गणितीय और भौतिक विज्ञान |
प्रोफेसर, सांख्यिकी विभाग |
कैलिफोर्निया विश्वविद्यालय
बर्कले, सीए 94720-3860 | 510-394-5077 | आँकड़ों ।berkeley.edu/~stark |
@philipbstark

मैं वास्तव में किसी भी मामले में तौलना करने के लिए PRNGs के बारे में पर्याप्त नहीं जानता, मैं सिर्फ पहले सांख्यिकीय गुणों पर ध्यान केंद्रित करना चाहता हूं (यदि जवाब है कि वे सभी बहुत अच्छे हैं, ठीक है)। एक बात जो मुझे आश्चर्यचकित करती है वह है अब के-आयामी समीकरण। क्या वर्तमान में हम PCG के वेरिएंट का उपयोग करते हैं जो MT की तुलना में यहाँ अच्छा करते हैं? (नॉनलाइनियर डायनामिक्स से आया, जो मुझे थोड़ा परेशान करता है, लेकिन मेरे पास PRNGs पर पर्याप्त अवलोकन नहीं है और मैं अगले 2 दिनों में इसे प्राप्त नहीं करूंगा ...

ऐसा लगता नहीं है कि वहाँ कई विंडोज 32-बिट उपयोगकर्ता हैं जो किनारे के प्रदर्शन को काटने के बारे में परवाह करते हैं। यह 64-बिट पर स्विच करने के लिए बहुत प्रयास नहीं करता है।

मैं इसे भी देखना चाहूंगा।

हम जानते हैं - गणित के आधार पर - कि कई बड़ी समस्याएं होनी चाहिए,
लेकिन हम अभी तक एक उदाहरण की ओर इशारा नहीं कर सकते।

एहतियाती सिद्धांत कहेंगे कि जब से हम जानते हैं कि बड़े हैं
समस्याओं और हम जानते हैं कि उन्हें कैसे रोका जाए (CS-PRNGs), हम भी ऐसा कर सकते हैं
डिफ़ॉल्ट रूप से, और यदि वे चुनते हैं तो उपयोगकर्ताओं को कम सतर्क रहने दें।

सोम, 27 मई, 2019 को दोपहर 12:39 बजे रॉबर्ट कर्ने नोटिफिकेशन @github.com
लिखा था:

@pbstark https://github.com/pbstark मैं जो देखना चाहूंगा वह एक ठोस है
समस्या का कार्यान्वयन (कृत्रिम हो सकता है, लेकिन बहुत अधिक नहीं)
एमटी या एक 128-बिट PRNG विफल हो जाता है और क्रिप्टोग्राफ़ी पर काम करेगा। क्या आप
एक कैमकॉर्डर को इंगित करें जहां रेज़मैप्लिंग विधि गलत है
128-बिट PRNG के साथ इंफ़ॉर्मेंस और क्रिप्टोग्राफ़र के साथ सही इंफ़ेक्शन?

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें
https://github.com/numpy/numpy/issues/13635?email_source=notifications&email_token=AANFDWODTUIPNMMOOJB6QP3BQP3QQ2FPA5CNFM4HPX3CHKYY3H3H3H3H3H3H3H3&hl=hi&hl=hi&hl=hi
या धागा म्यूट करें
https://github.com/notifications/unsubscribe-auth/AANFDWITAGQFZDQSIFNEHETPXQ2FPANCNFSM4HPX3CHA
।

-
फिलिप बी। स्टार्क | एसोसिएट डीन, गणितीय और भौतिक विज्ञान |
प्रोफेसर, सांख्यिकी विभाग |
कैलिफोर्निया विश्वविद्यालय
बर्कले, सीए 94720-3860 | 510-394-5077 | आँकड़ों ।berkeley.edu/~stark |
@philipbstark

k-equidistribution PRNG आउटपुट की एक सम्पूर्ण संपत्ति है
PRNG की अवधि। यह अच्छी बात है, लेकिन यह दूसरे के बारे में कुछ नहीं कहता है
यादृच्छिकता की विफलताओं के प्रकार, जैसे कि आउटपुट के सीरियल सहसंबंध।
यह अपेक्षाकृत कम बार है।

सोम, 27 मई, 2019 को दोपहर 12:48 बजे सेबेस्टियन बर्ग नोटिफिकेशन @github.com
लिखा था:

मैं वास्तव में किसी भी मामले में तौलना करने के लिए PRNGs के बारे में पर्याप्त नहीं जानता, मैं बस चाहता हूं
सबसे पहले सांख्यिकीय गुणों पर ध्यान केंद्रित किया जाना चाहिए (यदि उत्तर वह है
वे सभी बहुत अच्छे हैं, ठीक हैं)। एक बात जो मुझे आश्चर्य है कि अब है
k- आयामी संतुलन। क्या हम वर्तमान में PCG कहने के वेरिएंट का उपयोग करते हैं
MT की तुलना में यहाँ अच्छा है? (Nonlinear गतिशीलता से आ रहा है, कि
मुझे थोड़ा परेशान करता है, लेकिन मेरे पास PRNGs और I पर पर्याप्त अवलोकन नहीं है
अगले 2 दिनों में नहीं मिलेगा ...

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें
https://github.com/numpy/numpy/issues/13635?email_source=notifications&email_token=AANFDWPOBTPYHC3XBINQYA3PXQHHZA5CNFSM4HPX3CHKYY3p8H8H8648648&hl=hi&hl=hi
या धागा म्यूट करें
https://github.com/notifications/unsubscribe-auth/AANFDWOEB7KR2YJZWHRRAHLPXQ3HZANCNFSM4HPX3CHA
।

-
फिलिप बी। स्टार्क | एसोसिएट डीन, गणितीय और भौतिक विज्ञान |
प्रोफेसर, सांख्यिकी विभाग |
कैलिफोर्निया विश्वविद्यालय
बर्कले, सीए 94720-3860 | 510-394-5077 | आँकड़ों ।berkeley.edu/~stark |
@philipbstark

@pbstark MT कई सांख्यिकीय परीक्षण विफल करता है जो PCG (और अन्य जनरेटर) पास करता है।

@rkern

यदि कोई एमएसवीसी को रोर इंस्ट्रक्शन जेनरेट करना चाहता है, तो मुझे लगता है कि किसी को "_rotr64" आंतरिक का उपयोग करने की आवश्यकता है।

अनुकूलन के लिए भी कोई '/ O2' ध्वज पसंद कर सकता है।

इसे देखते हुए, यह वास्तव में इसे विधानसभा में लिखने के लिए सबसे अच्छा हो सकता है, अगर कोई पीसीजी 64 का उपयोग करना चाहता है।

@Pbstark के लिए , यहाँ पीसीजी -64 से कुछ आउटपुट अनजाने में एक बीज से अनजान है (वास्तव में, मैं आपको स्ट्रीम भी बताऊंगा, यह 0x559107ab8002ccda3b8daf9dbe4ed480 ):

  64bit: 0x21fdab3336e3627d 0x593e5ada8c20b97e 0x4c6dce7b21370ffc
     0xe78feafb1a3e4536 0x35a7d7bed633b42f 0x70147a46c2a396a0
  Coins: TTTHHTTTHHTHTTTTHTHHTTTTTHTTHHTTHHTHHTHHHHHHHHTTHHTTHHTHHHHHTHTHH
  Rolls: 5 3 5 2 5 3 1 6 6 5 4 4 5 5 5 6 2 3 5 3 2 3 2 5 6 2 4 6 2 3 4 6 3
  Cards: 5h 3h 3c 8d 9h 7s Kh Ah 5d Kc Tc 6h 7h 8s Ac 5c Ad Td 8c Qd 2h As
     8h 2d 3s 5s 4d 6d 2s Jd 3d 4h Ks 6s Qc Js Th 9d 9c Ts Jh 4c 2c 9s
     6c 4s 7c 7d Jc Qs Kd Qh

अब, मान लें कि आप एक और पीसीजी जनरेटर को बेतरतीब ढंग से चुने हुए बीज के साथ शुरू करते हैं। चलो 0xb124fedbf31ce435ff0151f8a07496d3 तर्क के लिए,

तो PCG-64 में एक ऐसा क्रम है जो वास्तव में वहाँ है, लेकिन, व्यावहारिक रूप से आप इसे कभी नहीं पाएंगे जब तक कि मैं आपको यह न बताऊं कि मुझे कहाँ देखना है। (और भी अधिक संभावनाएं होंगी यदि हम धारा को बदलते हैं।)

नियमित PCG वास्तव में शेक्सपियर प्ले के उत्पादन का शून्य मौका है; पीसीजी विस्तारित पीढ़ी योजना वास्तव में एक शेक्सपियर प्ले का उत्पादन कर सकती है, लेकिन कभी-कभी एक गैर-अंतर्विरोधी परिदृश्य में ऐसा करने की संभावना इतनी असीम है कि यह आवश्यक रूप से शून्य भी है। मेरी नजर में, एक संपत्ति में बहुत कम मूल्य है जिसका कोई व्यावहारिक परिणाम नहीं है।

(इसके अलावा, क्रिप्टोग्राफिक रूप से सुरक्षित PRNGs को k-dimensionally equidistributed होने की गारंटी नहीं है, और न ही वे उन लोगों के लिए एक जादू की गोली हैं जो PRNG चाहते हैं जो हर संभव अनुक्रम उत्पन्न कर सकते हैं। जिस क्षण आप PRNG से अधिक बिट्स चाहते हैं, जितना कि इसके अनुसार होता है। बीज और भंडार इसके राज्य के रूप में, आवश्यक रूप से कुछ बिट सीक्वेंस हैं जो उत्पन्न नहीं किए जा सकते हैं (प्रमाण: कबूतर-छेद सिद्धांत द्वारा) और। यदि आप अपने आप को बीज के रूप में उतने ही उत्पादन में सीमित करते हैं, जितना कि आप ' वास्तव में एक हैश फंक्शन की तलाश में है, या हो सकता है कि सिर्फ पहचान फ़ंक्शन अगर आपका बीज इनपुट वास्तव में यादृच्छिक है, PRNG नहीं है।)

जिज्ञासा से बाहर, मैंने aesctr.h का उपयोग करके AES काउंटर बिट जनरेटर को लपेटा, ns प्रति यादृच्छिक संख्या में समय:

+---------------------+--------------+----------+--------------+
|                     |   Xoshiro256 |    PCG64 |   AESCounter |
|---------------------+--------------+----------+--------------+
| 32-bit Unsigned Int |      3.40804 |  3.59984 |      5.2432  |
| Uniform             |      3.71296 |  4.372   |      4.93744 |
| 64-bit Unsigned Int |      3.97516 |  4.55628 |      5.76628 |
| Exponential         |      4.60288 |  5.63736 |      6.72288 |
| Normal              |      8.10372 | 10.1101  |     12.1082  |
+---------------------+--------------+----------+--------------+

अच्छा काम, @bashtage।

कुछ बातों को ध्यान में रखते हुए, एक यह है कि विशिष्ट एईएस निर्देश आर्किटेक्चर में भिन्न हो सकते हैं और सभी सक्रिय रूप से उपयोग किए जाने वाले सीपीयू में मौजूद नहीं हैं, इस प्रकार एक (धीमा) फालबैक पथ होने की आवश्यकता है।

इसके अलावा, यह तुलना करने के लिए एक सेब का एक सा है। विशेष निर्देशों का उपयोग करने के अलावा, एईएस कोड लूप अनरोलिंग से अपनी गति का एक हिस्सा प्राप्त कर रहा है - यह वास्तव में ब्लॉकों में संख्या पैदा कर रहा है और फिर उन्हें पढ़ रहा है। अनियंत्रित होने से संभावित रूप से किसी भी PRNG को गति मिल सकती है। FWIW, @lemire में वास्तव में PCG का वेक्टरकृत संस्करण है जो एक ही बार में कई आउटपुट उत्पन्न करने के लिए AVX निर्देशों का उपयोग करता है।

मुझे यह देखने दें कि क्या मैं सर्वसम्मति के कम से कम एक बिंदु को संक्षेप में प्रस्तुत कर सकता हूं: हम सभी सहमत हैं कि सुन्न को उस बारे में राय दी जानी चाहिए जिसके बारे में BitGenerator एल्गोरिदम का उपयोग करना है, और दूसरों पर एक BitGenerator बढ़ावा देना है।

मुझे एक "नो डिफॉल्ट" विकल्प से स्केच करने पर एक और छुरा लगाने की अनुमति दें जो उस सहमति से सहमति देता है और कुछ अन्य मुद्दों से कुछ मुद्दों से बचा जाता है। यदि यह कोई कर्षण नहीं मिलता है, तो मैं इसके बारे में बंद कर दूंगा।

"नो डिफॉल्ट" विकल्प से मेरा वास्तव में मतलब था "नो डिफॉल्ट डिफॉल्ट"। अभी भी ऐसे तरीके हैं जो हम एपीआई को डिज़ाइन कर सकते हैं जैसे कि एक वरीयता प्राप्त Generator प्राप्त करने का सबसे सुविधाजनक तरीका वह है जिसे हम नामित करते हैं PRNG। उदाहरण के लिए, मान लें कि हम _d't_ में BitGenerator एल्गोरिदम की पूरी श्रृंखला शामिल है। हम सामान्य रूप से सुन्न को न्यूनतम रखने और scipy और अन्य तीसरे पक्ष के पुस्तकालयों को पूरा करने की कोशिश करते हैं, और यहां ऐसा करना एक अच्छा विचार हो सकता है। वर्तमान वास्तुकला की सुंदरता यह है कि यह हमें उन BitGenerator को अन्य पुस्तकालयों में स्थानांतरित करने की अनुमति देता है। तो चलिए कहते हैं कि हम केवल MT19937 RandomState और BitGenerator करते हैं, जिसे हम लोगों को उपयोग करने के लिए पसंद करते हैं। तर्क के लिए, मान लें कि Xoshiro256 । चलो बनाने के Generator.__init__() निर्माता एक की आवश्यकता होती है BitGenerator । लेकिन साथ ही, आइए एक कार्य को परिभाषित करें np.random.xoshiro256_gen(seed) जो कवर के तहत Generator(Xoshiro256(seed)) लौटाता है। हम उस सुविधा फ़ंक्शन को एक वरीयता प्राप्त Generator प्राप्त करने के तरीके के रूप करते हैं ।

अब कुछ रिलीज को तेजी से आगे बढ़ाएं। मान लीजिए कि हमने PCG64 , ThreeFry , आदि को random-tng या scipy या किसी अन्य पैकेज से धकेल दिया और उनमें से एक लोकप्रिय हो गया अतिरिक्त सुविधाएँ या नई सांख्यिकीय खामियां Xoshiro256 में पाई जाती हैं। हम तय करते हैं कि हम सुपी की राय को अपडेट करना चाहते हैं जिसके बारे में BitGenerator लोगों को PCG64 उपयोग करना चाहिए। फिर हम जो कुछ भी करते हैं वह PCG64 BitGenerator क्लास है और np.random.pcg64_gen(seed) फ़ंक्शन जोड़ते हैं। हम यह कहते हुए np.random.xoshiro256_gen(seed) का एक अवमूल्यन चेतावनी जोड़ते हैं कि यह अब पसंदीदा एल्गोरिथ्म नहीं है: हम अनुशंसा करते हैं कि नए कोड का उपयोग np.random.pcg64_gen(seed) होना चाहिए, लेकिन Xoshiro256 एल्गोरिदम का उपयोग जारी रखने के लिए चेतावनी, उन्हें स्पष्ट रूप से Generator(Xoshiro256(seed)) उपयोग करना चाहिए।

मुझे लगता है कि यह कुछ समस्याओं से बचता है जो मुझे "अनाम" एपीआई (यानी Generator(seed) , Generator(DefaultBitGenerator(seed)) , np.random.default_gen(seed) ) के साथ होती हैं। हम निरंतरता में अब और पसंदीदा एल्गोरिदम का समर्थन कर सकते हैं। जब हम अपनी राय बदलते हैं, तो हमें अपनी राय को "पसंदीदा" बनाने की ज़रूरत नहीं होगी। क्योंकि हम वास्तविक नामों का उपयोग संस्करण संख्याओं के बजाय चीजों को अलग करने के लिए करते हैं, आप हमेशा पुराने परिणामों को पुन: उत्पन्न करने के लिए कोड को अपडेट करना जानते हैं (यदि आप किसी कारण से हानिरहित चेतावनी नहीं दे सकते हैं)। तुम भी कोई सिद्ध या दर्ज संख्या जारी संख्या के साथ कोड उठा सकते हैं और उस अद्यतन करते हैं। एक ही समय में, एल्गोरिदम की संख्या को पूर्णतम तक सीमित करके और लाइब्रेरी के साथ काम करने के लिए सबसे अच्छा अभ्यास _easiest_ तरीका बनाने से, हम प्रभावी रूप से सुन्न की राय व्यक्त करने में सक्षम हैं।

वह कैसा लगता है? हमें पहले रिलीज के लिए उस BitGenerator लिए ठोस विकल्प बनाने में अभी भी बहुत प्रयास करना चाहिए। यह अभी भी परिणामी है।

ऐसा लगता नहीं है कि वहाँ कई विंडोज 32-बिट उपयोगकर्ता हैं जो किनारे के प्रदर्शन को काटने के बारे में परवाह करते हैं। यह 64-बिट पर स्विच करने के लिए बहुत प्रयास नहीं करता है।

मैं सहमत हूँ। Win32 पर PCG64 साथ मुद्दा केवल प्रदर्शन है (और एक है कि हम शायद कुछ प्रयास के साथ पर्याप्त कर सकते हैं), क्या आप सहमत होंगे कि यह एक अवरोधक नहीं है?

यदि कोई एमएसवीसी को रोर इंस्ट्रक्शन जेनरेट करना चाहता है, तो मुझे लगता है कि किसी को "_rotr64" आंतरिक का उपयोग करने की आवश्यकता है।

अनुकूलन के लिए भी कोई '/ O2' ध्वज पसंद कर सकता है।

धन्यवाद! @imneme ने मेरे लिए इन सभी भूलों को इंगित किया। :-)

@seberg क्या आपके पास अपने क्षेत्र से कोई प्रशंसा पत्र है जो आपके k । दूसरों की अलग-अलग राय हो सकती है, और शायद आपके क्षेत्र में कुछ विशिष्ट मुद्दे हैं जिनके बारे में मुझे जानकारी नहीं है। यदि ऐसा है, तो विशिष्ट समाधान उपलब्ध हैं!

जिज्ञासा से बाहर, मैंने aesctr.h का उपयोग करके एईएस काउंटर बिट जनरेटर को लपेट दिया

मैं गलत हो सकता है, लेकिन मुझे विश्वास नहीं है कि यह @pbstark की चिंताओं के साथ मदद करेगा। AES-CTR एक CS-RNG है, लेकिन सभी CS-RNG में बड़ी अवधि नहीं है, जिसकी आवश्यकता (सैद्धांतिक रूप से) सभी संभव k! k लिए सभी भुगतानों तक पहुँचने में सक्षम होगी। काउंटर अभी भी एक 128-बिट संख्या है और एक बार यह रोल करने के बाद, आप अवधि के अंत तक पहुँच चुके हैं। @pbstark बहुत बड़ी अवधि के PRNGs की वकालत कर रहा है, जिनमें से ज्यादातर CS-RNG के रूप में होते हैं।

सामान्य तौर पर, समानता पर मेरा दृष्टिकोण यह है कि आप आमतौर पर PRNG के समीकरण को PRNG के राज्य आकार द्वारा अनुमत अधिकतम के करीब होना चाहते हैं।

हालाँकि कुछ लोग अधिकतम संपत्ति को एक वांछनीय संपत्ति मानते हैं, लेकिन इसे एक दोष भी माना जा सकता है (और वहाँ बहुत कुछ कहते हुए कागजात हैं)। यदि हमारे पास एक _k_-बिट PRNG है और प्रत्येक _k_-bit अनुक्रम ठीक एक बार होता है, तो यह जन्मदिन की समस्या का उल्लंघन करेगा जो कहता है कि हम 2 ^ (k / 2) आउटपुट के बाद एक आउटपुट दोहराने की उम्मीद करेंगे। ( मैंने इन विचारों के आधार पर एक जन्मदिन समस्या सांख्यिकीय परीक्षण लिखा है । इसने सही ढंग से स्प्लिटमिक्स में किसी भी दोहराव की सांख्यिकीय अनुपस्थित अनुपस्थिति का पता लगाया, 64-बिट-आउटपुट 64-बिट PRNG, और Xoroshiro64 +, 32-बिट-आउटपुट 64-बिट -स्टेट 2-डिमैन्सली-इक्विस्टीजेड PRNG, दूसरों के बीच में।)

दिलचस्प है, हालांकि यह एक सांख्यिकीय परीक्षण लिखने के लिए बहुत व्यावहारिक है जो 64-बिट दोहराव (या बहुत अधिक दोहराता है - हम एक पॉइसन वितरण की उम्मीद कर रहे हैं) की कमी के लिए एक PRNG विफल हो जाएगा, यह एक परीक्षण लिखने के लिए व्यावहारिक रूप से _not_ व्यावहारिक है जो होगा सभी 64-बिट मानों के 36.8% की चूक का पता लगाने के लिए अगर हम कुछ भी नहीं जानते हैं जिसके बारे में छोड़ दिया गया है।

स्पष्ट रूप से कमी-प्रत्याशित दोष के परीक्षण के लिए _k_ बड़ा होने के रूप में चलाने के लिए अव्यावहारिक होना शुरू होता है, लेकिन जैसा कि हम बड़े और बड़े राज्य आकार (और अवधि) में आते हैं, जोड़ा आकार का मतलब है कि यह दिखाने के लिए दोनों अव्यावहारिक है एक अधिकतम समतुल्य PRNG को दोहराने में नाकाम रहने के लिए त्रुटिपूर्ण है और समान रूप से अव्यवहारिक है यह दिखाने के लिए कि एक गैर-अधिकतम समतुल्य PRNG कुछ _k_-बिट अनुक्रमों (एक सांख्यिकीय रूप से प्रशंसनीय तरीके से) को दोहराने और दूसरों को पूरी तरह से छोड़ने के लिए त्रुटिपूर्ण है। दोनों ही मामलों में, PRNG हम दोनों को अलग करने में सक्षम होने के लिए बहुत बड़ा है।

मैं इसे भी देखना चाहूंगा। हम जानते हैं - गणित के आधार पर - कि कई बड़ी समस्याएं होनी चाहिए, लेकिन हम अभी एक उदाहरण की ओर इशारा नहीं कर सकते। एहतियाती सिद्धांत यह कहेंगे कि चूंकि हम जानते हैं कि बड़ी समस्याएं हैं और हम जानते हैं कि उन्हें कैसे रोका जाए (CS-PRNGs), हम डिफ़ॉल्ट रूप से ऐसा कर सकते हैं, और यदि वे चुनते हैं तो उपयोगकर्ताओं को कम सतर्क रहने दें।

मेरा कहना है कि मैं तर्क और सबूतों की इस पंक्ति से सहमत नहीं हूँ। जैसे, मैं सुन्न उपयोगकर्ताओं के सामने खड़े होने में सहज महसूस नहीं करता और उन्हें बताता हूं कि उन्हें इस कारण से स्विच करना चाहिए। मैं इस कथन का बचाव करने के लिए अप्रसन्न हूं, यही वजह है कि मैं इन उदाहरणों के लिए कह रहा हूं। वे प्रेरक होंगे और मुझे इस पद की रक्षा के लिए तैयार करेंगे जो आप सुझा रहे हैं कि हम लेते हैं।

बहुत सारी संपत्तियाँ हैं जिनके द्वारा परिमित PRNG सही RNGs से कम हो जाते हैं। और बहुत सारी संगणनाएँ हैं जो हम करना चाहते हैं, सैद्धांतिक रूप से, सच्चे RNG के उन गुणों पर निर्भर करते हैं (या कम से कम, हमने कठोरता से साबित नहीं किया है कि हम उन्हें कितना आराम दे सकते हैं)। लेकिन उनमें से बहुत से लघु-चित्रण केवल वास्तविक गणनाओं के परिणामों पर बहुत कम, व्यावहारिक रूप से ध्यान देने योग्य प्रभाव डालते हैं। ये उल्लंघन निंदात्मक नहीं हैं, सभी-या-कुछ नहीं, गो / नो-गो प्रकार की चीजें हैं। उनका प्रभाव आकार है, और हम प्रभाव को कम या ज्यादा सहन कर सकते हैं।

आप दिखाते हैं, निश्चित रूप से, कि निश्चित आकार के PRNG समान रूप से कुछ k लिए सभी k! परित्याग उत्पन्न नहीं कर सकते हैं। यह कदम जो मुझे याद आ रहा है, वह यह है कि उन सभी क्रमपरिवर्तन को उत्पन्न करने में असफलता एक ठोस संगणना को कैसे प्रभावित करती है जिसे मैं प्रदर्शन करने में रुचि रखता हूं। मुझे वह परीक्षण याद आ रहा है जिसे आप सुझाएंगे कि हम PractRand या TestU01 जोड़ते हैं जो लोगों को समस्या प्रदर्शित करेगा।

विश्लेषण की एक पंक्ति जो मुझे @imneme के PCG पेपर से बहुत जानकारीपूर्ण लगी, वह थी प्रत्येक PRNG के कई छोटे-छोटे राज्य संस्करण प्राप्त करना और यह देखना कि वे TestU01 को विफल करने के लिए कहाँ शुरू हुए। यह ऑर्डिनरी आर्किटेक्चर की तुलना करने के लिए हमें सिर्फ कहने के बजाय, ऑल-ऑल-नथिंग, "एक्स PRNG पास" या विफल होने के कुछ तरीके देता है। यह हमें यह अनुमान लगाने की सुविधा देता है कि हमारे पास उपयोग में राज्य के आकार में कितना हेडरूम है (जो कुछ नमूनों की बड़ी संख्या में टेस्टयू 01 पास करते हैं)। क्या ऐसी ठोस गणनाएँ हैं जो आप कर सकते हैं कि 8-बिट PRNGs के साथ कोई समस्या प्रदर्शित हो? 16-बिट PRNGs? फिर हम देख सकते हैं कि क्या यह नया परीक्षण हमें PRNG के बारे में पहले की तुलना में TestU01 / PractRand की जानकारी देगा जो वर्तमान में है। और वह सुपर-सहायक होगा।

दूसरी ओर, अगर PRRG से _more_ डेटा लिया गया है, तो प्रैक्ट्रेड में परीक्षण के वर्तमान सूट के लिए छोटे PRNG की विफलता बिंदु की तुलना में इन क्रमपरिवर्तन पर आधारित विफलता दिखाने के लिए, तो मैं यह निष्कर्ष निकालूंगा कि यह मुद्दा व्यावहारिक नहीं है चिंता, और हम "पास प्रैक्ट्रेंड" का उपयोग कर सकते हैं कि क्या एक अच्छा प्रॉक्सी मेरी गणना पर व्यावहारिक प्रभाव पड़ेगा या नहीं।

लेकिन जब तक मेरे हाथ में एक कार्यक्रम है जिसे मैं चला सकता हूं और लोगों को समस्या दिखा सकता हूं, मैं इस आधार पर सीएस-पीआरएनजी के लिए जोर नहीं दे रहा हूं। मैं पसंद को समझाने में असमर्थ हूँ।

उन लोगों के लिए जो मांग करते हैं कि जब 32 आइटम, सभी 32 फेरबदल! फेरबदल (यानी, सभी 263130836933693530167218012160000000 उनमें से) एक PRNG के बजाय उदार होना चाहिए, जो उन 32 से केवल एक यादृच्छिक नमूना प्रदान करता है! फेरबदल, मैं वास्तव में कहूंगा कि यदि आप बड़ी संख्या की मांग करने जा रहे हैं, तो आप अभी बहुत बड़ा नहीं सोच रहे हैं।

मैं इस प्रकार (स्पष्ट रूप से) यह दावा करूंगा कि जिन आदेशों में फेरबदल किया गया है, वह पूर्व निर्धारित नहीं होना चाहिए! स्पष्ट रूप से आपको मांग करनी चाहिए कि यह सभी 32 को आउटपुट देता है! सभी संभावित आदेशों में फेरबदल - (32)! आपको क्या चाहिए! बेशक, इसके लिए राज्य के लिए 3.8 × 10 ^ 18 एक्साबाइट की आवश्यकता होगी और इनिशियलाइज़ करने के लिए समान मात्रा में एन्ट्रापी, लेकिन यह निश्चित रूप से यह जानने के लायक है कि सब कुछ है।

... हम यह कहते हुए np.random.xoshiro256_gen(seed) एक अवमूल्यन चेतावनी जोड़ते हैं कि यह अब पसंदीदा एल्गोरिथ्म नहीं है: हम अनुशंसा करते हैं कि नए कोड को np.random.pcg64_gen(seed) उपयोग करना चाहिए, लेकिन चेतावनियों के बिना Xoshiro256 एल्गोरिथ्म का उपयोग जारी रखना चाहिए। उन्हें स्पष्ट रूप से Generator(Xoshiro256(seed)) उपयोग करना चाहिए

यह अभी भी उपयोगकर्ताओं को दोनों के साथ एक वंचित और अजीब-अजीब नामों के साथ परेशान कर रहा है जिनके बारे में वे वास्तव में जानना नहीं चाहते हैं।

एनईपी कहता है: दूसरी, नई विशेषताओं को पेश करने या प्रदर्शन में सुधार के लिए धारा-अनुकूलता को तोड़ना सावधानी के साथ अनुमति दी जाएगी।

यदि हमारे डिफ़ॉल्ट को अपडेट करने के लिए एक अच्छा पर्याप्त कारण है, तो ऐसा करना और उन उपयोगकर्ताओं के लिए बिट-फॉर-बिट बिटकॉइनबिलिटी को तोड़ना, जो स्पष्ट रूप से एक एल्गोरिथ्म निर्दिष्ट नहीं करते थे, बेहतर विकल्प imho है (और एक जिसे आप पहले से बहस कर रहे थे)।

"नो डिफॉल्ट" विकल्प से मेरा वास्तव में मतलब था "नो डिफॉल्ट डिफॉल्ट"।

तो क्या आपकी बात यह है कि आप _want_ उपयोगकर्ता PRNG का नाम जानने के लिए उपयोग कर रहे हैं?

इसे उपयोगकर्ताओं के दृष्टिकोण से देखें। उन्हें np.random.rand & co से np.random.RandomState() और फिर विधियों का उपयोग करना कठिन है। अब हम एक बेहतर प्रणाली शुरू करने जा रहे हैं, और जो कुछ भी उन्हें देखने को मिलता है वह np.random.xoshiro256_gen() ? यह एक प्रमुख प्रतिगमन प्रयोज्य-वार होगा।

तो क्या आपकी बात यह है कि आप _want_ उपयोगकर्ता PRNG का नाम जानने के लिए उपयोग कर रहे हैं?

नहीं, यह default_generator(seed) " @shoyer का version तर्क)।

धारा अनुकूलता बनाए रखना (जो एनईपी 19 डिस्क्लिम्स है) एपीआई ब्रेकेज के लिए माध्यमिक है। अलग-अलग BitGenerator s के पास अलग-अलग प्रभावी API होते हैं, जो उनके फीचर-सेट्स (सेलेबल, जंपहेड, प्राथमिक रूप से, हालांकि अन्य हो सकते हैं, यह इस बात पर निर्भर करता है कि PRNG कितना पैरामीटर योग्य है)। इसलिए हमारे डिफ़ॉल्ट PRNG चयन में कुछ बदलाव वास्तव में कोड को तोड़ देंगे (यानी अब नहीं चलता है या अब सही ढंग से नहीं चलता है), न केवल बाहर आने वाले मूल्यों को बदल दें।

उदाहरण के लिए, मान लें कि हम पहले PCG64 चुनते हैं। इसमें १२ It-बिट राज्य, २ ^ १२ sett बसने योग्य धाराएँ, और औजार जम्पहेड हैं; अच्छा और पूर्ण विशेषताओं वाला। इसलिए लोग default_generator(seed, stream=whatever) लिखना शुरू करते हैं। अब कहते हैं कि भविष्य के काम में कुछ प्रमुख सांख्यिकीय दोष पाए जाते हैं जो हमें कुछ और करने के लिए स्विच करना चाहते हैं। अगला PRNG जिसे हम डिफ़ॉल्ट के रूप में बढ़ावा देते हैं, उसके पास होना चाहिए = = 128-बिट स्थिति (आसान; मैं एक सामान्य-उद्देश्य डिफ़ॉल्ट के रूप में कुछ भी छोटा नहीं होगा), जम्पहेड (हार्ड!),> = 2 ^ 127 बसने योग्य धाराएँ (हू! लड़का!), पहले से ही कोड में default_generator() के उपयोग को नहीं तोड़ने के लिए। अब शायद हम उस शाफ़्ट के साथ रह सकते हैं।

@shoyer ने सुझाव दिया कि हो सकता है कि हम डिफ़ॉल्ट BitGenerator हमेशा जानबूझकर केवल कम से कम-आम-भाजक सुविधाओं के लिए शौकीन हों । इससे काम बन जाएगा! लेकिन यह भी @charris करना चाहते हैं जैसे समानांतर धाराओं समस्या को हल करने के लिए चूक जाएगा।

अब हम एक बेहतर प्रणाली शुरू करने जा रहे हैं, और जो कुछ भी उन्हें देखने को मिलता है वह np.random.xoshiro256_gen() ? यह एक प्रमुख प्रतिगमन प्रयोज्य-वार होगा।

यदि अजीब-अजीब नाम समस्या है, तो मैं एक अधिक मैत्रीपूर्ण, सामान्य नाम का उपयोग करके खुश होऊंगा, जब तक कि नीति अन्यथा एक ही है (हम एक नया फ़ंक्शन जोड़ते हैं और पुराने के बारे में चेतावनी देना शुरू करते हैं)। मुझे लगता है कि समकक्ष होगा। हमें ऐसा अक्सर नहीं करना चाहिए।

यदि हम शाफ़्ट के साथ रहने और version तंत्र से बचने का निर्णय लेते हैं तो भी मैं ठीक हूँ।

मेरा एक "डिफ़ॉल्ट" यह है कि हम इसे कार्यान्वयन विवरण के रूप में छोड़ सकते हैं, ताकि Generator() हमेशा काम करें। मैं इसे सावधानी के एक मजबूत नोट के साथ पार्ले करूँगा कि हमेशा प्रतिलिपि प्रस्तुत करने योग्य परिणाम (जेनरेटर में बदलाव के लिए) पाने का एकमात्र तरीका वाक्यविन्यास Generator(BitGenerator(kwarg1=1,kwargs2=b,...))

यह कार्यान्वयन विवरणों को छिपाना व्यावहारिक नहीं है क्योंकि राज्य तक पहुंच आवश्यक है।

इसका विकल्प यह है कि किसी भी अन्य कार्य की तरह इसका इलाज किया जाए - और यादृच्छिक पीढ़ी सामान्य रूप से - और एक मानक पदावन चक्र के माध्यम से जाना चाहिए बदलने के लिए एक अनिवार्य आवश्यकता होनी चाहिए। यह उन उपयोगकर्ताओं को कभी भी प्रभावित नहीं करेगा जो सही तरीके से काम करते हैं, और डॉक्स में पर्याप्त चेतावनी के साथ कम से कम बड़ी परियोजनाओं के बीच इस पर एक सभ्य हिट दर प्राप्त करना संभव हो सकता है। यहाँ मैं जो सुझाव दे रहा हूँ, वह यह है कि नई API के बारे में सोचते समय स्ट्रीम कम्पेटिबिलिटी गारंटी को कभी भी भुलाया जा सकता है।

# 13650 में @bashtage मैं करने के लिए उपयोग की अनुमति नहीं Generator().bit_generator एक तरीका है कि अभी भी करने के लिए कोई सीधी पहुँच के साथ नमकीन बनाना करने की अनुमति देता में state । यह थोड़ा पुनर्लेखन test_pickle को इस तरह से पास करता है जिससे अजगर Thread s का उपयोग कर सके।

मेरा सवाल है - क्या सुरक्षित है? विभिन्न गुणों के साथ अर्ध-यादृच्छिकता की अलग-अलग डिग्री है। अब तक मैंने किसी को ठोस उदाहरण देते हुए नहीं देखा, न ही यहां अन्य मुद्दों, पीआर या थ्रेड्स में।

कुछ _N_ (512, 1024) के लिए "_N_ GiB पर प्रैक्टिस पास करता है " यदि आप एक स्पष्ट उज्ज्वल-रेखा पास / असफल मानदंड चाहते हैं तो यह एक निष्क्रिय परिभाषा है। यदि आप एक ठोस उदाहरण चाहते हैं, तो एमटी और उसके वेरिएंट को इस मानदंड के आधार पर बाहर रखा जाएगा। हमने इस कारण पीआर से कुछ पुराने जोशीरो परिवार के सदस्यों को भी हटा दिया।

यदि आप सांख्यिकीय गुणवत्ता का अधिक परिष्कृत दृष्टिकोण चाहते हैं, जो एल्गोरिदम की क्रमिक रैंकिंग के लिए अनुमति देता है, तो मैं आपको @imneme के PCG पेपर की धारा 3 की सिफारिश करता हूं, जिसमें एल्गोरिदम के कम-राज्य वेरिएंट के प्रोफाइल का उपयोग किया जाता है कि कैसे एक विचार प्राप्त करने के लिए अधिक "हेडरूम" प्रत्येक पूर्ण एल्गोरिथ्म में है। यह काफी समान है कि क्रिप्टोग्राफ़र विभिन्न क्रिप्टो एल्गोरिदम का विश्लेषण कैसे करते हैं। जांच की जा रही किसी भी व्यवहार्य विकल्प को "टूटी नहीं जा रही" की आधारभूत कसौटी को पारित करना होगा, लेकिन इससे आपको दावेदारों को रैंक करने में मदद नहीं मिलेगी। इसके बजाय, वे दावेदार एल्गोरिदम के कम-राउंड संस्करणों का निर्माण करते हैं और देखते हैं कि इसे तोड़ने से पहले आपको कितना कम करना होगा। यदि N-1 में एक N- राउंड पूर्ण एल्गोरिथ्म टूट गया है, तो बहुत कम हेडरूम है, और क्रिप्टोग्राफ़र शायद इससे बचेंगे। इसी तरह, अगर एक 128-बिट BitGenerator प्रैक्ट्रैंड से गुजरता है, लेकिन इसका 120-बिट संस्करण विफल रहता है, तो यह संभवतः बहुत जोखिम भरा है।

@ मट्टीप वाजिब लगता है। हालांकि किसी ने कहीं

import gc
state = [o for o in gc.get_objects() if 'Xoshiro256' in str(o)][0].state

अगर वे चाहते हैं कि गहराई से, यह ठीक है। मैं सिर्फ गैर-विशेषज्ञ उपयोगकर्ता की मदद करना चाहता हूं

यह थोड़ा पुनर्लेखन test_pickle को इस तरह से पास करता है जिससे अजगर Thread s का उपयोग कर सके।

यह ध्यान देने योग्य है कि यह एक उत्कृष्ट मुद्दा है (# 9650) - आदर्श रूप से Generator() बच्चे के थ्रेड में फिर से दिखेंगे। IIRC यह केवल पायथन> = 3.7 में व्यावहारिक है

मेरा एक "डिफ़ॉल्ट" यह है कि हम इसे कार्यान्वयन विवरण के रूप में छोड़ सकते हैं, ताकि Generator() हमेशा काम करें। मैं इसे सावधानी के एक मजबूत नोट के साथ पार्ले करूँगा कि हमेशा प्रतिलिपि प्रस्तुत करने योग्य परिणाम (जेनरेटर में बदलाव के लिए) पाने का एकमात्र तरीका वाक्यविन्यास Generator(BitGenerator(kwarg1=1,kwargs2=b,...))

दो प्रकार के प्रजनन योग्यता हैं जिन्हें हमें अलग करने की आवश्यकता है। एक यह है कि मैं एक ही बीज के साथ दो बार अपना कार्यक्रम चलाता हूं और समान परिणाम प्राप्त करता हूं। हमें समर्थन करने की जरूरत है। दूसरे को खसखस ​​के संस्करणों में प्रतिलिपि प्रस्तुत करने योग्य है, जिसे हमने घोषित किया है, कम से कम सख्त अर्थ में।

तर्क-कम- Generator() , यानी "मुझे एक मनमाने ढंग से PRNG दें कि सुन्न की सिफारिश करें" प्राथमिक उपयोग का मामला नहीं है। इसमें बहुत अधिक समर्थन की आवश्यकता नहीं है। "मुझे PRNG दीजिए जो _this_ बीज के साथ सुन्न की सिफारिश करता है", और वह है जिसके लिए हम विकल्पों पर चर्चा कर रहे हैं। हमें अंकुरित PRNG प्राप्त करने के तरीके पर एक राय व्यक्त करने के लिए सुन्नत के लिए एक रास्ता चाहिए, और इस तरह से उपयोगकर्ताओं के लिए आसान और सुविधाजनक होना चाहिए (अन्यथा वे इसका उपयोग नहीं करेंगे)। I _like_ एल्गोरिथ्म का नामकरण (एक अधिक सुविधाजनक फ़ंक्शन के माध्यम से), लेकिन @rgommers को लगता है कि यह एक कदम बहुत दूर है, और मुझे उससे सहानुभूति है।

तर्क-कम जेनरेटर (), यानी "मुझे एक मनमाने ढंग से वरीयता प्राप्त PRNG दें जो कि खस्ता सिफारिश करता है" प्राथमिक उपयोग का मामला नहीं है। इसमें बहुत अधिक समर्थन की आवश्यकता नहीं है। "मुझे PRNG दें जो इस बीज के साथ सुन्न की सिफारिश करता है", और वह है कि हम किस विकल्प के लिए चर्चा कर रहे हैं। हमें अंकुरित PRNG प्राप्त करने के तरीके पर एक राय व्यक्त करने के लिए सुन्नत के लिए एक रास्ता चाहिए, और इस तरह से उपयोगकर्ताओं के लिए आसान और सुविधाजनक होना चाहिए (अन्यथा वे इसका उपयोग नहीं करेंगे)। मुझे एल्गोरिथ्म का नामकरण पसंद है (यद्यपि अधिक सुविधाजनक फ़ंक्शन के माध्यम से), लेकिन @rgommers को लगता है कि यह एक कदम बहुत दूर है, और मुझे उससे सहानुभूति है।

मैं तर्क दूंगा कि उपयोगकर्ता वास्तव में अच्छे बीज प्रदान करने के लिए बीमार हैं। उदाहरण के लिए, कितने उपयोगकर्ता Mersenne Twister को बीज बनाने का सही तरीका जानते हैं? यह उतना आसान नहीं है जितना आपको लगता है - यदि आप इसे 624 यादृच्छिक 32-बिट पूर्णांक (19937 बिट्स राज्य प्रदान करने के लिए) नहीं खिला रहे हैं, तो आप इसे गलत कर रहे हैं।

इसलिए वास्तव में मैं कहूंगा कि उपयोगकर्ता के लिए प्रतिलिपि प्रस्तुत करने योग्य परिणाम प्राप्त करने का सही तरीका PRNG बनाना है (बीज प्रदान किए बिना, यह अच्छी तरह से स्वचालित रूप से बोया जाना चाहिए) और फिर इसे अचार करें।

यदि चर्चा केवल सही तरीके के बारे में है तो मैं इसके लिए हूं
Generator(BitGenerator(**kwargs)) क्योंकि यह केवल द्वारा उपयोग किया जाएगा
semiaware उपयोगकर्ता जो पुन: उत्पन्न करने की परवाह करते हैं।

मुझे लगता है कि यह Generator() मामलों के लिए उपयोग किया जाने वाला डिफ़ॉल्ट है
माना गया विकल्प के रूप में कई के रूप में व्याख्या की और इसलिए इसे एक के रूप में लें
बीज रूप का उपयोग करते समय सिफारिश।

बस एक और बाहर फेंकने के लिए, एक वर्ग विधि Generator.seeded(seed[, bit_generator]) where bit generator is a string. This would allow the pattern of switching from one value to None to warn if the default was going to change, like lstsq. I would also only support a limited pallatte of but generators initially (i.e. 1). Doesn't make it easy to expose advanced features I suppose. In a perfect world it would use kwarg only to allow any keyword argument to be used which avoids most depreciation problems. Of course, this doesn't really need to be a class function, just सीडेड `।

Tue पर, 28 मई, 2019, 16:38 रॉबर्ट कर्न सूचनाएं @github.com ने लिखा:

"डिफॉल्ट" पर मेरा ध्यान यह है कि हम इसे एक कार्यान्वयन के रूप में छोड़ सकते हैं
विस्तार, ताकि जेनरेटर () हमेशा काम करे। मैं इसे एक साथ पार्ले करूंगा
मजबूत ध्यान दें कि हमेशा प्रजनन योग्य परिणाम प्राप्त करने का एकमात्र तरीका है
(जनरेटर में परिवर्तन तक) सिंटैक्स का उपयोग करना है
जेनरेटर (BitGenerator (kwarg1 = 1, kwargs2 = ख, ...))

दो प्रकार के प्रजनन योग्यता हैं जिन्हें हमें अलग करने की आवश्यकता है। एक है
मैं एक ही बीज के साथ दो बार अपना कार्यक्रम चलाता हूं और समान परिणाम प्राप्त करता हूं।
हमें समर्थन करने की जरूरत है। दूसरे के पार प्रजनन है
सुन्न के संस्करण, जिसे हमने घोषित किया है, कम से कम सबसे सख्त अर्थों में।

तर्क-कम जेनरेटर (), "मुझे एक मनमाने ढंग से वरीयता प्राप्त PRNG दे
numpy अनुशंसा करता है "प्राथमिक उपयोग का मामला नहीं है। इसे बहुत अधिक आवश्यकता नहीं है
सहयोग। "मुझे PRNG दें जो इस बीज के साथ सुन्न की सिफारिश करता है",
और हम किसके लिए विकल्पों पर चर्चा कर रहे हैं। हमें सुन्न करने के लिए एक रास्ता चाहिए
एक वरीयता प्राप्त PRNG प्राप्त करने के बारे में एक राय व्यक्त करें, और इस तरह से होना चाहिए
उपयोगकर्ताओं के लिए आसान और सुविधाजनक (या फिर वे इसका उपयोग नहीं करेंगे)। मुझे पसंद है
एल्गोरिथ्म का नामकरण (यद्यपि अधिक सुविधाजनक फ़ंक्शन के माध्यम से), लेकिन
@rgommers https://github.com/rgommers को लगता है कि यह एक कदम बहुत दूर है, और
मुझे उससे सहानुभूति है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें
https://github.com/numpy/numpy/issues/13635?email_source=notifications&email_token=ABKTSRKA4SSNW6XZEVFUMCDPXVW5W5A5CNFSM4HPX3CHKYYPPWW8H8H8646648&hl=hi&hl=hi
या धागा म्यूट करें
https://github.com/notifications/unsubscribe-auth/ABKTSROCMLHG6E6BLWI6TWDPXVGW5ANCNFSM4HPX3CHA
।

Tue पर, 28 मई, 2019, 16:38 रॉबर्ट कर्न सूचनाएं @github.com ने लिखा:

"डिफॉल्ट" पर मेरा ध्यान यह है कि हम इसे एक कार्यान्वयन के रूप में छोड़ सकते हैं
विस्तार, ताकि जेनरेटर () हमेशा काम करे। मैं इसे एक साथ पार्ले करूंगा
मजबूत ध्यान दें कि हमेशा प्रजनन योग्य परिणाम प्राप्त करने का एकमात्र तरीका है
(जनरेटर में परिवर्तन तक) सिंटैक्स का उपयोग करना है
जेनरेटर (BitGenerator (kwarg1 = 1, kwargs2 = ख, ...))

दो प्रकार के प्रजनन योग्यता हैं जिन्हें हमें अलग करने की आवश्यकता है। एक है
मैं एक ही बीज के साथ दो बार अपना कार्यक्रम चलाता हूं और समान परिणाम प्राप्त करता हूं।
हमें समर्थन करने की जरूरत है। दूसरे के पार प्रजनन है
सुन्न के संस्करण, जिसे हमने घोषित किया है, कम से कम सबसे सख्त अर्थों में।

तर्क-कम जेनरेटर (), "मुझे एक मनमाने ढंग से वरीयता प्राप्त PRNG दे
numpy अनुशंसा करता है "प्राथमिक उपयोग का मामला नहीं है। इसे बहुत अधिक आवश्यकता नहीं है
सहयोग। "मुझे PRNG दें जो इस बीज के साथ सुन्न की सिफारिश करता है",
और हम किसके लिए विकल्पों पर चर्चा कर रहे हैं। हमें सुन्न करने के लिए एक रास्ता चाहिए
एक वरीयता प्राप्त PRNG प्राप्त करने के बारे में एक राय व्यक्त करें, और इस तरह से होना चाहिए
उपयोगकर्ताओं के लिए आसान और सुविधाजनक (या फिर वे इसका उपयोग नहीं करेंगे)। मुझे पसंद है
एल्गोरिथ्म का नामकरण (यद्यपि अधिक सुविधाजनक फ़ंक्शन के माध्यम से), लेकिन
@rgommers https://github.com/rgommers को लगता है कि यह एक कदम बहुत दूर है, और
मुझे उससे सहानुभूति है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें
https://github.com/numpy/numpy/issues/13635?email_source=notifications&email_token=ABKTSRKA4SSNW6XZEVFUMCDPXVW5W5A5CNFSM4HPX3CHKYYPPWW8H8H8646648&hl=hi&hl=hi
या धागा म्यूट करें
https://github.com/notifications/unsubscribe-auth/ABKTSROCMLHG6E6BLWI6TWDPXVGW5ANCNFSM4HPX3CHA
।

प्रयोज्य दृष्टिकोण से, मुझे लगता है कि हमें वास्तव में Generator(seed) का समर्थन करने की आवश्यकता है। अन्यथा, एक विकल्प बनाने का सामना करना पड़ता है जिसे वे बनाने के लिए तैयार नहीं हैं, उपयोगकर्ता बस RandomState साथ छड़ी करने जा रहे हैं।

में डिफ़ॉल्ट बिट जनरेटर वर्ज़निंग के लिए Generator , हम इस्तेमाल कर सकते हैं bit_version=1 के बजाय version=1 , हालांकि मैं भी छोड़ने के साथ ठीक कर रहा हूँ version विचार। मुझे नहीं लगता कि उपयोगकर्ताओं को स्पष्ट रूप से बहुत बार बिट जनरेटर सेट करने की आवश्यकता होगी।

विशिष्ट उपयोग के मामलों को सुलझाने के लिए मेरी प्राथमिकता, जिन्हें विशेष जनरेटर सुविधाओं की आवश्यकता होती है, डिजाइन विवरणों को छिपाने वाले नए, सामान्य BitGenerator APIs होंगे। इन्हें या तो DefaultBitGenerator जोड़ा जा सकता है या नई कक्षाओं में डाला जा सकता है यदि उनके उपयोग में ट्रेडऑफ़, जैसे, ParallelBitGenerator ।

मैं निश्चित रूप से डिफ़ॉल्ट बिट जनरेटर को बदलने के कारण आरएनजी स्ट्रीम में भविष्य के परिवर्तनों के बारे में चेतावनी से बचना चाहूंगा। ये चेतावनी केवल उन अधिकांश उपयोगकर्ताओं के लिए शोर मचाएगी, जो इस तरह के विवरणों पर भरोसा नहीं करते हैं, लेकिन जिन्होंने जेनरेटर में अपने यादृच्छिक संख्या को अनायास बदलने से रोकने के लिए जनरेटर में seed सेट किया है।

उपयोगकर्ता केवल रैंडमस्टेट के साथ चिपके रहने वाले हैं।

यह ठीक है, वे शुरुआती अपनाने वाले नहीं हैं। मैं न्यूनतम संभव व्यवहार्य एपीआई के लिए कठिन (शायद बहुत कठिन?) धक्का दे रहा हूं, क्योंकि हम हमेशा एपीआई को चौड़ा कर सकते हैं लेकिन इसे सिकोड़ना अधिक कठिन है। Generator(Philox()) , Generator(seed(3)) और Generator(bit_version=1) बीच की बारीकियों को तब तक देखना थोड़ा कठिन है जब तक कि यह अंत उपयोगकर्ताओं के लिए नहीं निकल जाती।

चलो बिना Generator(seed) साथ पहला संस्करण प्राप्त करें और कुछ प्रतिक्रिया प्राप्त करें।

चलो बिना Generator(seed) साथ पहला संस्करण प्राप्त करें और कुछ प्रतिक्रिया प्राप्त करें।

ठीक है, मुझे यहाँ कोई गंभीर आपत्ति नहीं है। उस मामले में, हमें अभी के लिए भी पूर्ण BitGenerator को निर्दिष्ट करने की आवश्यकता हो सकती है।

इसलिए वास्तव में मैं कहूंगा कि उपयोगकर्ता के लिए प्रतिलिपि प्रस्तुत करने योग्य परिणाम प्राप्त करने का सही तरीका PRNG बनाना है (बीज प्रदान किए बिना, यह अच्छी तरह से स्वचालित रूप से बोया जाना चाहिए) और फिर इसे अचार करें।

मैं एक ही बात कहता हूं, लेकिन मुझे इसके साथ बहुत कम कर्षण मिलता है। जैसा कि आप कहते हैं, "ठीक है, सिर्फ इसलिए कि कुछ बुरा विचार है इसका मतलब यह नहीं है कि लोग ऐसा नहीं करना चाहेंगे!"

समस्या का एक हिस्सा एमटी के विशाल राज्य द्वारा विकसित किया गया है, जो वास्तव में एक फ़ाइल को क्रमबद्धता की आवश्यकता है। यह मुश्किल है कि फ़ाइल-आधारित नृत्य को सबसे आसान एपीआई उपलब्ध हो, जैसे कि उपयोगकर्ता इसका उपयोग करना चाहते हैं। बहुत छोटे राज्य के साथ डिफ़ॉल्ट PRNG के साथ चीजें बेहतर होंगी। 128-बिट्स एक यूयूआईडी का आकार है, जो कि हेक्स और कॉपी-पेस्ट में प्रिंट करने के लिए पर्याप्त छोटा है। तो एक अच्छा पैटर्न आपके प्रोग्राम को लिखने के लिए हो सकता है कि यह एक अच्छे एन्ट्रापी सीड को डिफॉल्ट करता है और फिर अपने स्टेट को इस तरह से प्रिंट करता है कि आप अगली बार प्रोग्राम को चलाने पर इसे कॉपी-पेस्ट कर सकते हैं।

❯ python secret_prng.py
Seed: 0x977918d0c7da45e5168f72005586500c
...
Result = 0.7223650399276123

❯ python secret_prng.py
Seed: 0xe8962534e5fb585483b86119fcb852ce
...
Result = 0.10640984721018876

❯ python secret_prng.py --seed 0xe8962534e5fb585483b86119fcb852ce
Seed: 0xe8962534e5fb585483b86119fcb852ce
...
Result = 0.10640984721018876

सुनिश्चित नहीं है कि अगर इस तरह का एक पैटर्न सादगी और भविष्य के प्रमाण दोनों प्रदान करेगा।

NumPy 1.next

class Generator:
    def __init__(bitgen_or_seed=None, *, bit_generator='pcg64', inc=0):

NumPy 1.20.x

`` `अजगर
कक्षा जनरेटर:
def __init __ (bitgen_or_seed = कोई नहीं, *, bit_generator = कोई नहीं, inc या कोई भी नहीं:
अगर bit_generator कोई नहीं है या inc कोई भी नहीं है:
चेतावनी दी गई है ('डिफ़ॉल्ट PCG64 से AESCtr में बदल रहा है। कीवर्ड)
'तर्क को हटा दिया गया है और भविष्य में उठाएंगे', FutureWarning)
`` ``

न्यूमपी 1.22

`` `अजगर
कक्षा जनरेटर:
def __init __ (bitgen_or_seed = none, *, bit_generator = 'aesctr', inc = none, counter = 0):
अगर bit_generator == 'pcg64' या inc कोई नहीं है:
अपवाद उठाना ('PCG अब समर्थित नहीं है और inc को हटा दिया गया है')
`` ``

सुनिश्चित नहीं है कि अगर इस तरह का एक पैटर्न सादगी और भविष्य के प्रमाण दोनों प्रदान करेगा।

जैसा कि मैंने https://github.com/numpy/numpy/issues/13635#issuecomment -496589421 में ऊपर उल्लेख किया है, मुझे लगता है कि यह अधिकांश उपयोगकर्ताओं के लिए आश्चर्य और निराशा की बात होगी। यदि उपयोगकर्ताओं ने सभी वैकल्पिक तर्क निर्धारित नहीं किए हैं, तो मुझे चेतावनी जारी करने की योजना की तुलना में एक स्पष्ट BitGenerator वस्तु प्रदान करने की आवश्यकता होगी। यह वास्तव में एक अंतिम उपाय होना चाहिए, ऐसे मामलों के लिए जहां हमें पता चलता है कि एपीआई उन तरीकों से टूटे हुए हैं, जिनकी हमने आशा नहीं की थी।

समस्या संक्रमण काल ​​है। चूक का उपयोग करने वाले सभी को अचानक संक्रमण की अवधि के दौरान स्विच करने का कोई शानदार तरीका के साथ चेतावनी मिलेगी। या कम से कम, आप उनमें से एक "कम ऊर्जा राज्य" से स्थानांतरित Generator(seed) एक कम सुविधाजनक के "उच्च ऊर्जा राज्य" को Generator(seed, bit_generator='aesctr') । चूंकि इस एपीआई का लक्ष्य एक सुविधाजनक "कम-ऊर्जा राज्य" प्रदान करना था, इसलिए हमने इस संक्रमण के दौरान अपने उद्देश्य को विफल कर दिया है। हमने अपने हिस्टोग्रामिंग कार्यों में से एक, IIRC के साथ एक बार ऐसा किया था, और यह एक बुरा सपना था।

यह उन सभी अपचयनों के लिए आम है जो तर्कों के अर्थ को जगह में बदलने की कोशिश करते हैं। Deprecations कि _move_ आप एक फ़ंक्शन से दूसरे में प्रबंधित करना बहुत आसान है, और यही मैं वकालत कर रहा था।

चलो बिना Generator(seed) साथ पहला संस्करण प्राप्त करें और कुछ प्रतिक्रिया प्राप्त करें।

"पहले संस्करण" से, क्या आपका मतलब पूरी तरह से रिलीज होने से है? या बस पीआर विलय हो रहा है (जो तब से हुआ है)?

यदि एक पूर्ण सुन्न रिलीज है, तो हमारे पास अभी भी कुछ चीजें निर्धारित करने के लिए हैं, जैसे कि हम कितने BitGenerator s शामिल करते हैं। यदि हम पूर्ण वर्तमान पूरक को शामिल करते हैं, तो हमने कुछ विकल्पों का खुलासा किया है।

Deprecations कि _move_ आप एक फ़ंक्शन से दूसरे में प्रबंधित करना बहुत आसान है, और यही मैं वकालत कर रहा था।

+1 सहमत हुआ

नहीं, यह एक "नामित चलती लक्ष्य" एपीआई की समस्याओं को कम करने के लिए है जैसे कि default_generator (बीज) एपीआई जो लोग काम कर रहे थे (जैसे @shoyer का संस्करण तर्क)।

धारा अनुकूलता बनाए रखना (जो एनईपी 19 डिस्क्लिम्स है) एपीआई ब्रेकेज के लिए माध्यमिक है। अलग-अलग BitGenerators के अलग-अलग प्रभावी API हैं

आह ठीक है, अब यह मेरे लिए और अधिक समझ में आता है।

यदि अजीब-अजीब नाम समस्या है, तो मैं एक अधिक मैत्रीपूर्ण, सामान्य नाम का उपयोग करके खुश होऊंगा, जब तक कि नीति अन्यथा एक ही है (हम एक नया फ़ंक्शन जोड़ते हैं और पुराने के बारे में चेतावनी देना शुरू करते हैं)। मुझे लगता है कि समकक्ष होगा। हमें ऐसा अक्सर नहीं करना चाहिए।

यह अब तक का सबसे अच्छा समाधान लगता है। यहां एक संत नाम चुनना संभव होना चाहिए। और अन्य संत नामों का एक बड़ा स्थान है - जिसकी हमें कभी भी आवश्यकता नहीं होगी।

np.random.generator या np.random.default_generator ।

कितने BitGenerators हम शामिल हैं

क्या आप उन लोगों को छोड़ने के प्रस्ताव के साथ एक अलग मुद्दा खोल सकते हैं जिन्हें आपको लगता है कि हमें वर्तमान में शामिल (MT19937, DSFMT, PCG32, PCG64, Philox, ThreeFry, Xoshiro256, Xoshiro512) को हटा देना चाहिए?

हमने अभी भी इस मुद्दे को हाथ में हल नहीं किया है: कौन सा BitGenerator डिफ़ॉल्ट होना चाहिए (वर्तमान में Xoshiro256 )

खैर, यह मुद्दा अधिक है "जो कि सुन्नत को BitGenerator रूप में बढ़ावा देना चाहिए," जो कि डिफ़ॉल्ट की पसंद में खिलाती है, लेकिन यह भी कि किन लोगों को शामिल किया जाना चाहिए या गिरा दिया जाना चाहिए। यांत्रिकी जिसके द्वारा हम डिफॉल्ट प्रदान करते हैं (यदि हम डिफॉल्ट प्रदान करते हैं) कुछ बाधाओं को जोड़ता है, इसलिए ये सभी चीजें हैं जिन्हें कम या ज्यादा एक साथ तय करने की आवश्यकता है। यह एक बड़ी बालों वाली गड़बड़ है, और सभी काम के बाद जो आपने इस पीआर के माध्यम से चरवाहा किया है, मुझे यकीन है कि आप एक और मेगा-थ्रेड को देख रहे हैं, जिसमें कोई भी योगदान देने वाला कोड नहीं है, इसलिए आपके पास मेरी सहानुभूति है। :-)

जहां तक ​​एल्गोरिदम प्रति सेग जाना है, मैंने पहले ही अपनी सिफारिशें दी हैं: हमें MT19937 RandomState और तुलनात्मक उद्देश्यों के लिए रखना चाहिए, और मुझे PCG64 सिफारिश के प्रयोजनों के लिए पसंद है।

मैंने कंपाइलर एक्सप्लोरर पर थोड़ा गड़बड़ कर दिया है, और मुझे लगता है कि मैंने 64-बिट MSVC के लिए PCG64 को एक तरह से आंतरिक रूप से उपयोग किया है जो कंपाइलर को uint128_t गणित के करीब असेंबली उत्पन्न करने के लिए मजबूर करता है: https: // godbolt .org / z / ZnPd7Z

मेरे पास इस समय एक विंडोज देव वातावरण नहीं है, इसलिए मुझे नहीं पता कि क्या यह वास्तव में _correct _... @bashtage है जो आप इसे शॉट देना चाहेंगे?

पैच के बिना:

Uniforms per second
************************************************************
PCG64            62.77 million

पैच के साथ:

Uniforms per second
************************************************************
PCG64           154.50 million

पैच परीक्षणों को पारित करता है, जिसमें 2 अलग-अलग बीजों के लिए 1000 uint64 मूल्यों का एक ही सेट पैदा करना शामिल है।

जीसीसी मूल और तुलना मोड में तुलना के लिए:

Time to produce 1,000,000 Uniforms
************************************************************
Linux-64, GCC 7.4                      PCG64            4.18 ms
Linux-64, GCC 7.4, Forced Emulation    PCG64            5.19 ms
Win64                                  PCG64            6.63 ms
Win32                                  PCG64           45.55 ms

वाह, यह वास्तव में बुरा लगता है। हो सकता है कि हम एक ही मशीन पर प्रदर्शन msvc2017-on-win-64, 32} बनाम gcc7.4-on-linux {64, 32} प्रदर्शन को प्रदर्शित करने के लिए तुलनात्मक पृष्ठ पर जानकारी का विस्तार करें (मुझे लगता है कि आप msvc2017 का उपयोग कर रहे हैं। आपको शायद उस जानकारी को कहीं न कहीं शामिल करना चाहिए)।

Win32 यहाँ निराशाजनक है। मुझे संदेह है कि लिनक्स 32 बिट भी काफी भयानक होगा, लेकिन आसानी से परीक्षण करने के लिए 32 बिट लिनक्स सिस्टम नहीं है।

मैं उन लोगों के लिए सिफारिश करने के मामले को निश्चित रूप से देख सकता हूं जो 32 बिट मशीन पर चिपके रहते हैं (कॉर्पोरेट आईटी नीतियों के कारण सबसे अधिक संभावना विंडोज)। यह प्रतिवेदन स्पष्ट है: 32 बिट के लिए DSFMT (या MT19937 भी अच्छा है)। बेंचमार्क हालांकि अच्छा होगा।

इसके लायक होने के लिए, मैं कई स्वतंत्र यादृच्छिक धाराओं के बार-बार दोहराया पीसीजी दावे पर संदेह कर रहा हूं। क्या किसी ने स्वतंत्रता के दावे का समर्थन करने के लिए कोई गंभीर सांख्यिकीय विश्लेषण किया है? (वास्तव में, मुझे लगता है कि ओ'नील का पेपर केवल "अलग" धाराओं को संदर्भित करता है, स्वतंत्रता के किसी भी दावे के बिना।)

मुझे लगता है कि संदेह होने का एक अच्छा कारण है: किसी दिए गए LCG गुणक के लिए, ये सभी अलग-अलग धाराएँ केवल स्केलिंग [*] के माध्यम से संबंधित हैं। तो एक ही मल्टीप्लायर के साथ कोई भी दो LCG स्ट्रीम दिए गए हैं, उनमें से एक बस एक स्थिर मल्टीपल होगा (मॉडुलो 2**64 या 2**32 उचित के रूप में), हालांकि अलग-अलग शुरुआती बिंदुओं के साथ। पीसीजी का क्रमपरिवर्तन वाला हिस्सा इसे थोड़ा छिपाने में मदद करेगा, लेकिन यह वास्तव में आश्चर्यजनक नहीं होगा यदि सांख्यिकीय रूप से पता लगाने योग्य संबंध नहीं थे।

इतनी अलग धाराएँ, निश्चित रूप से, लेकिन मैं कुछ गंभीर परीक्षण के बिना अंकित मूल्य पर स्वतंत्र धाराओं का दावा नहीं करूंगा।

[*] उदाहरण: मान लीजिए x[0], x[1], x[2], ... एक मानक 64-बिट LCG स्ट्रीम है, जिसमें x[i+1] := (m*x[i] + a) % 2**64 । सभी i लिए y[i] := 3*x[i] % 2**64 सेट करें। तब y[i] y[i+1] := (m*y[i] + 3*a) % 2**64 साथ एक LCG स्ट्रीम है, इसलिए मूल स्ट्रीम को स्केल करके, आपने एक ही गुणक लेकिन अलग-अलग योगात्मक स्थिरांक के साथ इन विशिष्ट LCG स्ट्रीम में से एक का उत्पादन किया है। 3 स्थान पर अन्य विषम गुणक का उपयोग करके, और यह मानते हुए कि हम केवल पूर्ण-अवधि LCGs में रुचि रखते हैं (और इसलिए a विषम है), आपको सभी संभव पूर्ण मिलेंगे- उस गुणक के साथ एलसीजी की अवधि।

संपादित करें: संयुग्मता वर्गों की संख्या के बारे में निश्चित गलत कथन।

मुझे लगता है कि पीसीजी धाराओं का सबसे गहन सार्वजनिक विश्लेषण यहाँ है: http://www.pcg-random.org/posts/critiquing-pcg-streams.html

@imneme क्या आप अपनी अंतिम सलाह पर विस्तार कर सकते हैं? "डेविड ब्लैकमैन के साथ पत्राचार से पता चलता है कि यह आसान हो सकता है क्योंकि मैंने एक निरंतर बीज और 1,2,3,4 की धाराओं जैसे सहसंबद्ध आरंभीकरण के साथ" पास "धारा बनाने के लिए सोचा था। यदि आप कई धाराओं का उपयोग करने जा रहे हैं। उसी समय, अब मैं यह सलाह दूंगा कि स्ट्रीम आईडी और बीज अलग होना चाहिए और एक दूसरे के साथ स्पष्ट संबंध नहीं होना चाहिए, जिसका अर्थ है कि उन दोनों को 1,2,3,4 नहीं बनाते हैं। "

क्या इसका मतलब यह है कि आपको लगता है कि एक ही अच्छा बीज (जैसे एक एन्ट्रापी स्रोत से प्राप्त) होना ठीक है और फिर आईडी 1,8,3,4 को स्ट्रीम करें? या बीज और धारा दोनों को एक अच्छे एन्ट्रोपी स्रोत से यादृच्छिक रूप से चुना जाना चाहिए?

कुछ लिनक्स -32 (Ubuntu 18.04 / GCC 7.4) संख्या

Time to produce 1,000,000 Uniforms
***************************************************************
Linux-64, GCC 7.4                      PCG64            4.18 ms
Linux-64, GCC 7.4, Forced Emulation    PCG64            5.19 ms
Win64                                  PCG64            6.63 ms
Win32                                  PCG64           45.55 ms
Linux-32, GCC 7.4                      PCG64           25.45 ms

तो यह विन -32 के मुकाबले दोगुना है लेकिन धीमा है। सभी 4 टाइमिंग एक ही मशीन पर की गई थी

Other Linux-32/GCC 7.4 Timing Results
-----------------------------------------------------------------
DSFMT            6.99 ms
MT19937         13.09 ms
Xoshiro256      17.28 ms
numpy           15.89 ms

NumPy, NumPy 1.16.4 है। DSFMT 32-बिट (x86) पर अच्छे प्रदर्शन के साथ एकमात्र जीनियर है। यह किसी भी 32 बिट उपयोगकर्ताओं के लिए स्पष्ट रूप से प्रलेखित किया जाना चाहिए। MT19937 32 बिट उपयोगकर्ता के लिए एक अपेक्षाकृत अच्छा विकल्प है।

इसलिए हमें विरासत उद्देश्यों के लिए MT19937 होने की आवश्यकता है। यदि हम न्यूनतम होना चाहते हैं जिसके बारे में हम PRNGs को शामिल करते हैं (यानी MT19937 प्लस हमारी एकल-सामान्य अनुशंसा), तो मैं अपने एकल-सामान्य उद्देश्य अनुशंसा को प्रतिबंधित करने के लिए 32-बिट प्रदर्शन का उपयोग करने के लिए मजबूर महसूस नहीं करूंगा एक तीसरा "अनुशंसित-32-बिट" PRNG जोड़ने के लिए मजबूर महसूस करें। MT19937 हमेशा उपलब्ध रहेंगे, और यह वर्तमान में उनके पास से भी बदतर नहीं है। और तीसरे पक्ष के पैकेज अधिक आला उपयोगों के लिए उपलब्ध होंगे।

बेशक, अगर हम अन्य कारणों से PRNG के अधिक पूर्ण सेट को शामिल करना चाहते हैं, तो हम प्रलेखन में सभी प्रकार की विशिष्ट सिफारिशें कर सकते हैं।

मैं उत्सुक था कि पीसीजी का "पी" हिस्सा सहसंबद्ध धाराओं से संभावित मुद्दों को कितना कम करता है।

तो यहां (शायद) LCG के लिए सबसे खराब संभव मामला है: जहां एक LCG स्ट्रीम का एडिटिव स्थिरांक दूसरे के लिए एडिटिव स्थिरांक का सटीक निषेध है। फिर बीज के उचित रूप से भयानक विकल्पों के साथ, हम LCG धाराओं में से एक के साथ समाप्त होते हैं जो दूसरे का सटीक निषेध है।

लेकिन अब अगर हम फ्लोट की एक श्रृंखला उत्पन्न करने के लिए दोनों धाराओं का उपयोग कर रहे हैं, तो पीसीजी के दोनों क्रमचय भाग और फ्लोट64 में रूपांतरण हमें थोड़ी मदद करनी चाहिए।

यहाँ एक प्लॉट दिखाया गया है कि क्रमचय कितना मदद करता है:

यह एक ऐसी धारा से 10000 की एक तितर बितर साजिश है, इसकी नकारात्मक जुड़वां से 10000 के खिलाफ है। भयानक नहीं, लेकिन महान नहीं भी: स्पष्ट कलाकृतियों हैं।

यह सुनिश्चित करने के लिए नहीं कि इससे क्या निष्कर्ष निकाला जाए: यह बिल्कुल एक विपरीत उदाहरण है, कि आप दुर्घटना से बचने की उम्मीद नहीं कर रहे हैं। दूसरी ओर, यह प्रदर्शित करता है कि कुछ विचार और देखभाल की आवश्यकता है यदि आपको वास्तव में कई असंबद्ध धाराओं की आवश्यकता है।

रिकॉर्ड के लिए, यहाँ स्रोत है:

import matplotlib.pyplot as plt
import numpy as np

from pcgrandom import PCG64

gen1, gen2 = PCG64(), PCG64()
multiplier, increment, state = gen1._get_core_state()
new_increment, new_state = -increment % 2**128, -state % 2**128
gen2._set_core_state((multiplier, new_increment, new_state))

xs = np.array([gen1.random() for _ in range(10**4)])
ys = np.array([gen2.random() for _ in range(10**4)])
plt.scatter(xs, ys, s=0.1)
plt.show()

PCG64 जनरेटर है जिसे ओ 'नील PCG-XSL-RR (PCG पेपर का सेक्शन 6.3.3) कहता है। pcgrandom पैकेज यहाँ से

मैंने सोचा था कि स्वतंत्र धाराओं को प्राप्त करने का मानक तरीका जम्पहेड () का उपयोग करना है।
"स्वतंत्र" स्ट्रीम प्राप्त करने के लिए री-सीडिंग सामान्य खतरनाक है।

काउंटर / हैश जनरेटर में एक तुच्छ कूदहेड () है। PCG करता है?

एक उपयोगकर्ता से भी एक दलील: कृपया कम से कम एक बिटस्ट्रीम प्रदान करें
क्रिप्टोग्राफ़िक गुणवत्ता, एक अनबाउंड स्टेट स्पेस के साथ।

चीयर्स,
फिलिप

(EDIT by seberg: निकाला गया ईमेल उद्धरण)

@pbstark : यह सिर्फ reseeding नहीं है: दो अंतर्निहित LCG जनरेटर वास्तव में अलग हैं: x (mx + a (mod 2 ^ 128) और x x mx + b (mod 2 ^ 128) विभिन्न वेतन वृद्धि a और b के लिए। ओ'नील का पीसीजी पेपर उस एलसीजी वृद्धि (कागज के खंड 4.3.2 देखें) को बदलकर विभिन्न धाराओं को बनाने में सक्षम होने का विचार बेचता है।

लेकिन एलसीजी की सादगी का मतलब यह है कि जोड़ने योग्य निरंतर _does_ सिर्फ मूल जनरेटर में कुछ अज्ञात राशि से जंपहेड के लिए राशि, एक साधारण रैखिक परिवर्तन (एक निरंतर द्वारा गुणा, या कुछ मामलों में एक स्थिर के अलावा) के साथ संयुक्त।

PCG का उपयोग नहीं करने का कोई कारण नहीं है, और मैं यह तर्क देने के लिए नहीं हूं कि यह NumPy के नए मुख्य PRNG के लिए उपयुक्त नहीं है; मैं नहीं चाहता कि लोगों को "स्वतंत्र" यादृच्छिक धाराओं के वादे के द्वारा लिया जाए। सबसे अच्छा, पीसीजी के लिए समझौता योग्य धारा विचार एक त्वरित जम्पहेड प्लस एक बोनस अतिरिक्त गुणात्मक या योज्य परिवर्तन के बराबर कुछ करने का एक सुविधाजनक तरीका प्रदान करता है।

हमने समुदाय कॉल में क्रिप्टोग्राफ़िक एक पर थोड़ी चर्चा की। मुझे लगता है कि हम इसके बारे में थोड़ा सतर्क थे। यह एक अच्छा विचार लगता है, लेकिन अगर हम एक क्रिप्टोग्राफिक रूप से ध्वनि आरएनजी को शामिल करते हैं, तो हमें किसी भी सुरक्षा मुद्दों के साथ भी रखना होगा, क्योंकि हम नहीं जानते हैं कि उपयोगकर्ता वास्तविक क्रिप्टोग्राफी प्रयोजनों के लिए उनका उपयोग करते हैं या नहीं।

कितने को शामिल करने के नोट पर: सर्वसम्मति से इसके बारे में कुछ और बिट जनरेटर के लिए ठीक होने की ओर रुझान (कुछ छोटे प्रलेखन निश्चित रूप से अच्छा होगा)। रखरखाव का बोझ बहुत बड़ा नहीं लगता है। अंत में, मेरा अनुमान है कि केविन और रॉबर्ट जो भी सुझाव देंगे हम उसके साथ जाएंगे।

नामों के नोट पर: मैं व्यक्तिगत रूप से RNG नामों का उपयोग करने और उपयोगकर्ताओं को उन्हें उपयोग करने के लिए मजबूर करने का बुरा नहीं मानता, केवल नकारात्मक पक्ष यह है कि कोडिंग करते समय हमें नाम को देखना पड़ सकता है। हमें बस यथासंभव कम-से-कम चेतावनियों की चेतावनी देने की कोशिश करनी चाहिए। मुझे बिना सीडिंग के डिफ़ॉल्ट RNG के लिए न्यूनतम उजागर एपीआई पसंद है।

@mdickinson , मैंने आपके ग्राफ़ को स्वयं पुन: उत्पन्न करने का प्रयास किया और विफल रहा। मैंने इस प्रोग्राम के साथ कोड के कैनोनिकल सी ++ संस्करण का उपयोग किया

#include "pcg_random.hpp"
#include <iostream>
#include <random>

int main() {
    std::random_device rdev;
    pcg_detail::pcg128_t seed = 0;
    pcg_detail::pcg128_t stream = 0;
    for (int i = 0; i < 4; ++i) {
        seed   <<= 32;           
        seed   |= rdev();
        stream <<= 32;           
        stream |= rdev();
    }
    pcg64 rng1(seed,stream);
    pcg64 rng2(-seed,-stream);
    std::cerr << "RNG1: " << rng1 << "\n";
    std::cerr << "RNG2: " << rng2 << "\n";
    std::cout.precision(17);
    for (int i = 0; i < 10000; ++i) {
        std::cout << rng1()/18446744073709551616.0 << "\t";
        std::cout << rng2()/18446744073709551616.0 << "\n";
    }
}

जब मैं इसे चलाता हूं, तो यह आउटपुट (प्रतिलिपि प्रस्तुत करने की अनुमति देने के लिए):

RNG1: 47026247687942121848144207491837523525 203756742601991611962280963671468648533 41579532896305845786243518008404876432
RNG2: 47026247687942121848144207491837523525 136525624318946851501093643760299562925 52472962479578397910044896975270170620

और डेटा पॉइंट जो निम्नलिखित ग्राफ को प्लॉट कर सकते हैं:

यदि आप यह पता लगा सकते हैं कि मैं क्या कर रहा हूं, तो यह मददगार होगा।

(मैं इस विचार का खंडन करने के लिए यह नहीं कह रहा हूं कि सहसंबंध संभव हैं, क्योंकि वे हैं, और मैं इस विषय पर एक अलग टिप्पणी लिखूंगा, लेकिन यह उस टिप्पणी को लिखने में था जिसे मैंने महसूस किया कि मैं आपके परिणाम का उपयोग करके पुन: पेश नहीं कर सका। मेरे सामान्य उपकरण।)

@ मिकिन्सन ने सामान्य प्रारंभिककरण दिनचर्या को दरकिनार करते हुए , गणना की गई स्थिति में वृद्धि की और सीधे इंटर्नल में वृद्धि की, जिसमें दो चरण-प्रगति है।

मैंने एक त्वरित लिटिल ड्राइवर स्क्रिप्ट लिखी, जो कि कई पीसीजी 32 धाराओं को इंटरलेक्ट करती है, जो विभिन्न तरीकों से निर्मित होती है, प्रैक्ट्रैंड में फीड करने के लिए। यह पायथन पर master खतना का उपयोग करता है। 3. जब मैं प्रतिकूल आंतरिक राज्यों / वेतन वृद्धि में सीधे पंच करता हूं, तो प्रैक्ट्रैंड जल्दी से विफल हो जाता है। मेरे लिए यह स्पष्ट नहीं है कि यदि हम प्रतिकूल अवस्थाओं को प्राप्त करने के लिए प्रतिकूल _seeds_ (जो वास्तव में शुरुआती दिनचर्या से गुजरते हैं) खोजने के लिए उचित तरीके पा सकते हैं।

जैसा कि मेरे ब्लॉग पोस्ट में पहले उल्लेख किया गया था, स्प्लिटमिक्स के साथ पीसीजी की धाराओं में बहुत कुछ है।

_Mveryinson के ग्राफ के बारे में, _every_ PRNG के लिए, जो आपको काउंटर-आधारित क्रिप्टोग्राफिक वाले सहित पूरे राज्य को बीज बनाने की अनुमति देता है, हम ऐसे बीजारोपण कर सकते हैं जहां हमारे पास PRNG होंगे जिनके आउटपुट किसी तरह से सहसंबद्ध थे (ऐसा करने का सबसे आसान तरीका PRNG राज्यों को बनाना है जो थोड़ी दूरी पर हैं, लेकिन अक्सर हम यह समझने के आधार पर अन्य काम कर सकते हैं कि वे कैसे काम करते हैं)। और यद्यपि PRNGs जो पूर्ण-राज्य सीडिंग की अनुमति नहीं देते हैं, इस समस्या से बच सकते हैं, ऐसा करने से केवल एक नया परिचय मिलता है, केवल अपने संभावित राज्यों के एक छोटे से हिस्से तक व्यावहारिक पहुंच प्रदान करता है।

धाराओं के बारे में सोचने का सही तरीका बस अधिक यादृच्छिक स्थिति है जिसे बीजने की आवश्यकता है। 1,2,3 जैसे छोटे मूल्यों का उपयोग करना आमतौर पर _any_ PRNG के लिए किसी भी बीजारोपण के उद्देश्यों के लिए बुरा विचार है (क्योंकि यदि हर कोई इन बीजों का पक्ष लेता है, तो उनके संबंधित प्रारंभिक क्रम को ओवररप्रिटेड किया जाएगा)।

हम इसे एक धारा नहीं कह सकते हैं और इसे केवल राज्य कह सकते हैं। यही मंगलगेलिया ने counter शेष राज्य के साथ बिल्कुल भी बातचीत नहीं करता है, और, एलसीजी की तरह, और प्रारंभिक मूल्य में भिन्नताएं वास्तव में केवल एक जोड़ा स्थिरांक में राशि होती हैं।

स्प्लिटमिक्स, PCG और XorWow की धाराएँ हैं जिन्हें हम "स्टूपिड" स्ट्रीम कह सकते हैं। वे जनरेटर के एक तुच्छ पुनर्मूल्यांकन का गठन करते हैं। हालांकि इसमें मूल्य है। मान लीजिए कि धाराओं के बिना, हमारे PRNG में 42 की एक दिलचस्प करीबी पुनरावृत्ति होगी, जहां त्वरित उत्तराधिकार में 42 बार कई फसलें होती हैं और यह केवल 42 के लिए होता है और कोई अन्य संख्या नहीं है। बेवकूफ "बस एक वेतन वृद्धि" या "सिर्फ एक एक्सोर" धाराओं के साथ, हम वास्तव में 42 तक अजीब दोहराने से बचने से बचेंगे; सभी नंबरों में एक स्ट्रीम होती है जिसमें वे अजीब तरह से दोहराते हैं। (इस कारण से, मैं जोशीरो 256 में क्लोज-रिपीट की समस्याओं को ठीक करने के लिए लागू होता है, एक

मैं एक विशेषज्ञ नहीं हूं, लेकिन क्रिप्टोग्राफी की तरफ, जो प्रस्तावित है वह इसमें उपलब्ध नहीं है:
https://cryptography.io/en/latest/ पायथन क्रिप्टोग्राफ़िक प्राधिकरण से ?

यादृच्छिक संख्या पीढ़ी पर उनके पृष्ठ का भी उल्लेख है:

पायथन 3.6 के साथ शुरू होने वाले मानक पुस्तकालय में रहस्य मॉड्यूल शामिल हैं, जिसका उपयोग पाठ-आधारित प्रारूपों के लिए विशिष्ट सहायकों के साथ क्रिप्टोग्राफिक रूप से सुरक्षित यादृच्छिक संख्याओं को उत्पन्न करने के लिए किया जा सकता है।

मुझे लगता है कि शायद पीढ़ी में सरणियों को जोड़ना। मुझे आश्चर्य होता है कि क्रायपोटग्राफिक मजबूती के साथ जुड़े होने के संभावित रखरखाव का बोझ वास्तव में इसके लायक है और NumPy बनाम उपयुक्त में कहेंगे। मुझे लगता है कि नथानियल ने पहले भी इसी तरह की चिंता का उल्लेख किया था।

वास्तव में, यह मुझे लगता है कि संभावित dtype रिफ्लेक्टर / एन्हांसमेंट जैसी चीजें भी आवश्यक रूप से विशेष नए अनुप्रयोगों के एक बड़े विविधता को बनाए रखने के बोझ के बिना एपीआई बुनियादी ढाँचा प्रदान करने के लिए डिज़ाइन की गई हैं।

बीटीडब्ल्यू, विग्ना के पीसीजी समालोचना [विशेष रूप से, इस खंड ] के प्रति मेरी प्रतिक्रिया में परस्पर संबंधित PRNG राज्यों के बारे में अधिक है। मैंने वहां जो कुछ देखा है, वह पीसीजी के साथ है, क्योंकि इसमें एक दूरी का कार्य है, आप वास्तव में अंतर्वर्ती बीजों का पता लगाने के लिए दूरी के कार्य की जांच कर सकते हैं। एक दूरस्थ कार्य के बिना PRNGs में, लोग अभी भी बीजारोपण जोड़े को जोड़ सकते हैं जो खराब विकल्प हैं (विशेषकर यदि वे बीजारोपण के लिए सार्वजनिक एपीआई को दरकिनार कर रहे हैं), लेकिन कोई भी ऐसा तंत्र उपलब्ध नहीं है, जो विरोधाभासों के सबसे प्रस्फुटित होने का भी पता लगा सके।

एक तरफ, यह सोचने में मज़ा है कि क्या यह आपके पसंदीदा (या कम से कम पसंदीदा) PRNG लेने के लिए संभव है और इसके लिए बीज को नियंत्रित करें जो इसे मनोरंजक या भयानक चीजें करने के लिए बनाते हैं (उदाहरण के लिए, यह विकृति विज्ञान ) ...

लेकिन बड़ी तस्वीर को देखते हुए, मुझे लगता है कि व्यवहार में उपयोगकर्ताओं का सामना करने वाले मुद्दों को देखना समझ में आता है। हम उन्हें क्या सलाह देते हैं, आदि। अधिकांश उपयोगकर्ताओं को पता ही नहीं चलता कि _ सभी PRNGs (भूत और भविष्य) के लिए _, एक 32-बिट बीज एक बहुत ही भयानक विचार है और इसके परिणामस्वरूप तुच्छ पता लगाने योग्य पूर्वाग्रह कोई फर्क नहीं पड़ता है जो PRNG खेलने में है। निश्चित रूप से, हम इसे बंद कर सकते हैं और इसके बजाय अपना समय इस बारे में चिंता करने में बिता सकते हैं कि क्या मेर्सन ट्विस्टर को ज्यादातर ज़ीरोस राज्य (या ऑल-ज़ीरोस राज्य जहां एलएफएसआर सभी पर काम करने में असफल हो जाते हैं) को शुरू करने में कामयाब रहे या क्या कोई हो सकता है! Xoshiro को उस बिंदु के पास आरंभीकृत करें जहां वह एक ही आउटपुट को सात बार ग्यारह आउटपुट के स्पेस में दोहराता है, या दो समान PCG स्ट्रीम, या जो भी हो, को कंट्रास्ट करता है, लेकिन इन सभी कॉन्ट्रिब्यूशन में मूल रूप से इन्फिनिटिमल (व्यवहार शून्य में) होता है यदि जनरेटर यादृच्छिक डेटा के साथ वरीयता प्राप्त है। जैसा कि बौद्धिक रूप से आकर्षक और अकादमिक रूप से दिलचस्प है क्योंकि ये विविधताएं हैं, उनके बारे में सोचते हुए ज्यादातर इस तथ्य को अनदेखा करते हैं कि उपयोगकर्ताओं को आमतौर पर इस बात का बहुत कम पता होता है कि जब वे बीजारोपण की बात करते हैं तो रोम जलता है।

यदि inc=1,2,3,4 एक बुरा विचार है, तो यह सुझाव नहीं देगा कि इसे या तो बहुत स्पष्ट रूप से प्रलेखित किया जाना चाहिए, या शायद हमें थोड़ा अलग एपीआई होना चाहिए? शायद new_generator = (Bit)Generator().independent() , हम उस पर एक चेतावनी डाल सकते हैं यदि (अंतर्निहित) बिट जनरेटर इसे प्राप्त करने का एक शानदार तरीका प्रदान नहीं करता है।

साथ ही, यह निर्भर करता है कि 32 बिट सीडिंग कितनी खराब है। क्या हम इसे फ्रीज करने के लिए बीज बनाने और भंडारण के लिए एक अच्छा एपीआई के बारे में सोच सकते हैं? मुझे नहीं पता। शायद यह भी "एक जमे हुए बीज कैश फ़ाइल बनाएँ अगर यह मौजूद नहीं है"।

पीसीजी के लिए सिर्फ बीज -> uint64_t [2] -> स्प्लिटमिक्स64 (seed_by_array) -> uint128 जो यह सुनिश्चित कर सकता है कि कम, लगातार बीज फैल रहे हैं।

पीसीजी के लिए सिर्फ बीज -> uint64_t [2] -> स्प्लिटमिक्स64 (seed_by_array) -> uint128 जो यह सुनिश्चित कर सकता है कि कम, लगातार बीज फैल रहे हैं।

या बस किसी अच्छे पूर्णांक हैश का उपयोग करें। (यह एक आक्षेप होना चाहिए।)। सस्ते और छोटे वाले बहुत हैं। Multiply-XorShift के कुछ राउंड ठीक हैं।

@Mdickinson की बात पर, मुझे लगता है कि वह अभी भी इस बात को लेकर आश्वस्त होना चाहता है कि धारा निर्भरता सीमित / प्रतिकूल सेटिंग्स के एक छोटे समूह तक सीमित है। और अगर ऐसा है, तो हम ऐसे मामलों को रोकने के लिए उचित प्रथाओं के साथ इसे हल कर सकते हैं। हमारे पास मौजूद वर्तमान कोड के साथ, कुछ खराब स्थिति हैं जो उपयोगकर्ता वर्तमान एपीआई के साथ आसानी से चूक सकते हैं। मैं डेविड ब्लैकमैन की खोज की पुष्टि कर सकता हूं कि दोनों seed=1 और inc=0,1,2,... स्थापना सहसंबंध बनाती है। यह प्रदर्शित करने के लिए interleaved PCG32 धाराओं के लिए मेरा नवीनतम प्रैक्टैंड ड्राइवर इस्तेमाल किया जा सकता है।

❯ ./pcg_streams.py --seed 1 --inc 0 |time ./RNG_test stdin32
[
    {
        "bit_generator": "PCG32",
        "state": {
            "state": 12728272447693586011,
            "inc": 1
        }
    },
    {
        "bit_generator": "PCG32",
        "state": {
            "state": 7009800821677620407,
            "inc": 3
        }
    }
]
RNG_test using PractRand version 0.93
RNG = RNG_stdin32, seed = 0x470537d5
test set = normal, folding = standard (32 bit)

rng=RNG_stdin32, seed=0x470537d5
length= 128 megabytes (2^27 bytes), time= 4.0 seconds
  Test Name                         Raw       Processed     Evaluation
  BCFN(2+0,13-3,T)                  R=  +9.6  p =  2.3e-4   mildly suspicious
  ...and 116 test result(s) without anomalies

rng=RNG_stdin32, seed=0x470537d5
length= 256 megabytes (2^28 bytes), time= 8.7 seconds
  Test Name                         Raw       Processed     Evaluation
  BCFN(2+0,13-2,T)                  R= +26.1  p =  6.3e-13    FAIL           
  ...and 123 test result(s) without anomalies

./RNG_test stdin32  8.86s user 0.11s system 93% cpu 9.621 total

मैं अभी तक एक यादृच्छिक बीज के साथ एक विफलता में नहीं चला था, लेकिन समान वेतन वृद्धि। मैं कल तुम्हारे साथ में जाँच करूँगा।

मैं नोटिस करता हूं कि हम अनुशंसित डिफ़ॉल्ट वेतन वृद्धि का उपयोग नहीं कर रहे हैं जब कोई भी निर्माता में निर्दिष्ट नहीं है। हमें शायद इसे ठीक करना चाहिए। हो सकता है कि यह एक अच्छा आधार नंबर हो जिससे हम दिए गए स्ट्रीम आईडी से वास्तविक वेतन वृद्धि 2*inc + 1 बजाय प्राप्त करें।

हम डिफ़ॉल्ट एंट्रॉपी-सीड्स का उपयोग करने और उन्हें बचाने के लिए लोगों की सहायता करने के लिए कुछ टूलिंग बनाने की कोशिश कर सकते हैं। एक प्रश्न जो मेरे पास है, वह यह है कि अगर कई धाराओं के लिए वेतन वृद्धि सिर्फ या तो उत्पन्न की जा सकती है या फिर हमें उन्हें दर्ज करने के साथ-साथ उन्हें बचाने की भी आवश्यकता है। यह अनुकार की "प्रारंभिक अवस्था" को सिंगल नंबर के रूप में एनकोड करने में सक्षम होने के लिए सुविधाजनक है जो एक अपारदर्शी फ़ाइल के बजाय किसी सहकर्मी के ईमेल से कॉपी-पेस्ट किया जा सकता है। केवल 128 या 256 बिट्स वाले इन छोटे PRNGs के साथ, मैं आसानी से उस हेक्स को अपनी लॉग फ़ाइल में प्रिंट कर सकता हूं और फिर जब मैं इसे पुन: प्रस्तुत करना चाहता हूं, तो इसे केवल अपनी कमांड लाइन में कॉपी-पेस्ट करें। यह 32-बिट पूर्णांक से बड़ा है, लेकिन यह प्रबंधनीय है। अगर मुझे अपनी सभी स्ट्रीम आईडी को भी एन्ट्रापी-सैंपल देना है, तो मुझे उसको छोड़ना होगा और यह सुनिश्चित करना होगा कि मैं सब कुछ स्टेट फाइल में दर्ज कर लूं। हो सकता है कि हमने कुछ ऐसे मामलों का इस्तेमाल किया हो, जिन पर हमने चर्चा की है, जहां हम नई धाराओं को गतिशील बनाना चाहते हैं। अगर मैं सिर्फ एक अच्छी स्ट्रीम आईडी प्राप्त करने के लिए एक काउंटर बढ़ा सकता हूं (हो सकता है कि यह काउंटर के हैश के माध्यम से प्राप्त कर रहा हो, या जो भी हो), तो मुझे केवल प्रारंभिक बीज रिकॉर्ड करने की आवश्यकता है, न कि स्ट्रीम आईडी।

IIRC, रहस्य मॉड्यूल ओएस के एन्ट्रापी स्रोत को कॉल करता है, जो काफी हो सकता है
कुछ प्रणालियों में बुरा है, और इसकी परवाह किए बिना प्रतिगामी / प्रतिलिपि प्रस्तुत करने योग्य नहीं है।

बुध पर, 29 मई, 2019 को 3:19 बजे टायलर रेड्डी नोटिफिकेशन @github.com
लिखा था:

मैं एक विशेषज्ञ नहीं हूं, लेकिन क्रिप्टोग्राफी की तरफ, जो प्रस्तावित है वह है
इसमें उपलब्ध नहीं है:
https://cryptography.io/en/latest/ पायथन क्रिप्टोग्राफ़िक प्राधिकरण से
https://github.com/pyca ?

यादृच्छिक संख्या पीढ़ी पर उनका पृष्ठ
https://cryptography.io/en/latest/random-numbers/ का भी उल्लेख है:

पायथन 3.6 के साथ शुरू होने वाले मानक पुस्तकालय में रहस्य शामिल हैं
https://docs.python.org/3/library/secrets.html मॉड्यूल, जो हो सकता है
विशिष्ट के साथ क्रिप्टोग्राफिक रूप से सुरक्षित यादृच्छिक संख्या उत्पन्न करने के लिए उपयोग किया जाता है
पाठ-आधारित स्वरूपों के लिए सहायक।

मुझे लगता है कि शायद पीढ़ी में सरणियों को जोड़ना। मुझे आश्चर्य होगा कि अगर
क्रायपोटग्राफिक से जुड़े होने का संभावित रखरखाव बोझ
मजबूती वास्तव में इसके लायक है और NumPy बनाम कहो में उपयुक्त है
पाइका के साथ संवाद करना और शायद किसी तीसरे पक्ष के बारे में सोचना
उसके लिए जनरेटर / प्लगइन। मुझे लगता है कि नथानिएल ने इसी तरह की चिंता का उल्लेख किया है
पहले से।

वास्तव में, यह मुझे लगता है कि संभावित dtype रिफ्लेक्टर / जैसी चीजें
एन्हांसमेंट को बिना API के आधारभूत संरचना प्रदान करने के लिए डिज़ाइन किया गया है
एक बड़ी विविधता को बनाए रखने के बोझ पर जरूरी है
विशेष नए अनुप्रयोग।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें
https://github.com/numpy/numpy/issues/13635?email_source=notifications&email_token=AANFDWKXSSTX6QI7HJ65GYTP336O3A5CNFSM4HPX3CHKYY3N3H3H3H3H3H3H3&hl=hi&hl=hi&hl=hi
या धागा म्यूट करें
https://github.com/notifications/unsubscribe-auth/AANFDWKGZMUB67VPCMFZYGTPX36O3ANCNFSM4HPX3CHA
।

-
फिलिप बी। स्टार्क | एसोसिएट डीन, गणितीय और भौतिक विज्ञान |
प्रोफेसर, सांख्यिकी विभाग |
कैलिफोर्निया विश्वविद्यालय
बर्कले, सीए 94720-3860 | 510-394-5077 | आँकड़ों ।berkeley.edu/~stark |
@philipbstark

@tylerjereddy वे भौतिक एंट्रोपी स्रोत से थोड़ी मात्रा में यादृच्छिक बिट्स प्राप्त करने के लिए हैं जो एक हमलावर (और आप!) के लिए अप्रत्याशित हैं। इनका उपयोग क्रिप्टोग्राफी में इनिशियलाइज़ेशन वैक्टर, नॉन, की, जैसी चीज़ों के लिए किया जाता है, जो सभी छोटे होते हैं। इनमें से संपूर्ण बिंदु यह है कि उन्हें पुन: उत्पन्न करने का कोई तरीका नहीं है, जो np.random के संख्यात्मक सिमुलेशन उद्देश्यों के साथ है। वह पृष्ठ _reproducible_ को क्रिप्टोग्राफिक रूप से सुरक्षित PRNGs के बारे में बात नहीं कर रहा है, जो कि मौजूद चीजें भी हैं और _could_ cryptography पैकेज में उपलब्ध प्राथमिकताओं से निर्मित हैं। _Ults_ में, हालांकि, हमारे पास उन एल्गोरिदमों का बेहतर कार्यान्वयन है जो पहले से ही कुशल सी कोड में हमारे पास उपलब्ध हैं, कम से कम उन लोगों को जो सिमुलेशन प्रयोजनों के लिए तैयार और परीक्षण किए गए हैं। @bashtage ने इस ढांचे के लिए

मैं यह भी स्पष्ट करना चाहता हूं कि खस्ता टीम को जो @pbstark प्रस्ताव दे रहा है, वह केवल किसी भी क्रिप्टो-आधारित

ज्यादातर क्रिप्टो-आधारित PRNGs जिन्हें आमतौर पर सिमुलेशन के लिए माना जाता है _not_ के पास अनबाउंड स्थिति है जो cryptorandom भी 2**(256+64) अनन्य प्रारंभिक शर्तों के कारण निश्चित-आकार के 256-बिट डाइजेस्ट अवस्था और निश्चित-आकार के 64-बिट लंबाई काउंटर से बंधा हुआ है। यह संभवत: लंबाई काउंटर को मनमाने ढंग से आकार देकर PRNG को सही मायने में लागू करने के तरीके को इंगित करता है, लेकिन मैंने ऐसा एल्गोरिथ्म प्रकाशित या परीक्षण कभी नहीं देखा है।

दूसरी ओर, यदि आप बस एक PRNG एल्गोरिदम चाहते हैं जिसमें एक मनमाने ढंग से आकार की स्थिति है, तो बस एक है जो शुरुआत में आपको जो कुछ भी ज़रूरत है उससे ऊपर के लिए तय है, तो पीसीजी के विस्तारित जनरेटर उस कार्य के लिए अच्छी तरह से काम करेंगे। ये विशिष्ट रूप से CS-PRNG नहीं हैं, लेकिन वे वास्तव में @pbstark की मांग पर भारी राज्य स्थान की इच्छा को पूरा करेंगे। बहरहाल, मैं अनुशंसा नहीं करता कि हम उन्हें सुन्न में शामिल करें।

अन्य गुण हैं जो मानक, बंधे, CS-PRNGs हैं जो हम चाहते हैं, लेकिन वे कोई ब्रेनर डिफ़ॉल्ट, IMO नहीं हैं।

क्रिप्टोकरेंसी का राज्य स्थान 256 बिट हैश नहीं है: यह अबाधित है।
बीज अवस्था मनमानी लंबाई की एक स्ट्रिंग है, और प्रत्येक अद्यतन एक शून्य जोड़ता है
वर्तमान स्थिति के लिए। एक अनबाउंड पूर्णांक काउंटर को बढ़ाना होगा
एक ही बात को पूरा करें। हमने शुरू में इसे लागू किया, लेकिन बदल दिया
वेतन वृद्धि के बजाय अपेंड करें, क्योंकि यह अधिक कुशल अपडेट की अनुमति देता है
खरोंच (ध्यान देने योग्य स्पीडअप) से प्रत्येक राज्य को हैशिंग से पचाना।

बुध पर, 29 मई, 2019 को शाम 7:26 बजे रॉबर्ट कर्न सूचनाएं @github.com
लिखा था:

@tylerjereddy https://github.com/tylerjereddy जो पाने के लिए हैं
एक भौतिक एन्ट्रापी स्रोत से यादृच्छिक बिट्स की थोड़ी मात्रा
एक हमलावर के लिए अप्रत्याशित (और आप!)। इनका उपयोग क्रिप्टोग्राफी में किया जाता है
आरंभीकरण वैक्टर, नॉन, की, जैसी चीजें, जो सभी छोटी हैं।
इनमें से पूरी बात यह है कि उन्हें पुन: पेश करने का कोई तरीका नहीं है, जो कि है
np.random के संख्यात्मक सिमुलेशन प्रयोजनों के साथ बाधाओं। वह पेज है
प्रतिलिपि प्रस्तुत करने योग्य क्रिप्टोग्राफी द्वारा सुरक्षित PRNGs, के बारे में बात नहीं जो
ऐसी चीजें भी हैं जो अस्तित्व में हैं और आदिम से निर्मित हो सकती हैं
क्रिप्टोग्राफी पैकेज में उपलब्ध है। व्यवहार में , हालांकि, हमारे पास है
उन एल्गोरिदम के बेहतर कार्यान्वयन जो पहले से ही हमारे लिए उपलब्ध हैं
कुशल सी कोड, कम से कम जिन्हें तैयार और परीक्षण किया गया है
सिमुलेशन प्रयोजनों के लिए। @bashtage https://github.com/bashtage कार्यान्वित
कुछ https://github.com/numpy/numpy/issues/13635#issuecomment-4949282850
इस ढांचे के लिए।

मैं यह भी स्पष्ट करना चाहता हूं कि खस्ता टीम को @pbstark क्या है
https://github.com/pbstark प्रस्ताव कर रहा है कि यह केवल क्रिप्टो-आधारित नहीं है
PRNG। इसके बजाए, वह निर्बाध राज्य चाहता है, जो प्रदान करेगा
वह गणितीय संपत्ति जिसे वह खोज रहा है।

अधिकतर क्रिप्टो-आधारित PRNGs जिन्हें आमतौर पर सिमुलेशन के लिए माना जाता है
@pbstark के पास अबाधित स्थिति नहीं है
https://github.com/pbstark चाहती है। वे आम तौर पर आसपास आधारित होते हैं
एक परिमित काउंटर को एन्क्रिप्ट करना। एक बार जब वह काउंटर इधर-उधर लुढ़क जाता है, तो आप हिट हो जाते हैं
परिमित अवधि। तकनीकी तौर पर, उनकी क्रिप्टोकरंसी
https://statlab.github.io/cryptorandom/ भी 2 ** (256 + 64) के लिए बाध्य है
256-बिट डाइजेस्ट स्थिति और निश्चित आकार के कारण अद्वितीय प्रारंभिक स्थितियां
निश्चित-आकार 64-बिट लंबाई काउंटर। शायद यही इशारा करता है
लंबाई काउंटर बनाकर एक सही मायने में अप्रभावित PRNG को लागू करना
मनमाने ढंग से आकार, लेकिन मैंने इस तरह के एक एल्गोरिथ्म को प्रकाशित या कभी नहीं देखा है
का परीक्षण किया।

दूसरी ओर, यदि आप सिर्फ एक PRNG एल्गोरिदम चाहते हैं जिसमें ए है
मनमाने ढंग से राज्य, बस एक है कि शुरुआत में तय हो गई है
आपको जो कुछ भी आवश्यक है उसके ऊपर, फिर पीसीजी के विस्तारित जनरेटर
http://www.pcg-random.org/party-tricks.html उसके लिए अच्छा काम करेगा
कार्य। ये विशिष्ट रूप से CS-PRNG नहीं हैं, लेकिन वे वास्तव में संतुष्ट होंगे
@pbstark https://github.com/pbstark की विशाल राज्य रिक्त स्थान की इच्छा है
मांग पर। बहरहाल, मैं अनुशंसा नहीं करता कि हम उन्हें सुन्न में शामिल करें।

अन्य गुण हैं जो मानक, बंधे, CS-PRNGs हैं
हम चाहते हैं, लेकिन वे एक नहीं brainer डिफ़ॉल्ट, IMO नहीं हैं।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें
https://github.com/numpy/numpy/issues/13635?email_source=notifications&email_token=AANFDWLGAF6YVIWXYZ2LTXPXXONONA5CNFSM4HPX3CHPYH3H3H3H3H3H3H3H3&hl=hi&hl=hi&hl=hi
या धागा म्यूट करें
https://github.com/notifications/unsubscribe-auth/AANFDWLIJD3UCVY3NXCLPKDPX43ONANCNFSM4HPX3CHA
।

-
फिलिप बी। स्टार्क | एसोसिएट डीन, गणितीय और भौतिक विज्ञान |
प्रोफेसर, सांख्यिकी विभाग |
कैलिफोर्निया विश्वविद्यालय
बर्कले, सीए 94720-3860 | 510-394-5077 | आँकड़ों ।berkeley.edu/~stark |
@philipbstark

मुझे डर है कि SHA-256 का ऑनलाइन अपडेट कैसे काम करता है। राज्य जो इसे बनाए रखता है वह केवल 256-बिट डाइजेस्ट और निश्चित आकार के 64-बिट लंबाई काउंटर है जो इसे अपडेट की गणना करते समय जोड़ता है। यह पूरे पाठ को धारण नहीं करता है। हिचकोले सेकते हैं। यही कारण है कि यह प्रत्येक बाइट पर कुशल अपडेट करने में सक्षम है। मौलिक रूप से, कई प्रारंभिक / पिछले इतिहास हैं जो एक ही आंतरिक SHA-256 राज्य में मैप करते हैं, जो कि परिमित है। जबकि चक्र निश्चित रूप से लंबे होते हैं, शायद 2**(256+64) से अधिक लंबे होते हैं, वे निश्चित रूप से मौजूद होते हैं। और किसी भी मामले में, आपके पास केवल 2**(256+64) संभव प्रारंभिक शर्तें हैं (प्रत्येक पाठ लंबाई के लिए 0 से 2**64-1 , आपके पास अधिकांश 2**256 आंतरिक हैश राज्यों में हो सकता है; एक बार; पाठ की लंबाई 32 बाइट्स से अधिक है, वहाँ टकराव एक ला कबूतर होना चाहिए)। डेटा संरचना में अभी कोई और बिट्स नहीं हैं।

बहुत बहुत धन्यवाद; समझ लिया। मैं इसे अलग तरह से व्यक्त करूंगा: राज्य
अंतरिक्ष अबाधित है, लेकिन (कबूतर द्वारा) कई अलग-अलग प्रारंभिक अवस्थाएं होनी चाहिए
निर्विवाद आउटपुट दृश्यों का उत्पादन।

बुध पर, 29 मई, 2019 को रात 8:21 बजे रॉबर्ट केर्न नोटिफिकेशन @ithub.com
लिखा था:

मुझे डर है कि SHA-256 का ऑनलाइन अपडेट कैसे काम करता है। राज्य
यह केवल 256-बिट डाइजेस्ट और निश्चित आकार 64-बिट बनाए रखता है
लंबाई काउंटर है कि यह अद्यतन जब गणना करता है। यह पकड़ नहीं है
पूरा पाठ। हिचकोले सेकते हैं। यह कैसे कुशल करने में सक्षम है
प्रत्येक बाइट पर अपडेट करें। मौलिक रूप से, कई प्रारंभिकियां / अतीत हैं
इतिहास जो एक ही आंतरिक SHA-256 राज्य के लिए मैप करता है, जो परिमित है।
हालांकि चक्र निश्चित रूप से लंबे होते हैं, शायद 2 (256 + 64) से अधिक लंबे होते हैं
और किसी भी मामले में, आपके पास केवल 2 (256 + 64)
संभव प्रारंभिक शर्तें (प्रत्येक पाठ की लंबाई 0 से 2 64-1 के लिए, आप कर सकते हैंअधिकांश 2 256 आंतरिक हैश राज्यों में हैं; एक बार जब पाठ की लंबाई 32 से अधिक हो जाती है
बाइट्स, वहाँ टकराव एक ला कबूतर होना चाहिए)। वहाँ कोई भी नहीं हैं
डेटा संरचना में अधिक बिट्स।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें
https://github.com/numpy/numpy/issues/13635?email_source=notifications&email_token=AANFDWOO6HRJZHTVBF2TLK3L3XBB5b3s5cnxhp5chwyhwH3H&hl=hi&hl=hi&hl=hi&hl=hi&hl=hi&hl=hi
या धागा म्यूट करें
https://github.com/notifications/unsubscribe-auth/AANFDWM56HCQRZXDO3BAQHDPX5B3TANCNFSM4HPX3CHA
।

-
फिलिप बी। स्टार्क | एसोसिएट डीन, गणितीय और भौतिक विज्ञान |
प्रोफेसर, सांख्यिकी विभाग |
कैलिफोर्निया विश्वविद्यालय
बर्कले, सीए 94720-3860 | 510-394-5077 | आँकड़ों ।berkeley.edu/~stark |
@philipbstark

यह भी मामला है कि वहाँ केवल 2**(256+64) हैं कि यह संभवतः गुजर सकता है। चूंकि अपडेट हर बार समान रूप लेता है, आप अंततः एक ऐसी स्थिति मारते हैं जो आपने पहले देखी है और अज्ञात (मेरे लिए) लूप दर्ज करते हैं, लेकिन अंतिम अवधि। चाहे वह प्रारंभिक राज्यों की परिमित संख्या हो या एक परिमित अवधि, cryptorandom दोनों ही हों, और मुझे लगता है कि वे MT19937 से भी छोटे हैं।

ऐसा नहीं है कि मुझे लगता है कि यह cryptorandom , प्रति से एक समस्या है। मुझे इस बात पर यकीन नहीं हुआ है कि प्रारंभिक अवस्थाओं का एक निर्बाध सेट या अनबाउंड पीरियड कुछ ऐसा है जो वास्तव में व्यावहारिक अर्थ में आवश्यक है।

मैं अभी तक एक यादृच्छिक बीज के साथ एक विफलता में नहीं चला था, लेकिन समान वेतन वृद्धि। मैं कल तुम्हारे साथ में जाँच करूँगा।

अभी भी 512GiB पर मजबूत:

❯ ./pcg_streams.py -i 0 |time ./RNG_test stdin32
[
    {
        "bit_generator": "PCG32",
        "state": {
            "state": 10843219355420032665,
            "inc": 1
        }
    },
    {
        "bit_generator": "PCG32",
        "state": {
            "state": 5124747729404067061,
            "inc": 3
        }
    }
]
RNG_test using PractRand version 0.93
RNG = RNG_stdin32, seed = 0xb83f7253
test set = normal, folding = standard (32 bit)

rng=RNG_stdin32, seed=0xb83f7253
length= 128 megabytes (2^27 bytes), time= 4.0 seconds
  no anomalies in 117 test result(s)

rng=RNG_stdin32, seed=0xb83f7253
length= 256 megabytes (2^28 bytes), time= 8.6 seconds
  no anomalies in 124 test result(s)

rng=RNG_stdin32, seed=0xb83f7253
length= 512 megabytes (2^29 bytes), time= 16.9 seconds
  Test Name                         Raw       Processed     Evaluation
  BCFN(2+2,13-2,T)                  R=  -8.0  p =1-2.1e-4   mildly suspicious
  ...and 131 test result(s) without anomalies

rng=RNG_stdin32, seed=0xb83f7253
length= 1 gigabyte (2^30 bytes), time= 33.8 seconds
  no anomalies in 141 test result(s)

rng=RNG_stdin32, seed=0xb83f7253
length= 2 gigabytes (2^31 bytes), time= 65.7 seconds
  Test Name                         Raw       Processed     Evaluation
  BCFN(2+2,13-1,T)                  R=  -7.8  p =1-3.8e-4   unusual          
  ...and 147 test result(s) without anomalies

rng=RNG_stdin32, seed=0xb83f7253
length= 4 gigabytes (2^32 bytes), time= 136 seconds
  no anomalies in 156 test result(s)

rng=RNG_stdin32, seed=0xb83f7253
length= 8 gigabytes (2^33 bytes), time= 270 seconds
  no anomalies in 165 test result(s)

rng=RNG_stdin32, seed=0xb83f7253
length= 16 gigabytes (2^34 bytes), time= 516 seconds
  no anomalies in 172 test result(s)

rng=RNG_stdin32, seed=0xb83f7253
length= 32 gigabytes (2^35 bytes), time= 1000 seconds
  no anomalies in 180 test result(s)

rng=RNG_stdin32, seed=0xb83f7253
length= 64 gigabytes (2^36 bytes), time= 2036 seconds
  no anomalies in 189 test result(s)

rng=RNG_stdin32, seed=0xb83f7253
length= 128 gigabytes (2^37 bytes), time= 4064 seconds
  no anomalies in 196 test result(s)

rng=RNG_stdin32, seed=0xb83f7253
length= 256 gigabytes (2^38 bytes), time= 8561 seconds
  no anomalies in 204 test result(s)

rng=RNG_stdin32, seed=0xb83f7253
length= 512 gigabytes (2^39 bytes), time= 19249 seconds
  no anomalies in 213 test result(s)

आह, अगर हम क्रमिक वेतन वृद्धि के साथ 2 से अधिक धाराएँ करते हैं, तो हम जल्दी से विफलताओं को देखते हैं। हमें अंतरिक्ष के चारों ओर इसे फैलाने के लिए किसी न किसी प्रकार की आपत्ति के साथ उपयोगकर्ता इनपुट से वास्तविक वेतन वृद्धि प्राप्त करने की आवश्यकता होगी।

❯ ./pcg_streams.py -n 3  | time ./build/RNG_test stdin32
[
    {
        "bit_generator": "PCG32",
        "state": {
            "state": 18394490676042343370,
            "inc": 2891336453
        }
    },
    {
        "bit_generator": "PCG32",
        "state": {
            "state": 12676019050026377766,
            "inc": 2891336455
        }
    },
    {
        "bit_generator": "PCG32",
        "state": {
            "state": 6957547424010412162,
            "inc": 2891336457
        }
    }
]
RNG_test using PractRand version 0.93
RNG = RNG_stdin32, seed = 0x4a9d21d1
test set = normal, folding = standard (32 bit)

rng=RNG_stdin32, seed=0x4a9d21d1
length= 128 megabytes (2^27 bytes), time= 3.2 seconds
  Test Name                         Raw       Processed     Evaluation
  DC6-9x1Bytes-1                    R= +19.4  p =  1.6e-11    FAIL           
  [Low8/32]DC6-9x1Bytes-1           R= +13.2  p =  4.6e-8    VERY SUSPICIOUS 
  ...and 115 test result(s) without anomalies

@imneme

यदि आप यह पता लगा सकते हैं कि मैं क्या कर रहा हूं, तो यह मददगार होगा।

मैं तुम्हें लाइन को बदलने के लिए की जरूरत है pcg64 rng2(-seed,-stream); के साथ अपने कोड में pcg64 rng2(-seed,-1-stream); के लिए अनुमति देने के लिए, increment = 2 * stream + 1 परिवर्तन। वेतन वृद्धि का निषेध स्ट्रीम इंडेक्स के बिटवाइज नकार से मेल खाता है। यदि मैं वह परिवर्तन करता हूं और आपका कोड चलाता हूं, तो मुझे अपने पहले के कथानक की तरह बहुत कुछ दिखाई देता है। (और मैं पुष्टि करता हूं कि अगर मैं वह परिवर्तन नहीं करता हूं, तो सब कुछ नेत्रहीन अच्छा लगता है।)

@imneme

धाराओं के बारे में सोचने का सही तरीका बस अधिक यादृच्छिक स्थिति है जिसे बीजने की आवश्यकता है।

माना। ठीक किए जाने के गुणक अच्छी तरह चुने हुए एक 64-बिट LCG के लिए: मुझे लगता है कि LCGs के लिए एक बहुत साफ तस्वीर देता है लगता है a , हम तो आकार के एक राज्य की जगह है 2^127 , सभी जोड़ों से मिलकर (x, c) पूर्णांकों का c विषम वृद्धि है। राज्य का अद्यतन कार्य next : (x, c) ↦ (ax+c, c) , राज्य के स्थान को 2^63 लंबाई में 2^64 प्रत्येक में विभाजित करता है। सीडिंग में इस राज्य स्थान में एक प्रारंभिक बिंदु चुनना शामिल है।

तब एक स्पष्ट समूह कार्रवाई होती है जो विश्लेषण को आसान बनाती है, और विभिन्न धाराओं के बीच संबंधों को स्पष्ट करती है: Z / 2^64Z पर इन्वर्टिबल 1-डी affine परिवर्तनों का समूह बिल्कुल 2^127 ऑर्डर करता है, और सकारात्मक रूप से कार्य करता है (और इसलिए भी ईमानदारी से) राज्य के स्थान पर: affine परिवर्तन y ↦ ey + f जोड़े (x, c) (ex + f, ec + (1-a)f) नक्शा। वह समूह कार्रवाई next फ़ंक्शन के साथ शुरू होती है, इसलिए अद्वितीय समूह तत्व जो एक स्थान (x, c) को राज्य स्थान में दूसरे में परिवर्तित करता है, (x2, c2) , (x, c) द्वारा उत्पन्न अनुक्रम का भी मैप करता है (x2, c2) ।

tl; dr: एक निश्चित गुणक के लिए, एक ही गुणक के साथ कोई भी दो LCG क्रमांक (चाहे एक ही वेतन वृद्धि का उपयोग कर रहे हों, जैसा कि लुकहेड केस में, या अलग-अलग वेतन वृद्धि) एक एफाइन ट्रांसफ़ॉर्मेशन से संबंधित हैं। दुर्भाग्यपूर्ण मामलों में, जिनसे हम बचना चाहते हैं, कि चक्करदार परिवर्तन कुछ बहुत ही सरल है, जैसे 2 जोड़ना या -1 गुणा करना। सामान्य स्थिति में, हम आशा करते हैं कि एफाइन परिवर्तन पर्याप्त जटिल है कि मानक सांख्यिकीय परीक्षण दोनों धाराओं के बीच संबंध का पता नहीं लगा सकते हैं।

@mdickinson स्थिति को अच्छी तरह से कवर करता है। पीसीजी के क्रमपरिवर्तन एलसीजी मामले से चीजों को थोड़ा बदल देंगे, लेकिन बहुत कुछ नहीं। पीसीजी क्रमपरिवर्तन की पूरी बात यह है कि हम यह चुन सकते हैं कि कितना करना है। क्योंकि काटे गए 128-बिट LCG पहले से ही BigCrush को पास कर देते हैं, जब मैंने pcg64 लिए एक परमिट लिया था तो मैंने उस आकार LCG (XSL RR) के लिए एक मामूली राशि चुनी। इसके विपरीत, 64-बिट एलसीजी कई सांख्यिकीय परीक्षणों को जल्दी से विफल कर देते हैं, इसलिए pcg32 थोड़ा अधिक जुआ का उपयोग करता है, लेकिन यह अभी भी पीसीजी पेपर से सबसे मजबूत क्रमपरिवर्तन नहीं है। जैसा कि मैंने थ्रेड पुल-रिक्वेस्ट थ्रेड में उल्लेख किया है, मैंने pcg32 उपयोग के मामले के लिए एक मजबूत PCG क्रमचय (RXS M) की ओर झुकाव करना शुरू कर दिया है। यह अभी तक डिफ़ॉल्ट नहीं है, आपको उस संस्करण के लिए स्पष्ट रूप से पूछना होगा, लेकिन एक अच्छा मौका है जब मैं पीसीजी के लिए एक प्रमुख संस्करण टक्कर करता हूं, तो मैं डिफ़ॉल्ट पर स्विच करूंगा। (आरएक्सएस एम आरएक्सएस एम एक्सएस का आधा हिस्सा है, जिसे विग्ना ने इस आकार में बड़े पैमाने पर परीक्षण किया है और यह भी कि डेविड ब्लैकमैन को पसंद है)।

पीसीआर 32 (एक्सएचएस आरआर और आरसीएस एम [और कच्चे अंतर्निहित एलसीजी, भी] दोनों के लिए दोनों योजनाओं के उपयोग पर हम अंतर-धारा परीक्षण कार्यक्रम के एक अद्यतन संस्करण की कल्पना कर सकते हैं:)

#include "pcg_random.hpp"
#include <iostream>
#include <random>

// Create a "PCG" variant with a trivial output function, just truncation

template <typename xtype, typename itype>
struct truncate_only_mixin {
    static xtype output(itype internal)
    {
        constexpr size_t bits = sizeof(itype) * 8;
        return internal >> (bits/32);
    }
};

using lcg32 = pcg_detail::setseq_base<uint32_t, uint64_t, truncate_only_mixin>;

int main() {
    std::random_device rdev;
    uint64_t seed = 0;
    uint64_t stream = 0;
    for (int i = 0; i < 2; ++i) {
        seed   <<= 32;           
        seed   |= rdev();
        stream <<= 32;           
        stream |= rdev();
    }
    lcg32 rng1(seed,stream);
    lcg32 rng2(-seed,-1-stream);
    // pcg32 rng1(seed,stream);
    // pcg32 rng2(-seed,-1-stream);
    // pcg_engines::setseq_rxs_m_64_32 rng1(seed,stream);
    // pcg_engines::setseq_rxs_m_64_32 rng2(-seed,-1-stream);
    std::cerr << "RNG1: " << rng1 << "\n";
    std::cerr << "RNG2: " << rng2 << "\n";
    std::cout.precision(17);
    for (int i = 0; i < 10000; ++i) {
        std::cout << rng1()/4294967296.0 << "\t";
        std::cout << rng2()/4294967296.0 << "\n";
    }
}

शुरू करने से पहले, आइए देखें ग्राफ @mdickinson आकर्षित किया है, लेकिन सिर्फ एक LCG के लिए कोई क्रमपरिवर्तन नहीं है, बस छंटनी:

ध्यान दें कि यह उन राज्यों के साथ पैथोलॉजिकल एलसीजी के लिए है जो सहसंबंधित हैं। अगर इसके बजाय हम दो एलसीजी को बेतरतीब ढंग से चुने गए एडिटिव कॉन्स्टेंट (लेकिन समान स्टार्ट वैल्यू) के साथ लेंगे, तो यह इस तरह होगा:

PCG के आउटपुट फंक्शंस पर चलते हुए, यदि हम उपयोग करते हैं तो XSH RR पैथोलॉजिकल केस पर इस तरह दिखता है - यह ऊपर दिए गए ग्राफ़ पर एक बड़ा सुधार है, लेकिन स्पष्ट रूप से यह पूरी तरह से अस्पष्टता को अस्पष्ट नहीं कर रहा है:

और यह एक ही अंतर्निहित (बुरी तरह सहसंबद्ध) LCG जोड़ी के साथ RXS M है:

लेकिन यह केवल एक चीज है जिसे मैं pcg32 लिए मसल रहा हूं। प्रदर्शन जुर्माना छोटा है, और pcg32 इतना छोटा है कि मैं कुछ भारी उपयोगकर्ता को यादृच्छिक-वरीयता प्राप्त pcg32 जनरेटर बनाने और उनसे एक टन संख्या मांगने के बारे में चिंतित होने की कल्पना कर सकता हूं सहसंबंधों की एक असीम-पर्याप्त संभावना नहीं है। मैं, स्पष्ट रूप से, दो दिमागों में इसके बारे में यद्यपि, क्योंकि यह पौराणिक शक्ति उपयोगकर्ता पहली जगह में pcg32 का उपयोग कर रहा होगा।

एक कारण मैं बहुत अधिक pcg64 स्ट्रीम बनाने के बारे में परेशान नहीं हूं, इसलिए मुझे यकीन नहीं है कि मुझे एक ऐसा उपयोग मामला दिखाई दे रहा है, जहां सभी अन्य राज्य एक ही रखने और स्ट्रीम को स्विच करने के लिए समझदार होंगे एक अलग एक (जैसे, एक यादृच्छिक मूल्य के लिए, अकेले एक पास के लिए)। बहुत ज्यादा सभी PRNGs के लिए, एक दूसरे को बनाने का सही तरीका यह है कि इसे ताजा एन्ट्रोपी के साथ शुरू किया जाए।

अंत में, NumPy के लिए, मुझे लगता है कि यह सबसे अधिक समझ में आ सकता है कि PCG64 राज्य के दो 256 बिट्स चाहता है (तकनीकी रूप से यह 255 है क्योंकि स्ट्रीम के उच्च बिट को अनदेखा किया गया है) और इसे कॉल किया। यह एपीआई से संबंधित मुद्दों से भी बचना होगा क्योंकि यह एक कम सुविधा वाला व्यक्ति होगा जिसमें एक बिटगेंसर में होगा और दूसरे में नहीं।

(लेकिन आप 32-बिट पीसीजी वेरिएंट को आरएक्सएस एम वन में स्विच करना चाह सकते हैं। सी स्रोत के लिए, आपको एक हालिया संस्करण की आवश्यकता है क्योंकि मैंने सी कोड में स्पष्ट रूप से आरएक्सएस एम प्रदान करने की जहमत नहीं उठाई, केवल इसे सी ++ में उपलब्ध कराया। अवतार।)

[क्षमा करें यदि यह आप से अधिक जानना चाहते हैं! खैर, नहीं _that_ क्षमा करें। ;-)]

एक कारण मैं बहुत अधिक pcg64 स्ट्रीम बनाने के बारे में परेशान नहीं हूं वह यह है कि मुझे यकीन नहीं है कि मैं एक उपयोग मामला देख रहा हूं जहां यह सभी अन्य राज्य को समान रखने और स्ट्रीम को स्विच करने के लिए समझदार होगा एक अलग एक (जैसे, एक यादृच्छिक मूल्य के लिए, अकेले एक पास के लिए)। बहुत ज्यादा सभी PRNGs के लिए, एक दूसरे को बनाने का सही तरीका यह है कि इसे ताजा एन्ट्रोपी के साथ शुरू किया जाए।

मैंने पहले उपयोग के मामले का वर्णन किया है। एक स्टोकेस्टिक प्रोग्राम को लिखने के लिए मजबूत यूएक्स कारण हैं जो एक एकल "बीज" इनपुट को स्वीकार करता है (यानी एक कमांड-लाइन पर एक ईमेल से कॉपी-पेस्ट कर सकते हैं आकार के बारे में) जो तब प्रोग्राम के आउटपुट को निर्धारक बनाता है। @stevenjkern ने एक ऑफ़लाइन बातचीत में मुझे बताया कि नियामक एजेंसियों के साथ काम करने के लिए उस तरह की बातचीत आवश्यक थी जिसे उसके सॉफ़्टवेयर को मान्य करना था। यदि आपको परिणाम दोहराने के लिए किसी प्रोग्राम के रन के _output_ फ़ाइल का उपयोग करना था, तो ऐसी परिस्थितियों में थोड़ा संदिग्ध लगता है। नियामक को कोड पर एक गहरा गोता लगाना होगा (जो कि वास्तव में उनके लिए उपलब्ध नहीं हो सकता है) यह सुनिश्चित करने के लिए कि फ़ाइल की जानकारी वास्तव में कोषेर थी।

अब हमारे पास पायथन में अच्छे उपकरण हैं जो एन समानांतर प्रक्रियाओं को कताई के लिए गतिशील रूप से कुछ काम करते हैं फिर परिणाम इकट्ठा करते हैं और मुख्य प्रक्रिया में आगे बढ़ते हैं (फिर बाद में एम प्रक्रियाओं को स्पिन करते हैं, आदि)। एमपीआई जैसी पुरानी, ​​कम लचीली योजनाओं के विपरीत, हम शुरुआत में केवल एक निश्चित एन प्रक्रियाओं को स्पिन नहीं करते हैं। उन मामलों में, मैं प्रत्येक एन PRNGs में एन्ट्रापी-सीडिंग देख सकता था और उन्हें एक फ़ाइल में सहेज सकता था क्योंकि प्रोग्राम में सिर्फ एक ही जगह है जो ऐसा करता है। कम से कम एक प्रोग्रामिंग दृष्टिकोण से, यह बहुत कठिन नहीं है। हमारे पास अब समानता के लिए अधिक लचीले उपकरण हैं। PRNGs को सीडिंग करना अब अड़चन है जो हमें स्टोकेस्टिक कार्यक्रमों में उस लचीलेपन का उपयोग करने से रोकती है। अब जिम्मेदारी का एक भी बिंदु नहीं है जहां हम फ़ाइल-आधारित पुस्तक-रख रख सकते हैं।

एन स्ट्रीम को फिर से तैयार करने की आवश्यकता काफी मजबूत है कि लोग हमारे वर्तमान एमटी एल्गोरिदम के साथ इसे प्राप्त करने के लिए अजीब चीजें करेंगे। मुझे जोखिम भरी योजनाओं का एक समूह बनाना है, और मुझे उम्मीद थी कि पीसीजी की धाराएं हमें वहां पहुंचने में मदद करेंगी।

राज्य के समान रहते हुए, एक काउंटर अनुक्रम 0,1,2,3, ... से वेतन वृद्धि प्राप्त करने के लिए 2**63 / 2**127 का उपयोग करने के बारे में आप क्या सोचते हैं ...? क्या आप इसके साथ समस्याओं का पूर्वाभास करते हैं? राज्य को नए चक्र के एक हिस्से में स्थानांतरित करने के लिए एक बड़ी छलांग लगाने के बाद हैशेड वेतन वृद्धि के संयोजन के बारे में आप क्या सोचते हैं? शायद हम इस उप-चर्चा को ईमेल या किसी अन्य मुद्दे पर स्थानांतरित कर सकते हैं और वापस रिपोर्ट कर सकते हैं।

@ रेकर्न , ऐसा कुछ हो सकता है जो PRNGs को बहुत कम बीज देने में सक्षम होने के बारे में अच्छा लगता है, लेकिन (PRNG की परवाह किए बिना), यह एक भयानक विचार है। यदि आप बीज इनपुट के _k_ बिट्स प्रदान करते हैं, और फिर _k_ बिट्स की मांग करते हैं (या तो _j_ बिट्स को पहले छोड़ें [कुछ मनमाने तरीके से _j_] के लिए और फिर _k_ बिट्स पढ़ें), भले ही सभी 2 ^ _k_ बिट्स वैध इनपुट हैं, सभी 2 नहीं ^ _k_ आउटपुट देखे जा सकते हैं (क्योंकि बिट्स से बिट्स तक के फंक्शन की गारंटी नहीं दी जाती है [और वास्तव में ऐसा नहीं हो सकता है] एक आक्षेप)। अपेक्षित वितरण एक द्विपद (2 ^ k, 2 ^ -k) है, जिसे हम Poisson वितरण के रूप में अनुमानित कर सकते हैं और इस प्रकार 2 ^ k / e मान नहीं देखे जाएंगे। यह सही है कि PRNG क्या है। हम केवल इतना कर सकते हैं कि _k_ इतना बड़ा हो कि जो गायब है उसका पता लगाना पूरी तरह से अव्यावहारिक हो।

समस्या तब कंपाउंड हो जाती है जब हर कोई, एक ही PRNG (जैसे Mersenne ट्विस्टर) का उपयोग करके और एक ही छोटे सेट से बीज उठाता है (जैसे, 10000 से कम संख्या), क्योंकि एक विशेष रूप से प्रति प्रोग्राम बायस के बजाय, यह एक _for- हर कोई इस_ पूर्वाग्रह को कर रहा है। उदाहरण के लिए, मान लें कि आप चार अंकों का बीज चुनते हैं और फिर मेरसेन ट्विस्टर के बाहर संख्या को उचित संख्या में पकड़ लेते हैं, (कहते हैं, कम मिलियन)। उस स्थिति में, मैं आपको आश्वासन दे सकता हूं कि अशुभ संख्या 13 _will कभी नहीं दिखाती है_ क्योंकि 10 बिलियन आउटपुट में से कोई भी (वास्तव में 32-बिट पूर्णांक के 10% के बारे में अनुपस्थित होगा), और संख्या 123580738 को एक कारक द्वारा अधिलेखित किया गया है 16. यह वास्तव में हम दस बिलियन 32-बिट पूर्णांकों के यादृच्छिक नमूने के लिए उम्मीद करेंगे, लेकिन यह एक वास्तविक समस्या है। सभी लोग समान नमूना_ का उपयोग कर रहे हैं। अगर हम नौ अंकों के बीजों को उठाते हैं और केवल 10000 की संख्या ही खींचते हैं, तो हमें एक बिल्कुल अनुरूप समस्या होगी।

तथ्य यह है कि बहुत से लोग कुछ करना चाहते हैं यह एक अच्छा विचार नहीं है। (इसका मतलब यह नहीं है कि यह केवल उन लोगों को बताना ठीक है जो वे गलत कर रहे हैं या गलत काम करना चाहते हैं। आपको यह पता लगाना होगा कि उन्हें वास्तव में क्या चाहिए (उदाहरण के लिए, एक शॉर्ट-कमांड कमांड तर्क से प्रतिलिपि प्रस्तुत करने योग्य परिणाम हैं - संभवतः सही बात यह है कि यूयूआईडी और एक छोटे पूर्णांक से बीजारोपण की अनुमति दें, बीज डेटा बनाने के लिए इन चीजों को अच्छी तरह से कैसे बिखेरना है इसके लिए कुछ विचार इस ब्लॉग पोस्ट में पाए जा सकते हैं और रंडुटिल्स में अपना रास्ता बना सकते हैं।)

(यहाँ कोड के साथ खेलना है, क्योंकि यह काफी छोटा है ...)

// mtbias.cpp -- warning, uses 4GB of RAM, runs for a few minutes
// note: this is *not* showing a problem with the Mersenne Twister per se, it is
// showing a problem with simplistic seeding

#include <vector>
#include <iostream>
#include <random>
#include <cstdint>

int main() {
    std::vector<uint8_t> counts(size_t(std::mt19937::max()) + 1);
    for (size_t seed=0; seed < 10000; ++seed) {
        std::mt19937 rng(seed);
        for (uint i = 0; i < 1000000; ++i) {
            ++counts[rng()];
        }
    }
    size_t shown = 0;
    std::cout << "Never occurring: ";
    for (size_t i = 0; i <= std::mt19937::max(); ++i) {
        if (counts[i] == 0) {
            std::cout << i << ", ";
            if (++shown >= 20) {
                std::cout << "...";
                break;
            }
        }
    }
    std::cout << "\nMost overrepresented: ";
    size_t highrep_count = 0;
    size_t highrep_n = 0;
    for (size_t i = 0; i <= std::mt19937::max(); ++i) {
        if (counts[i] > highrep_count) {
            highrep_n = i;
            highrep_count = counts[i];
        }
    }
    std::cout << highrep_n << " -- repeated " << highrep_count << " times\n";
}

जैसा कि मैंने पहले कहा है, मुझे लगता है कि उस उद्देश्य के लिए 128-बिट बीज काफी कम हैं, और मैं टूलिंग का निर्माण उन लोगों को प्रोग्राम लिखने में मदद करने के लिए कर सकता हूं जो सही काम करते हैं। अर्थात्, उन्हें डिफ़ॉल्ट रूप से एंट्रॉपी-सैंपल दें, उन्हें प्रिंट करें या अन्यथा उन्हें लॉग इन करें, फिर बाद में इसे पारित करने की अनुमति दें। प्रत्येक कार्यक्रम के लिए एक यूयूआईडी बनाने और संभवतः एक छोटे उपयोगकर्ता-प्रदान किए गए बीज प्रति रन में मिश्रण करने की आपकी सिफारिश भी एक अच्छी है।

चलो मान लेते हैं कि मैं लोगों को PCG64 , एक तरह से या दूसरे के राज्य के हिस्से के लिए अच्छे 128-बिट बीज का उपयोग करने के लिए मिल सकता है। क्या आपके पास उसी राज्य से प्राप्त होने वाली धाराओं पर कोई टिप्पणी है? मैं अधिक संख्याएँ नहीं देख रहा हूँ, कुल मिलाकर, हम एक PCG64 स्ट्रीम से। मैं बस प्रत्येक ड्रा पर समन्वय के बिना विभिन्न प्रक्रियाओं में इन नंबरों को आकर्षित करने में सक्षम होना चाहता हूं। एक तदर्थ 63-बिट मल्टीप्लेशिफ्ट हैश का उपयोग करना अब तक बहुत अच्छा काम करने लगता है (मैं अभी 32 GiB पर हूं), 8192 स्ट्रीम के लिए इंटरलेय्ड।

@imneme

यह परिभाषित करने में मददगार हो सकता है कि हम संक्षेप में क्या कहते हैं।

मुझे लगता है कि @rkern ने लिखा है "आकार के बारे में कुछ वे एक कमांड लाइन पर एक ईमेल से कॉपी-पेस्ट कर सकते हैं"। मैं कुछ वर्णों जैसे 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff ’में से कुछ वर्णों में बहुत बड़ी संख्या का प्रतिनिधित्व कर सकता हूं।

मैं बस प्रत्येक ड्रा पर समन्वय के बिना विभिन्न प्रक्रियाओं में इन नंबरों को आकर्षित करने में सक्षम होना चाहता हूं। एक तदर्थ 63-बिट मल्टीप्लेशिफ्ट हैश का उपयोग करना अब तक बहुत अच्छा काम करने लगता है (मैं अभी 32 GiB पर हूं), 8192 स्ट्रीम के लिए इंटरलेय्ड।

क्या आपने कुछ बड़ी पर्याप्त संख्या में राज्य को आगे बढ़ाते हुए एकल गुणवत्ता के बीज का उपयोग करके n स्ट्रीम की कोशिश की है (जो 2 ** 64 है, जो कि PCG64.jumped द्वारा उपयोग किया जाता है)? ऐसा लगता है कि शिथिल तरीके से बड़े पैमाने पर n धाराओं को PCG64(seed).jumped(node_id) जैसी किसी चीज़ का उपयोग करने के लिए सबसे सरल तरीके से समन्वित किया जा सकता है

जहाँ node_id 0,1,2 है, ...

क्या कोई PRNG है जो इंडेक्स जैसी किसी चीज़ का उपयोग करके सरल स्वतंत्र स्ट्रीम बनाने में वास्तव में अच्छा है? मुझे लगता है कि एक MLFG कर सकते हैं, लेकिन मुझे यह पसंद नहीं आया क्योंकि यह 63-बिट जनरेटर था।

@bashtage , जो वास्तव में इसे करने का सही तरीका नहीं है। सही तरीका एक बीज लेना है, यदि आप एक छोटे पूर्णांक में जोड़ना चाहते हैं, तो इसे हैश करने के लिए हैश फ़ंक्शन का उपयोग करें। जैसा कि पहले उल्लेख किया गया है, मैंने पहले (पीसीजी से स्वतंत्र) एक गंभीर मिक्सिंग फ़ंक्शन लिखा

आदर्श रूप से, आप एक ऐसा तंत्र चाहते हैं जो पीसीजी के लिए विशिष्ट न हो। पीसीजी आपकी डिफ़ॉल्ट पसंद नहीं हो सकता है, और भले ही यह था, आप चाहते हैं कि लोग सभी जनरेटर के साथ समान काम करें। मुझे नहीं लगता कि आपको कई स्वतंत्र PRNG बनाने के लिए एक योजना चाहिए जो धाराओं या कूद-आगे पर निर्भर है।

(उफ़, मैं गलत ब्लॉग पोस्ट से जुड़ा हुआ हूं; मैंने पिछला संदेश संपादित किया है, लेकिन यदि आप ईमेल के माध्यम से पढ़ रहे हैं, तो मेरा मतलब इस ब्लॉग पोस्ट से लिंक करना है)

@imneme अभी, सभी जेनरेटर में हमारे पास एक कूद का समर्थन है (जिनमें से कुछ वास्तव में अग्रिम-प्रकार की कॉल हैं)। मुझे इसमें कोई संदेह नहीं है कि सावधानीपूर्वक बोना एक अच्छा विचार है, मुझे संदेह है कि कई उपयोगकर्ता PRNG.jumped() कॉल का उपयोग करने के लिए लुभाए जाएंगे। क्या यह कुछ ऐसा है जिसे अस्वीकार किया जाना चाहिए?

बीजारोपण के लिए, एमटी जनरेटर सभी लेखक के इनिट रूटीन का उपयोग करते हैं, पीसीजी आपका उपयोग करता है, और शेष कुछ ऐसा होता है

seed = np.array(required_size, dtype=np.uint64)
last = 0
for i in range(len(user_seed))
    if i < len(user_seed)
        last = seed[i] = splitmix64(last ^ user_seed[i])
    else:
        last = seed[i] = splitmix64(last)

मुझे लगता है कि इसमें सुधार किया जा सकता है।

क्या यह कुछ ऐसा है जिसे अस्वीकार किया जाना चाहिए?

मैंने jumped नहीं देखे थे। यह अंतर्निहित LCG के लिए बहुत भयानक है।

मान लें कि हमारे पास 0x96704a6bb5d2c4fb3aa645df0540268d गुणक, M है। यदि हम M ^ (2 ^ 64) की गणना करते हैं, तो हमें 0x6147671fb92252440000000000000001 जो कि एक भयानक LCG गुणक है। इस प्रकार यदि आप 128-बिट एलसीजी से हर 2 ^ 64 वां आइटम लेते हैं तो यह भयानक होगा (कम ऑर्डर बिट्स सिर्फ एक काउंटर हैं)। पीसीजी के मानक क्रमोन्नति कार्यों को एक LCG के सामान्य आउटपुट को स्क्रैम्बल करने के लिए डिज़ाइन किया गया है, न कि स्क्रैम्बल काउंटरों के लिए।

PCG64 को वर्तमान में प्रैक्ट्रैंड के साथ आधे पेटाबाइट तक परीक्षण किया गया है और आगे के विश्लेषण से पता चलता है कि आप दो की शक्तियों से संबंधित मुद्दों के बिना कई पेटाबाइट्स पढ़ सकते हैं। काश, अगर आप दो की आगे की विशाल सटीक शक्तियों को छोड़ने के लिए कूदते हैं, तो पीसीजी के सामान्य (कुछ हद तक मामूली) क्रमिक रूप से अंतर्निहित LCG की विशाल दूरी को लंघन से रोग अनुक्रम के लिए पर्याप्त रूप से क्षतिपूर्ति नहीं कर सकते हैं। आप इसे ठीक करने के लिए क्रमपरिवर्तन-शक्ति को आगे बढ़ा सकते हैं, और वास्तव में मैं और विग्ना दोनों स्वतंत्र रूप से पीसीजी के मानक क्रमपरिवर्तन की तुलना में ऑफ-द-शेल्फ पूर्णांक हैश फ़ंक्शंस की तुलना में करेंगे, जो संभवतः ऐसा करेंगे (आखिरकार, वे स्प्लिटमिक्स की नींव हैं जो _is_ बस एक काउंटर)। जब मैंने 2014 में फास्ट हैश के साथ इसे देखा तो गति इतनी शानदार नहीं लग रही थी, लेकिन जब विग्ना ने इसे हाल ही में बड़बड़ाहट के साथ किया, तो उन्होंने दावा किया कि मानक पीसीजी (!) को हराया।

यदि आप वास्तव में 2 ^ 64 का जंप-फ़ॉरवर्ड करना चाहते हैं, तो मुझे लगता है कि आपको एक मजबूत आउटपुट फंक्शन परमीशन पर स्विच करने की ज़रूरत है (जो कि हमने देखा है कि कम लागत पर किया जा सकता है)। लेकिन अगर आपको लगता है कि यह वास्तव में "मानक" पीसीजी नहीं बनाता है और सामान्य आउटपुट क्रमांकन रखना चाहता है, तो jumped() शायद जाने की आवश्यकता है।

(BTW, पैथोलॉजिकल जंप-फॉरवर्ड अन्य PRNG पर भी लागू होता है। स्प्लिटमिक्स को कुछ खराब वेतन वृद्धि के लिए जाना जाता है और यह मान लेना उचित है कि हालांकि 0xd2424737395bb84d9 का सामान्य वेतन वृद्धि (a.ka. "गामा") 2 ^ से आगे है। 32 आपको 0x95fb84d900000000 का इंक्रीमेंट देगा, जो इतना अच्छा नहीं है। LFSRs के लिए, खराब जंप-फॉरवर्ड शायद दो की शक्ति नहीं है, लेकिन मुझे पूरा यकीन है कि ऐसे कूद होंगे जहां अंतर्निहित मैट्रिक्स पैथोलॉजिकल रूप से बढ़ेंगे। विरल।)

मैं पुष्टि कर सकता हूं, कम से कम PCG32 , .jumped() का उपयोग करके 4 इंटरलेस्ड स्ट्रीम बहुत जल्दी विफल हो जाती हैं।

❯ ./pcg_streams.py --jumped -n 4 | time ./RNG_test stdin32
[
    {
        "bit_generator": "PCG32",
        "state": {
            "state": 10149010587776656704,
            "inc": 2891336453
        }
    },
    {
        "bit_generator": "PCG32",
        "state": {
            "state": 1158608670957446464,
            "inc": 2891336453
        }
    },
    {
        "bit_generator": "PCG32",
        "state": {
            "state": 10614950827847787840,
            "inc": 2891336453
        }
    },
    {
        "bit_generator": "PCG32",
        "state": {
            "state": 1624548911028577600,
            "inc": 2891336453
        }
    }
]
RNG_test using PractRand version 0.93
RNG = RNG_stdin32, seed = 0xeedd49a8
test set = normal, folding = standard (32 bit)

rng=RNG_stdin32, seed=0xeedd49a8
length= 128 megabytes (2^27 bytes), time= 2.1 seconds
  Test Name                         Raw       Processed     Evaluation
  BCFN(2+0,13-3,T)                  R= +58.7  p =  1.3e-27    FAIL !!!       
  BCFN(2+1,13-3,T)                  R= +48.0  p =  1.5e-22    FAIL !!        
  BCFN(2+2,13-3,T)                  R= +16.0  p =  2.3e-7   very suspicious  
  DC6-9x1Bytes-1                    R= +53.5  p =  1.8e-32    FAIL !!!       
  [Low8/32]DC6-9x1Bytes-1           R= +27.4  p =  1.1e-17    FAIL !         
  ...and 112 test result(s) without anomalies

आदर्श रूप से, आप एक ऐसा तंत्र चाहते हैं जो पीसीजी के लिए विशिष्ट न हो। पीसीजी आपकी डिफ़ॉल्ट पसंद नहीं हो सकता है, और भले ही यह था, आप चाहते हैं कि लोग सभी जनरेटर के साथ समान काम करें।

खैर, यही हम यहाँ तय करने की कोशिश कर रहे हैं। :-) हम प्रत्येक PRNG द्वारा प्रदान की जाने वाली विशेषताओं को उजागर करने के लिए यथोचित रूप से सामग्री थे, इस धारणा पर कि प्रत्येक एल्गोरिदम द्वारा उजागर किए गए गुणों का अच्छी तरह से अध्ययन किया जाता है। हम यह कहते हुए यथोचित सामग्री दे रहे हैं कि "यहाँ डिफ़ॉल्ट PRNG की हम अनुशंसा करते हैं; इसमें सुविधाओं का एक समूह है जो उपयोगी हैं, दूसरे उनके पास नहीं हो सकते हैं"।

किसी भी एल्गोरिथ्म के लिए एक दिए गए राज्य और एक धारा आईडी से एक नया राज्य प्राप्त करने के लिए एक हैश का उपयोग करने की धारणा दिलचस्प है। क्या आप जानते हैं कि इसका कितना अच्छा अध्ययन किया गया है? यह सत्यापित करने के लिए एक शोध समस्या की तरह लगता है कि यह सभी एल्गोरिदम के लिए अच्छा काम करता है। मैं "यहाँ सभी PRNGs के लिए स्वतंत्र स्ट्रीम प्राप्त करने की सामान्य प्रक्रिया" का दावा करने में संकोच करूँगा। मैं स्वतंत्र धाराओं को प्राप्त करने के लिए "यहां एक सामान्य एपीआई के साथ अधिक सामग्री हूं, प्रत्येक PRNG इसे एल्गोरिथ्म के लिए उपयुक्त तरीके से लागू करता है और यदि एल्गोरिथ्म इसे अच्छी तरह से समर्थन नहीं करता है तो इसे लागू नहीं कर सकता है"।

दूसरी ओर, अगर यह प्रैक्ट्रेड पर एन GiB के लिए प्रत्येक BitGenerator लिए interleaved धाराओं का परीक्षण करने के लिए पर्याप्त सीपीयू चक्र आवंटित करने की बात है, तो यह भी बहुत अच्छा नहीं है।

किसी भी एल्गोरिथ्म के लिए एक दिए गए राज्य और एक धारा आईडी से एक नया राज्य प्राप्त करने के लिए एक हैश का उपयोग करने की धारणा दिलचस्प है। क्या आप जानते हैं कि इसका कितना अच्छा अध्ययन किया गया है? यह सत्यापित करने के लिए एक शोध समस्या की तरह लगता है कि यह सभी एल्गोरिदम के लिए अच्छा काम करता है। मैं "यहाँ सभी PRNGs के लिए स्वतंत्र स्ट्रीम प्राप्त करने की सामान्य प्रक्रिया" का दावा करने में संकोच करूँगा। मैं स्वतंत्र धाराओं को प्राप्त करने के लिए "यहां एक सामान्य एपीआई के साथ अधिक सामग्री हूं, प्रत्येक PRNG इसे एल्गोरिथ्म के लिए उपयुक्त तरीके से लागू करता है और यदि एल्गोरिथ्म इसे अच्छी तरह से समर्थन नहीं करता है तो इसे लागू नहीं कर सकता है"।

मुझे नहीं पता है कि आप इसे "एक शोध समस्या" (और इस तरह "अच्छी तरह से अध्ययन किया गया") कह सकते हैं, लेकिन C ++ 11 (जो कि ज्यादातर कोशिश की गई और सच्ची लंबी-स्थापित तकनीकों का उपयोग करने के बारे में है) _SeedSequence_ अवधारणा प्रदान करता है (और एक विशिष्ट std::seed_seq कार्यान्वयन) जिसका काम पूरी तरह से मनमाने ढंग से PRNGs को सीडिंग डेटा प्रदान करना है।

सामान्य तौर पर, लगभग सभी PRNG रैंडम बिट्स के साथ इनिशियलाइज़ / सीडेड होने की उम्मीद करते हैं। यादृच्छिक बिट्स के बारे में कुछ भी विशेष रूप से जादुई नहीं है (कहना) random.org और यादृच्छिक बिट्स कुछ अधिक एल्गोरिदम (सीएस PRNG, हैश फ़ंक्शन, आदि) से बाहर आ रहे हैं।

एक ही योजना के PRNGs के संग्रह के बारे में सोचने के लिए यह बिल्कुल सीधा है कि सभी अपने स्वयं के यादृच्छिक बिट्स के साथ वरीयता प्राप्त करते हैं। आप सोच सकते हैं कि हम पिकिंग पॉइंट्स के रूप में क्या कर रहे हैं (या वास्तव में एक निश्चित अधिकतम लंबाई तक अंतराल है जो यादृच्छिक संख्या की मात्रा के अनुरूप है, हम कभी-कभी लाइन पर उदासीन रूप से पूछने की उम्मीद करते हैं, उदाहरण के लिए, 2 ^ 56)। 2 ^ 255 अंकों के साथ लाइन)। हम इस संभावना की गणना कर सकते हैं कि यदि हम _n_ अंतराल के लिए पूछते हैं कि एक दूसरे के साथ ओवरलैप करेगा। यह काफी बुनियादी संभावना है - मुझे यकीन नहीं है कि आप इसके बारे में प्रकाशित एक पेपर प्राप्त कर सकते हैं क्योंकि (जैसा कि मैं इसे समझता हूं) कोई भी प्रारंभिक गणित वाले पेपर के बारे में कभी भी उत्साहित नहीं होता है। ( @ शायर असहमत हो सकता है!)

[मैं तर्क दूंगा कि आपको आमतौर पर _not_ क्या करना चाहिए, एक PRNG है, जिसमें यादृच्छिक बिट्स खुद से निकलते हैं। ऐसा लगता है कि मेरे लिए बहुत ज्यादा अशोभनीय है।]

ठीक है, यह मेरे लिए स्पष्ट है कि एक अच्छी तरह से डिज़ाइन किए गए _SeedSequence_ की तरह कुछ का उपयोग करना एक मनमाना प्रारंभिक बीज लेने और हमारे एल्गोरिथ्म के चक्र में कई शुरुआती बिंदुओं को खींचने का एक तरीका होगा जो ओवरलैप नहीं करना चाहिए। और अगर यह स्वतंत्र धाराओं को प्राप्त करने का एकमात्र वास्तविक तरीका है, तो यह हो। यह सुविधाजनक बनाने के लिए एपीआई डिजाइन की बात होगी।

आरंभिक PRNG की वर्तमान स्थिति को लेने के लिए यह कितना सुरक्षित है, इस बारे में मैं स्पष्ट नहीं हूं, चक्र में एक नए राज्य में कूदने के लिए स्ट्रीम आईडी में हैश-मिक्स है, जो कि मुझे लगा कि आप सुझाव दे रहे थे (और यह बाद में मेरे साथ हुआ कि मैं उसके बारे में गलत हो सकता था)। jumped() शो की विफलता के रूप में चक्र में अच्छी तरह से अलग होना एकमात्र कारक नहीं है। jumped() यह भी आश्वासन देता है कि आपको उस अनुक्रम के एक बहुत बड़े हिस्से में भेजा जा रहा है जो ओवरलैप नहीं होगा; यह सिर्फ एक हिस्सा है जो शुरुआती हिस्से के साथ बहुत दृढ़ता से सहसंबंधित कर सकता है यदि कूद अच्छी तरह से चुना नहीं गया है। यह जानने के लिए कि क्या अच्छा है और क्या नहीं है प्रत्येक एल्गोरिथ्म के कुछ ज्ञान को ले सकते हैं। हम स्पष्ट रूप से पीसीजी के मामले के लिए नहीं थे।

मौलिक रूप से, अगर हम PRNGs को संक्रमण कार्यों और आउटपुट कार्यों के रूप में सोचते हैं, तो यह new_state = seed_seq(old_state||streamID) केवल एक और संक्रमण फ़ंक्शन है जिसे हम एक चरण के लिए छोड़ रहे हैं। हमें यह सुनिश्चित करना होगा कि प्रत्येक PRNG एल्गोरिथ्म (या उनके व्युत्क्रम) में संक्रमण कार्यों से seed_seq शामिल ऑपरेशन अलग-अलग हों और हो सकता है कि उन्हें अन्य चीजों के बारे में सुनिश्चित करना पड़े। मैं कुछ, से कहते हैं, का निर्माण का उपयोग नहीं करना चाहते wyhash प्रारंभ करने में wyrand । जैसा कि आप कहते हैं, आप स्वयं बिट्स प्रदान करने के लिए PRNG का उपयोग नहीं करना चाहते हैं। इसलिए मुझे लगता है कि यह सभी PRNGs के लिए यह आश्वासन देने के लिए कुछ अध्ययन की आवश्यकता है (यह अध्ययन कि मैं उम्मीद कर रहा था कि मुझे खुद ऐसा नहीं करना होगा)।

दूसरी ओर, new_state = seed_seq(old_state||streamID) संभवतः इस संबंध में बंद से भी बदतर नहीं है, कई धाराओं के लिए _SeedSequence_ के उपयोग से: दो राज्यों को क्रम से बाहर निकालना। यदि ऐसा है, तो मैं ठीक है C ++ के अनुभव पर आराम कर सकता हूं, शायद आपके कार्यान्वयन के साथ, और बस हमारे सभी एल्गोरिदम के लिए प्रैक्ट्रैंड के साथ कुछ अनुभवजन्य परीक्षण कर रहे हैं कि वे अपने एकल-स्ट्रीम समकक्षों से बदतर नहीं हैं।

हैश-जंप का काम करना वास्तव में अच्छा होगा क्योंकि समन्वय-मुक्त तरीके से PRNGs को बंद करने के लिए कुछ यूजेस को खोलता है। स्ट्रीम आईडी का उपयोग करने के लिए कुछ संचार या पूर्व-आवंटन की आवश्यकता होती है। dask ने अतीत में कुछ इस तरह से मांगा है।

यदि अच्छे विकल्प हैं जो केवल अच्छी सीडिंग पर भरोसा करते हैं कि हम सही काम करने के लिए सुविधाजनक बना सकते हैं, तो हमें संभवतः डिफ़ॉल्ट के चयन के लिए मानदंड के रूप में व्यवस्थित धाराओं को हटा देना चाहिए। हम बस एक डिफ़ॉल्ट एल्गोरिथ्म चाहते हैं जिसमें पर्याप्त रूप से बड़े राज्य की जगह हो।

सभी ने कहा, ऐसा लगता है कि 63-बिट हैश का PCG32 क्रमानुसार स्ट्रीम आईडी से ( range(N) ) काम करने लगता है। 8192 इंटरलेव्ड स्ट्रीम प्रैक्टिरैंड को 2 टीआईबी से बाहर करती है। यदि हम PCG जनरेटर के लिए स्ट्रीम आईडी को उजागर करते हैं, तो हम इस तकनीक का उपयोग वेतन वृद्धि प्राप्त करने के लिए कर सकते हैं, भले ही हम सुझाव दें कि लोग अन्य साधनों का उपयोग करने के लिए स्वतंत्र धाराओं को प्राप्त करें।

आरंभिक PRNG की वर्तमान स्थिति को लेने के लिए यह कितना सुरक्षित है, इस बारे में मैं स्पष्ट नहीं हूं, चक्र में एक नए राज्य में कूदने के लिए स्ट्रीम आईडी में हैश-मिक्स है, जो कि मुझे लगा कि आप सुझाव दे रहे थे (और यह बाद में मेरे साथ हुआ कि मैं उसके बारे में गलत हो सकता था)।

मैंने संभवतः अपने आप को अस्पष्ट रूप से व्यक्त किया, लेकिन नहीं , मैं यह सुझाव देने के लिए कभी नहीं था कि PRNG की वर्तमान स्थिति का उपयोग आत्म-पुनर्निधारण में किया जाना चाहिए।

लेकिन, FWIW, स्प्लिटमिक्स ऐसा करता है, यह वही है जो split() ऑपरेशन करता है। और, मुझे यह पसंद नहीं है कि यह करता है।

यह बहुत अधिक जानकारी हो सकती है, लेकिन स्प्लिटमिक्स के split() फ़ंक्शन द्वारा मैं इस बारे में थोड़ा साझा करूंगा कि मैं क्यों भयभीत था (शायद इससे अधिक भयभीत होना चाहिए)। एक ऐतिहासिक नोट के रूप में, स्प्लिटमिक्स और पीसीजी को उसी समय के आसपास स्वतंत्र रूप से डिजाइन किया गया था (स्प्लिटमिक्स 20 अक्टूबर 2014 को प्रकाशित हुआ था, जबकि pcg-random.org अगस्त, 2014 में लाइव हो गया था और 5 सितंबर 2014 को PCG पेपर से जुड़ा था। )। पीसीजी और स्प्लिटमिक्स (और विभिन्न अन्य PRNGs के बीच कुछ समानताएं हैं, जिनमें विग्ना की xor शिफ्ट * और xorshift + भी शामिल है - 2014 में दुनिया के लिए जारी की गई)। सभी के पास काफी सरल नहीं-काफी-अच्छा-पर्याप्त-पर्याप्त राज्य संक्रमण फ़ंक्शन एक स्क्रूबल आउटपुट फ़ंक्शन द्वारा तय किया गया है। जब मैं पीसीजी पेपर लिख रहा था, तो एक बात जो मुझे पता था कि कुछ लोग चाहेंगे कि split() फंक्शन हो, लेकिन इसे करने का एक अच्छा तरीका नहीं निकल सका; इसके बजाय मैंने एक त्वरित प्रमाण विकसित किया कि यदि आपके पास एक _k_-बिट PRNG है, जहाँ आप प्रत्येक चरण पर बाएं या दाएं जा सकते हैं, तो _k_ चरणों के भीतर आपको पहले से मौजूद राज्य में पहुंचने में सक्षम होना चाहिए, इस प्रकार पूरी अवधारणा साबित होगी बीमार था। उस अवलोकन ने इसे कागज में नहीं बनाया। लेकिन उस सबूत से पहले मेरे विचार के विचार के परिणामस्वरूप, पेपर के पास-फाइनल-ड्राफ्ट में एक फुटनोट में, मैंने सुझाव दिया, कुछ हद तक, क्योंकि पीसीजी का उत्पादन अपने राज्य का एक हैश / हाथापाई / क्रमोन्नति था, यदि आप थे नटखट महसूस कर आप जनरेटर को अपने स्वयं के आउटपुट के साथ फिर से शुरू कर सकते हैं और इसके साथ दूर हो सकते हैं। मैंने इसे अंतिम संस्करण से बाहर कर दिया क्योंकि मुझे लगा था कि समीक्षकों के लिए इस तरह की सनकी लाल झंडा बहुत बड़ा होगा, यह देखते हुए कि अपने स्वयं के राज्य के साथ एक PRNG को फिर से संगठित करना एक PRNG के दुरुपयोग का प्रकार माना जाता था, और इस तरह हम उन लोगों से देखते हैं जो उनका उपयोग करने में अनुभवहीन हैं।

स्प्लिटमिक्स पेपर को पढ़ना, मुझे बहुत पसंद आया, लेकिन जब मैंने split() देखा, तो मुझे बहुत बुरा लगा। इसने कुछ ऐसा किया जिसे मैंने मूल रूप से केवल एक मजाक के रूप में माना और इसे एक टैम्पोल सुविधा बना दिया। यह कुछ साल बाद तक नहीं था जब मुझे इस तरह के ऑपरेशन के बारे में अधिक तकनीकी गहराई में

कुल मिलाकर दूर यह है कि यदि आपके पास एक बड़ा पर्याप्त राज्य स्थान है (और स्प्लिटमिक्स मुश्किल से पर्याप्त है), तो आप हैश फ़ंक्शन के माध्यम से स्वयं को पुनः प्राप्त करने में सक्षम हो सकते हैं। मुझे अभी भी लगता है कि यह एक अच्छा विचार नहीं है। क्योंकि रैंडम मैपिंग (जो हम इस स्थिति में काम कर रहे हैं) जैसे गुण होते हैं जैसे "नॉन जीरो एसिम्प्टोटिक प्रायिकता के साथ, एक कार्यात्मक ग्राफ में सबसे ऊंचा पेड़ सबसे लंबे चक्र पर निहित नहीं होता है", मेरा दावा है कि पूर्ण आत्मविश्वास होना कठिन है जब तक कि डिजाइनर यह दिखाने के लिए आवश्यक कार्य पर नहीं गए हैं कि इस तरह की विकृति उनके डिजाइन में मौजूद नहीं है।

मज़े के लिए, यहाँ स्प्लिटमिक्स के एक छोटे संस्करण के राज्य-स्थान का एक डंप है, जो next() और split() के संयोजन के विभिन्न (और कठोरता से निश्चित) तरीकों में से तीन को खोज रहा है:

Testing: SplitMix16: void advance() { rng = rng.split();}

Finding cycles...
- state 00000000 -> new cycle 1, size 4, at 000043b0 after 516 steps
- state 00000050 -> new cycle 2, size 41, at 00002103 after 2 steps
- state 000000cd -> new cycle 3, size 4, at 0000681a after 6 steps
- state 00000141 -> new cycle 4, size 23, at 00004001 after 11 steps
- state 00000dee -> new cycle 5, size 7, at 00007436 after 4 steps
- state 00008000 -> new cycle 6, size 90278, at 5e5ce38c after 46472 steps
- state 00030000 -> new cycle 7, size 6572, at 12c65374 after 10187 steps
- state 00030016 -> new cycle 8, size 3286, at 65d0fc0c after 402 steps
- state 00058000 -> new cycle 9, size 17097, at 2a2951fb after 31983 steps
- state 08040000 -> new cycle 10, size 36, at 08040000 after 0 steps
- state 08040001 -> new cycle 11, size 218, at 08040740 after 360 steps
- state 08040004 -> new cycle 12, size 10, at 38c01b3d after 107 steps
- state 08040006 -> new cycle 13, size 62, at 38c013a0 after 39 steps
- state 08040009 -> new cycle 14, size 124, at 08045259 after 24 steps
- state 08040019 -> new cycle 15, size 32, at 38c06c63 after 151 steps
- state 08040059 -> new cycle 16, size 34, at 38c00217 after 17 steps
- state 08040243 -> new cycle 17, size 16, at 38c06e36 after 13 steps
- state 123c8000 -> new cycle 18, size 684, at 77d9595f after 194 steps
- state 123c8002 -> new cycle 19, size 336, at 5de8164d after 141 steps
- state 123c9535 -> new cycle 20, size 12, at 123c9535 after 0 steps
- state 139f0000 -> new cycle 21, size 545, at 743e3a31 after 474 steps
- state 139f0b35 -> new cycle 22, size 5, at 139f0b35 after 0 steps
- state 139f1b35 -> new cycle 23, size 5, at 68d3c943 after 8 steps

Cycle Summary:
- Cycle 1, Period 4, Feeders 32095
- Cycle 2, Period 41, Feeders 188
- Cycle 3, Period 4, Feeders 214
- Cycle 4, Period 23, Feeders 180
- Cycle 5, Period 7, Feeders 12
- Cycle 6, Period 90278, Feeders 1479024474
- Cycle 7, Period 6572, Feeders 102385385
- Cycle 8, Period 3286, Feeders 5280405
- Cycle 9, Period 17097, Feeders 560217399
- Cycle 10, Period 36, Feeders 413
- Cycle 11, Period 218, Feeders 51390
- Cycle 12, Period 10, Feeders 1080
- Cycle 13, Period 62, Feeders 4113
- Cycle 14, Period 124, Feeders 4809
- Cycle 15, Period 32, Feeders 2567
- Cycle 16, Period 34, Feeders 545
- Cycle 17, Period 16, Feeders 87
- Cycle 18, Period 684, Feeders 95306
- Cycle 19, Period 336, Feeders 100263
- Cycle 20, Period 12, Feeders 7
- Cycle 21, Period 545, Feeders 163239
- Cycle 22, Period 5, Feeders 12
- Cycle 23, Period 5, Feeders 34

- Histogram of indegrees of all 2147483648 nodes:
      0  529334272
      1 1089077248
      2  528875520
      3     131072
      4      65536

Testing: SplitMix16: void advance() { rng.next(); rng = rng.split();}

Finding cycles...
- state 00000000 -> new cycle 1, size 36174, at 6b34fe8b after 21045 steps
- state 00000002 -> new cycle 2, size 4300, at 042a7c6b after 51287 steps
- state 0000000f -> new cycle 3, size 11050, at 0b471eb5 after 4832 steps
- state 0000001d -> new cycle 4, size 38804, at 2879c05c after 16280 steps
- state 00000020 -> new cycle 5, size 4606, at 46e0bdf6 after 7379 steps
- state 00046307 -> new cycle 6, size 137, at 0a180f87 after 89 steps
- state 00081c25 -> new cycle 7, size 16, at 177ed4d8 after 27 steps
- state 0044c604 -> new cycle 8, size 140, at 5e1f125b after 44 steps
- state 006e329f -> new cycle 9, size 18, at 006e329f after 0 steps
- state 13ebcefc -> new cycle 10, size 10, at 13ebcefc after 0 steps

Cycle Summary:
- Cycle 1, Period 36174, Feeders 975695553
- Cycle 2, Period 4300, Feeders 766130785
- Cycle 3, Period 11050, Feeders 110698235
- Cycle 4, Period 38804, Feeders 251133911
- Cycle 5, Period 4606, Feeders 43723200
- Cycle 6, Period 137, Feeders 4101
- Cycle 7, Period 16, Feeders 172
- Cycle 8, Period 140, Feeders 2310
- Cycle 9, Period 18, Feeders 124
- Cycle 10, Period 10, Feeders 2

- Histogram of indegrees of all 2147483648 nodes:
      0  529334272
      1 1089077248
      2  528875520
      3     131072
      4      65536

Testing: SplitMix16: void advance() { rng.next(); rng = rng.split(); rng = rng.split();}

Finding cycles...
- state 00000000 -> new cycle 1, size 40959, at 0069b555 after 49520 steps
- state 00000031 -> new cycle 2, size 1436, at 5f619520 after 2229 steps
- state 000003a4 -> new cycle 3, size 878, at 18d1cb99 after 1620 steps
- state 0000046c -> new cycle 4, size 2596, at 46ba79c0 after 1591 steps
- state 0000c6e2 -> new cycle 5, size 24, at 0212f11b after 179 steps
- state 000af7c9 -> new cycle 6, size 61, at 40684560 after 14 steps
- state 00154c16 -> new cycle 7, size 110, at 29e067ce after 12 steps
- state 0986e055 -> new cycle 8, size 4, at 2b701c82 after 7 steps
- state 09e73c93 -> new cycle 9, size 3, at 352aab83 after 1 steps
- state 19dda2c0 -> new cycle 10, size 1, at 78825f1b after 2 steps

Cycle Summary:
- Cycle 1, Period 40959, Feeders 2129209855
- Cycle 2, Period 1436, Feeders 5125630
- Cycle 3, Period 878, Feeders 7077139
- Cycle 4, Period 2596, Feeders 5997555
- Cycle 5, Period 24, Feeders 24221
- Cycle 6, Period 61, Feeders 1774
- Cycle 7, Period 110, Feeders 1372
- Cycle 8, Period 4, Feeders 23
- Cycle 9, Period 3, Feeders 4
- Cycle 10, Period 1, Feeders 3

- Histogram of indegrees of all 2147483648 nodes:
      0  829903716
      1  684575196
      2  468475086
      3  132259769
      4   32192209
      5      58402
      6      17026
      7       1982
      8        261
      9          1

Testing: SplitMix16: void advance() { rng.next(); rng.next(); rng = rng.split();}

Finding cycles...
- state 00000000 -> new cycle 1, size 55038, at 3e57af06 after 30005 steps
- state 00000005 -> new cycle 2, size 376, at 4979e8b5 after 6135 steps
- state 0000001e -> new cycle 3, size 10261, at 0cd55c94 after 1837 steps
- state 0000002d -> new cycle 4, size 3778, at 7f5f6afe after 3781 steps
- state 00000064 -> new cycle 5, size 2596, at 3bc5404b after 5124 steps
- state 0000012b -> new cycle 6, size 4210, at 525cc9f3 after 397 steps
- state 00000277 -> new cycle 7, size 1580, at 410010c8 after 1113 steps
- state 00001394 -> new cycle 8, size 916, at 7b20dfb0 after 193 steps
- state 00063c2d -> new cycle 9, size 51, at 6e92350b after 121 steps
- state 058426a6 -> new cycle 10, size 8, at 058426a6 after 0 steps
- state 0e5d412d -> new cycle 11, size 1, at 0e5d412d after 0 steps
- state 4c2556c2 -> new cycle 12, size 1, at 4c2556c2 after 0 steps

Cycle Summary:
- Cycle 1, Period 55038, Feeders 2027042770
- Cycle 2, Period 376, Feeders 28715945
- Cycle 3, Period 10261, Feeders 49621538
- Cycle 4, Period 3778, Feeders 13709744
- Cycle 5, Period 2596, Feeders 15367156
- Cycle 6, Period 4210, Feeders 10418779
- Cycle 7, Period 1580, Feeders 1782252
- Cycle 8, Period 916, Feeders 744273
- Cycle 9, Period 51, Feeders 2351
- Cycle 10, Period 8, Feeders 24
- Cycle 11, Period 1, Feeders 0
- Cycle 12, Period 1, Feeders 0

- Histogram of indegrees of all 2147483648 nodes:
      0  529334272
      1 1089077248
      2  528875520
      3     131072
      4      65536

आदि।

आह, महान। मैंने कुछ साल पहले उन पंक्तियों के साथ कुछ प्रस्तावों को शूट किया था, इसलिए मुझे डर था कि हम कुछ अच्छा करने से चूक गए। :-)

पीसीजी धाराओं के लिए वेतन वृद्धि के लिए हैश दृष्टिकोण पर कोई अंतिम विचार? यह निर्धारित करना कि स्वतंत्र धारा प्राप्त करने का मुख्य तंत्र है या नहीं। उस सुविधा तक पूरी तरह से पहुंच को कम करने, ऐसा लगता है कि कुछ ऐसा है जिसे हम आसानी से दुरुपयोग करने वाले अनुक्रमिक आईडी को रोकने के लिए करना चाहते हैं।

जिज्ञासा से बाहर, क्या यह बताने का कोई आसान (आसान) तरीका है कि PCG64 में दो राज्य कितने दूर हैं?

हां, हालांकि हम इसे उजागर नहीं करते हैं: http://www.pcg-random.org/useful-features.html#distance

जिज्ञासा से बाहर, क्या यह बताने का कोई आसान (आसान) तरीका है कि PCG64 में दो राज्य कितने दूर हैं?

हां, हालांकि हम इसे उजागर नहीं करते हैं: http://www.pcg-random.org/useful-features.html#distance

C ++ स्रोत में, दूरी फ़ंक्शन आपको धाराओं के बीच की दूरी भी बताएगा, निकटतम बिंदु के बारे में अपनी बात देगा (जहां धाराओं के बीच एकमात्र अंतर एक जोड़ा स्थिरांक है)।

संयोग से, अंतर्निहित LCG के लिए, हम दूरी को काम करने के लिए उपयोग कर सकते हैं कि हम पदों से कितने सहसंबद्ध हैं। थोड़ी दूरी स्पष्ट रूप से खराब है (और किसी भी PRNG के लिए बुरा है), लेकिन सिर्फ एक बिट सेट के साथ एक दूरी या तो महान नहीं है, यही कारण है कि 2 ^ 64 ( 0x10000000000000000 ) से आगे कूद रहा है। .jumped एक बुरा विचार है। मेरी पीसीजी टू-डू लिस्ट में " independence_score " फंक्शन लिखा हुआ है, जो दो राज्यों के बीच की दूरी को देखता है और आपको बताता है कि रैंडम-लुकिंग डिस्टेंस कितना है (वजन कम करने के माध्यम से, आदि) - आदर्श रूप से हम लगभग आधा चाहते हैं बिट्स शून्य और आधे वाले होते हैं और उन्हें उदारतापूर्वक बिखरे हुए होते हैं)।

एक तरह से करने के लिए _keep_ jumped PCG64 साथ द्वारा कूद नहीं होगा n * 0x10000000000000000 लेकिन इसके बजाय द्वारा कूद n * 0x9e3779b97f4a7c150000000000000000 (128 बिट तक छोटा कर दिया)। यह आपको उन सभी सामान्य गुणों को देगा जो आप चाहते हैं (अंतर्निहित .jumped(3).jumped(5) == .jumped(8) LC

(मुझे यह भी पता है कि " 0x10000000000000000 अग्रिम नहीं है" यह " अच्छी तरह से है, इसे इस तरह से प्रतिक्रिया न दें " और मैं इससे बहुत संतुष्ट नहीं हूँ। यकीन है, यह शांत है कि independence_score मौजूद हो सकता है, लेकिन यह पूरी बात (और समान धाराओं के साथ मुद्दा), एक मजबूत डिफ़ॉल्ट आउटपुट फ़ंक्शन के लिए बहस कर सकता है ताकि मैं भले ही लोगों को (दुर्लभ) चीजें करता हूं जो अंतर्निहित के लिए पूरी तरह से विकृतिपूर्ण हैं LCG, कोई नुकसान नहीं होगा। PCG इस बिंदु पर पांच साल पुराना हो रहा है, और मैं एक संस्करण टक्कर पर विचार कर रहा हूं और इस गर्मी में ट्विस्ट करता हूं, इसलिए यह मुद्दा सूची बना सकता है। बेशक, यह आप लोगों को परेशान कर सकता है। जिस तरह आप पीसीजी में डालते हैं, मैं एक प्रमुख संस्करण को टक्कर देता हूं और इसमें सुधार करता हूं।)

पीसीजी धाराओं के लिए वेतन वृद्धि के लिए हैश दृष्टिकोण पर कोई अंतिम विचार? यह निर्धारित करना कि स्वतंत्र धारा प्राप्त करने का मुख्य तंत्र है या नहीं। उस सुविधा तक पूरी तरह से पहुंच को कम करने, ऐसा लगता है कि कुछ ऐसा है जिसे हम आसानी से दुरुपयोग करने वाले अनुक्रमिक आईडी को रोकने के लिए करना चाहते हैं।

मैं आपको मुरमुर 3 मिक्सर के माध्यम से इसे डालने की सलाह 0x9e3779b97f4a7c15f39cc0605cedc835 (fract का आंशिक भाग) पसंद है, लेकिन 0xb7e151628aed2a6abf7158809cf4f3c7 (ई का आंशिक हिस्सा) भी ठीक होगा, या _any_ यादृच्छिक-दिखने वाली संख्या।)

मैं wyhash (https://github.com/wangyi-fudan/wyhash) की सलाह देता हूं क्योंकि यह सबसे तेज़ और सबसे सरल है जो BigCrush और PracticeRand से गुजरता है। C कोड जितना सरल है

inline  uint64_t    wyrand(uint64_t *seed){    
    *seed+=0xa0761d6478bd642full;    
    __uint128_t t=(__uint128_t)(*seed^0xe7037ed1a0b428dbull)*(*seed);    
    return  (t>>64)^t;    
}

@ wangyi-fudan, मैं खुद को नहीं समझा सकता कि यह एक आपत्ति है।

मेरे सीमित ज्ञान के लिए क्षमा करें: PRNG के लिए बायजेक्शन आवश्यक / इष्ट क्यों है?
कुछ स्पष्टीकरण के लिए सराहना की जाएगी :-)

@ wangyi-fudan, यदि 64-बिट ints से 64-बिट ints तक एक हैश फ़ंक्शन एक आक्षेप (यानी, 1-टू -1 फ़ंक्शन) नहीं है, तो कुछ परिणाम एक से अधिक बार उत्पन्न होते हैं और कुछ बिल्कुल नहीं। यह एक तरह का पूर्वाग्रह है।

मैं समझता हूं तुम्हारा क्या मतलब है। हालाँकि, 64 बिट रैंडम नंबर जनरेटर आर के लिए, हम 1.2 * 2 ^ 32 रैंडम नंबर (http://mathworld.wolfram.com/BirthdayAttack.html) के बाद एक टक्कर की उम्मीद करेंगे। 2 ^ 64 यादृच्छिक संख्याओं के साथ कई टकराव होना स्वाभाविक है। टकराव स्वाभाविक हैं जबकि आपत्ति स्वाभाविक रूप से यादृच्छिक नहीं है। अगर मुझे पता है कि जुए की मेज (उदाहरण के लिए 3 बिट PRNG) का निर्धारण 8 ट्रेल्स के भीतर 0 मान है, तो मैं 5 गैर-शून्य का अवलोकन करने के बाद शून्य पर एक बड़ा दांव लगाने का साहस करूंगा।

@ wangyi-fudan, इस संदर्भ में, हम स्ट्रीम-आईडी को अनुमति देने के तरीकों के बारे में बात कर रहे थे ताकि 1,2,3 जैसी धाराएं कुछ अधिक यादृच्छिक रूप से दिखें (उर्फ अधिक सामान्य)। इस प्रक्रिया में टक्करों में कोई गुण नहीं है।

सामान्य तौर पर PRNGs के लिए, आपको यादृच्छिक मैपिंग के आधार पर PRNGs और रैंडम इनवर्टेबल मैपिंग (1-टू -1 फ़ंक्शन) के आधार पर अंतर को पढ़ना चाहिए। मैंने इसके बारे में लिखा है, लेकिन ऐसा दूसरों के पास है। यह छोटे आकार, यादृच्छिक मैपिंग पर आधारित PRNGs पूर्वाग्रह दिखाएगा और अन्य तकनीकों के आधार पर लोगों की तुलना में अधिक तेज़ी से विफल होगा। बड़े आकार में, सभी प्रकार की खामियों का पता लगाना कठिन हो सकता है।

हम इस संभावना की गणना कर सकते हैं कि यदि हम _n_ अंतराल के लिए पूछते हैं कि एक दूसरे के साथ ओवरलैप करेगा। यह काफी बुनियादी संभावना है - मुझे यकीन नहीं है कि आप इसके बारे में प्रकाशित एक पेपर प्राप्त कर सकते हैं क्योंकि (जैसा कि मैं इसे समझता हूं) कोई भी प्रारंभिक गणित वाले पेपर के बारे में कभी भी उत्साहित नहीं होता है।

मुझे लगता है कि आपको सिर्फ पियरे L'Ecuyer होना चाहिए। ;-) पृष्ठ 15

हां, जब वह मूल बातें समझाता है तो इसे ठीक माना जाता है!

@rkern @imneme सरलता एक विशेषता है, सॉफ्टवेयर और गणित दोनों में। कि कुछ सरल काम से अप्रभावित हैं विरोधाभासी सबूत के रूप में नहीं लिया जाना चाहिए।

@ ब्लेयर : एक हास्य टुकड़ा है जो मुझे पसंद है कि मुझे लगता है कि इसके पास बहुत सारी सच्चाई है जिसे _ कहा जाता है

डिफ़ॉल्ट BitGenerator PCG64 । आपके विचारपूर्ण योगदान के लिए आप सभी का धन्यवाद। और सहनशक्ति!

इस सूत्र से बहुत प्रेरित होकर, मुझे रिपोर्ट करने के लिए कुछ समाचार ...

पृष्ठभूमि

कई उपायों द्वारा pcg64 बहुत अच्छा है; उदाहरण के लिए, सांख्यिकीय गुणवत्ता के सामान्य उपायों के तहत, इसे स्वास्थ्य का साफ बिल मिलता है। इसका विभिन्न तरीकों से परीक्षण किया गया है; हाल ही में मैंने इसे प्रेक्टैंड के साथ आधी पेटीबाइट पर चला दिया है। यह सामान्य उपयोग के मामलों में अच्छी तरह से काम करता है।

लेकिन, इस सूत्र में आने वाली विकृति मेरे साथ अच्छी तरह से नहीं बैठती है। निश्चित रूप से, मैं कह सकता हूं कि " ठीक है, इसे इस तरह से मत पकड़ो ", लेकिन एक सामान्य उद्देश्य PRNG का पूरा बिंदु यह है कि इसे मजबूत होना चाहिए। मैं बेहतर करना चाहता था ...

इसलिए, लगभग 25 दिन पहले मैंने पीसीजी परिवार के एक नए सदस्य को डिजाइन करने के बारे में सोचना शुरू किया ...

लक्ष्य

मेरा लक्ष्य एक नए पीसीजी परिवार के सदस्य को डिजाइन करना था जो वर्तमान pcg64 संस्करण के लिए प्रतिस्थापन में एक बूंद हो सकता है। जैसे की:

• आउटपुट फ़ंक्शन को XSL आरआर से अधिक बिट्स को हाथापाई करना चाहिए (क्योंकि ऐसा करने से इस थ्रेड में आने वाले मुद्दों से बचना होगा)।
• प्रदर्शन मौजूदा pcg64 तुलना में तेज़ (या तेज़) होना चाहिए।
• डिजाइन PCG-ish होना चाहिए (यानी, तुच्छ रूप से पूर्वानुमान नहीं किया जा सकता है, और इस प्रकार आउटपुट फ़ंक्शन के कार्य के _any_ को आसानी से पूर्ववत करने की अनुमति नहीं है)।

हमेशा की तरह एक व्यापार बंद है जैसा कि हम सबसे अच्छी गुणवत्ता प्राप्त करने की कोशिश करते हैं जितनी जल्दी हम कर सकते हैं। यदि हम गति के बारे में बिल्कुल भी ध्यान नहीं देते हैं, तो हम आउटपुट फ़ंक्शन में अधिक भारी स्क्रैम्बल आउटपुट का उत्पादन करने के लिए और अधिक कदम रख सकते हैं, लेकिन पीसीजी का मुद्दा यह था कि अंतर्निहित LCG "लगभग काफी अच्छा" था और इसलिए हमें इसकी आवश्यकता नहीं थी काफी प्रयास के रूप में जाने के लिए के रूप में हम 1 से एक काउंटर वेतन वृद्धि की तरह कुछ के साथ होगा।

स्पॉइलर

मुझे सफलता की सूचना मिली है! लगभग 25 दिन पहले जब मैं पहली बार इस बारे में सोच रहा था कि मैं वास्तव में छुट्टी पर था। जब मैं लगभग दस दिन पहले वापस आया, तो मैंने उन विचारों को आज़माया और मुझे खुशी हुई कि वे अच्छा काम कर रहे हैं। बाद के समय को ज्यादातर विभिन्न प्रकार के परीक्षण पर खर्च किया गया है। कल पर्याप्त संतुष्ट था कि मैंने कोड को पीसीजी के सी ++ संस्करण में धकेल दिया । छोटे आकार के परीक्षण यह दर्शाते हैं कि यह XSL RR से बहुत बेहतर है, और RXS M के साथ प्रतिस्पर्धात्मक है, लेकिन यह वास्तव में बड़े आकार में चमकता है। यह अन्य सभी लक्ष्यों को पूरा करता है।

विवरण

FWIW, नया आउटपुट फ़ंक्शन (64-बिट आउटपुट केस के लिए) है:

uint64_t output(__uint128_t internal)
{
    uint64_t hi = internal >> 64;
    uint64_t lo = internal;

    lo |= 1;
    hi ^= hi >> 32;
    hi *= 0xda942042e4dd58b5ULL;
    hi ^= hi >> 48;
    hi *= lo;
    return hi;
}

यह आउटपुट फ़ंक्शन xorshift-गुणा द्वारा प्रेरित है, जिसके द्वारा व्यापक रूप से उपयोग किया जाता है। मल्टीप्लायरों की पसंद (ए) जादू की संख्या को कम रखने के लिए है, और (बी) क्रमचय को पूर्ववत होने से रोकने के लिए (यदि आपके पास कम-ऑर्डर बिट्स तक पहुंच नहीं है), और पूरे "यादृच्छिक" भी प्रदान करें PCG आउटपुट फ़ंक्शंस में आमतौर पर "गुणवत्ता" ही होती है।

अन्य परिवर्तन

यह भी मामला है कि इस PRNG के लिए 0xda942042e4dd58b5 LCG गुणक है (और सभी cm_ उपसर्ग 128-बिट PCG जनरेटर)। की तुलना में 0x2360ed051fc65da44385df649fccf645 द्वारा इस्तेमाल किया pcg64 , इस निरंतर वास्तव में अभी भी वर्णक्रमीय परीक्षण गुणों के संदर्भ में काफी अच्छा है, लेकिन द्वारा क्योंकि 128 बिट × 64-बिट की तुलना में आसान है गुणा करने के लिए सस्ता है 128-बिट × 128-बिट। मैंने इस LCG का उपयोग कई वर्षों तक बिना किसी समस्या के किया है। सस्ते-गुणक प्रकार का उपयोग करते समय, मैं पूर्व-पुनरावृत्त राज्य पर आउटपुट फ़ंक्शन चलाता हूं, बजाय अधिक अनुदेश-स्तरीय समानता के लिए पुनरावृत्त स्थिति के बाद।

परिक्षण

मैंने इसका पूरी तरह से परीक्षण किया है (प्रैक्ट्रैंड और टेस्टयू 01) और मैं इससे खुश हूं। टेस्ट में इस थ्रेड में उल्लिखित परिदृश्य शामिल थे (उदाहरण के लिए, गैंग जनरेटर को या तो अनुक्रमिक स्टीम पर ले जाना या 2 ^ 64 तक उन्नत और उनके आउटपुट को इंटरलाकिंग करना - मैंने चार के एक गैंग का परीक्षण किया और 8192 में से 8 टीबी के गैंग को बिना किसी समस्या के परीक्षण किया, साथ ही साथ एक धारा और इसके विपरीत भूमि समकक्ष के रूप में)।

स्पीड

मैं गति परीक्षण और बेंचमार्क के बारे में लंबाई पर जा सकता था। सभी प्रकार के कारक हैं जो प्रभावित करते हैं कि क्या एक PRNG किसी दिए गए बेंचमार्क में दूसरे की तुलना में तेजी से चलता है, लेकिन कुल मिलाकर, यह संस्करण अक्सर थोड़ा तेज, कभी-कभी बहुत तेज, और कभी-कभी थोड़ा धीमा हो जाता है। संकलक और अनुप्रयोग जैसे कारक बेंचमार्क परिवर्तनशीलता पर बहुत अधिक प्रभाव डालते हैं।

उपलब्धता

C ++ हेडर के उपयोगकर्ता इस नए परिवार के सदस्य _now_ को pcg_engines::cm_setseq_dxsm_128_64 रूप में एक्सेस कर सकते हैं; भविष्य में कुछ बिंदु पर, मैं pcg64 को pcg_engines::setseq_xsl_rr_128_64 इस नई योजना में बदल दूंगा। मेरी वर्तमान योजना इस वर्ष गर्मियों में एक पीसीजी 2.0 संस्करण टक्कर के हिस्से के रूप में करने की है।

औपचारिक घोषणाएँ

कुल मिलाकर, मैं इस नए परिवार के सदस्य के साथ बहुत खुश हूं और कुछ बिंदु पर गर्मियों में बाद में, और अधिक विस्तार के साथ ब्लॉग पोस्ट होंगे, संभवतः इस धागे का संदर्भ देते हुए।

तुम्हारी पसंद...

बेशक, आपको यह काम करना होगा कि इसके साथ क्या करना है। भले ही आप इसका उपयोग करें या न करें, मैं वास्तव में यह देखने के लिए बहुत उत्सुक हूं कि यह आपके स्पीड बेंचमार्क में बेहतर या बुरा है।

@imneme क्या यह तेजी से पूरे 64-बिट गुणक की आवश्यकता के आसपास मिलता है? (जो x64 पर सुपर फास्ट है लेकिन कुछ कमजोर आर्किटेक्चर पर एक धीमी गति है।)

@ ब्लेयर : 128-बिट × 64-बिट गुणा, जो आंतरिक रूप से x86 पर दो गुणा निर्देशों के साथ किया जाएगा (64-बिट × 64-बिट → कम-बिट बिट्स पर 128-बिट परिणाम, और 64-बिट × 64 उच्च क्रम बिट्स पर -बिट करें। दोनों गुणा समानांतर में हो सकते हैं, और फिर दो परिणामों को जोड़ने की आवश्यकता है।)

यह अभी भी संभावित रूप से 128-बिट × 128-बिट से बेहतर है। हालांकि कितना बेहतर यह निर्भर करता है कि उस समय निर्देशन कितनी अच्छी तरह से चलता है।

आप सही हैं कि ARM पर, 64-बिट × 64-बिट → 128-बिट परिणाम वास्तव में दो निर्देश हैं।

(यह पूरी तरह से संभव है, दो 64-बिट एलसीजी को एक साथ मिलाने और उन्हें मिश्रण करने के लिए। सभी PRNGs का स्थान जो मौजूद हो सकता है और अच्छी तरह से काम करेगा, बहुत बड़ा है।)

हमारे ढांचे में एक त्वरित और गंदा कार्यान्वयन एक हल्के प्रदर्शन में सुधार का सुझाव देता है, कम से कम 64-बिट लिनक्स पर:

Time to produce 1,000,000 64-bit unsigned integers
************************************************************
MT19937      5.42 ms
PCG64        2.59 ms
PCG64DXSM    2.41 ms
Philox       4.37 ms
SFC64        2.07 ms
numpy        5.41 ms
dtype: object

64-bit unsigned integers per second
************************************************************
MT19937      184.39 million
PCG64        386.01 million
PCG64DXSM    415.02 million
Philox       228.88 million
SFC64        483.94 million
numpy        184.79 million
dtype: object

मुझे लगता है कि यह पूर्व-पुनरावृत्त राज्य से आउटपुट हो रहा है जो इसे टक्कर देता है, कम से कम इस संदर्भ में। मैंने उसे पहले ही छोड़ दिया और अनिवार्य रूप से PCG64 1.0 के समान प्रदर्शन प्राप्त किया। असली जीत 128-बिट एमुलेशन के तहत होगी, मुझे संदेह है, लेकिन मुझे उस लेखन के लिए चारों ओर नहीं मिला, और मेरे पास इस मामले में प्लेटफार्मों पर परीक्षण करने का एक अच्छा तरीका नहीं है।

मुझे लगता है कि आप के लिए असली सवाल, @imneme , यह है कि आप 1.0 एल्गोरिथ्म को लागू करने वाले numpy.random.PCG64 के नाम से कितने नाराज हैं? रिलीज आसन्न है और पहले से ही विलंबित है, इसलिए मैं _think_ नहीं करता हूं हम इस समय एल्गोरिथ्म को बदलने जा रहे हैं। यदि 32-बिट प्लेटफ़ॉर्म पर प्रदर्शन विशेष रूप से अच्छा है, तो मुझे लगता है कि हम निम्नलिखित रिलीज में PCG64DXSM जोड़ सकते हैं, और शायद पंक्ति के नीचे कुछ रिलीज के डिफ़ॉल्ट पर पुनर्विचार करें।

यह आपकी पसंद है!

मुझे आपके शिपिंग के PCG64 संस्करण के साथ कोई समस्या नहीं है। बहुत से अन्य लोगों ने उस संस्करण का उपयोग किया है।

मुझे लगता है कि इस धागे में आए एज-केस-यूज़ के मुद्दों से बचने के लिए डीएक्सएसएम वेरिएंट का फायदा है (आखिरकार, यह बहुत ज्यादा क्यों मौजूद है), लेकिन दूसरी तरफ, इसका नुकसान यह है कि देर हो चुकी है पार्टी। यह PRNG शिप करने के लिए काफी लापरवाह लग सकता है जो उपयोगकर्ताओं के लिए एक महीने से भी कम समय पुराना है (भले ही यह अधिक समय परीक्षण किए गए पीसीजी वेरिएंट के समान विचारों पर आधारित हो)।

(यह कहा, अगर यह _my_ पसंद थे, लापरवाही के संभावित आरोपों के बावजूद, मैं शायद नया हूँ; मुझे लगता है कि इसे उठने में देरी करना और Numpy में चलना बहुत कम है। और जोखिम बहुत कम है। यह पहले से ही कम है। BigCrush के माध्यम से परीक्षण किया गया, और प्रेक्ट्रैंड के साथ 16 टीबी तक का परीक्षण किया गया ( cm_mcg_dxsm_64_32 जो आकार [कोई धारा, 32-बिट आउटपुट] का एक चौथाई है), और संभवत: एक सप्ताह से भी कम समय में 32 टीबी से टकराएगा ।)

[खुशी है कि इस प्रदर्शन को बेहतर ढंग से मिला। पांच साल पहले, पूर्व-पुनरावृत्त राज्य का उपयोग करना 128-बिट गुणक के साथ 128-बिट आकारों के लिए एक निराशाकरण था। लेकिन तब मैं जिन मशीनों पर परीक्षण कर रहा था, उन बेंचमार्क के साथ जिनका मैं उपयोग कर रहा था।]

जब आप उस नाम का उपयोग करने जा रहे हैं, तो आप PCG64 2.0 के नाम का उपयोग करने जा रहे हैं।

@ रेकर्न यदि यह सिर्फ एक नामकरण मुद्दा है, तो PCG64DXSM और PCG64 उन्हें अच्छी तरह से अलग करते हैं, नहीं?

सुन्न के लिए, निश्चित रूप से। मैं बस सोच रहा था कि क्या @imneme पसंद करेगा कि हम अपने 1.0 कार्यान्वयन PCG64 नाम न दें जब वह C ++ संस्करण में उस नाम के तहत 2.0 संस्करण को बढ़ावा देने वाला है। मैं इस तथ्य के प्रति संवेदनशील हूं कि नामों के साथ ढीले होने का मतलब है कि कुछ लोग खामियों के PCG64 का परीक्षण कर सकते हैं और तुलना कर सकते हैं कि 2.0 संस्करण के बारे में pcg-random.org पर किए जाएंगे। बॉब जेनकिन के PRNGs के बारे में किसी भी बातचीत के बारे में सीएफ।

PCG पेपर की धारा 6.3 में, यह कहता है:

यह भी ध्यान दें कि यद्यपि जेनरेटर उनके द्वारा किए गए क्रमपरिवर्तन के आधार पर mnemonic नामों के साथ प्रस्तुत किए जाते हैं, PCG लाइब्रेरी के उपयोगकर्ताओं को शायद ही कभी इन mnemonics द्वारा परिवार के सदस्यों का चयन करना चाहिए। पुस्तकालय उनके गुणों के आधार पर नामित जनरेटर प्रदान करता है, न कि उनके अंतर्निहित कार्यान्वयन (जैसे, एक सामान्य स्ट्रीम के लिए एक सामान्य-उद्देश्य 32-बिट जनरेटर के लिए pcg32_unique)। इस तरह, जब भविष्य में बेहतर प्रदर्शन करने वाले परिवार के सदस्यों की खोज की जाती है और उन्हें जोड़ा जाता है (उम्मीद है कि दूसरों की खोजों के कारण), तो उपयोगकर्ता मूल रूप से उन पर स्विच कर सकते हैं।

और सी और सी ++ लाइब्रेरीज़ को इस तरह से संरचित किया जाता है। पुस्तकालय प्रदान करते हैं

• एक निम्न-स्तरीय इंटरफ़ेस जो आपको एक विशिष्ट परिवार के सदस्य को उसके क्रमांकन के नाम से, उसके द्वारा संचालित बिट आकार और अंतर्निहित LCG की विशेषताओं को चुनने देता है।
• एक उच्च स्तरीय इंटरफ़ेस जो pcg64 जैसे सुविधाजनक उपनाम प्रदान करता है जो एक पूर्व-चयनित निम्न-स्तरीय परिवार के सदस्य से जुड़ता है।

इस तरह, नए परिवार के सदस्यों को इंगित करने के लिए उपनामों को अद्यतन किया जा सकता है, लेकिन उपयोगकर्ता जो पुराने परिणामों को वास्तव में पुन: उत्पन्न करना चाहते हैं, वे अभी भी निम्न स्तर के इंटरफ़ेस का उपयोग करके परिवार के सदस्य का चयन करने में सक्षम होंगे जो पहले एक सुविधाजनक उच्च द्वारा पहुंच योग्य था। -वेल्व उर्फ

यदि आप PCG64 PRNG शिप करने जा रहे हैं, तो मैं कहूंगा कि आपके दस्तावेज़ में यह कहना पर्याप्त है कि कौन सा विशिष्ट PCG संस्करण है - दूसरे शब्दों में, यह कहें कि परिवार का कौन सा सदस्य निम्न में मेल खाता है -लेवल सी या सी ++ लाइब्रेरी इंटरफ़ेस।

डिफ़ॉल्ट जनरेटर कार्यान्वित किया जाता है इसे np.random.default_gen() में https://github.com/numpy/numpy/pull/13840 पर लागू किया जाता है @ भविष्य के संदर्भ के लिए, यह शायद गीथहब में याद करना आसान है, क्योंकि इसके लिए कोई सूचना नहीं है।)

एक मामूली नाइट: इस np.random.default_generator() बजाय कॉल करने के बारे में क्या? gen मुझे बहुत छोटा / गैर-स्पष्ट लगता है। मैं उत्सुक होऊंगा कि दूसरे क्या सोचते हैं।

इसके बजाय np.random.default_generator () को कॉल करने के बारे में क्या?

मेरे पास एक ही विचार था, लेकिन फिर, np.random.default_generator() लंबे तरफ एक बाल है, इसलिए मैंने default_rng साथ खेला।

default_rng मुझे default_gen से भी बेहतर default_generator ओर झुकूंगा।

: +1: default_rng() ।