फ्लोट नंबरों की समानता की तुलना कनिष्ठ डेवलपर्स को गुमराह करता है, भले ही मेरे मामले में कोई गोल त्रुटि न हो?

Question

उदाहरण के लिए, मैं 0,0.5, ... 5 से बटन की एक सूची दिखाना चाहता हूं, जो प्रत्येक 0.5 के लिए कूदता है। मैं ऐसा करने के लिए एक लूप का उपयोग करता हूं, और बटन STANDARD_LINE पर अलग रंग है:

var MAX=5.0;
var DIFF=0.5
var STANDARD_LINE=1.5;

for(var i=0;i<=MAX;i=i+DIFF){
    button.text=i+'';
    if(i==STANDARD_LINE){
      button.color='red';
    }
}

इस मामले में कोई गोल त्रुटि नहीं होनी चाहिए क्योंकि IEEE 754 में प्रत्येक मान सटीक है। लेकिन मैं संघर्ष कर रहा हूं यदि मुझे फ्लोटिंग पॉइंट समानता की तुलना से बचने के लिए इसे बदलना चाहिए:

var MAX=10;
var STANDARD_LINE=3;

for(var i=0;i<=MAX;i++){
    button.text=i/2.0+'';
    if(i==STANDARD_LINE/2.0){
      button.color='red';
    }
}

एक तरफ, मूल कोड मेरे लिए अधिक सरल और आगे है। लेकिन एक बात है जिस पर मैं विचार कर रहा हूं: i == STANDARD_LINE जूनियर टीम के साथियों को गुमराह करता है? क्या यह इस तथ्य को छिपाता है कि फ्लोटिंग पॉइंट नंबरों में राउंडिंग त्रुटियाँ हो सकती हैं? इस पोस्ट से टिप्पणियों को पढ़ने के बाद:

https://stackoverflow.com/questions/33646148/is-hardcode-float-precise-if-it-can-be-represented-by-binary-format-in-ieee-754

ऐसा लगता है कि कई डेवलपर्स हैं जो नहीं जानते हैं कि कुछ फ्लोट नंबर सटीक हैं। क्या मुझे फ्लोट संख्या समानता तुलनाओं से बचना चाहिए, भले ही यह मेरे मामले में वैध हो? या मैं इस बारे में सोच रहा हूँ?

Comments

इन दो कोड लिस्टिंग का व्यवहार समकक्ष नहीं है। 3 / 2.0 1.5 है, लेकिन iकेवल दूसरी लिस्टिंग में पूरे नंबर होंगे। दूसरे को हटाने का प्रयास करें /2.0।

— कैंडिड_ओरेंज

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

चाहे जो भी आप चुनते हैं, यह उन मामलों में से एक है जहां एक टिप्पणी यह ​​बताती है कि कैसे और क्यों आवश्यक है। एक बाद के डेवलपर भी उनके ध्यान में लाने के लिए एक टिप्पणी के बिना सूक्ष्मता पर विचार नहीं कर सकते हैं। इसके अलावा, मैं इस तथ्य से बहुत विचलित हूं कि buttonआपके पाश में कहीं भी परिवर्तन नहीं होता है। बटन की सूची कैसे एक्सेस की जाती है? सरणी या किसी अन्य तंत्र में वाया सूचकांक? यदि यह किसी ऐरे में इंडेक्स एक्सेस के द्वारा होता है, तो यह पूर्णांक पर स्विच करने के पक्ष में एक और तर्क है।

— jpmc26

उस कोड को लिखें। जब तक कोई सोचता है कि 0.6 एक बेहतर कदम आकार होगा और बस उस स्थिर को बदलता है।

— टॉफ्रो

"... जूनियर डेवलपर्स को भ्रमित करें " आप वरिष्ठ डेवलपर्स को भी भ्रमित करेंगे। इस विचार की मात्रा के बावजूद कि आप इसमें शामिल हैं, वे मान लेंगे कि आप नहीं जानते कि आप क्या कर रहे थे, और संभवतः पूर्णांक संस्करण में भी इसे बदल देगा।

— ग्रैंडऑपनर

Answer 1

जब तक मैं जिस मॉडल की गणना कर रहा हूं उनके लिए मुझे लगातार फ्लोटिंग-पॉइंट ऑपरेशन से बचना होगा। फ्लोटिंग-पॉइंट अंकगणितीय अधिकांश और त्रुटियों के एक प्रमुख स्रोत के लिए अनुपयुक्त है। और उन मामलों को बताना जिनमें यह उन त्रुटियों का कारण बनता है जहां यह नहीं है और भी अधिक सूक्ष्म अंतर है!

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

Comments

मुझे "एक दोष घटित होने की प्रतीक्षा है" पसंद है। यकीन है, यह अब काम कर सकता है , लेकिन किसी के चलने से एक हल्की हवा इसे तोड़ देगी।

— आकाशवाणी

उदाहरण के लिए, मान लीजिए कि आवश्यकताओं में परिवर्तन हुआ है, इसलिए 4 बटन पर "मानक रेखा" के साथ 0 से 5 तक समान रूप से फैलाए गए बटन के बजाय, आपके पास 6 पर "मानक रेखा" के साथ 0 से 5 तक समान रूप से 16-समान बटन हैं। बटन। तो जो भी आपको यह कोड विरासत में मिला है, वह 0.5 से 1.0 / 3.0 बदलता है और 1.5 से 5.0 / 3.0 बदलता है। फिर क्या होता है?

— डेविड के

हाँ, मैं इस विचार के साथ असहज है कि बदलते क्या कर रहा हूँ लगता है एक मनमाना संख्या होने के लिए (के रूप में "सामान्य" एक नंबर हो सकता है के रूप में) एक और मनमाना संख्या को (जो लगता है उतना ही "सामान्य") वास्तव में एक दोष परिचय देता है।

— अलेक्जेंडर - मोनिका

@Alexander: सही है, आपको एक टिप्पणी की आवश्यकता होगी जो कहा DIFF must be an exactly-representable double that evenly divides STANDARD_LINE। यदि आप उस टिप्पणी को लिखना नहीं चाहते हैं (और इसे समझने के लिए IEEE754 बाइनरी 64 फ़्लोटिंग पॉइंट के बारे में जानने के लिए सभी भविष्य के डेवलपर्स पर भरोसा करते हैं), तो इस तरह से कोड न लिखें। यानी इस तरह से कोड न लिखें। विशेष रूप से क्योंकि यह शायद अधिक कुशल भी नहीं है: एफपी जोड़ में पूर्णांक जोड़ की तुलना में उच्च विलंबता है, और यह लूप-आधारित निर्भरता है। इसके अलावा, कंपाइलर (यहां तक ​​कि जेआईटी कंपाइलर?) शायद पूर्णांक काउंटरों के साथ लूप बनाने में बेहतर करते हैं।

— पीटर कॉर्ड्स

Answer 2

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

यह कुछ हद तक व्यक्तिपरक है, लेकिन मेरी विनम्र राय में, यदि आप एक निश्चित संख्या में लूप को पूर्णांक सूचकांक का उपयोग करने के लिए लूप को फिर से लिख सकते हैं, तो आपको ऐसा करना चाहिए। तो निम्नलिखित विकल्प पर विचार करें:

var DIFF=0.5;                           // pixel increment
var MAX=Math.floor(5.0/DIFF);           // 5.0 is max pixel width
var STANDARD_LINE=Math.floor(1.5/DIFF); // 1.5 is pixel width

for(var i=0;i<=MAX;i++){
    button.text=(i*DIFF)+'';
    if(i==STANDARD_LINE){
      button.color='red';
    }
}

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

Comments

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

— ilkachachu

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

— नील

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

— मोनिका

आपका स्पष्टीकरण जावा के लिए पूरी तरह से सही होगा / C ++ / रूबी /, अजगर / ... लेकिन जावास्क्रिप्ट पूर्णांक नहीं है तो iऔर STANDARD_LINEकेवल पूर्णांकों की तरह लग रहे। कोई ज़बरदस्ती नहीं है, और DIFF, MAXऔर STANDARD_LINEसभी सिर्फ Numberएस। Numberपूर्णांक के रूप में उपयोग किया जाना चाहिए नीचे सुरक्षित है 2**53, वे अभी भी अस्थायी संख्या में हैं, हालांकि।

— एरिक डुमिनील

@EricDuminil हाँ, लेकिन यह इसका आधा हिस्सा है। अन्य आधा पठनीयता है। मैं इसे इस तरह से करने के लिए सिद्धांत कारण के रूप में उल्लेख करता हूं, अनुकूलन के लिए नहीं।

— नील

Answer 3

मैं अन्य सभी उत्तरों से सहमत हूं कि गैर-पूर्णांक लूप चर का उपयोग करना आमतौर पर इस तरह के मामलों में भी खराब शैली है जहां यह सही ढंग से काम करेगा। लेकिन यह मुझे लगता है कि यहां एक और कारण है कि यह खराब शैली है।

आपका कोड "जानता है" कि उपलब्ध लाइन चौड़ाई ठीक 0 से 5.0 तक 0.5 के गुणक हैं। इसे होना चाहिए? ऐसा लगता है कि यह एक उपयोगकर्ता-इंटरफ़ेस निर्णय है जो आसानी से बदल सकता है (उदाहरण के लिए, शायद आप चाहते हैं कि उपलब्ध चौड़ाई के बीच अंतराल चौड़ाई के रूप में बड़ा हो जाए। 0.25, 0.5, 0.75, 1.0, 1.5, 2.0, 2.5, 3.0, 4.0, 4.0) 5.0 या कुछ)।

आपका कोड "जानता है" कि उपलब्ध लाइन चौड़ाई सभी में "अच्छा" प्रतिनिधित्व है जो फ्लोटिंग-पॉइंट संख्या और दशमलव के रूप में दोनों है। यह भी कुछ ऐसा लगता है जो बदल सकता है। (आप किसी बिंदु पर 0.1, 0.2, 0.3, ... चाहते हो सकते हैं।)

आपका कोड "जानता है" कि बटन पर डालने का पाठ बस वही है जो जावास्क्रिप्ट उन फ्लोटिंग-पॉइंट मानों को बदल देता है। यह भी कुछ ऐसा लगता है जो बदल सकता है। (जैसे, शायद किसी दिन आप 1/3 जैसी चौड़ाई चाहते हैं, जिसे आप शायद 0.33333333333333 या जो कुछ भी प्रदर्शित नहीं करना चाहेंगे। या शायद आप "1.5" के साथ "1" के बजाय "1.0" देखना चाहते हैं। ।)

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

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

Answer 4

एक कोड गंध इस तरह लूप में फ्लोट्स का उपयोग कर रहा है।

लूपिंग बहुत तरीकों से किया जा सकता है, लेकिन 99.9% मामलों में आपको 1 की वेतन वृद्धि से चिपकना चाहिए या निश्चित रूप से भ्रम होगा, न केवल जूनियर डेवलपर्स द्वारा।

Comments

मैं असहमत हूं, मुझे लगता है कि 1 का पूर्णांक गुणक एक लूप में भ्रमित नहीं कर रहा है। मुझे लगता है कि एक कोड गंध नहीं होगा। केवल अंश।

— कोडमॉन्की

Answer 5

हां, आप इससे बचना चाहते हैं।

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

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

आपके मामले में, वहाँ होगा , Murphys कानून द्वारा, बिंदु जहां प्रबंधन आप 0.0, 0.5, 1.0 ... लेकिन 0.0, 0.4, 0.8 ... या जो कुछ भी नहीं करना चाहता है; आप तुरंत बोर हो जाएंगे, और आपका जूनियर प्रोग्रामर (या खुद) आपको समस्या का पता लगने तक लंबा और कठिन डिबग करेगा।

आपके विशेष कोड में, मैं वास्तव में एक पूर्णांक लूप चर होगा। यह iवें बटन को दर्शाता है , रनिंग नंबर को नहीं।

और मैं शायद, अतिरिक्त स्पष्टता के लिए, नहीं लिखूंगा, i/2लेकिन i*0.5जो इसे स्पष्ट रूप से स्पष्ट करता है कि क्या चल रहा है।

var BUTTONS=11;
var STANDARD_LINE=3;

for(var i=0; i<BUTTONS; i++) {
    button.text = (i*0.5)+'';
    if (i==STANDARD_LINE) {
      button.color='red';
    }
}

नोट: जैसा कि टिप्पणियों में बताया गया है, वास्तव में जावास्क्रिप्ट में पूर्णांकों के लिए एक अलग प्रकार नहीं है। लेकिन 15 अंकों तक के पूर्णांक सटीक / सुरक्षित होने की गारंटी है (देखें https://www.ecma-international.org/ecma-262/6.0/#sec-number.max_safe_integer ), इसलिए इस पर तर्क के लिए ("यह है") अधिक भ्रामक / त्रुटि पूर्णांक या गैर-पूर्णांक के साथ काम करने की संभावना है ") यह उचित रूप से" आत्मा में "एक अलग प्रकार होने के करीब है; दैनिक उपयोग में (लूप, स्क्रीन निर्देशांक, सरणी सूचकांक आदि) Numberजावास्क्रिप्ट के रूप में प्रतिनिधित्व पूर्णांक संख्या के साथ कोई आश्चर्य नहीं होगा ।

Comments

मैं नाम BUTTONS को कुछ और में बदल दूंगा - सभी के बाद 11 बटन हैं और 10. नहीं। शायद FIRST_BUTTON = 0, LAST_BUTTON = 10, STANDARD_LINE_BUTTON = 3. इसके अलावा, हाँ, यह है कि इसे कैसे करना चाहिए।

— gnasher729

यह सच है, @EricDuminil, और मैंने उत्तर में इसके बारे में थोड़ा जोड़ा है। धन्यवाद!

— AnoE

Answer 6

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

function precisionRound(number, precision) {
  let factor = Math.pow(10, precision);
  return Math.round(number * factor) / factor;
}

var maxButtonValue = 5.0;
var buttonSpacing = 0.5;

let countEstimate = precisionRound(maxButtonValue / buttonSpacing, 5);
var buttonCount = Math.floor(countEstimate) + 1;

var highlightPosition = 3;
var highlightColor = 'red';

for (let i=0; i < buttonCount; i++) {
    let buttonValue = i / buttonSpacing;
    button.text = buttonValue.toString();
    if (i == highlightPosition) {
        button.color = highlightColor;
    }
}

यह अधिक कोड हो सकता है, लेकिन यह अधिक पठनीय और अधिक मजबूत भी है।

Answer 7

आप मान के रूप में लूप काउंटर का उपयोग करने के बजाय आपके द्वारा दिखाए जा रहे मूल्य की गणना करके पूरी बात को टाल सकते हैं:

var MAX=5.0;
var DIFF=0.5
var STANDARD_LINE=1.5;

for(var i=0; (i*DIFF) < MAX ; i=i+1){
    var val = i * DIFF

    button.text=val+'';

    if(val==STANDARD_LINE){
      button.color='red';
    }
}

Answer 8

फ्लोटिंग प्वाइंट अंकगणित धीमा है और पूर्णांक अंकगणित तेज है, इसलिए जब मैं फ्लोटिंग पॉइंट का उपयोग करता हूं, तो मैं इसका अनावश्यक रूप से उपयोग नहीं करूंगा जहां पूर्णांक का उपयोग किया जा सकता है। कुछ छोटी सी त्रुटि के साथ अस्थायी बिंदु संख्याओं, यहां तक ​​कि स्थिरांक के बारे में सोचना हमेशा उपयोगी होता है। डिबगिंग के दौरान देशी फ़्लोटिंग पॉइंट नंबरों को प्लस / माइनस फ़्लोटिंग पॉइंट ऑब्जेक्ट्स से बदलना बहुत उपयोगी होता है जहाँ आप प्रत्येक नंबर को पॉइंट के बजाय रेंज के रूप में मानते हैं। इस तरह से आप प्रत्येक अंकगणितीय ऑपरेशन के बाद प्रगतिशील बढ़ती अशुद्धि को उजागर करते हैं। तो "1.5" को "1.45 और 1.55 के बीच कुछ संख्या" के रूप में सोचा जाना चाहिए, और "1.50" के बारे में "1.495 और 1.505 के बीच कुछ संख्या" के रूप में सोचा जाना चाहिए।

Comments

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

— 23

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

— जीरो मोस्टर्ट

@JeroenMostert SSE / AVX ने पूर्णांक और फ़्लोट्स दोनों के लिए वेक्टर संचालन किया है, और आप छोटे पूर्णांक (क्योंकि बिट्स घातांक पर व्यर्थ नहीं होते हैं) का उपयोग करने में सक्षम हो सकते हैं, इसलिए सिद्धांत रूप में एक अक्सर अत्यधिक-अनुकूलित पूर्णांक कोड से अधिक प्रदर्शन को निचोड़ सकता है। तैरने की तुलना में। लेकिन फिर भी, यह अधिकांश अनुप्रयोगों के लिए प्रासंगिक नहीं है और निश्चित रूप से इस प्रश्न के लिए नहीं है।

— लेफ्टरनबाउट

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

— जीरो मोस्टर्ट