Коррекция значения результата ошибки с плавающей запятой?

Question

[GreenX5]

Получаю по вебсокету (данные не я стряпаю) иногда вот таких например жертв фичи с плавающей запятой
0.9192899999999999
3.234000000000001
Чтобы не задавать вектор и разрядность округления для каждого значения, можете подсказать общий метод округления с минимальными накладными расходами?
Очевидно, значения должны выйти
0.91929
3.234
питоновский float. хотя можно и string, всё равно дальше на вебсокет пулять
UPD:
Если задача труднореализуема или попросту непонятна ввиду косноязычного изложения, прошу помочь с регулярным выражением для отсечки справа всех девяток (или нулей) вместе со совсем что правее, если их (девяток или нулей) больше пяти подряд.
Спасибо.

Comments

[Roman K]

Вопрос-то в чём? Данные как предполагается использовать? Зачем округлять, что такое "разумное округление"?

[GreenX5]

Roman Kitaev, вопрос задан, поправлен. Данные отправятся питон-сервером подключенным клиентам через другой вебсокет.

[shurshur]

GreenX5, да просто сделать round(x, 5) чтобы не больше 5 цифр после запятой.

[GreenX5]

shurshur, нет, не вариант. Я же сразу указал что "полезных" цифр после запятой может быть разное количество, и их все нужно сохранить.
А куча девяток и нулей поле них это отрыжка вычисления (хранения) в двоичной системе, нужно округлять обратно или отсекать.
Лишние цифры тоже не нужны

[kamenyuga]

GreenX5, решение, предложенное shurshur, - рабочее для приведенных в вопросе примеров.
Попробовал бы для начала хоть строку кода в питоне написать и запустить, прежде чем голословно утверждать, что не вариант.

[soremix]

kamenyuga, а если число 1.1234567899999999 ?

[GreenX5]

kamenyuga, пробовали бы прочитать и понять вопрос, прежде чем умничать. round здесь не подходит.

[kamenyuga]

soremix, тогда ставишь округление до 8 знаков и все продолжает работать. Настолько невероятно, что даже не верится. Но легко проверяется. А вот угадывать, какие там могут быть случаи - дело неблагодарное.

[Roman K]

GreenX5, вопрос исправлен, но мне не стало очевидно, по какому признаку ты решаешь, какая часть числа значимая, а какая мусорная. Почему вдруг последовательность девяток или нулей стала «очевидно» незначимой?

[GreenX5]

Roman Kitaev, а почему это не должно стать очевидным? Что более очевидно?

[Roman K]

GreenX5, потому что это не логично, не так ли? Более очевидны формальные требования, которые ты не сформулировал. Также как и не описал граничные случаи.

[GreenX5]

Roman Kitaev, не, не так. Наличие пяти нулей или девяток в конце дробной части числа плюс любое число последнее и минимальные машинные ресурсы на проверку и коррекцию - вполне конкретные формальные требования.

Answer 1

[kamenyuga]

Решение из комментария от shurshur - простое до безобразия. Понятное и рабочее. Какая его особенность делает его непригодным для решения задачи?

>>>round(1.1234567899999999, 10)
1.12345679
>>> round(3.234000000000001, 10)
3.234
>>> round(0.9192899999999999, 10)
0.91929

Comments

[GreenX5]

отлично, теперь попробуйте это

print(str(round(1.2338355678823499999999,10)))

последняя "полезная" цифра здесь 4, которая должна быть 5

[kamenyuga]

GreenX5, это что-то на грани реальности или уже за ней. Речь о числах с плавающей запятой, их арифметике и точности представления. Попробуй держаться в разумных пределах. После запятой в питоне будет максимум 15 или 16 цифр. Пятью из них вполне можно пожертвовать во многих реальных задачах. Ну или тремя. Если нельзя, то изначально питоновский тип float не годится для использования в этом случае.

>>> 1.2338355678823499999999
1.23383556788235

[shurshur]

GreenX5, 8-байтовое вещественное (double в C) имеет значимых 15-16 цифр в мантиссе, 10-байтовое (long double) - 19-20. В python тип float 8-байтовый.

Числа превращаются в таких монстров просто по причине неточностей при переводе из двоичной формы в десятичную. Например:

f"{0.23:.20f}" == "0.23000000000000000999"

[GreenX5]

shurshur,
Причины понятны. Это скольки-байтовое?
print(len(str(0.1 + 0.2).split('.')[1]))
или речь именно о значимых, нули не в счет?

[GreenX5]

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

[shurshur]

GreenX5, float всегда 8-байтовый, даже float(0). Считать len от строкового десятичного представления несколько странно.

Вещественные числа хранятся в виде m*10^o, где m - мантисса (53 бита), o - порядок (11 бит). Можно посмотреть подробности sys.float_info и тут: https://ru.wikipedia.org/wiki/%D0%A7%D0%B8%D1%81%D...

Значащими являются цифры в мантиссе. При этом возможны всякие казусы, например: 1+(1e-17)=1 - потеря точности, так как в мантиссе не может быть 18 значащих цифр, хотя 1 и 1e-17 не теряют точности по отдельности - там всего одна значащая цифра.

Можно просто делать round(x, sys.float_info.dig).

[GreenX5]

shurshur, да, спасибо за подтягивание теории, я ни в коем случае не вступаю в спор с Вами по этим вопросам. Просто рано или поздно хочется положить в закрома какое-то рабочее решение для исправления битых конвертациями чисел. Это проблема всех машинных языков, помню еще в LUA нужно было решать когда писал биржевых ботов лет 15 назад, там котировки требовали строго определенной не побитой разрядности. И разрядность у многих фин. инструментов была разная.
Конечно, заведомо определяя разрядность каждой переменной как условие результата, можно её проверять и даже передавать при обмене второй переменной, как например раздает Яху финанс в своих JSON. И рамках моей задачи сейчас мне действительно пока оказалось достаточно round 5, даже без проверки индивидуальных разрядностей. Но это "пока". Даже в мире финансов есть разрядности поболее 5 знаков после запятой. А в области bigdata это вообще дает катастрофические суммарные итоговые погрешности, и это давно известная проблема.
Строковое представление я дал чтобы чья-н. среда разработки не округлила для вывода в интерфейсе. Не так уж это странно. ) Вот выше kamenyuga утверждал что "После запятой в питоне будет максимум 15 или 16 цифр", я, чтобы не начать торговаться с ним как на базаре, дал число с 17-ю, причем не импортированное, это родил питон в результатом арифм. операции.
Сейчас проверю ваше round(x, sys.float_info.dig)
Спасибо.

[GreenX5]

kamenyuga, или поторгуемся дальше? ) Вот еще результат арифм операции

a = (7e-05)*10
print(str(a), type(a), f"{len(str(a).split('.')[1])} знаков после запятой")

[GreenX5]

shurshur, не работает в условиях поставленной задачи

a = 0.919289999999999
print(a, type(a), f"{len(str(a).split('.')[1])} знаков после запятой")
print(round(a, sys.float_info.dig))

[kamenyuga]

GreenX5, а что это тут у нас?

Получаю по вебсокету (данные не я стряпаю)

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

[shurshur]

GreenX5, а вот как понять, сколько цифр в записи 0.919289999999999 являются значащими, а сколько - ошибкой округлений?

Так-то не очень сложно написать алгоритм, который найдёт на конце все девятки и затем передаст в round(x, текстовая_длина_числа-число_девяток) (не совсем так, так как в текстовую длину входит знак и десятичная точка, но принцип должен быть понятен), но такой алгоритм и 0.9 превратит в 1, а ведь это вряд ли задумывалось.

В итоге всё упирается в то, какая конкретно точность ожидается от чисел. Сколько в них значимых цифр? Вот эту величину и надо передать вторым аргументом round. А 0.919289999999999 с 16 значащими цифрами вполне легально не округляется.

[GreenX5]

shurshur,
Я же вроде понятно дал формальные требования для пути к решению задачи. Первый пост, после UPD:
Например путем поиска регулярными выражениями пяти девяток или нулей. Да, конвертация в строку и обратно накладно, не лучшее решение, но хоть какое -то.

[GreenX5]

kamenyuga, ну никогда не поздно и не постыдно раздвигать границы своих "ограниченных возможностей", за тем мы и на Хабре, правда? )
Не расслабляйтесь, вот вам 324 знака после запятой в float

a = 5e-324
print(type(a), a)

[shurshur]

GreenX5, тут всего одна значащая цифра, так что этот пример неинтересен.