Доброго дня!
Нашел такую фичу/баг с float преобразованием. Понимаю, что сама по-себе float условно-точная, но у меня вышло, что её точность в очень небольших диапазонах, при определенных не сложных математических вычислениях, падает до 2%
OL 1.22.287 тестировал на реальном приборе, но и в онлайн-отладке погрешность проявляется.
изображение_2022-02-13_172901.png
Ошибки размером в "1" в нижней части вычислений (для Int_2) возникают, когда энергонезависимая "Float_1" принимает значения:
0,53 0,59
1,05 1,06 1,17 1,18
2,09 2,10 2,11 2,12 2,34 2,35 2,36 2,37
4,18 4,19 4,20 4,22 4,24 4,43 4,45 4,47 4,49 4,68 4,70 4,72 4,74
8,11 8,23 8,36 8,40 8,44 8,48 8,61 8,65 8,69 8,73 8,86 8,90 8,94 8,98
9,11 9,23 9,36 9,40 9,44 9,48 9,61 9,65 9,69 9,73 9,86 9,90 9,94 9,98
На Float_1=10 закончил эксперимент, но определенную логику и прогрессию возникновения погрешности(*2) видно.
Естественно, это не реальный проект, и способ "обойти трудности" в реальном проекте приведен в верхней части скриншота, но хотелось бы обратить внимание разработчиков OL. Может мой тест-репорт подтолкнет на более существенные мысли.
В реальном проекте обнаружил данную проблему при использовании EQ, когда ожидалось, что числа должны быть равны, а они отличались, на эти единицы. Могут возникать и другие специфически вещи, связанные с этим. Поэтому, проблема вроде как не существенная, но нужно о ней знать.
Ответить с цитированием