1. arithmetic
- Posted by George Walters <gwalters at sc.rr.com> May 31, 2002
- 424 views
Next problem is when is zero really zero. I'm adding and subtracting a bunch of numbers (dollars and cents) which total to zero on an adding machine but on EU it's -6.blabla -15. How does one deal with this? Does not EU handle this? I have typed the numbers as atom. Was this wrong? george
2. Re: arithmetic
- Posted by George Walters <gwalters at sc.rr.com> May 31, 2002
- 447 views
the inability of binary computers to accurately represent base 10 numbers has been known since the beginning of computers, however, languages (i.e. fortran, basic, cobol,and any language i've ever used) deals with it where an equal (=) for normal arithmetic is useful. I'm beginning to see why euphoria is so fast... it doesen't do a lot of things that need to be done in a language. If the floating point accuracy of the machine is ~10^ -15 then 10^ -14 should be considered zero (fuzz factor usually called). So instead of having to say that 'a = 0' (or a = anyother number) you must say 'abs(a)< .00000000000001' which is pretty poor... the language should do that for me. So to compare any 2 numbers you must use 'abs(a-b)<.00000000000001' is an equality. Without this you can't do any programming with the equal sign (=). You can't use equal (=) with strings either, you must use 'match'....so '=' is not too useful. george ----- Original Message ----- From: "Chris Bensler" <bensler at mail.com> To: "EUforum" <EUforum at Topica.com> Sent: Friday, May 31, 2002 5:07 PM Subject: RE: arithmetic > > That is a known problem with floating point accuracy. Not eu's fault. > The fpu has a hard time dealing with certain numbers, and doesn't > calculate them accurately. > > With fp, 0.1+0.1+0.1+0.1+0.1+0.1+0.1+0.1+0.1+0.1 != 1 > > Using FP, the actual value of 0.1 can't be represented, instead it's > 0.1... > Only certain numbers are affected because of the fp anomaly. > > To get around this, if you are using $ numbers, multiply all your values > by 100 first, to remove the decimal. When you are finished calculating, > divide by 100. and the value should be accurate. > > EG: > function add_money(atom a, atom b) > return ((a*100) + (b*100))/100 > end function > > You also have to consider rounding. > Your adding machine stops at 2 decimal places (all values rounded to > .00). Or most do. > The FPU uses 15 places of precision (basically, no rounding) > > > This very topic was discussed a few months ago. If you search the > February posts. Sorry, I don't remember the name of the thread. > > Chris > > George Walters wrote: > > Next problem is when is zero really zero. I'm adding and subtracting a > > bunch > > of numbers (dollars and cents) which total to zero on an adding machine > > but > > on EU it's -6.blabla -15. How does one deal with this? Does not EU > > handle > > this? I have typed the numbers as atom. Was this wrong? > > > > george > > > > > > > > >