प्रक्रियात्मक पीढ़ी, खेल अपडेट, और तितली प्रभाव


10

नोट: मैंने कुछ दिन पहले स्टैक ओवरफ्लो पर यह पूछा था लेकिन बहुत कम विचार और कोई प्रतिक्रिया नहीं मिली। इसके बजाय मुझे Gamdev.stackexchange पर पूछना चाहिए।

यह एक सामान्य प्रश्न / अनुरोध है कि पहले से तैयार की गई सामग्री को तोड़े बिना कई पोस्ट-रिलीज़ अपडेट के माध्यम से एक प्रक्रियात्मक पीढ़ी प्रणाली को बनाए रखने के लिए सलाह।

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

इस दृष्टिकोण में मुख्य खतरा यह है कि यहां तक ​​कि प्रक्रियात्मक पीढ़ी प्रणाली में थोड़ा सा बदलाव भी पूरी दुनिया को बदलने वाले एक तितली प्रभाव का कारण बन सकता है। यह खिलाड़ियों को खोज रहे दुनिया को नष्ट किए बिना गेम को अपडेट करने के लिए बहुत मुश्किल बना देता है।

इस समस्या से बचने के लिए मैं जिस मुख्य तकनीक का उपयोग कर रहा हूं, वह है कि प्रक्रियात्मक पीढ़ी को कई चरणों में डिजाइन करना, जिसमें से प्रत्येक का अपना रैंडम रैंडम नंबर जनरेटर हो। इसका मतलब यह है कि प्रत्येक उप-प्रणाली स्वयं निहित है, और अगर कुछ टूट जाता है तो यह दुनिया की हर चीज को प्रभावित नहीं करेगा। हालांकि ऐसा लगता है कि यह अभी भी "टूटना" की बहुत संभावना है, भले ही खेल के एक अलग हिस्से में।

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

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

मैं वर्तमान में यूनिटी 3 डी / सी # में काम कर रहा हूं, हालांकि यह एक भाषा अज्ञेय प्रश्न है।

अपडेट करें:

आपके उत्तरों के लिये धन्यवाद।

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

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


मैं इस प्रश्न को ऑफ-टॉपिक के रूप में बंद करने के लिए मतदान कर रहा हूं क्योंकि यह बहुत व्यापक है।
आलमो

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

2
अल्मो गलत है। यह बिल्कुल भी व्यापक नहीं है। यह एक उत्कृष्ट प्रश्न है और दिए गए अच्छे उत्तरों के लिए काफी संकीर्ण है। यह ऐसा कुछ है जो मुझे लगता है कि हम में से बहुत से प्रक्रियात्मक लोग अक्सर विचार करते हैं।
अभियंता

जवाबों:


8

मुझे लगता है कि आपने यहाँ आधारों को कवर कर लिया है:

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

  • सहेजें फ़ाइल में प्रयुक्त जनरेटर संस्करण का ट्रैक रखना और उचित जवाब देना। "उपयुक्त" का अर्थ क्या हो सकता है ...

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


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

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

"सही" उत्तर चुनना कठिन था। मैंने इसे उठाया क्योंकि यह संक्षिप्त था और मुख्य मुद्दों को स्पष्ट तरीके से संक्षेप में प्रस्तुत किया। धन्यवाद।
नल

4

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

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

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

10 के बाद, आपके पास 20 स्लॉट्स मुफ्त हैं जिन्हें आप अन्य पहलुओं के लिए उपयोग कर सकते हैं जैसे कि गेम डिज़ाइन प्रगति करता है। यहाँ लागत निश्चित रूप से है कि आपको स्लॉट 11-30 के लिए संख्याओं को उत्पन्न करना होगा, भले ही वे वर्तमान में उपयोग में न हों , अर्थात अवधि को पूरा करें, 1-10 के अगले अनुक्रम में वापस लाने के लिए। इसमें सीपीयू लागत है, हालांकि यह मामूली होना चाहिए (मुफ्त स्लॉट की संख्या के आधार पर)। अन्य नकारात्मक पक्ष यह है कि आपको निश्चित होना चाहिए कि आपके अंतिम डिज़ाइन को आपके विकास की प्रक्रिया के प्रारंभ में आपके द्वारा उपलब्ध कराए गए स्लॉट की संख्या में समायोजित किया जा सकता है ... और जितना अधिक आप शुरू में असाइन करते हैं, उतना ही "खाली" स्लॉट। आप संभावित रूप से प्रत्येक के माध्यम से जाना है, चीजों को काम करने के लिए।

इसके प्रभाव इस प्रकार हैं:

  • आपके पास हर चीज के लिए एक जनरेटर उत्पादक संख्या है
  • आपके लिए संख्याएँ उत्पन्न करने के लिए आवश्यक पहलुओं की संख्या में परिवर्तन, नियतत्ववाद पर प्रभाव नहीं डालेगा (बशर्ते आपकी अवधि सभी पहलुओं को समायोजित करने के लिए पर्याप्त हो)

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


नमस्ते। मुझे लगता है कि मैं कर रहा हूँ कुछ चीजों के समान है। मैं आमतौर पर प्रारंभिक विश्व बीज के आधार पर उप-बीजों का एक गुच्छा उत्पन्न करता हूं। हाल ही में मैंने शोर का एक लंबा सरणी बनाना शुरू कर दिया है, और फिर प्रत्येक "स्लॉट" केवल उस सरणी में एक सूचकांक है। इस तरह से प्रत्येक सबसिस्टम सही बीज को पकड़ सकता है और अलगाव में काम कर सकता है। एक और बढ़िया तकनीक है x का उपयोग करना, y प्रत्येक स्थान के लिए एक बीज उत्पन्न करने के लिए निर्देशांक करता है। मैं इस स्टैक पेज पर यूफोरिक के उत्तर से कोड का उपयोग कर रहा हूं: programmers.stackexchange.com/questions/16133/…
null

3

यदि आप पीसीजी के साथ दृढ़ता चाहते हैं, तो मेरा सुझाव है कि आप पीसीजी कोड को डेटा के रूप में मानें । जैसे आप नियमित सामग्री के साथ संशोधन के दौरान डेटा को बनाए रखेंगे, उत्पन्न सामग्री के साथ, यदि आप इसे संशोधन के दौरान जारी रखना चाहते हैं, तो आपको जनरेटर को जारी रखने की आवश्यकता होगी।

बेशक, सबसे लोकप्रिय तरीका यह है कि आप जनरेट किए गए डेटा को स्टैटिक डेटा में कनवर्ट करें, जैसा कि आपने उल्लेख किया है।

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


यह एक चतुर विचार है, बस विभिन्न क्षेत्रों के लिए अलग-अलग जनरेटर का उपयोग करना है।
null

2

मैं लगभग 300 मिलियन वर्ग किलोमीटर के क्षेत्र को बनाए रखता हूं, ca 1 मिलियन इमारतों और अन्य वस्तुओं को पकड़े हुए, मिसकैरेज चीजों के यादृच्छिक स्थानों के अलावा। एक बाहरी अनुकरण। संग्रहीत डेटा सीए 4 जीबी है। मैं भंडारण स्थान के लिए भाग्यशाली हूं, फिर भी यह असीमित नहीं है।

रैंडम यादृच्छिक है, अनियंत्रित है। लेकिन कोई इसे थोड़ा कम कर सकता है:

  • नियंत्रण यह अंत अंत शुरू होता है (जैसा कि अन्य पदों में वर्णित है, बीज संख्या और कितने उत्पन्न संख्या)।
  • इसके संख्यात्मक स्थान को सीमित करें, जैसे। केवल 0 और 100 के बीच पूर्णांक बनाते हैं।
  • एक मान जोड़कर इसकी संख्यात्मक जगह को बंद करें, (जैसे 0 और 100 के बीच 100 + [उत्पन्न संख्या) 100 और 100 के बीच यादृच्छिक संख्या पैदा करता है)
  • इसे स्केल करें (उदा। 0.1 से गुणा करें)
  • और इसके चारों ओर विभिन्न पिंजरों को लागू करें। यह पीढ़ी के हिस्से को कम कर रहा है। उदाहरण के लिए। यदि 2-आयामी स्थान में उत्पन्न हो रहा है, तो एक जोड़े के शीर्ष पर एक आयत डाल सकता है और बाहर क्या है इसे स्क्रैप कर सकता है। या एक सर्कल, या एक बहुभुज। यदि 3 डी-स्पेस में, कोई उदाहरण के लिए स्वीकार कर सकता है केवल एक गोले के अंदर रहने वाले ट्रिपल या कुछ अन्य आकार (अब नेत्रहीन रूप से सोच रहे हैं, लेकिन यह वास्तविक दृश्य या स्थिति के साथ कुछ भी करने के लिए जरूरी नहीं है)।

यह इसके बारे में। दुर्भाग्य से पिंजरे भी डेटा का उपभोग करते हैं।

वहाँ एक कहावत है, हज़ोटा जा हॉलिट्ज़। विभाजित और जीत में अनुवाद

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

संख्यात्मक स्थानों को नियंत्रित और प्रबंधित करने के लिए, प्रबंधनीय क्या है?

  • एक बूलियन ग्रिड है (बिट्स छोटे हैं!)
  • कॉर्नर पॉइंट हैं
  • एक पेड़ की संरचना है (= "पिंजरे पकड़े पिंजरों" में पालन करने के लिए)

अनुरक्षण-वार, और संस्करण इंटरकम्पैसबिलिटी-वार ... हमारे पास
: यदि संस्करण = n तब
: और फिर संस्करण = m तब ...
हां, कोड आधार बड़ा हो जाता है :-)।

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

DMGregory द्वारा प्रस्तावित मजाकिया "nuke it fom orbit" के साथ पूरी तरह से असंगत नहीं है, लेकिन शायद छोटे और सटीक यूकेज़ का उपयोग करें? :-)


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

सभी उत्तरों में से, मैं खुद को इस बारे में सबसे ज्यादा सोचता हूं। मैंने चीजों के आपके थोड़े दार्शनिक विवरणों का आनंद लिया। विचारों को समझाते समय मुझे "केज" शब्द बहुत उपयोगी लगता है, इसलिए इसके लिए धन्यवाद। तितली को उड़ने दो ... उसके पिंजरे में :)
null

PS मैं वास्तव में यह जानने के लिए उत्सुक हूं कि आप किस खेल में काम करते हैं। क्या आप उस जानकारी को साझा करने में सक्षम हैं?
null

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

पिछले पर मूल्यांकन करते हुए, एक छोटे वाहन आंदोलन पर विचार करें, 0.01 [मीटर, यूनिट] का 1-फ्रेम वेतन वृद्धि: आप 32-बिट संख्यात्मक सटीकता (एकल) में 10000.1 + 0.01 की सही गणना नहीं कर सकते हैं, लेकिन आप 0.1 + 0.01 की गणना कर सकते हैं। इसलिए, यदि "कार्रवाई" दूर (पहाड़ों के पीछे) होती है, तो वहां न जाएं, इसके बजाय पहाड़ों को आप तक ले जाएं (10000 के साथ आगे बढ़ें, तो आप अभी 0.1 पर हैं)। भंडारण स्थान के लिए वैध भी। एक दूसरे के करीब संख्यात्मक मूल्यों के भंडारण के साथ लालची हो सकता है। एक बार उनमें से सामान्य भाग को स्टोर करें, और भिन्नताएं व्यक्तिगत रूप से - बिट्स को बचा सकती हैं! क्या आपको लिंक मिला? ;-)
स्टॉर्मविंड
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.