- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
namespace test
{
//public record P(double D);
class Program1
{
static void Main(string[] args)
{
//The differences between Double.Equals and Double==
Console.WriteLine(double.NaN.Equals(double.NaN)); //True
Console.WriteLine(double.NaN == double.NaN); // False
//The same is true for tuples!
Console.WriteLine((double.NaN, 1).Equals((double.NaN, 1))); // True
Console.WriteLine((double.NaN, 1) == (double.NaN, 1)); // False
//But records in C# 9 behave differently!
Console.WriteLine(new P(double.NaN).Equals(new P(double.NaN))); // True
Console.WriteLine(new P(double.NaN) == new P(double.NaN)); // True
}
}
}
Follow us!
или деанон?
ахахах, какой убе
не очень-то шарп этот ваш си
а тендеция -- да. Сейчас не 1995-й год, чтобы два года вылизывать софт, и поставлять его стабильным и с тонной документации на CD.
Если верить спецификации, то:
«В соответствии с IEEE 754, такое состояние задаётся через установку показателя степени в зарезервированное значение 11…11, а мантиссы — во что угодно, кроме 0»
Мне кажется, что это слишком сильно зависит от реализации. Может так получиться, что в конкретном ЯП NaN будет только одним зарезервированным значением, поэтому sqrt(-1), 0/0, 0*NaN – всё после хеширования станет одинаковой штукой и в хеш-таблице образуется длинная анскильная цепочка.
Я, кажется, даже понимаю, почему в C# такой багор получается:
Equals проверяет, что если оба числа по формату подходят под NaN, то они равны, что вообще-то логично. А получение хеша, скорее всего, уже задействует биты (те самые, которые могут быть какими угодно, лишь бы не 0).
Я за хеширование строк и каких-нибудь длинных чисел.
Сейчас всё деградирует.
Пару месяцев назад был пост, где замеряли скорость питона разных версий https://govnokod.ru/26945
Или вот бенчи грааль-вма, как йажисты всё питумизируют, придумывают всякие AOT, а скорость с каждым релизом только падает.
https://www.phoronix.com/scan.php?page=article&item=graalvm201-openj920-jvm&num=3
Самое страшное, что анскильные лалки и заедушные макаки пробрались в самые жизненно важные отрасли.
https://www.extremetech.com/extreme/304590-boeing-employee-737-max-is-designed-by-clowns-supervised-by-monkeys
- это типа выпустить падучую Win95, два года её вылизывать и выпустить падучую Win98? На CD конечно же
За всё время на нее вышел OSR2 только вроде.
Ну IEEE 754 уже давно создали. 1985 - это не так современно.
Зачем вообще придумали отдать под NaN столько кобенаций? В NaN в double можно спрятать int, short и ещё останется немного места.
А что там хранить? Банку сгущёнки?
По сути NaN — это бесконечность с ненулевой дробной частью.
Ну x86 додумались использовать оттуда один бит для сигнализации ошибки (qNaN/sNaN).
На самом деле очень хороший вопрос.
Ведь можно было не засирать кодовое пространство и поднять диапазон флоатов на 1.
Введя тем самым перенормализованные числа (симметричные денормализованным).
Кодировать ∞ с дробной частью из всех 11111111111.
А под особый undefined value 0/0=? выделить ровно одно кодовое значение например -0.0
Нахера вообще нужно было вводить отрицательный ноль?
Видимо в железе так проще, там частные кейсы дорого обходятся. Ну и чтобы на него делить и получать отрицательную бесконечность.
Я думал на этот счёт. NaNы и бесконечности — как раз и есть частные кейсы.
А вот реально дорого обходится денормализованная питушня без неявной единички.
И кстати она быстрее работает если просто округлять её в ноль (частный случай).
>чтобы на него делить и получать отрицательную бесконечность.
(-1./0.)
-(1./0.)
Давай, возьми мой член в ротик, он уже дымится...
Притом что на ГК эти NaN-багры обсасывали примерно три миллиона сто сорок тысяч раз.
Ну посмотрим какими баграми ответит Шарпу Йажа. Там тоже вовсю пошли клепать скоростные релизы.
То обратную совместимость сломают, то жвм оптимизируют, так что скорость от версии к версии деградирует.
Видимо поэтому багу и не заметили.
https://ideone.com/Hi7g6m
https://ideone.com/sh9ERy
https://metanit.com/python/tutorial/6.4.php
А в похапэ такого никогда не будет, потому что любители «PHP» не знают про всю эту питушню с неточными числами дробными )))
Какой внезапный БАГОР.
Вот именно поэтому я за «PHP». Там хоть есть эпсилоны.
Сразу понятно какой язык делали практические программисты, а какой лалки-кукаретики.
да, бывает печаль
> денормалы
если исключить +0 и -0, денормалы не пересекаются с нормалами и другими денормалами
вроде только +0, -0, ой-нанэ-нанэ, бесконечные дроби как у Госта и потеря точности