বেশিরভাগ প্রোগ্রামিং ভাষাগুলিতে '!>' (এর চেয়ে বেশি নয়) এবং '! <' (এর চেয়ে কম নয়) অপারেটর না থাকার কোনও কারণ আছে কি?


28

আমি ভাবছি কোন কারণে না থাকলে - অথবা যদি এটা শুধু ইতিহাসের একটি দুর্ঘটনা - কোন আছে !>এবং !<এ অপারেটার সবচেয়ে প্রোগ্রামিং ভাষা?

a >= b (একটি বৃহত্তর বা সমান খ সমান) হিসাবে লেখা যেতে পারে !(a < b) (একটি কম খ নয়) , সমান a !< b

এই প্রশ্নটি আমাকে আঘাত করেছিল যখন আমি নিজের অভিব্যক্তি ট্রি বিল্ডারকে কোডিংয়ের মাঝখানে ছিলাম। বেশিরভাগ প্রোগ্রামিং ভাষার a != bজন্য অপারেটর থাকে !(a=b), তবে কেন !>এবং না !<?

হালনাগাদ:

  • !<(কম নয়) এর চেয়ে উচ্চতর (সমান বা সমান) উচ্চারণ করা সহজ>=
  • !<(কম নয়) টাইপ করার চেয়ে কম >=(বৃহত্তর বা সমান)
  • !<(কম নয়) এর চেয়ে বেশি বোঝা *>= (বৃহত্তর বা সমান)

* কারণ ORবাইনারি অপারেটর আপনার মস্তিষ্কে দুটি অপারেন্ড (গ্রাটার, সমান) পরিচালনা করতে হবে, যখন NOTঅ্যানারি অপারেটর এবং আপনার মস্তিষ্ককে কেবল একটি অপারেণ্ড (কম) দিয়ে পরিচালনা করতে হবে।


3
এটা না যে ভাষায় উচ্চারণ সহজ অগত্যা। জার্মান ভাষায়, উদাহরণস্বরূপ, আমরা "গ্রেরার / গ্লাইচ" বলি, আমি কখনই "নিক্ট ক্লিনার" শুনিনি।
ইঙ্গো

1
সহজভাবে বোঝার জন্য যুক্তি পানি না রাখা হয়। রিলেশনাল অপারেটরগুলির সাথে এটি স্বাভাবিক হিসাবে আপনার উভয় ক্ষেত্রেই দুটি অপারেটর পরিচালনা করতে হবে। তদতিরিক্ত, আপনি কেবল সহজেই ধরে নিয়েছেন যে মস্তিষ্ক 2 এর পরিবর্তে 1 টি অপারেন্ডে আরও সহজভাবে কাজ করতে পারে ? নিউরোসায়েন্সের ক্ষেত্র থেকে আপনার কাছে কি কোনও প্রমাণ আছে ?
ইঙ্গো

উত্তর:


84

ডি প্রোগ্রামিং ভাষা এবং ডিএমসি এর এক্সটেনশন সি এবং সি ++ এইসব অপারেটার (তাদের সব 14 সমন্বয়) সমর্থন করেনি, কিন্তু মজার ব্যাপার, ডি এই অপারেটার বিনয়ী যাচ্ছে , প্রধানত কারণ

  1. আসলে কি a !< b? এটা হয় a>=b || isNaN(a) || isNaN(b)!<হয় না হিসাবে একই >=কারণে NaN !< NaNসত্য যখন NaN >= NaNমিথ্যা। আইইইই 754 আয়ত্ত করা শক্ত , সুতরাং a !< bনাএন হ্যান্ডলিংয়ের জন্য কেবল বিভ্রান্তি সৃষ্টি করবে - আপনি ফোবস (ডি এর স্ট্যান্ডার্ড লাইব্রেরি) তে এই ধরনের অপারেটরগুলি অনুসন্ধান করতে পারেন, এবং পাঠকদের মনে করিয়ে দেওয়ার জন্য বেশ কয়েকটি ব্যবহারের পাশে মন্তব্য রয়েছে এনএন জড়িত রয়েছে,
  2. অতএব, এই ধরণের অপারেটর ডি এর মতো উপস্থিত থাকলেও খুব কম লোকই এটি ব্যবহার করবে will
  3. এবং এই হ্রাসযুক্ত ব্যবহৃত অপারেটরগুলির জন্য আরও 8 টি টোকেন নির্ধারণ করতে হবে, যা সামান্য উপকারের জন্য সংকলককে জটিল করে তোলে,
  4. এবং এই অপারেটরগুলি ব্যতীত, কেউ এখনও সমতুল্য ব্যবহার করতে পারে !(a < b), বা যদি কেউ স্পষ্ট করে বলতে পছন্দ করে a >= b || isNaN(a) || isNaN(b), এবং সেগুলি পড়া সহজ।

এছাড়াও, সম্পর্কগুলি (≮, ≯, ≰, ≱) খুব কমই !=(≠) বা >=(≥) এর বিপরীতে মৌলিক গণিতে দেখা যায় , তাই এটি অনেক লোকের পক্ষে বোঝা শক্ত

বেশিরভাগ ভাষাগুলি তাদের সমর্থন না করার কারণগুলিও সম্ভবত এটি।


seldomly seen in basic math- আরও পছন্দ, কখনও দেখা যায় না। আমরা এটিকে আবার গাণিতিক সমতুল্য (বিশেষত যেহেতু NaNবেসিক গণিতে হাজির হয় না) এটির পিছনে বীজগণিত শিখি
ইজকাটা

আসলে যা প্রয়োজন আইএমএইচও হ'ল ভেরিয়েবলগুলি ঘোষণার একটি মাধ্যম যা তাদের আচরণগুলি double বাদ দিয়েNaN আচরণ করে। অনেক ক্ষেত্রে, কোড যা কোনও ধরণের তুলনা সম্পাদন NaNকরতে পারে তার NaNসাথে সব চেয়ে বড় তুলনা করতে চায় , এটির চেয়ে সব চেয়ে ছোট তুলনা করতে পারে, বা তুলনা প্রয়াসে একটি ব্যতিক্রম ছুঁড়ে দিতে চায়। কোড উল্লেখ করার অনুমতি declaratively কিভাবে NaNসঠিক আচরণ অর্জন করা একান্ত প্রয়োজনীয় কোড ব্যবহার করার প্রয়োজনীয়তা কমে যাবে গণ্য করা উচিত নয়।
সুপারক্যাট

@ সুপের্যাট: আপনি এনএএন অপারেশনগুলি <fenv.h>যেমন ফাংশন ব্যবহার করে ব্যতিক্রম করতে পারেন fesetexceptflag
কেনেটিএম

@ কেনেনিটিএম: কোনও অপারেশন করার আগে পতাকাটি সেট করে রাখা এবং অসুস্থ ও ঝামেলা-প্রবণ মনে হওয়ার পরে এটি আনসেট করা এবং এটি সম্পূর্ণ অর্ডার আরোপের ইচ্ছার সম্ভাবনাকে সম্বোধন করে না। আইআইইই আমি যা বুঝতে পেরেছি তা থেকে সম্প্রতি কিছু নতুন তুলনা পদ্ধতি প্রবর্তন করা হয়েছে যা সামগ্রিক অর্ডার আরোপ করবে, যা আমি ওভার্ডের পরিবর্তনে যদি স্বাগত হিসাবে বিবেচনা করব; ভাষা কীভাবে প্রতিক্রিয়া দেখায় তা আকর্ষণীয় হবে।
সুপারক্যাট

47

কারণ ঠিক একই অর্থ সহ দুটি পৃথক অপারেটর থাকা খুব বেশি অর্থবোধ করে না।

  • "বৃহত্তর নয়" ( !>) হ'ল "কম বা সমান" ( <=) এর মতো
  • "কম নয়" ( !<) হ'ল "বৃহত্তর বা সমান" ( >=) এর মতো

এটি "সমান নয়" ( !=) এর ক্ষেত্রে প্রযোজ্য নয় , একই অর্থ সহ কোনও অপারেটর নেই।

সুতরাং, আপনার পরিবর্তনটি কোনও লাভ ছাড়াই ভাষা আরও জটিল করে তুলবে।


5
কি x = x + 1, x += 1এবং x++?

33
@ ডান্সমোরব: এগুলির কোনওটিই একই জিনিস নয়। "বর্ধিতকরণ" এর উদ্দেশ্য কেবলমাত্র একজনই পরিবেশন করে। একই উদ্দেশ্যটি পরিবেশন করতে আপনি অন্য দুটি অভিব্যক্তিটি লাভবান করেছেন তা অপ্রাসঙ্গিক- এগুলি উভয়ই অনেক বেশি সাধারণ।
ডেড এমএমজি

1
<>একই অপারেটর হিসাবে একই অর্থ !=, এবং পাইথন 2 এর দুটি রয়েছে।
krlMLr

9
@ user946850 আর এখন ব্যাপকভাবে ভুল হিসেবে গণ্য করা হয় থাকার, ব্যবহার <>একটি দীর্ঘ সময়ের জন্য অবচিত হয়েছে এবং এটি 3.0 থেকে মুছে (এবং আপনি কিছু মনে গত 2.x রিলিজে কি কখনো , 2.7, গ্রীষ্ম 2010 সালে মুক্তি পায়)।

3
@ এসভিক যা ++ অপারেটরটিকে আরও উজ্জ্বল করে তোলে, এটি সেই সি # প্রোগ্রামারগুলিকে এখানে আসতে বাধা দেয়, প্রোগ্রামের আচরণ সম্পর্কে যৌক্তিক ধারণা তৈরি করে, তারপরে আমার সি ++ প্রোগ্রামার চাকরীটি চুরি করে!

10

!<প্রতিশব্দ হয় >=। পরে সঠিকভাবে সংজ্ঞায়িত গাণিতিক প্রতীক টাইপ করার একটি উপায় । আপনি ঠিক বলেছেন যে "তুলনায় কম নয়" কথ্য ভাষায় ব্যবহৃত হয়, তবে এটি চালচলিক এবং অস্পষ্ট হতে পারে (এর অর্থ ব্যাখ্যা করা বা ভুল ব্যাখ্যা করা যেতে পারে >)। অন্যদিকে প্রোগ্রামিং এবং গণিতের ব্যবহার স্পষ্টভাবে সংজ্ঞায়িত, দ্ব্যর্থহীন পরিভাষা।

অর্থাত্ সঙ্গতি ANSI এসকিউএল যেমন 3-মান যুক্তি, এ, not x < yএর সমতূল্য x >= yসেগুলিও উভয় দিতে NULLযদি পারেন xবা yহয় NULL। তবে, অ-এএনএসআই অনুমানকারী এসকিউএল উপভাষাগুলি রয়েছে, যেখানে এটি সমতুল্য নয় এবং তাদের রয়েছে!<


10
ভাসমান-পয়েন্ট সংখ্যা ব্যবহার করার সময় এগুলি সাধারণত সমতুল্য নয়। উদাহরণস্বরূপ, কোনও কিছুর সাথে তুলনা NaNকরা মিথ্যা, তাই !(2 < NaN) == true, যখন (2 >= NaN) == false
হামার

@ হ্যামার: সত্য তবে এটি প্রায় সমস্ত গাণিতিক সম্পর্কের ক্ষেত্রে সত্য NaN। তাদের সবাই স্বাভাবিকভাবে আচরণ বন্ধ করে দেয়।
নিকোল বোলাস

@ হ্যামার - এটি ভাসমান-পয়েন্টস দোষ, এটি কেবল অর্ডকে সঠিকভাবে বাস্তবায়ন করছে না, তাই বলছি। তবুও এটি কোনও বড় সমস্যা নয় যেহেতু কেউ আমাদের প্রয়োগ করতে বাধ্য করে না a !< b = not (a < b), আমরা কেবল (! <) = (> =) বলতে পারি।
ইঙ্গো

8

লেনদেন-এসকিউএল রয়েছে !> (এর চেয়ে বড় নয়) এবং <(এর চেয়ে কম নয়) অপারেটর রয়েছে।

সুতরাং, আপনি ব্যতীত সিবাজ মাইক্রোসফ্টেরও কেউ ভাবতেন এটি ভাল ধারণা হবে। মাইক্রোসফ্ট বব মত! :)


V 2005 এ এটি যুক্ত করা হয়নি?
জেফও

5
এই পৃথিবীতে প্রচুর ক্রেজি অসুস্থ-পরামর্শযুক্ত লোক রয়েছে যারা একে অপরের সাথে একমত হতে সম্মত নয়, sensকমত্য! = যথার্থতা।

@ জেফো তারপরে আমাদের মাইক্রোসফ্টকে দোষ দেওয়া উচিত, সাইবাসকে নয়?
ইয়ানিস

মজাদার. এর পেছনের গল্পটি সম্পর্কে আমি কৌতূহলী।
surfasb

@ সুরফাসব ইয়াপ, আমাকেও আমার অনুমান হবে যে এটি কেবল সিনট্যাকটিক চিনি, এটি সম্পর্কে বিশেষ কিছুই নয়।
ইয়ানিস

4

আমি মনে করি উত্তরটি কেবল !<অপারেটরের প্রয়োজন নেই । যেমন আপনি আপনার প্রশ্নে উল্লেখ করেছেন যে ইতিমধ্যে >=এবং <=বরাবর একটি বিদ্যমান প্রকাশকে তুচ্ছ করার সম্ভাবনা রয়েছে, তবে কেন অন্য অপারেটর যুক্ত করবেন?


আমি সম্মত হই যে একই কাজ করে এমন অপারেটর যুক্ত করার কোনও অর্থ নেই, তবে কেন "তারা" বেছে নিয়েছে = = এর পরিবর্তে <! <নট লেসারের উচ্চারণ করা সহজ, তারপরে গ্রেটার বা সমপরিমাণ, এটি টাইপ করা সংক্ষিপ্ত, এটি সহজ মস্তিষ্ক বুঝতে।
অ্যালেক্স বার্টসেভ

!<টাইপ করার চেয়ে কম সংক্ষিপ্ত >=, বা আমি কিছু মিস করছি?
ব্রায়ান ওকলে

আমি বোঝাতে চাইছি এটি পাঠ্য উপস্থাপনা (উচ্চারিত পাঠ্য)।
অ্যালেক্স বার্টসেভ

4

আরএফসি 1925 থেকে

যোগ করার মতো কিছুই না থাকলে সিদ্ধি পৌঁছেছে, কিন্তু যখন কিছুই ছিনিয়ে নিতে বাকি নেই।

বিদ্যমান কার্যকারিতা সদৃশ করে এমন অতিরিক্ত অপারেটর যুক্ত করা ভাষায় (এবং এইভাবে টোকেনাইজার এবং পার্সার) জটিলতা যুক্ত (অপ্রয়োজনীয়) ছাড়া আর কিছুই করে না।

অপারেটর ওভারলোডিং যে ভাষাগুলিতে সম্ভব তাও বিবেচনা করুন, আপনার ওভারলোডের জন্য আরও একটি অপারেটর থাকতে হবে। কখন bool operator<=এবং bool operator!>বিভিন্ন জিনিস ফেরত দিতে পারে সেই বিভ্রান্তির বিষয়টি বিবেচনা করুন (হ্যাঁ, আমি জানি যে কেউ ইতিমধ্যে অসামঞ্জস্য তুলনা করতে পারে)।

সর্বশেষে, ভাষা যেখানে পদ্ধতি বা অপারেটার সংখ্যাবৃদ্ধি সংজ্ঞায়িত করা হয় মনে (রুবি - আমি দিকে তাকিয়ে আছি আপনি ) এবং আপনি এক প্রোগ্রামার ব্যবহার আছে <= অন্য ব্যবহারসমূহ যখন!> এবং আপনি একই অভিব্যক্তি জন্য একাধিক কোড শৈলী আছে।


হ্যাঁ! এটি বৈজ্ঞানিক পার্সিমনি নীতি।
লুসার droog

3

! <সমান>> এখন কেন আমাদের প্রথমে দ্বিতীয়টি নেই কারণ সমস্ত ভাষা প্রথমে ইতিবাচক অপারেটর প্রয়োগ করে এবং তারপরে নেতিবাচক অপারেটরের কাছে যায়, যেমন প্রয়োগ করা হচ্ছে = = কভারও! <এবং <= কভার!> তাই ভাষা নির্মাতা এগুলিতে যান এবং ভেবেছিল তারা অনর্থক হবে এবং এগুলি এড়িয়ে যাবে।

সর্বদা ইতিবাচক কেস বাস্তবায়নের চেষ্টা করুন প্রথমে নেতিবাচক ক্ষেত্রে (:) ইতিবাচক চিন্তাভাবনা, কেবল আমার ব্যক্তিগত দৃষ্টিভঙ্গি)


2

কারণটি হ'ল প্রোগ্রামিং ভাষার অপারেটররা গাণিতিক traditionতিহ্য থেকে orrowণ নেন এবং গণিতে নুন রিয়েলি "ছোট বা সমান" এবং "বৃহত্তর বা সমান" যেহেতু "বৃহত্তর নয়" এবং "ছোট নয়" ব্যবহার করেন ঠিক তেমন একটি কাজের জন্য।

সুতরাং ভাষায় প্রোগ্রামিং আমরা সাধারণত সমান না করার জন্য একটি প্রতীক মত খুঁজছেন পেতে ≠ ( !=বা /=, যদি না কেউ যদি সাথে অভিনব হচ্ছে <>বা পাঠগত অপারেটর)

এবং that এবং ≥ ( <=এবং >=) এর মতো দেখতে এমন জিনিসগুলি


বিটিডব্লিউ, আমি আপনার এই দৃ with়তার সাথে একমত নই যে ততক্ষণে ওআর সম্পর্কে বোঝা এবং যুক্তি করা সহজ নয়। গণিতে, যদি আরও প্রত্যক্ষ বিকল্প উপলব্ধ থাকে তবে সাধারণত প্রচুর অবহেলার সাথে যুক্ত প্রমাণ (অযৌক্তিক হ্রাস করার মতো) সাধারণত ভ্রূণ্য হয়। এছাড়াও, অর্ডারিংয়ের ক্ষেত্রে, আমাদের কাছে যে প্রাথমিক জ্ঞান রয়েছে (এবং এটি কোনও কিছু ভাবার বা প্রমাণ করার সময় ব্যবহৃত হয়) <, = এবং> এর মধ্যে যে কোনও ট্রাইক্রোটমি! <বিধানটি সম্ভবত>> তে রূপান্তর করতে হবে যদি আপনি করতে চান এটি দিয়ে দরকারী কিছু।


2

আমি আংশিকভাবে সমাবেশ নির্দেশ সেটকে দোষ দেব। jge"এর চেয়ে বড় বা সমান হলে লাফানোর" মতো নির্দেশাবলী পেয়েছেন got "কম না হলে লাফিয়ে" বিরোধী।

সংকলক লেখকরা যে সমাবেশে লেখক নিয়ে এসেছিলেন তা থেকে বিরত থাকতে পারে, যা সম্ভবত চিপের উপর ডিজাইন করার সময় এটি কীভাবে লেবেল করা হয়েছিল তার উপর ভিত্তি করে তৈরি হয়েছিল।

... সম্ভবত।


1

আমার মনে হয় আমি কয়েক বছর আগে কিছু ভাষা দেখেছি যেখানে !=অপারেটরের পরিবর্তে (সমান নয়) এর মতো কিছু <>ব্যবহৃত হয়েছিল। যদিও তাদের নামগুলি মনে করতে পারে না ...

আমি মনে করি এটি পড়া !(a < b)বা এটির a !< bচেয়ে শক্ত a >= b। সম্ভবত এটিই কারণ !<ব্যবহার করা হয়নি (এটি আমার মতে কুৎসিত দেখায়)।


1
<>মূলত বেসিক উপভাষা, এসকিউএল এবং পাসকাল উপভাষাগুলি দ্বারা ব্যবহৃত হয় (ছিল?)।
ইয়ানিস

@ ইয়ানিস রিজোস অনুস্মারকটির জন্য ধন্যবাদ। তারা আমাদের উচ্চ-বিদ্যালয়ে পাস্কল শিখিয়েছিল এবং এটিই আমি এটি দেখেছি :)।
রাদু মুর্জিয়া

2
পাইথন 2 এছাড়াও আছে <>, যদিও এটি 3 সরানো হয়েছে
ড্যানিয়েল Lubarov

যৌক্তিক দৃষ্টিকোণ থেকে, !=সাধারণ তুলনায় আরও সাধারণ <>, যেহেতু আপনার কাছে এমন জিনিস থাকতে পারে (জটিল সংখ্যার মতো) যেখানে সাম্যতা সুনির্দিষ্টভাবে সংজ্ঞায়িত করা হয় তবে সেখানে কার্যকর অর্ডার দেওয়া যায় না।
ডেভিড থর্নলি
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.