Привет!
Долго мне питон не нравился, потом таки постепенно начал вникать, дух противоречия спадает.
Решил отбросить разное лишнее, калькулятор в частности, и пользоваться питоноконсолью.
Но сегодня с утра я в шоке:

Что бы это значило?
--
Граница глюка
>>> 40-31.2
8.8
>>> 40-32.2
7.799999999999997
Причем, в выражениях - то же самое. Это чтож оно насчитает в итоге?!

Вести с полей.
Если пишешь print 40-37.96 то выводит 2.04
Нет никакого желания продолжать дальше. На использование в кач-ве калькулятора можно забить. И хорошо, что из книжек 80-х годов осталась масса макулатуры по бейсику, там всегда были контрольные примеры. Проверим, что эта гадость в компании с numPy насчитает, хотя бы с матрицами. Ух, как я зол!

это уже прочитал? Вообще-то питон честно следует ieee-шному стандарту на числа с плавающей точкой и показывает их так, как видит машина.

И бейсик и фортран (даже матлаб) вам посчитают точно то же самое, только вывод на экран там -- как бы это поточнее сказать -- более "умный".

Где-то должно что-то задаваться для подобного представления, чует мое сердце.
Но это все цветочки. Берем онлайн конвертер ieee754 в зубы и курим

Я перестаю понимать. При вычитании чушь начинается как только экспоненты стали равны.
А у 40 и 32.2 экспонента == 5
До того, по законам жанра, должны выравниваться порядки и только после вычитаться мантиссы. И в этом случае все нормально, хотя "мусор" в вычитаемом тот же. А представления меняются. Чушь? Чушь собачья!

То есть исходный вопрос заключается все-таки "Как правильно вывести на печать?"
Сегодня праздник "чистых" программистов?

Венда, версия пытона на 1 младше, чем





А вот так:

Ага, непонятно почему print с его стандартными модификаторами e, f, g и т.п. игнорируется?

Вообще то, если уж задумываться о точности и возможностях Питона с его динамическими типами, то наверно стоит познакомиться также с такими пакетами Python library for arbitrary-precision floating-point arithmetic

Это означает, что множество чисел типа double не содержит числа 2.04



print выполняет округление.



Пользуйтесь прогами позволяющими оперировать с числами произвольной точности.
Например, pari/gp, J...
Хотя, для подавляющего большинства вычислений точности даблов хватает. Не очень понимаю, что именно вас не устраивает.

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


Ага. Спасибо, у меня его еще нет.


Невероятно, но



Судя по листингу выше, это ничего не означает

Означает. Даже не сомневайтесь.
А вот листинг действительно ничего не означает, ибо



Успехов в поиске несуществующих глюков.

Спасибо, ужЕ нашел
Еще раз, механика скорбного дела.
37.96+2.04 Выровняли порядки и сложили. Ошибка представления ушла от сдвигов мантиссы 2.04 вправо.
--
Вычли из 40 37.96 появилась ошибка представления. Вопросов нет.
--
Вычли из 40 31.2 после приведения порядков ошибка представления ушла? А нормализация с непременным сдвигом влево?
--
Вопрос: почему нельзя сразу округлить результат до числа, представленного наибольшей точностью? Если эти точности заданы явно? Кому это полезно?

Куда кто ушел? 31.2 уже не представимо. Мантисса не позволяет. Ближайшее 31.199999999999999.

Гм, ради интереса у себя все проверил... Тоже самое) Как быть-то?

Вот и именно.
40.0 = 1.25*2^5
31.2 = 1.9500000476837158 * 2^4=0.975000023841858*2^5 (казалось бы, здесь она уменьшается, эта ошибка)
40.0-31.2 = 0.274999976158142*2^5=8.79999923706054
--
А пишет 8.8
Т.е. в зависимости от того, как там дела на Марсе, он то "хочет" округлить то "не хочет"
--
Для более придирчивого взгляда, обобщу: если мы из представимого множеством double числа вычтем непредставимое, то в результате обязательно получим непредставимое, а в консоли это не так.

Может сервис локализации тут мельтешит?( Параметры категории LC_NUMERIC, какое правильное значение grouping для Ваших примеров - никак не соображу, в Excel всё это выглядит как-то прозрачнее).

OK. Смотрим, ессно, дефолтный локаль, какой эст

Врядли оно тутта при чём. Это чистая проблема конверсии double -> string
До системы уравнений пока сегодня не добрался на предмет чреватости ошибки, но это тоже врядли. Не может же весь мир дураками быть, в конце концов!
--
Покурю-ка я исходники 2.7.3
Себе полезно, - людЯм интересно
Тем более, документировано - ну просто красота!

Не забудьте рассказать результаты. Как я поняла по этим страницам "усовершенствование IEEE-754" началось как раз с версии 2.7