C के पास अहस्ताक्षरित फ़्लोट क्यों नहीं है?


131

मुझे पता है, सवाल अजीब लग रहा है। प्रोग्रामर कभी-कभी बहुत ज्यादा सोचते हैं। कृपया पर पढ़ें ...

CI उपयोग signedऔर unsignedपूर्णांक में। मुझे यह तथ्य पसंद है कि कंपाइलर मुझे चेतावनी देता है यदि मैं एक हस्ताक्षरित पूर्णांक को एक अहस्ताक्षरित चर को असाइन करने जैसी चीजें करता हूं। यदि मुझे अहस्ताक्षरित पूर्णांकों के साथ हस्ताक्षरित और बहुत अधिक तुलना में चेतावनी मिलती है।

मुझे ये चेतावनी पसंद है। वे मेरे कोड को सही रखने में मेरी मदद करते हैं।

फ्लोट के लिए हमारे पास समान लक्जरी क्यों नहीं है? एक वर्गमूल निश्चित रूप से एक ऋणात्मक संख्या कभी नहीं लौटाएगा। अन्य स्थानों के साथ-साथ एक नकारात्मक फ्लोट मूल्य का कोई मतलब नहीं है। अहस्ताक्षरित फ्लोट के लिए एकदम सही उम्मीदवार।

Btw - मैं वास्तव में एकल अतिरिक्त बिट के बारे में उत्सुक नहीं हूं, जो मैं फ़्लोट से साइन बिट को हटाकर प्राप्त कर सकता हूं। मैं सुपर के साथ खुश हूं floatक्योंकि वे अभी हैं। मैं कभी-कभी बिना बताए एक फ्लोट को चिह्नित करना चाहता हूं और मुझे उसी तरह की चेतावनी मिलती है जो मुझे पूर्णांक के साथ मिलती है।

मैं किसी भी प्रोग्रामिंग भाषा से अवगत नहीं हूँ जो अहस्ताक्षरित फ्लोटिंग-पॉइंट संख्याओं का समर्थन करती है।

किसी भी विचार क्यों वे मौजूद नहीं है?


संपादित करें:

मुझे पता है कि x87 FPU में अहस्ताक्षरित फ़्लोट्स से निपटने के लिए कोई निर्देश नहीं है। चलो बस हस्ताक्षरित फ्लोट निर्देशों का उपयोग करें। दुरुपयोग (जैसे शून्य से नीचे जाना) को उसी तरह से अपरिभाषित व्यवहार माना जा सकता है जिस तरह से हस्ताक्षरित पूर्णांक का अतिप्रवाह अपरिभाषित है।


4
दिलचस्प है, क्या आप एक ऐसे मामले का उदाहरण पोस्ट कर सकते हैं जहां हस्ताक्षर टाइपकास्टिंग सहायक था?

litb, क्या आपकी टिप्पणी मुझ पर निर्देशित थी? यदि ऐसा है, तो मैं इसे प्राप्त नहीं करता

इरिंबिलंजा यस :) फैब एक नकारात्मक संख्या नहीं लौटा सकता है, क्योंकि यह अपने तर्क का पूर्ण मूल्य लौटाता है
-

Right.i didnt यह पूछते हैं कि एक काल्पनिक अहस्ताक्षरता कैसे corectness.what की मदद कर सकती है। मैंने पूछा था: किस स्थिति में पिपेंब्रिनक ने इंट सिग्नेचर टाइपेकिटेकिंग को सहायक पाया है (जिससे वह फ़्लोट्स के लिए एक ही तंत्र का नेतृत्व करता है)। कारण यह है कि मैं पूछता हूँ कि मुझे अहस्ताक्षरित पूरी तरह से बेकार लगता है। प्रकार के संबंध में

1
पॉइंट-इन-रेंज चेक के लिए एक अहस्ताक्षरित माइक्रो-ऑप्टिमाइज़ेशन है: ((अहस्ताक्षरित) (पी-मिनट)) <(अधिकतम-मिनट), जिसमें केवल एक शाखा है, लेकिन, हमेशा की तरह, यह देखने के लिए प्रोफ़ाइल के लिए सबसे अच्छा है कि क्या यह वास्तव में मदद करता है (मैं ज्यादातर 386 कोर पर इसका इस्तेमाल करता था इसलिए मुझे नहीं पता कि आधुनिक सीपीयू कैसे सामना करते हैं)।
स्किज़

जवाबों:


114

C ++ में अहस्ताक्षरित फ़्लोट्स के लिए समर्थन क्यों नहीं है क्योंकि सीपीयू को निष्पादित करने के लिए कोई समान मशीन कोड संचालन नहीं है। इसलिए इसका समर्थन करना बहुत ही अयोग्य होगा।

यदि C ++ ने इसका समर्थन किया, तो आप कभी-कभी एक अहस्ताक्षरित फ़्लोट का उपयोग करेंगे और यह महसूस नहीं करेंगे कि आपका प्रदर्शन अभी-अभी मारा गया है। यदि C ++ ने इसका समर्थन किया है तो हर फ्लोटिंग पॉइंट ऑपरेशन को यह देखने के लिए जांचना होगा कि यह हस्ताक्षरित है या नहीं। और उन कार्यक्रमों के लिए जो लाखों फ्लोटिंग पॉइंट ऑपरेशन करते हैं, यह स्वीकार्य नहीं है।

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

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

मैं निश्चित रूप से अहस्ताक्षरित फ्लोट होने की उपयोगिता देखता हूं। लेकिन C / C ++ ऐसी दक्षता को चुनता है जो सुरक्षा के लिए सभी के लिए सबसे अच्छा काम करती है।


17
C / C ++ को भाषा को लागू करने के लिए विशिष्ट मशीन कोड संचालन की आवश्यकता नहीं होती है। प्रारंभिक C / C ++ कंपाइलर 386 के लिए फ्लोटिंग पॉइंट कोड उत्पन्न कर सकता है - एक सीपीयू जिसमें कोई FPU नहीं है! कंपाइलर FPU निर्देशों का अनुकरण करने के लिए पुस्तकालय कॉल उत्पन्न करेगा। इसलिए, CPU समर्थन के बिना एक ufloat किया जा सकता है
Skizz

10
स्किज़, जबकि यह सही है, ब्रायन ने पहले ही इसे संबोधित किया - क्योंकि कोई समान मशीन कोड नहीं है, प्रदर्शन तुलनात्मक रूप से भयानक होगा।
एंथोनी

2
@ ब्रायन आर बॉडी: मैंने आपको यहां खो दिया: "क्योंकि सीपीयू को निष्पादित करने के लिए कोई समान मशीन कोड संचालन नहीं है ..."। क्या आप सरल शब्दों में समझा सकते हैं?
लेज़र

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

2
मुझे यकीन नहीं है कि मैं देख रहा हूं कि इस प्रदर्शन को क्यों प्रभावित करना चाहिए। ठीक उसी तरह int, जैसे साइन-संबंधित सभी प्रकार की जाँच संकलन समय पर हो सकती है। ओपी का सुझाव है कि unsigned floatयह सुनिश्चित करने के लिए एक नियमित float-समय-समय पर जांच के रूप में लागू किया जाएगा कि कुछ गैर-सार्थक संचालन कभी नहीं किया जाता है। परिणामी मशीन कोड और प्रदर्शन समान हो सकते हैं, भले ही आपके फ्लोट पर हस्ताक्षर किए गए हों या नहीं।
xanderflood

14

C / C ++ में हस्ताक्षरित और अहस्ताक्षरित पूर्णांक के बीच एक महत्वपूर्ण अंतर है:

value >> shift

साइन किए गए मान शीर्ष बिट को अपरिवर्तित छोड़ देते हैं (साइन एक्सटेंशन), ​​अहस्ताक्षरित मान शीर्ष बिट को साफ़ करते हैं।

कोई अहस्ताक्षरित फ्लोट नहीं होने का कारण यह है कि यदि कोई नकारात्मक मान नहीं है, तो आप जल्दी से सभी प्रकार की समस्याओं में भाग लेंगे। इस पर विचार करो:

float a = 2.0f, b = 10.0f, c;
c = a - b;

C का क्या मूल्य है? -8। लेकिन नकारात्मक संख्या के बिना एक प्रणाली में इसका क्या मतलब होगा। FLOAT_MAX - 8 शायद? वास्तव में, यह FLOAT_MAX के रूप में काम नहीं करता है - 8 सटीक प्रभाव के कारण FLOAT_MAX है इसलिए चीजें और भी अधिक खराब हैं। क्या होगा अगर यह अधिक जटिल अभिव्यक्ति का हिस्सा था:

float a = 2.0f, b = 10.0f, c = 20.0f, d = 3.14159f, e;
e = (a - b) / d + c;

यह 2 के पूरक प्रणाली की प्रकृति के कारण पूर्णांक के लिए कोई समस्या नहीं है।

मानक गणितीय कार्यों पर भी विचार करें: पाप, कॉस और टैन केवल उनके आधे इनपुट मानों के लिए काम करेंगे, आप मानों का लॉग नहीं पा सकते <1, आप द्विघात समीकरणों को हल नहीं कर सकते: x = (-b +/- रूट ( बी बी - 4.एसी)) / 2. ए, और इतने पर। वास्तव में, यह संभवतः किसी भी जटिल कार्य के लिए काम नहीं करेगा क्योंकि ये बहुपद सन्निकटन के रूप में लागू होते हैं जो कहीं न कहीं नकारात्मक मूल्यों का उपयोग करेंगे।

तो, अहस्ताक्षरित फ़्लोट्स बहुत बेकार हैं।

लेकिन इसका मतलब यह नहीं है कि एक वर्ग जो फ्लोट मानों की जाँच करता है, उपयोगी नहीं है, आप किसी दिए गए रेंज के मानों को क्लैंप करना चाहते हैं, उदाहरण के लिए RGB गणनाएँ।


@Skizz: यदि प्रतिनिधित्व एक समस्या है, तो आपका मतलब है कि अगर कोई व्यक्ति फ्लोट स्टोर करने के लिए एक विधि तैयार कर सकता है जो उतना ही कुशल है 2's complement, तो अहस्ताक्षरित फ़्लोट होने के साथ कोई समस्या नहीं होगी?
लेज़र

3
value >> shift for signed values leave the top bit unchanged (sign extend) क्या अापको उस बारे में पूर्ण विशवास है? मैंने सोचा था कि कार्यान्वयन-परिभाषित व्यवहार, कम से कम नकारात्मक हस्ताक्षरित मूल्यों के लिए।
दान

@Dan: अभी हाल के मानक को देखा है और यह वास्तव में बताता है कि यह कार्यान्वयन को परिभाषित करता है - मुझे लगता है कि बस एक सीपीयू है जिसमें साइन एक्सटेंशन निर्देश के साथ कोई बदलाव नहीं है।
19


1
फ़्लोटिंग पॉइंट पारंपरिक रूप से रैप करने के बजाय (- to / + Inf) संतृप्त होता है। आप संतृप्त 0.0या शायद Inf या NaN को संतृप्त अतिप्रवाह अतिप्रवाह की उम्मीद कर सकते हैं । या बस अपरिभाषित व्यवहार करें, जैसे ओपी ने प्रश्न को संपादित करने का सुझाव दिया। पुन: ट्रिगर कार्य: इसलिए के sinऔर इतने पर अहस्ताक्षरित-इनपुट संस्करणों को परिभाषित नहीं करते हैं , और हस्ताक्षर किए अनुसार उनके वापसी मूल्य का इलाज करना सुनिश्चित करते हैं। यह सवाल अहस्ताक्षरित फ्लोट के साथ फ्लोट को बदलने का प्रस्ताव नहीं था , बस unsigned floatएक नए प्रकार के रूप में जोड़ रहा है ।
पीटर कॉर्डेस

9

(एक तरफ के रूप में, पर्ल 6 आपको लिखने देता है

subset Nonnegative::Float of Float where { $_ >= 0 };

और फिर आप Nonnegative::Floatकिसी अन्य प्रकार की तरह उपयोग कर सकते हैं ।)

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

[संपादित करें]

सी असेंबली की तरह है: जो आप देखते हैं वही आपको मिलता है। एक निहितार्थ "मैं देखूंगा कि यह फ्लोट आपके लिए नॉनवेजेटिव है" इसके डिजाइन दर्शन के खिलाफ जाता है। यदि आप वास्तव में इसे चाहते हैं, तो आप इसे जोड़ सकते हैं assert(x >= 0)या समान कर सकते हैं , लेकिन आपको यह स्पष्ट रूप से करना होगा।


svn.perl.org/parrot/trunk/languages/perl6/docs/STATUS हाँ कहता है, लेकिन of ...पार्स नहीं करता है।
इफिशिएंट

8

मेरा मानना ​​है कि हस्ताक्षर किए गए प्रस्ताव की तुलना में एक बड़े मूल्य मार्जिन की आवश्यकता के कारण अहस्ताक्षरित int बनाया गया था।

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

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


2
इसके अलावा, पूर्णांकों का जोड़ और घटाव एक ही हस्ताक्षरित या अहस्ताक्षरित - अस्थायी बिंदु है, इतना नहीं। इस तरह की सुविधा की अपेक्षाकृत कम सीमांत उपयोगिता को देखते हुए हस्ताक्षरित और अहस्ताक्षरित दोनों झांकियों का समर्थन करने के लिए अतिरिक्त काम कौन करेगा?
पंचांग

7

मुझे लगता है कि ट्रेब सही रास्ते पर है। पूर्णांक के लिए यह अधिक महत्वपूर्ण है कि आपके पास एक समान संगत प्रकार है। वे हैं जो बिट-शिफ्टिंग में उपयोग किए जाते हैं और बिट-मैप में उपयोग किए जाते हैं । एक साइन बिट बस रास्ते में हो जाता है। उदाहरण के लिए, ऋणात्मक मान को राइट-शिफ्ट करने से परिणामस्वरूप मूल्य C ++ में परिभाषित होता है। ऐसा करना कि एक अहस्ताक्षरित पूर्णांक या इस तरह के अतिप्रवाह के साथ शब्दार्थ को पूरी तरह से परिभाषित किया गया है क्योंकि रास्ते में ऐसा कुछ भी नहीं है।

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


5

एक वर्गमूल निश्चित रूप से एक ऋणात्मक संख्या कभी नहीं लौटाएगा। अन्य स्थानों के साथ-साथ एक नकारात्मक फ्लोट मूल्य का कोई मतलब नहीं है। अहस्ताक्षरित फ्लोट के लिए एकदम सही उम्मीदवार।

C99 जटिल संख्या का समर्थन करता है, और sqrt का एक सामान्य प्रकार है, इसलिए sqrt( 1.0 * I)नकारात्मक होगा।


टिप्पणीकारों ने ऊपर एक मामूली चमक पर प्रकाश डाला, जिसमें मैं sqrtफ़ंक्शन के बजाय टाइप-जेनेरिक मैक्रो का उल्लेख कर रहा था , और यह जटिल के ट्रंकेशन द्वारा स्केलर फ्लोटिंग पॉइंट मान को उसके वास्तविक घटक में लौटा देगा:

#include <complex.h>
#include <tgmath.h>

int main () 
{
    complex double a = 1.0 + 1.0 * I;

    double f = sqrt(a);

    return 0;
}

इसमें एक मस्तिष्क-मस्सा भी शामिल है, क्योंकि किसी भी जटिल संख्या के sqrt का वास्तविक भाग सकारात्मक या शून्य है, और sqrt (1.0 * I) sqrt (0.5) + sqrt (0.5) * है, मैं -1.0 नहीं।


हां, लेकिन यदि आप जटिल संख्याओं के साथ काम करते हैं, तो आप एक अलग नाम के साथ एक फ़ंक्शन कहते हैं। साथ ही रिटर्न का प्रकार भी अलग है। हालाँकि अच्छी बात है!
निल्स पिपेनब्रिनक

4
Sqrt (i) का परिणाम एक जटिल संख्या है। और चूंकि जटिल संख्याओं का आदेश नहीं दिया गया है, आप नहीं कह सकते कि एक जटिल संख्या
नकारात्मक है

1
quinmars, यकीन है कि यह csqrt नहीं है? या आप सी के बजाय गणित के बारे में बात करते हैं? मैं वैसे भी सहमत हूँ कि यह एक अच्छा बिंदु है :)
जोहान्स शाउब -

दरअसल, मैं गणित के बारे में बात कर रहा था। मैं सी में जटिल संख्या के साथ कभी नहीं निपटा।
21

1
"वर्गमूल निश्चित रूप से एक ऋणात्मक संख्या कभी नहीं लौटाएगा।" -> sqrt(-0.0)अक्सर पैदा करता है -0.0। बेशक -0.0 एक नकारात्मक मूल्य नहीं है ।
chux -

4

मुझे लगता है कि यह इस बात पर निर्भर करता है कि IEEE फ़्लोटिंग-पॉइंट विनिर्देशों पर केवल हस्ताक्षर किए गए हैं और अधिकांश प्रोग्रामिंग भाषाएं उनका उपयोग करती हैं।

IEEE-754 फ़्लोटिंग-पॉइंट नंबरों पर विकिपीडिया लेख

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


C को IEEE-754 मानक के प्रदर्शित होने से बहुत पहले पेश किया गया था
14

@phuclv न तो सामान्य फ़्लोटिंग पॉइंट हार्डवेयर थे। इसे कुछ साल बाद मानक C "कुछ" में अपनाया गया था। संभवतः इसके बारे में इंटरनेट पर कुछ दस्तावेज तैर रहे हैं। (इसके अलावा, विकिपीडिया लेख में C99 का उल्लेख है)।
टोबियास विस्रे

मुझे समझ नहीं आ रहा है कि आपका क्या मतलब है। आपके उत्तर में कोई "हार्डवेयर" नहीं है, और IEEE-754 C के बाद पैदा हुआ था, इसलिए C में फ्लोटिंग-पॉइंट प्रकार IEEE-754 मानक पर निर्भर नहीं हो सकते, जब तक कि उन प्रकारों को C में बाद में पेश नहीं किया गया
phuclv

@phuclv C / को पोर्टेबल असेंबली के रूप में भी जाना जाता है, इसलिए यह हार्डवेयर के काफी करीब हो सकता है। वर्षों में भाषाओं का लाभ मिलता है, भले ही (मेरे समय से पहले) फ्लोट सी में लागू किया गया था, यह शायद एक सॉफ्टवेयर आधारित ऑपरेशन था और काफी महंगा था। इस प्रश्न का उत्तर देने के समय, मुझे स्पष्ट रूप से इस बात की बेहतर समझ थी कि अब मैं जो कर रहा हूं, मैं उसे समझाने की कोशिश कर रहा हूं। और यदि आप स्वीकृत उत्तर को देखते हैं तो आप समझ सकते हैं कि मैंने IEE754 मानक का उल्लेख क्यों किया। जो मुझे समझ में नहीं आता है वह यह है कि आपने 10 साल पुराने उत्तर को गलत कर दिया है जो स्वीकार नहीं किया गया है?
टोबियास विस्रे

3

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


4
पीडीपी -7, सी का पहला प्लेटफॉर्म, एक वैकल्पिक हार्डवेयर फ्लोटिंग पॉइंट यूनिट था। पीडीपी -11, सी का अगला प्लेटफॉर्म, हार्डवेयर में 32-बिट फ़्लोट्स था। 80x86 एक पीढ़ी बाद में आया, कुछ तकनीक के साथ जो पीछे की पीढ़ी थी।
ईपीएमिएंट

3

C में अनइंस्टॉल किए गए पूर्णांक प्रकारों को इस तरह से परिभाषित किया जाता है जैसे कि अमूर्त बीजगणितीय वलय के नियमों का पालन करना। उदाहरण के लिए, किसी भी मान के लिए X और Y, XY को Y से जोड़ने पर X की उपज होगी। अनइंस्टॉल किए गए पूर्णांक प्रकारों को सभी मामलों में इन नियमों का पालन करने की गारंटी दी जाती है, जिसमें किसी भी अन्य संख्यात्मक प्रकार से रूपांतरण नहीं होता है [या अलग-अलग आकार के बिना टाइप किए हुए] , और यह गारंटी इस प्रकार के सबसे महत्वपूर्ण लक्षणों में से एक है। कुछ मामलों में, अतिरिक्त गारंटीकृत प्रकारों के लिए नकारात्मक संख्याओं के बदले में नकारात्मक संख्याओं का प्रतिनिधित्व करने की क्षमता छोड़ देना सार्थक है। फ्लोटिंग-पॉइंट प्रकार, चाहे हस्ताक्षर किए गए हों या नहीं, बीजगणितीय रिंग के सभी नियमों का पालन नहीं कर सकते हैं [जैसे कि वे गारंटी नहीं दे सकते कि X + YY बराबर X होगा], और वास्तव में IEEE doesn ' यहां तक ​​कि उन्हें एक समानता वर्ग के नियमों का पालन करने की अनुमति देता है [कि कुछ मूल्यों की आवश्यकता है कि असमान खुद की तुलना करें]। मुझे नहीं लगता कि एक "अहस्ताक्षरित" फ़्लोटिंग-पॉइंट प्रकार किसी भी अक्षतंतु द्वारा पालन कर सकता है जो एक सामान्य फ़्लोटिंग-पॉइंट प्रकार नहीं कर सकता है, इसलिए मुझे यकीन नहीं है कि यह क्या लाभ प्रदान करेगा।


1

IHMO ऐसा इसलिए है क्योंकि हार्डवेयर या सॉफ़्टवेयर में हस्ताक्षरित और अहस्ताक्षरित फ़्लोटिंग दोनों प्रकारों का समर्थन करना बहुत अधिक परेशानी वाला होगा

पूर्णांक प्रकार के लिए हम उपयोग कर सकते हैं एक ही के लिए तर्क इकाई दोनों पर हस्ताक्षर किए और अहस्ताक्षरित पूर्णांक संचालन , 2 के पूरक के अच्छा संपत्ति का उपयोग कर ज्यादातर स्थितियों में, क्योंकि परिणाम उन मामलों में समान है ऐड, उप के लिए, गैर चौड़ा mul और सबसे बिटवाइज़ आपरेशनों। उन कार्यों के लिए जो हस्ताक्षरित और अहस्ताक्षरित संस्करण के बीच अंतर करते हैं, हम अभी भी अधिकांश तर्क साझा कर सकते हैं । उदाहरण के लिए

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

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

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

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

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

ऐसे सिस्टम पर जो सॉफ़्टवेयर फ़्लोटिंग-पॉइंट का उपयोग करते हैं, आपको प्रत्येक फ़ंक्शन के लिए 2 संस्करणों की आवश्यकता होती है, जो उस समय की स्मृति के लिए अपेक्षित नहीं था, इतना महंगा था, या आपको हस्ताक्षरित और अहस्ताक्षरित कार्यों के कुछ हिस्सों को साझा करने के लिए कुछ "पेचीदा" तरीका खोजना होगा।

हालाँकि फ्लोटिंग-पॉइंट हार्डवेयर सी का आविष्कार करने से बहुत पहले से मौजूद था , इसलिए मेरा मानना ​​है कि सी में चुनाव हार्डवेयर समर्थन की कमी के कारण था क्योंकि मैंने ऊपर उल्लेख किया था

कहा कि , मुख्य रूप से छवि प्रसंस्करण उद्देश्यों के लिए कई विशिष्ट अहस्ताक्षरित फ़्लोटिंग-पॉइंट प्रारूप मौजूद हैं, जैसे कि क्रोनोस समूह के 10 और 11-बिट फ़्लोटिंग-पॉइंट प्रकार


0

मुझे संदेह है क्योंकि सी कंपाइलरों द्वारा लक्षित अंतर्निहित प्रोसेसर के पास अहस्ताक्षरित फ्लोटिंग पॉइंट नंबरों से निपटने का अच्छा तरीका नहीं है।


क्या अंतर्निहित प्रोसेसर के पास हस्ताक्षरित फ्लोटिंग-पॉइंट संख्याओं से निपटने का एक अच्छा तरीका है? C तब लोकप्रिय हो रहा था जब फ्लोटिंग-पॉइंट सहायक प्रोसेसर idiosyncratic और शायद ही सार्वभौमिक थे।
डेविड थॉर्नले

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

0

अच्छा प्रश्न।

यदि, जैसा कि आप कहते हैं, यह केवल संकलन-समय की चेतावनी के लिए है और उनके व्यवहार में कोई बदलाव नहीं है अन्यथा अंतर्निहित हार्डवेयर प्रभावित नहीं होता है और इस तरह यह केवल C ++ / Compiler परिवर्तन होगा।

मैंने पहले भी वही जीता है, लेकिन बात यह है: यह बहुत मदद नहीं करेगा। सबसे अच्छा संकलक स्थिर असाइनमेंट पा सकता है।

unsigned float uf { 0 };
uf = -1f;

या न्यूनतम रूप से लंबा है

unsigned float uf { 0 };
float f { 2 };
uf -= f;

इसके बारे में बस इतना ही। अहस्ताक्षरित पूर्णांक प्रकारों के साथ आपको एक परिभाषित आवरण भी मिलता है, अर्थात यह मॉड्यूलर अंकगणित की तरह व्यवहार करता है।

unsigned char uc { 0 };
uc -= 1;

इसके बाद 'uc' 255 का मान रखता है।

अब, एक संमिलित फ़्लोट-प्रकार को दिए गए परिदृश्य के साथ एक कंपाइलर क्या करेगा? यदि मानों को संकलन समय पर नहीं पता है, तो यह कोड उत्पन्न करने की आवश्यकता होगी जो पहले गणनाओं को निष्पादित करता है और फिर साइन-चेक करता है। लेकिन क्या होगा जब इस तरह की गणना का परिणाम "-5.5" कहा जाएगा - किस मूल्य में संग्रहीत फ्लोट में संग्रहीत किया जाना चाहिए? अभिन्न प्रकार के लिए एक मॉड्यूलर अंकगणित की कोशिश कर सकता है, लेकिन यह अपनी समस्याओं के साथ आता है: सबसे बड़ा मूल्य अनन्तता अनंत है .... जो काम नहीं करता है, आपके पास "अनंत - 1" नहीं हो सकता है। सबसे बड़ी विशिष्ट मूल्य के लिए जा रही यह भी वास्तव में काम नहीं करेगा क्योंकि आप इसे में चलाते हैं। "NaN" एक उम्मीदवार होगा।

अंत में यह निश्चित बिंदु संख्याओं के साथ समस्या नहीं होगी क्योंकि मोडुलो को अच्छी तरह से परिभाषित किया गया है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.