Си диез / Говнокод #27146 Ссылка на оригинал

0

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 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
        }
    }
}

https://twitter.com/STeplyakov/status/1333831742134779904

Запостил: nihau nihau, (Updated )

Комментарии (31) RSS

  • NaN values with different bit patterns were considered equal by Equals() method, but their GetHashCode() method returned different hashes, so their use in hash-based collections was broken.

    ахахах, какой убе

    не очень-то шарп этот ваш си
    Ответить
    • С одной стороны, использовать NaN как ключ в хеш-таблице не нужно, с другой стороны это какой-то багор, аж неприятно за С# стало. Это такая современная тенденция, писать отсосные тулзы, делать баги в ОС и ЯП?
      Ответить
      • почему не нужно?

        а тендеция -- да. Сейчас не 1995-й год, чтобы два года вылизывать софт, и поставлять его стабильным и с тонной документации на CD.
        Ответить
        • Выглядит страшно )))

          Если верить спецификации, то:

          «В соответствии с IEEE 754, такое состояние задаётся через установку показателя степени в зарезервированное значение 11…11, а мантиссы — во что угодно, кроме 0»

          Мне кажется, что это слишком сильно зависит от реализации. Может так получиться, что в конкретном ЯП NaN будет только одним зарезервированным значением, поэтому sqrt(-1), 0/0, 0*NaN – всё после хеширования станет одинаковой штукой и в хеш-таблице образуется длинная анскильная цепочка.

          Я, кажется, даже понимаю, почему в C# такой багор получается:

          Equals проверяет, что если оба числа по формату подходят под NaN, то они равны, что вообще-то логично. А получение хеша, скорее всего, уже задействует биты (те самые, которые могут быть какими угодно, лишь бы не 0).

          Я за хеширование строк и каких-нибудь длинных чисел.
          Ответить
        • > чтобы два года вылизывать софт, и поставлять его стабильным и с тонной документации на CD

          Сейчас всё деградирует.

          Пару месяцев назад был пост, где замеряли скорость питона разных версий 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
          Ответить
        • > Сейчас не 1995-й год, чтобы два года вылизывать софт
          - это типа выпустить падучую Win95, два года её вылизывать и выпустить падучую Win98? На CD конечно же
          Ответить
          • Ну win95 была относительно стабильна (для такой сложной ОС, рабоатющей на куче разных компьютеров).
            За всё время на нее вышел OSR2 только вроде.
            Ответить
      • > современная тенденция, писать отсосные тулзы, делать баги в ОС и ЯП?
        Ну IEEE 754 уже давно создали. 1985 - это не так современно.

        Зачем вообще придумали отдать под NaN столько кобенаций? В NaN в double можно спрятать int, short и ещё останется немного места.
        Ответить
        • > Зачем вообще придумали отдать под NaN столько кобенаций?
          А что там хранить? Банку сгущёнки?

          По сути NaN — это бесконечность с ненулевой дробной частью.

          Ну x86 додумались использовать оттуда один бит для сигнализации ошибки (qNaN/sNaN).
          Ответить
        • > Зачем вообще придумали отдать под NaN столько кобенаций?

          На самом деле очень хороший вопрос.

          Ведь можно было не засирать кодовое пространство и поднять диапазон флоатов на 1.
          Введя тем самым перенормализованные числа (симметричные денормализованным).

          Кодировать ∞ с дробной частью из всех 11111111111.

          А под особый undefined value 0/0=? выделить ровно одно кодовое значение например -0.0

          Нахера вообще нужно было вводить отрицательный ноль?
          Ответить
          • > отрицательный ноль

            Видимо в железе так проще, там частные кейсы дорого обходятся. Ну и чтобы на него делить и получать отрицательную бесконечность.
            Ответить
            • >Видимо в железе так проще, там частные кейсы дорого обходятся

              Я думал на этот счёт. NaNы и бесконечности — как раз и есть частные кейсы.

              А вот реально дорого обходится денормализованная питушня без неявной единички.
              И кстати она быстрее работает если просто округлять её в ноль (частный случай).

              >чтобы на него делить и получать отрицательную бесконечность.
              (-1./0.)
              -(1./0.)
              Ответить
        • Старший статистик Новосельцев умер, дитя моё. Теперь ты статистик - не старший, а единственный.

          Давай, возьми мой член в ротик, он уже дымится...
          Ответить
      • >с другой стороны это какой-то багор, аж неприятно за С# стало

        Притом что на ГК эти NaN-багры обсасывали примерно три миллиона сто сорок тысяч раз.

        Ну посмотрим какими баграми ответит Шарпу Йажа. Там тоже вовсю пошли клепать скоростные релизы.

        То обратную совместимость сломают, то жвм оптимизируют, так что скорость от версии к версии деградирует.
        Ответить
    • Ну такое. Кто флоат пихает в хешмапу то? Там же начнутся всякие отрицательные нули, денормалы и т.п.

      Видимо поэтому багу и не заметили.
      Ответить
      • Да отрицательные нули — это не самое печальное.
        >>> d = {0.3: 'hello'}
        >>> d[0.1 + 0.2]
        Traceback (most recent call last):
          File "<stdin>", line 1, in <module>
        KeyError: 0.30000000000000004
        Ответить
            • Конечно, ты разрые ключи указал, ПЕТУШОК. ПЕТОН СОСНУЛ!!!
              Ответить
              • Не угадал.
                <?php
                
                $d = [0.3 => 'hello', 0.30000000000000004 => 'world'];
                echo $d[0.1 + 0.2] . "\n";
                echo $d[0.3];
                Ответить
              • Кстати, смотри как питон могёт:

                https://metanit.com/python/tutorial/6.4.php

                А в похапэ такого никогда не будет, потому что любители «PHP» не знают про всю эту питушню с неточными числами дробными )))
                Ответить
              • Змее было бы весьма затруднительно сосать, с таким-то тонким языком-ленточкой. Это же не 1024--... Ты хоть не завирайся, пися.
                Ответить
        • БЛЯТЬ!

          Какой внезапный БАГОР.

          Вот именно поэтому я за «PHP». Там хоть есть эпсилоны.
          Сразу понятно какой язык делали практические программисты, а какой лалки-кукаретики.
          Ответить
      • > отрицательные нули
        да, бывает печаль

        > денормалы
        если исключить +0 и -0, денормалы не пересекаются с нормалами и другими денормалами

        вроде только +0, -0, ой-нанэ-нанэ, бесконечные дроби как у Госта и потеря точности
        Ответить

Добавить комментарий

Помни, guest, за тобой могут следить!

    А не использовать ли нам bbcode?


    8