decimal woes

Hi Max, you can use e.g.: do http://www.fm.vslib.cz/~ladislav/rebol/rounding.r time: 0 loop 50 [ time: round/to time + 0.02 0.01 probe time ] -L ----- Original Message ----- Hi all, I am having fun converting SEISMIC data (sampled at 5 thousands of a second :-) within a 30MB file. I must dump all of this in a 3d animation package (maya) and its working... except for one point.. decimal datatype is a little unstable, and maybe someone can tell me why this happens: if you do: time: 0 loop 50 [ time: time + 0.02 probe time ] ask "" at the end you will have 0.92 0.940000000000001 0.960000000000001 0.980000000000001 but if you then do 0.92 + 0.02 you get 0.94 the floating point error gets worse and worse (and eventually diminishes a little!!!) there are only two signifiant digits in all calculus, I am wondering if it could be possible for the floating point algorythms to be a little more stable... I had to an ugly integer calculation workaround divided by 100 to get the clean decimals... -max

Hi all, I am having fun converting SEISMIC data (sampled at 5 thousands of a second :-) within a 30MB file. I must dump all of this in a 3d animation package (maya) and its working... except for one point.. decimal datatype is a little unstable, and maybe someone can tell me why this happens: if you do: time: 0 loop 50 [ time: time + 0.02 probe time ] ask "" at the end you will have 0.92 0.940000000000001 0.960000000000001 0.980000000000001 but if you then do 0.92 + 0.02 you get 0.94 the floating point error gets worse and worse (and eventually diminishes a little!!!) there are only two signifiant digits in all calculus, I am wondering if it could be possible for the floating point algorythms to be a little more stable... I had to an ugly integer calculation workaround divided by 100 to get the clean decimals... -max

That must be a bug from what I can gather. You might want to submit that to feedback via www.rebol.com/feedback.html Paul Tretter ----- Original Message ----- From: "Maxim Olivier-Adlhoch" <[maximo--meteorstudios--com]> To: "Rebol-List (E-mail)" <[rebol-list--rebol--com]> Sent: Friday, July 18, 2003 10:01 AM Subject: [REBOL] decimal woes Hi all, I am having fun converting SEISMIC data (sampled at 5 thousands of a second :-) within a 30MB file. I must dump all of this in a 3d animation package (maya) and its working... except for one point.. decimal datatype is a little unstable, and maybe someone can tell me why this happens: if you do: time: 0 loop 50 [ time: time + 0.02 probe time ] ask "" at the end you will have 0.92 0.940000000000001 0.960000000000001 0.980000000000001 but if you then do 0.92 + 0.02 you get 0.94 the floating point error gets worse and worse (and eventually diminishes a little!!!) there are only two signifiant digits in all calculus, I am wondering if it could be possible for the floating point algorythms to be a little more stable... I had to an ugly integer calculation workaround divided by 100 to get the clean decimals... -max

great! thanks -Max

Hi Maxim, decimal fractions like 0.02 are typically represented as binary fractions at the hardware level, in this case: 0.02 base 10 0.0_00001010001111010111_ recurring base 2 Due to the limited precision a roundoff error is introduced at the the 23rd, 53th or 80th bit of the mantissa (depending on the floating point format), which tends to accumulate when you do lots of additions and subtractions. One option would be to use fixed point arithmetic done with premultiplied numbers. Another option would be to rewrite the code: time: 0.0 time-start: 0.0 time-end: 1.0 repeat n 50 [ m: n / 50 time: time-start * (1 - m) + time-end * m probe time ] Depending on the number of iterations, this may (not necessarily!) be more accurate.

reply in-line PS: check out the e-mail replacement... it sometimes work when sites ask for passwords... the sysadmin receives their own spam ;-)

> -----Original Message----- > From: Roland Hadinger [[root--localhost--com]] > point format), which tends to accumulate when you do lots of > additions and subtractions.

> One option would be to use fixed point arithmetic done with > premultiplied numbers.

> Another option would be to rewrite the code: > > time: 0.0 > time-start: 0.0 > time-end: 1.0 > > repeat n 50 [ ...]

> Do you think this means that print and probe do not contain > all digits of the internal hw decimal value? so that when it > prints 0.92 it only looked at the 15 first digits and there > was still some data past that, which only spills off after > repeated (and expected) rounding errors?

> if so, does anyone know how to build a print-xtended-decimal function?

Carl (S.) had at one point suggested including a "binary coded decimal" type! and necessary op!s that would atleast cover the case in point. On Fri, 18 Jul 2003, Roland Hadinger wrote:

Hi Tom, TC> Carl (S.) had at one point suggested including a "binary coded decimal" TC> type! and necessary op!s that would atleast cover the case in point. Which would be nice for money! values. money! values suffer some glitches when printed or probed as well right now. -- Gregg

Hi Maxim, On Friday, July 18, 2003, 7:28:06 PM, you wrote: MOA> Do you think this means that print and probe do not contain MOA> all digits of the internal hw decimal value? Of course they don't. The internal representation is binary, while they print in decimal. There's no point in showing an amount that is lower than the error caused by the internal representation. However, since you use repeated additions, this error sums up and becomes "visible", i.e. big enough that PRINT thinks it is worth showing. In your case, fixed point arithmetic is probably the best solution. If you want to use floating point, you have to take the error into account. Or, at least you have to avoid operations that can make the error grow, as in: i: 0 loop 50 [ probe time: 2 * i / 100 i: i + 1 ] Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amiga Group Italia sez. L'Aquila --- SOON: http://www.rebol.it/