Баги флеша при работе с дробными числами
 

Приветствую всех. Столкнулся с проблемой, попортившей немало крови а именно:
Флеш некорректно выполняет арифметические операции над некоторыми отдельно взятыми числами. Например - при вычитании из 2.3 единицу (2.3-1) получается бред вида 1.29999999.... При этом если вместо 2.3 взять 3.3, 5.3 то все ок, зато если из 5.3 вычитаем 4 (чтобы получить опять таки проблемное 1.3) получаем опять таки 1.2999999.
Похожие проблемы были с делением, например при делении 1.9/0.1 получалось не 19 а 18.9999999...... В итоге это все приводило к тому что при последующих манипуляциях с числами получались реально неверные результаты, и я никак н мог понять в чем дело.
Да, проверил это на других SDK - все тоже самое. Кто нибудь сталкивался с подобным?

сталкивался и сталкиваюсь...
еще пытаюсь сам понять что за фигня)))

Вот блин =)) И как теперь быть, когда в программе сплошные вычисления?

я тем же вопросом озадачен ))

Этот вопрос часто обсуждается, используйте поиск по форуму.

а если арифметические действия будут происходить с числами у которых после запятой около 4-5 знаков тоже будет врать?

Это не баг флэша - это обычное поведение floating point. Так, например нельзя точно посчитать 0.1, 0.6 и т.д. Округляйте до нужного вам знака.

как это??нельзя точно посчитать 0.5 - 0.1 к примеру????????

Это накопительная ошибка. Я ее встречал также в javascript и php.

Не очень понятно что до чего округлять. Допустим я работаю с десятыми долями, т е мне достаточно одного знака. И как мне быть когда мне нужно к примеру 19 умножить на 0.1? Или же вышеприведенное вычитание. И чтобы всегда было без сюрпризов?

Ps Не знаю обычное ли это поведение, но я с плавающей точкой работаю не первый и даже не десятый раз (начинаю с паскаля и заканчивая .Net), но подобное виже впервые во flash.

Создайте html документ с этим кодом и получите 3.000000000000001

Все правильно - все основываются на одном и том же стандарте. Цитата из хэлпа:
В .NET то же самое...

и это жесть господа)

Это не жесть, а ваше недопонимание, как компьютер работает с числами с плавающей запятой. Если интересно - почитайте статью в английской википедии, там всё очень подробно описано. IEEE-754 существует уже 24 года и сейчас является самым распространённым стандартом - повода для беспокойства нет.

немного утрированно, как мне показалось, но в тему

И все таки это следствие лени разработчиков.
Таких сюрпризов можно было бы избежать.

Delphi тоже иногда не любит Real
Даже Excel страдает подобным

во всех языках есть библиотеки для точных вычислений. я думаю и для ас3 тоже есть. нужно только поискать.
а вообще, для большинства задач вполне хватает той точности, которая есть

так работает процессор. такое поведение абсолютно во всех языках происходит при работе с float'ами. программное обеспечение тут не причём. это зашито на аппаратном уровне.

Это можно обойти на программном уровне

Как говорится - чтд. Так почему это не зашито в fp?

Зачем? Кстати, координаты не могу быть меньше 0.05 пикселя, так как такая точность не нужна. Это не расчеты ядерных реакторов.

как насчет "С", СИ крут, а все остальное реально не для точных вычислений.

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

И где же вы раньше были? Как всегда появился гений, которому наплевать на 20 летние разработки математиков и программистов всего мира.

Си ничем не отличается от других языков программирования — использует все те же числа с плавающей запятой. Только одно отличие — в настройках можно указать повышенную точность вычислений вещественных чисел, что означает, что все вычисления будут производиться с 80битными числами, а затем округлятся, а не обрезаться до размера переменной этого типа.

Помоему вы накручиваете проблему, я при разработке программ очень часто имею дело с вещественными числами, ни разу это не вызывало для меня проблем. Тот факт, что вычисления с вещественными числами не соответствуют вычислениям с десятичными нужно просто учесть — это плата за скорость работы с такими числами. Например, нужно исключить из программы все сравнения с такими числами, сравнивать всегда нужно с учетом погрешности. Также нельзя складывать числа, которые сильно отличаются порядком.
В программах, в которых требуется точность вычислений не используются числа с плавающей запятой. В программах, которые работают с деньгами используются числа с фиксированной запятой — фактически каждое число умножается на 10000 для вычислений, а затем делится при выводе. Также есть вариант чисел очень высокой точности — при вычислениях точность чисел повышается автоматически.

хммм а есть вопрос гео координат, там как раз важна точность десятых, сотых и тысячных

как уже сказали, во флеше такая точность просто излишняя, нужна точность возьмите фортран

зашибись блин фортран, тогда можно будет и про флеш забыть... потому как скорость упадет в разу просто потому что буду дольше передавать инфу по externaInterface или через запросы... бред какой то

че-то не увидел в чем проблема
написал

Ипать, для AS2 это действительно так, а для AS3:

2 ZIK68 и murz

и для as2 и для as3

:p

Яски все правильно сказал, проблем с этим возникать не должно Если у вас любая 10 секундная проблема создает большие сложности, значит у вас мало опыта.
См. выше. Умножате все на 10, 100 или 1000 и проблем нет.

там моя опечатка была, последние 2 строчки в примере были одинаковые, а вы в своем примере это не исправили :D

исправил
опять непонятно
если
то выводит false, если замениьт на тыщу, то все тру