Чи повинен `Vector <float> .Equals` бути рефлексивним чи він повинен дотримуватися семантики IEEE 754?

При порівнянні значень з плаваючою комою для рівності існує два різних підходи:

• NaNне дорівнює собі, що відповідає специфікації IEEE 754 .
• NaNрівність собі, що забезпечує математичну властивість рефлексивності, що має істотне значення для визначення відношення еквівалентності

Вбудований в IEEE з плаваючою точкою типу в C # ( floatі double) слід IEEE семантиці ==і !=(і реляційні оператори , як <) , але забезпечити повернення для object.Equals, IEquatable<T>.Equals(і CompareTo).

Тепер розглянемо бібліотеку, яка забезпечує векторні структури поверх float/ double. Такий векторний тип би перевантажував ==/ !=і переосмислював object.Equals/ IEquatable<T>.Equals.

З чим усі згодні, це те, що ==/ !=слід слідувати семантиці IEEE. Питання полягає в тому, чи повинна така бібліотека реалізовувати Equalsметод (який є окремим від операторів рівності) таким чином, що рефлексивно або таким чином, що відповідає семантиці IEEE.

Аргументи для використання семантики IEEE для Equals:

• Звідси випливає IEEE 754

• Це (можливо, набагато швидше), оскільки він може скористатися інструкціями SIMD

  Я задав окреме запитання щодо stackoverflow про те, як би ви виражали рефлексивну рівність, використовуючи інструкції SIMD та їх вплив на продуктивність: інструкції SIMD для порівняння рівності з плаваючою комою

  Оновлення: Схоже, можна ефективно реалізувати рефлексивну рівність за допомогою трьох інструкцій SIMD.

• Документація для Equalsне вимагає рефлексивності під час залучення плаваючої точки:

  Наступні твердження повинні бути правдивими для всіх реалізацій методу рівнянь (Object). У списку x, yі zявляють собою посилання на об'єкти, які не є порожніми.

  x.Equals(x)повернення true, за винятком випадків, що стосуються типів з плаваючою комою. Див. ISO / IEC / IEEE 60559: 2011, Інформаційні технології - Мікропроцесорні системи - Арифметика з плаваючою комою.

• Якщо ви використовуєте поплавці як словникові клавіші, ви живете в стані гріха і не повинні сподіватися на розумну поведінку.

Аргументи рефлексивності:

• Це узгоджується з існуючими типами, в тому числі Single, Double, Tupleі System.Numerics.Complex.

  Я не знаю жодного прецеденту в BCL, де Equalsслід IEEE, а не рефлексивно. Лічильник приклади включають Single, Double, Tupleі System.Numerics.Complex.

• Equalsв основному використовується контейнерами та алгоритмами пошуку, які покладаються на рефлексивність. Для цих алгоритмів підвищення продуктивності не має значення, якщо заважає їм працювати. Не жертвуйте правильністю виконання.
• Він ламає всі хеш на основі наборів і словники, Contains, Find, IndexOfна різних збірках / LINQ, набір на основі LINQ операції ( Union, Exceptі т.д.) , якщо дані містять NaNзначення.

• Код, який робить фактичні обчислення, де IEEE семантичний прийнятний, зазвичай працює на конкретних типах і використовує ==/ !=(або, скоріше, порівняння epsilon).

  Наразі ви не можете писати обчислення високої продуктивності, використовуючи дженерики, оскільки для цього вам потрібні арифметичні операції, але вони недоступні через інтерфейси / віртуальні методи.

  Так повільніший Equalsметод не вплине на більшість високопродуктивних кодів.

• Можна запропонувати IeeeEqualsметод або IeeeEqualityComparer<T>для тих випадків, коли вам потрібна семантика IEEE або вам потрібно мати перевагу у виконанні.

На мій погляд, ці аргументи сильно сприяють рефлексивному виконанню.

Команда CoreFX Microsoft планує впровадити такий векторний тип у .NET. На відміну від мене, вони віддають перевагу рішенню IEEE , головним чином завдяки перевагам у роботі. Оскільки таке рішення, безумовно, не буде змінено після остаточного випуску, я хочу отримати відгук громади про те, що я вважаю великою помилкою.

Я заперечую, що поведінка IEEE є правильною. NaNs ні в якому разі не рівноцінні один одному; вони відповідають погано визначеним умовам, коли числова відповідь не підходить.

Крім переваг від продуктивності, що виникають від використання арифметики IEEE, яку підтримує більшість процесорів, я думаю, що існує семантична проблема з тим, що, якщо isnan(x) && isnan(y), тоді x == y. Наприклад:

// C++
double inf = std::numeric_limits<double>::infinity();
double x = 0.0 / 0.0;
double y = inf - inf;

Я заперечую, що немає жодної значущої причини, яку можна вважати xрівним y. Ви навряд чи зможете зробити висновок, що вони є еквівалентними числами; вони взагалі не є цифрами, тому це просто здається цілком недійсним поняттям.

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

Виникає проблема: IEEE754 визначає відносні операції та рівність способом, який добре підходить для чисельних застосувань. Він не підходить для сортування та хешування. Отже, якщо ви хочете сортувати масив на основі числових значень або якщо ви хочете додати числові значення до набору або використовувати їх як ключі у словнику, ви або заявляєте, що значення NaN заборонені, або ви не використовуєте IEEE754 вбудовані операції. Ваша хеш-таблиця повинна переконатися, що всі NaN збігаються з однаковим значенням, і порівняти однакові між собою.

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