Pull to refresh

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 just landed and posted this here
UFO just landed and posted this here
Напомнило одного нашего препода, который примерно такими же аргументами как пример с double пытался убедить нас в том, что ООП отстой и хороший программист им никогда в жизни пользоваться не станет. а дотнет по его словам вобще зло из зол. и агитировал за Visual Basic
ООП зло? Бред! Я же писал, высокоуровневая абстракция (в том числе и ООП) это не зло! Это друг. Просто надо ко всему относится с пониманием, а то за деревьями иерархий наследования, можно и не увидеть леса ООП.
это не я и утверждаю, а препод в универе. сам я с удовольствием пишу на шарпе. впрочем как и на С и Asm
Вы прежде чем за руль сесть — правила дорожного движения учите?
Так почему прежде чем начинать писать программы, вы даже не удосуживаетесь изучить «правила»? Там про все про это написано. Никакого открытия вы не сделали — все нормальные программисты об этом знают. Ну а начинающие на то и начинающие, чтобы грабли искать.
Я бы не сказал, что примеры отображают абстракции уж очень высокого уровня. По идее можно и на ассемблере написать десятичные литералы. А набегание погрешности да, оно известно и случается при разных расчётах. Тема заголовка не раскрыта, но иногда подумать над этим не мешает.
Sign up to leave a comment.

Articles