Чи є причина, чому більшість мов програмування не мають операторів "!>" (Не більше) та "! <" (Не менше)?

Цікаво, чи є якась - або причина - або , якщо це не просто випадковість історії - тобто немає !>і !<операторів в більшості мов програмування?

a >= b (більший АБО b) може бути записаний як !(a < b) (НЕ менший b) , що дорівнює a !< b.

Це питання мене вразило, коли я опинився в середині кодування власного конструктора дерева виразів. Більшість мов програмування мають a != bоператора для !(a=b), так чому б ні !>і !<?

ОНОВЛЕННЯ:

• !<(не менше) легше вимовляти, ніж >=(більший або рівний)
• !<(Не менше) є коротше , щоб ввести , ніж >=(більше або дорівнює)
• !<(не менше) легше зрозуміти *, ніж >=(більший або рівний)

* оскільки ORце бінарний оператор, мозку потрібно оперувати двома операндами (терткою, рівними), а NOTоператором є одинарним, а мозку потрібно оперувати лише одним операндом (меншим).

Мова програмування D та розширення DMC на C та C ++ підтримували ці оператори (усі 14 комбінацій), але що цікаво, D збирається знецінювати цих операторів , головним чином тому, що

1. що саме таке a !< b? Це так a>=b || isNaN(a) || isNaN(b). не!< є тим самим , що, тому що істина, а неправда. IEEE 754 важко освоїти, тому використання просто спричинить плутанину щодо обробки NaN - ви можете шукати таких операторів у Phobos (стандартна бібліотека D), і поруч із цим є багато коментарів, щоб нагадати читачам, що NaN задіяний,>=NaN !< NaNNaN >= NaNa !< b
2. тому мало хто буде використовувати його, навіть якщо такі оператори існують, як у D,
3. і для цих рідко використовуваних операторів потрібно визначити ще 8 маркерів, що ускладнює компілятор з невеликою користю,
4. і без цих операторів все одно можна використовувати еквівалент !(a < b), або якщо він любить бути явним a >= b || isNaN(a) || isNaN(b), і їх легше читати.

Крім того, відносини (≮, ≯, ≰, ≱) рідко спостерігаються в базовій математиці, на відміну від !=(≠) або >=(≥), тому багатьом людям важко зрозуміти.

Це, мабуть, і причини, чому більшість мов їх не підтримує.

Тому що не має сенсу мати двох різних операторів з абсолютно однаковим значенням.

• "Не більший" ( !>) точно такий же, як "менший або рівний" ( <=)
• "Не менший" ( !<) точно такий же, як "більший або рівний" ( >=)

Це не стосується "не дорівнює" ( !=), не існує оператора з тим самим значенням.

Отже, ваша модифікація ускладнила б мову без жодної користі.

!<є синонімом до >=. Пізніше це лише спосіб набору чітко визначеного математичного символу ≥. Ви маєте рацію, що в розмовній мові використовується "не менше" , однак це розмовно і може бути неоднозначним (можна інтерпретувати ≥або неправильно трактувати як >). З іншого боку, програмування та математика використовують чітко визначену, однозначну термінологію.

Навіть у 3-значній логіці, такі як ANSI SQL, not x < yеквівалентно x >= y, оскільки вони обидва дають, NULLякщо є xчи yє NULL. Однак є діалекти SQL, що не відповідають ANSI, де це не еквівалентно, і вони є!< .

Transact-SQL має !> (Не більше) та ! <(Не менше) операторів.

Тож, крім вас, хтось із Sybase Microsoft теж думав, що це буде гарною ідеєю. Так само, як Microsoft Bob! :)

Я думаю, що відповідь проста в тому, що !<оператора немає потреби . Як ви вказали в своєму питанні вже є , >=і <=поряд з можливістю звести на немає існуюче вираз, так навіщо додавати ще один оператор?

Від RFC 1925 року

досконалості досягнуто не тоді, коли не залишається нічого додати, а коли не залишається нічого, щоб забрати.

Додавання додаткових операторів, що дублюють існуючу функціональність, не робить нічого іншого, крім додавання (непотрібної) складності мові (і, таким чином, токенізатору та аналізатору).

Розгляньте також на мовах, де можлива перевантаження оператора, у вас був би ще один оператор, який повинен перевантажувати. Розглянемо замішання , коли bool operator<=і bool operator!>може повертати різні речі (так, я знаю , що можна зробити вже неузгоджені порівняння).

Нарешті, подумайте про мови, де методи чи оператори багатозначно визначені (Ruby - я дивлюся на вас ), і у вас є один програміст, який використовує <= в той час, як інший використовує!>, І у вас є кілька стилів коду для одного виразу.

! <дорівнює> = Тепер, чому ми маємо другий не перший, тому що вся мова спочатку реалізує позитивний оператор, а потім підходить до негативного оператора, оскільки реалізує> = також охоплює! <і <= охоплює!> і думав, що вони будуть зайвими і пропустять їх.

Завжди намагайтеся спочатку реалізувати позитивний випадок, а потім перейдіть до негативного випадку (:) позитивне мислення, лише особистий погляд)

Причина полягає в тому, що оператори в мовах програмування запозичують математичну традицію, а в математиці ніхто реально не використовує "не більший" і "не менший", оскільки "менший або рівний" і "більший або рівний" роблять так само хорошу роботу.

Отже, в мовах програмування ми зазвичай отримуємо символ, схожий на ≠, що не дорівнює ( !=або /=, якщо хтось не любить <>або текстовий оператор)

і речі, схожі на ≤ і ≥ ( <=і >=)

До речі, я не згоден з вашим твердженням, що НЕ простіше зрозуміти і міркувати про це АБО. У математиці докази, що містять багато негативів (наприклад, зведення до абсурду), як правило, піддаються нахиленню, якщо є більш пряма альтернатива. Крім того, у випадку замовлення основні знання, які ми маємо (і які використовуються, коли щось думаєш чи доводимо), - це трикотомія між <, = та>, тому будь-яка! <Заява, ймовірно, повинна бути перетворена в> =, якщо ти хочеш зробити нічого корисного з цим.

Я частково звинувачую набір інструкцій по збірці. У вас є інструкції, такі як jge"стрибок, якщо більший або рівний". На відміну від "стрибати, якщо не менше".

Автори-компілятори, можливо, пішли з того, що придумали автори збірки, що, імовірно, грунтувалося на тому, як це було позначено під час проектування на мікросхемі.

... можливо.

Я думаю, я кілька років тому бачив деякі мови, де замість !=оператора (не дорівнює) використовується щось подібне <>. Не можу згадати їх імена, хоча ...

Я думаю, що це важче читати !(a < b)чи a !< bніж a >= b. Можливо, саме тому !<не використовується (на мою думку, це виглядає некрасиво).