При умножении n на 0.1 после(меньше) 0.1 появляется «выхлоп» в виде маленького остатка.

это везде так

http://0.30000000000000004.com/

Ты же правда читал https://docs.python.org/2/tutorial/floatingpoint.html ?

http://habrahabr.ru/post/112953/

Ну и что? Используй round.

А пофиксить как можно, кроме округления? И еще вопрос: почему так происходит? Хотя бы кратко

Кратко: При умножении n на 0.1 после(меньше) 0.1 появляется «выхлоп» в виде маленького остатка. (комментарий)

И еще вопрос: почему так происходит? Хотя бы кратко

Вот тут доходчиво объяснено же:

http://habrahabr.ru/post/112953/

А пофиксить как можно, кроме округления?

Только если не использовать чисел с плавающей запятой, независимо от ЯП.

Печально. Ясно, спасибо.

В принципе, думаю, можно написать отдельную часть кода, которая будет это фиксить. Т.е. вычитать. Ведь если числа очень большие(т.е. маленькие), то этот остаток может сильно помешать.

А пофиксить как можно, кроме округления?

Представь как строку и возьми символов столько, сколько тебе нужно (это если без округления), в том числе используя format и аналоги.

Ах, да. Спасибо

Используй Decimal:

from decimal import Decimal

a = Decimal(1000)
count = 0
while count != 15:
    count = count + 1
    a = a * Decimal('0.1')
    print('====\n#', count)
    print('a =', a)

Выхлоп:

('====\n#', 1)
('a =', Decimal('100.0'))
('====\n#', 2)
('a =', Decimal('10.00'))
('====\n#', 3)
('a =', Decimal('1.000'))
('====\n#', 4)
('a =', Decimal('0.1000'))
('====\n#', 5)
('a =', Decimal('0.01000'))
('====\n#', 6)
('a =', Decimal('0.001000'))
('====\n#', 7)
('a =', Decimal('0.0001000'))
('====\n#', 8)
('a =', Decimal('0.00001000'))
('====\n#', 9)
('a =', Decimal('0.000001000'))
('====\n#', 10)
('a =', Decimal('1.000E-7'))
('====\n#', 11)
('a =', Decimal('1.000E-8'))
('====\n#', 12)
('a =', Decimal('1.000E-9'))
('====\n#', 13)
('a =', Decimal('1.000E-10'))
('====\n#', 14)
('a =', Decimal('1.000E-11'))
('====\n#', 15)
('a =', Decimal('1.000E-12'))

Используй тDecimal для точных вычислений. Только он тормозит чуток.

В принципе, думаю, можно написать отдельную часть кода, которая будет это фиксить. Т.е. вычитать. Ведь если числа очень большие(т.е. маленькие), то этот остаток может сильно помешать.

Ты так ничего и не понял. Ну не может твой несчастный double запомнить число 0.010000000000000000. Либо больше, либо меньше. Ты можешь вычитать 0.010000000000000002 - 0.000000000000000002 хоть до посинения, но 0.01 никогда не получишь.

Когда же уже переведутся горе-программисты, не знающие как представлены вещественные числа в компьютере? ОП, на, поиграйся: http://www.h-schmidt.net/FloatConverter/IEEE754.html

Они «переведутся» перед тем как программисты исчезнут

Так что это, в принципе, даже хорошо

What every computer scientist should know about floating-point arithmetic

В общем случае ошибка норовит накапливаться при сложении-вычитании близких чисел, в некоторых задачах может помочь Kahan summation.

http://floating-point-gui.de

Даже тут Go отличился, лол.

Да какая разница, как проводить сложение/вычитание/умножение?

ТС хочет, чтобы a = 0.01, чего не может быть с double в принципе.

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

Вон из профессии.

Я ждал здесь с этим комментарием именно тебя)

Давай позориться вместе :) QJsonObject и double - вместо 0.1 дает 0.099999

Кстати, а почему так происходит?

>>> a = 1 * 0.01
>>> a
0.01
>>> a = 1 * 0.1 * 0.1
>>> a
0.010000000000000002

Почему?

>>> a
0.010000000000000002
>>> b = a - 0.000000000000000002
>>> b
0.01

А пофиксить как можно, кроме округления?

Замени делитель (0.1) дробью с целыми числами, т.е. дели на 10.

>>> a
0.010000000000000002
>>> b = a - 0.000000000000000002
>>> '%.20f' % b
'0.01000000000000000021'

Почему?

Потому что 1/10 в двоичной системе исчисления — периодическая дробь. Ну прочти же ты уже про числа с плавающей точкой.

Тут видимо два не полностью точных числа перемножаются и теряется точность и число вылезает за пределы округления.

Прочитал хабростатью. Но остались еще открытые вопросы. Например, если использовать двойную точность я смогу этого избежать? И есть ли сишный аналог double для python, или он сразу в двойной работает?

Т.е., я понимаю, что до определенной степени я все-таки смогу решать эту проблему с двойной точностью. Но в python она по дефолту стоит?

Только если не использовать чисел с плавающей запятой, независимо от ЯП.

perl6 же!

http://blogs.perl.org/users/ovid/2015/02/a-little-thing-to-love-about-perl-6-...


Ну и практически все scheme'ы это умеют из коробки (здесь может и вру).

Не сможешь, в double ошибка будет меньше, но не уйдёт.

Может и уйти, на самом деле. Зависит от числа

Уйдёт, а потом опять прийдёт. Отчего итоговый результат исказится ещё больше. Поэтому если нужна точность - либо fixed point, либо gmp

fixed point в python только в помощью сишной библиотеки «Decimal» можно реализовать, как я знаю. В принципе, на этом варианте и остановлюсь

И есть ли сишный аналог double для python, или он сразу в двойной работает?

В твоем питоне и так double.