क्या कोई कारण है कि अधिकांश प्रोग्रामिंग भाषाओं में '>!' (इससे अधिक नहीं) और '<!' (ऑपरेटरों से कम नहीं) है?


28

मुझे आश्चर्य है कि अगर कोई कारण है - या अगर यह सिर्फ इतिहास की दुर्घटना है - कि अधिकांश प्रोग्रामिंग भाषाओं में कोई !>और !<ऑपरेटर नहीं हैं?

a >= b (एक बड़ा या बराबर बी) के रूप में लिखा जा सकता है !(a < b) (एक कम बी) , जो बराबर है a !< b

इस सवाल ने मुझे तब मारा जब मैं अपनी अभिव्यक्ति ट्री बिल्डर को कोड करने के बीच में था। अधिकांश प्रोग्रामिंग भाषाओं के लिए a != bऑपरेटर हैं !(a=b), तो क्यों नहीं !>और !<?

अद्यतन करें:

  • !<(कम नहीं) की तुलना में उच्चारण करना अधिक आसान है >=(अधिक से अधिक या बराबर)
  • !<(कम नहीं) टाइप>= (अधिक से अधिक या बराबर) से छोटा है
  • !<(कम नहीं) समझने में आसान है *>= (अधिक से अधिक या बराबर)

* क्योंकि ORबाइनरी ऑपरेटर आपको मस्तिष्क को दो ऑपरेंड (grater, बराबर) संचालित करने की आवश्यकता है, जबकि NOTएकरी ऑपरेटर है और आपको मस्तिष्क केवल एक ऑपरेंड (कम) के साथ संचालित करने की आवश्यकता है।


3
यह नहीं हर भाषा में उच्चारण आसान जरूरी। उदाहरण के लिए, जर्मन में, हम कहते हैं "ग्रोअर / ग्लीइच", मैंने कभी भी "निक्ट क्लीनेर" नहीं सुना है।
इंगो

1
समझने में अधिक आसान तर्क पानी पकड़ नहीं करता है या तो। आपको किसी भी स्थिति में 2 ऑपरेंड का संचालन करना होगा, क्योंकि यह रिलेशनल ऑपरेटरों के साथ सामान्य है। इसके अलावा, आप बस यह मान सकते हैं कि मस्तिष्क 2 के बजाय 1 ऑपरेंड पर आसान काम कर सकता है। क्या आपके पास तंत्रिका विज्ञान के क्षेत्र से इसके लिए कोई सबूत है?
ingo

जवाबों:


84

डी प्रोग्रामिंग भाषा और डीएमसी के विस्तार C और C ++ के लिए इन ऑपरेटरों (उन सभी को 14 संयोजनों) का समर्थन किया था, लेकिन दिलचस्प है, डी इन ऑपरेटरों का बहिष्कार करने जा रहा है , जिसका मुख्य कारण

  1. वास्तव में क्या है a !< b? यह है a>=b || isNaN(a) || isNaN(b)!<के रूप में ही नहीं है >=, क्योंकि NaN !< NaNसच है जबकि NaN >= NaNझूठ है। IEEE 754 को मास्टर करना कठिन है, इसलिए a !< bNaN हैंडलिंग पर भ्रम का कारण होगा - आप फ़ोबोस (डी के मानक पुस्तकालय) में ऐसे ऑपरेटरों की खोज कर सकते हैं, और पाठकों द्वारा एनएनएन को याद दिलाने के लिए इसके बगल में टिप्पणियों का उपयोग करना शामिल है।
  2. इसलिए, कुछ लोग इसका उपयोग करेंगे, भले ही ऐसे ऑपरेटर डी की तरह मौजूद हों,
  3. और किसी को इन शायद ही कभी इस्तेमाल किए गए ऑपरेटरों के लिए 8 अधिक टोकन को परिभाषित करना होगा, जो संकलक को थोड़े से लाभ के लिए जटिल करता है,
  4. और उन ऑपरेटरों के बिना, एक अभी भी समकक्ष का उपयोग कर सकता है !(a < b), या यदि कोई स्पष्ट होना पसंद करता है a >= b || isNaN(a) || isNaN(b), और उन्हें पढ़ना आसान है।

इसके अलावा, संबंध (≮, ≮, ≮, s) शायद ही कभी मूल गणित में देखे जाते हैं, (≥) !=या >=(, ) के विपरीत , इसलिए कई लोगों के लिए समझना मुश्किल है।

शायद ये भी कारण हैं कि अधिकांश भाषाएं उनका समर्थन नहीं करती हैं।


seldomly seen in basic math- और अधिक, कभी नहीं देखा। हम बीजगणित में वापस जानने के लिए इसे गणितीय रूप से समतुल्य (विशेषकर चूंकि NaNमूल गणित में प्रकट नहीं होते हैं)
फ्लिप करते हैं

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

@ सुपरकैट: आप <fenv.h>जैसे कार्यों का उपयोग करके अपवाद को फेंकने के लिए NaN संचालन कर सकते हैं fesetexceptflag
kennytm

@ केनीटीएम: ऑपरेशन करने से पहले ध्वज को सेट करना और icky और परेशानी-रहित प्रतीत होने के बाद इसे बंद करना, और यह कुल ऑर्डर लगाने की इच्छा की संभावना को संबोधित नहीं करता है। आईईईई जो मुझे समझ में आया है, उसने कुछ नए तुलना तरीकों को पेश किया है जो कुल आदेश लागू करेगा, जिसे मैं एक स्वागत पर विचार करूंगा यदि अतिदेय बदल जाए; यह देखना दिलचस्प होगा कि भाषाएं कैसे प्रतिक्रिया देती हैं।
सुपरकैट

47

क्योंकि यह बिल्कुल अलग अर्थ के साथ दो अलग ऑपरेटरों के लिए बहुत मतलब नहीं है।

  • "अधिक नहीं" ( !>) "कम या बराबर" ( <=) के समान है
  • "कम नहीं" ( !<) बिल्कुल "अधिक या बराबर" ( >=) के समान है

यह "नहीं के बराबर" ( !=) पर लागू नहीं होता है , एक ही अर्थ वाला कोई ऑपरेटर नहीं है।

तो, आपका संशोधन भाषा को बिना किसी लाभ के अधिक जटिल बना देगा।


5
के बारे में क्या x = x + 1, x += 1है, और x++?

33
@dunsmoreb: उनमें से कोई भी एक ही बात नहीं है। केवल एक ही "वेतन वृद्धि" का उद्देश्य है। तथ्य यह है कि आप एक ही उद्देश्य की सेवा के लिए अन्य दो अभिव्यक्तियों का लाभ उठाते हैं, अप्रासंगिक है- वे दोनों कहीं अधिक सामान्य हैं।
डेडएमजी

1
<>के रूप में एक ही अर्थ के साथ एक ऑपरेटर है !=, और अजगर 2 दोनों है।
krlmlr

9
@ user946850 और दोनों को अब व्यापक रूप से एक गलती माना जाता है, के उपयोग को <>लंबे समय से हटा दिया गया है और इसे 3.0 से हटा दिया गया है (और आपको लगता है, पिछले 2.x रिलीज कभी , 2.7, गर्मियों में 2010 में जारी किया गया था)।

3
@svick जो ++ ऑपरेटर को और भी शानदार बनाता है, यह उन C # प्रोग्रामर्स को यहाँ आने से रोकेगा, जो प्रोग्राम के व्यवहार के बारे में तर्कसंगत धारणा बनाते हैं, फिर मेरी C ++ प्रोग्रामर जॉब को चुरा लेंगे!

10

!<का पर्यायवाची है >=। बाद में अच्छी तरह से परिभाषित गणितीय प्रतीक टाइप करने का एक तरीका है । आप सही कह रहे हैं कि "कम से कम" बोलचाल की भाषा में प्रयोग नहीं किया जाता है, हालाँकि यह बोलचाल की भाषा में है और अस्पष्ट हो सकता है (इसकी व्याख्या की जा सकती है या इसकी गलत व्याख्या की जा सकती है >)। दूसरी ओर प्रोग्रामिंग और गणित का उपयोग स्पष्ट रूप से परिभाषित, अस्पष्ट शब्दावली है।

3-मान तर्क में भी, जैसे एएनएसआई एसक्यूएल, not x < yके बराबर है x >= y, क्योंकि वे दोनों या NULLतो देते हैं xया yहै NULL। हालाँकि, गैर-एएनएसआई अनुरूप SQL बोलियाँ हैं, जहाँ यह समकक्ष नहीं है, और उनके पास नहीं है!<


10
हालांकि, फ्लोटिंग-पॉइंट नंबरों का उपयोग करते समय वे आमतौर पर समतुल्य नहीं होते हैं। उदाहरण के लिए, किसी भी चीज की तुलना NaNकरना गलत है, इसलिए !(2 < NaN) == true, जबकि (2 >= NaN) == false
हमार

@ उमर: सच है, लेकिन यह एस के आसपास सभी अंकगणितीय संबंधों का सच है NaN। वे सभी सामान्य रूप से व्यवहार करना बंद कर देते हैं।
निकोल बोलस

@ उमर - यह फ्लोटिंग-पॉइंट फॉल्ट है, यह सिर्फ ऑर्ड को सही ढंग से लागू नहीं कर रहा है, इसलिए बोलने के लिए। यह फिर भी कोई बड़ी समस्या नहीं है क्योंकि कोई भी हमें लागू करने के लिए मजबूर नहीं करता है a !< b = not (a < b), हम बस (<!) = (> =) कह सकते हैं।
इंगो

8

Transact-SQL में है !> (इससे अधिक नहीं) और ! <(से कम नहीं) ऑपरेटर हैं।

तो, आपके अलावा, Sybase Microsoft में किसी ने भी सोचा कि यह एक अच्छा विचार होगा। जैसे Microsoft Bob! :)


क्या इसे 2005 में जोड़ा नहीं गया था?
जेएफओ

5
इस दुनिया में बहुत सारे पागल बीमार लोग हैं जो एक दूसरे के साथ सहमत होने में अकेले नहीं हैं, आम सहमति! = शुद्धता।

@ जेफ़ो तब हमें माइक्रोसॉफ्ट को दोष देना चाहिए, न कि साइबेस को?
यानि

दिलचस्प। इसके पीछे की कहानी से मैं उत्सुक हूं।
सर्फस

@surfasb Yeap, मुझे भी। मेरा अनुमान है कि यह सिंटैक्टिक शुगर है, इसके बारे में कुछ खास नहीं है।
यानि

4

मुझे लगता है कि उत्तर बस इतना है कि !<ऑपरेटर की कोई आवश्यकता नहीं है । के रूप में आप अपने प्रश्न में बताया वहाँ पहले से ही है >=और <=साथ संभावना के लिए एक मौजूदा अभिव्यक्ति नकारना के साथ, तो क्यों एक और ऑपरेटर जोड़ सकता हूँ?


मैं मानता हूँ कि ऑपरेटर को जोड़ने का कोई मतलब नहीं है जो एक ही काम करते हैं, लेकिन "उन्होंने" क्यों चुना = = के बजाय! <!, यह बहुत आसान नहीं है LESSER, फिर GREATER या EQUALS, यह टाइप करने के लिए छोटा है, यह आसान है समझने के लिए मस्तिष्क।
एलेक्स बर्टसेव

!<टाइप करने के लिए छोटा नहीं है >=, या मैं कुछ याद कर रहा हूँ?
ब्रायन ओकली

मेरा मतलब था कि यह पाठ प्रतिनिधित्व (स्पष्ट पाठ) है।
एलेक्स बर्टसेव

4

से आरएफसी 1925

पूर्णता तब तक पहुंची है जब जोड़ने के लिए कुछ नहीं बचा है, लेकिन जब कुछ भी नहीं बचा है तो लेने के लिए नहीं है।

अतिरिक्त ऑपरेटरों को जोड़ना जो मौजूदा कार्यक्षमता को डुप्लिकेट करते हैं, वे भाषा (और इस तरह टोकन और पार्सर) में जोड़ (अनावश्यक) जटिलता के अलावा कुछ भी नहीं करते हैं।

उन भाषाओं पर भी विचार करें जहां ऑपरेटर ओवरलोडिंग संभव है, आपके पास ओवरलोड करने के लिए एक और ऑपरेटर होगा। भ्रम पर विचार करें जब bool operator<=और bool operator!>अलग-अलग चीजें वापस कर सकती हैं (हां, मुझे पता है कि कोई पहले से ही असंगत तुलना कर सकता है)।

अंत में, उन भाषाओं के बारे में सोचें, जहाँ विधियाँ या परिचालकों को बहुतायत से परिभाषित किया गया है (रूबी - मैं आपको देख रहा हूँ ) और आपके पास एक प्रोग्रामर है जो <= का उपयोग करता है जबकि दूसरा उपयोग करता है!> और आपके पास एक ही अभिव्यक्ति के लिए कई कोड शैलियाँ हैं।


हाँ! यह वैज्ञानिक पारसीमोनी का सिद्धांत है।
लूसर

3

! <> के बराबर है = अब हमारे पास दूसरा क्यों नहीं है क्योंकि सभी भाषा पहले सकारात्मक ऑपरेटर को लागू करती हैं और फिर नकारात्मक ऑपरेटर के पास पहुंचती हैं, जैसा कि कार्यान्वयन => भी कवर होता है! <और <= कवर!>। तो भाषा निर्माता इन पर जाता है और सोचा कि वे बेमानी हो जाएंगे और उन्हें छोड़ देंगे।

हमेशा सकारात्मक मामले को लागू करने की कोशिश करें, फिर पहले नकारात्मक मामले पर जाएं (:) सकारात्मक सोच, मुझे केवल व्यक्तिगत दृष्टिकोण)


2

कारण यह है कि प्रोग्रामिंग भाषाओं में ऑपरेटर गणितीय परंपरा से उधार लेते हैं और गणित में कोई भी "छोटे या बराबर" के बाद "अधिक नहीं" और "छोटा नहीं" का उपयोग करता है और "बड़ा या समान" सिर्फ नौकरी के रूप में अच्छा करता है।

इसलिए प्रोग्रामिंग भाषाओं में हमें आमतौर पर एक प्रतीक मिलता है जैसे als बराबरी के लिए नहीं (!= या /=, जब तक कि किसी के साथ <>या पाठ्य सामग्री के साथ फैंसी न हो )

और ≤ और look जैसी दिखने वाली चीजें (<= और >=)


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


2

मैं आंशिक रूप से विधानसभा निर्देश सेट को दोष देता हूं। आपको jge"जंप से अधिक या बराबर" के लिए जैसे निर्देश मिले हैं । के रूप में "से कम नहीं तो कूद करने के लिए"।

कंपाइलर लेखकों ने असेंबली के लेखकों के साथ क्या किया है, जो कि चिप पर डिज़ाइन किए जाने के समय लेबल के आधार पर संभवत: आधारित था।

... संभवतः।


1

मुझे लगता है कि मैंने कुछ साल पहले कुछ भाषाओं को देखा था, जहां !=ऑपरेटर (बराबरी नहीं) के बजाय , कुछ <>का उपयोग किया गया था। हालांकि उनके नाम याद नहीं किए जा सकते ...

मुझे लगता है कि इसे पढ़ना !(a < b)या उससे a !< bभी कठिन है a >= b। शायद यही कारण है कि !<इसका उपयोग नहीं किया जाता है (यह मेरी राय में बदसूरत दिखता है)।


1
<>मुख्य रूप से बेसिक बोलियों, एसक्यूएल और पास्कल बोलियों द्वारा प्रयोग किया जाता है।
यानिस

@Yannis Rizos अनुस्मारक के लिए धन्यवाद। उन्होंने हमें हाई-स्कूल में पास्कल सिखाया और यहीं मैंने इसे देखा :)।
रादु मुराज़े

2
पाइथन 2 में भी है <>, हालांकि इसे 3 में हटा दिया गया था
डैनियल लुबरोव

तार्किक दृष्टिकोण !=से <>, सामान्य से अधिक है , क्योंकि आपके पास चीजें (जैसे जटिल संख्या) हो सकती हैं जहां समानता अच्छी तरह से परिभाषित है, लेकिन वास्तव में एक उपयोगी आदेश नहीं है।
डेविड थार्नले
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.