как сравнивать?? если 9.45-9.44 != 0.01

[mrspb]

Hi!
здесь (http://www.flash-mx.ru/forum/topic_show.pl?pid=1027;hl=%cf%db%c9%c2%cb%c9;hlm=and#pid1027) есть пример
q = 10.2 - 8.1;
trace(q);
trace(q == 2.1); //выводит false
а как это обходить-то?

***
ЗЫ
что странно - через такую функцию работает
roundTo = function (theNumber, decPlaces) {
if (decPlaces>=0) {
var temp = Math.pow(10, decPlaces);
return Math.round(theNumber*temp)/temp;
}
}
trace (roundTo((10.2 - 8.1), 2) == 2.1); //выводит true
trace (roundTo((8.52 - 8.51), 2) == 0.01); //выводит true
,a через такую - нет
transit = function (tt){
String(tt);
return Number(tt)
}
trace(transit(10.2 - 8.1) == 2.1); //выводит false
:confused: :eek:

[AlexMatveev]

http://www.flasher.ru/forum/showthread.php?t=59237

[mrspb]

AlexMatveev, пасибо!
Замечательно, во всё виноваты Винды и проц, ГЫ!
Тепеть для "точных" вычисленией класс дописывать? на основе:
BrainSmasher
Кстати, что касается суммовых операций то тут все куда проще, смещаем принудительно разрядную сетку на 4 разряда (умножаем все суммы на 10000) а после любых вычислений делаем round результата, в итоге получаем целое число, которое точно представимо всегда (если не выходит за пределы разрядной сетки, но сильно я сомневаюсь что Вы оперируете подобными суммами

Я чё, подумал-то, у меня в первом посте две функции, обе возвращают одно и тоже число (2.1) но в одном случае сравнение прокатывает, а в другом - нет. А как сделать, чтоб в обоих случаях сравнение получалось???

может при использовании первой функции Флэш выставляет биты регистра control word (http://www.flasher.ru/forum/showpost.php?p=389622&postcount=20) в нужное состояние?

[AlexMatveev]

Все потому же....
если взять и сделать так ;)

a = int((10.2-8.1)*10000000);
trace (a)

то получим, а = 20999999
а это значит что после вычисления (10.2-8.1) мы получаем не (2.1), а банально, но факт (2.0999999). А это соответственно не равно (2.1)

Тут получается что все дробные вычисления надо делать через сдвиг разрядной сетки.


-

[mrspb]

не понял, ты это к чему?
не, int - не туда округляет :) Туда окугляет Math.round(theNumber)
c = Math.round((10.2-8.1)*10000);
trace (c) //21000
trace (c == 21000); //true

][otia i bez nego Mo]|[no
a = 10.2*10000;
b = 8.1*10000;
c = a - b;
trace (c); //21000
trace (c == 21000); //true
c = c/10000;
trace (c);//2.1
но это долго
Тут получается что все дробные вычисления надо делать через сдвиг разрядной сетки
в каком смысле???
>>>, >>, <<= эти?

[mrspb]

не понял, ты это к чему?
не, int - не туда округляет :) Туда окугляет Math.round(theNumber)
c = Math.round((10.2-8.1)*10000);
trace (c) //21000
trace (c == 21000); //true

][otia i bez nego Mo]|[no
a = 10.2*10000;
b = 8.1*10000;
c = a - b;
trace (c); //21000
trace (c == 21000); //true
c = c/10000;
trace (c);//2.1
но так долго.
Тут получается что все дробные вычисления надо делать через сдвиг разрядной сетки
в каком смысле???
>>>, >>, <<= эти?

[Nox Noctis]

не, int - не туда округляет :) Туда окугляет Math.round(theNumber)какая разница, чем округлять?

задача - сдвинуть разрядную сетку так, чтобы неточность вычислений _для нашей конкретной задачи_ не менялась при ошибках в числах с плавающей точкой. умножили всё на 10^N - получили сдвиг разрядной сетки на N разрядов (поскольку речь о десятичной системе). после округления ошибка никуда не денется (на то оно и округление), но просто будет пренебрежимо мала.

кстати, вот тут (http://flash-mx.ru/forum/topic_show.pl?tid=167), точно такая же тема рассматривалась.

[Kotenochek]

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

q = 10.2 - 8.1;
eps=0.01; //погрешность
trace(Math.abs(q-2.1)<eps);

[K.A.T.A.F.A.L.K.E.R]

Один математик (к сожалению, не помню, кто) утверждал, что 0.9999... (0.(9)) в точности равняется единице. В смысле, не "приблизительно", а именно точно. И он смог это доказать! Доказательство было просто гениальным: "пойдем от обратного. Допустим не равны. Тогда пусть мне скажут, на сколько 1 превышает 0.999...". Ответ был очевиден. На 0. :D
В нашем случае все не совсем так, т.к. отличаются они в этом примере на 4.44089209850063e-16. Посему поддерживаю мысль о введении погрешности, но сделать ее порядка e-10 :)