Comments 21
> first == second
Значения с плавающей точкой надо сравнивать с погрешностью:
abs(first — second) < 0.00001
Так как точность их ограничена, и не в фреймворках дело
Я это прекрасно понимаю. Смысл статьи совершенно не в том, что надо проверять равенство двух double с некой погрешностью, а в том, что привычный подход иногда перестает срабатывать. И нужно понимать, в чем проблема. Вот Вы понимаете )
А что, теперь «привычный подход» == «дырявые абстракции», что ли? Хотя, если Вы говорите, что абстракции придумали из-за лени, в основном, я уже ничему не удивлюсь. Небось, по вашему, и ООП, в целом, нужен, чтобы не копипастить код, да?
По моему, чтобы не «копипастить код» были придуманы:
1. Циклы
2. Процедуры/функции/методы
ООП, Вы правы, придумали для другого.
Сомнительная связь громкого заголовка и вялого содержания статьи.

1. Любому здравомыслящему человеку, имеющему отношение к созданию ПО и хоть мало-мальски приличное образование, очевидно, что сравнивать double/float надо с заранее определенной точностью (обычно обозначаемое epsilon). Отношение к абстрацкии вообще никакого.

2. Не думаю, что каждый программист должен знать особенности работы кэша процессора и другие тонкости. Не стоит преждевременно оптимизировать код. Вы все равно не знаете как его соптимизирует компилятор и можете своими «улучшениями» сделать только хуже. В данном случае, если не устраивает скорость работы программы — прогоняем профайлером и правим те участки кода, которые действительно того требуют.

3. Боксинг/Анбоксинг это первые главы любой книги по C#. Не думаю, что найдется много .Net программистов, которые об этом не знают. Пример, как Вы и сами указакли несколько притянутый, т.к. generics ftw. Опять же см. пункт 2. Преждевременную оптимизацию в лес.
> Любому здравомыслящему человеку, имеющему отношение к созданию ПО и хоть мало-мальски приличное образование, очевидно, что сравнивать double/float надо с заранее определенной точностью (обычно обозначаемое epsilon). Отношение к абстрацкии вообще никакого.
не любому… допустим как epsilon выбираете вы? оно у вас меньше чем 0.05?
умножаем исходные чила на 1000000 и он не работает.
я считаю что эпсилон должен быть относительным, например 0.001% от одного из аргументов…
Дело в том, что после той, знаменитой ошибки Intel с умножением, современные процессоры умножают правильно. А вот со сложением остались еще проблемы.
UFO landed and left these words here
А мне ArtemKulyabin нравится. ЧЮ порой хорошее. И часто озвучивает то, что, больше никто не скажет, т.к. минусов наловить ссыт.
Напомнило одного нашего препода, который примерно такими же аргументами как пример с double пытался убедить нас в том, что ООП отстой и хороший программист им никогда в жизни пользоваться не станет. а дотнет по его словам вобще зло из зол. и агитировал за Visual Basic
ООП зло? Бред! Я же писал, высокоуровневая абстракция (в том числе и ООП) это не зло! Это друг. Просто надо ко всему относится с пониманием, а то за деревьями иерархий наследования, можно и не увидеть леса ООП.
это не я и утверждаю, а препод в универе. сам я с удовольствием пишу на шарпе. впрочем как и на С и Asm
Вы прежде чем за руль сесть — правила дорожного движения учите?
Так почему прежде чем начинать писать программы, вы даже не удосуживаетесь изучить «правила»? Там про все про это написано. Никакого открытия вы не сделали — все нормальные программисты об этом знают. Ну а начинающие на то и начинающие, чтобы грабли искать.
Я бы не сказал, что примеры отображают абстракции уж очень высокого уровня. По идее можно и на ассемблере написать десятичные литералы. А набегание погрешности да, оно известно и случается при разных расчётах. Тема заголовка не раскрыта, но иногда подумать над этим не мешает.
Only those users with full accounts are able to leave comments. Log in, please.