1. RE: arithmetic
- Posted by irv at take.maxleft.com
Jun 01, 2002
George Walters wrote:
> 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.
George:
Fortran has exactly the same floating point errors as
Euphoria, if you're comparing floating point numbers.
See http://www.lahey.com/float.htm
COBOL has the same problem, but COBOL programmers
rarely use floating point, because COBOL has a
decimal type. Which for all practical purposes is
just integer math, with an imaginary decimal point
inserted on display. You can do the same thing with
Euphoria. See http://cobolreport.com/pp/part2.asp
As for Basic, I don't know, haven't used it in years,
but I do see that BCD math packages are available
as add-ons for Visual Basic, so I guess it can't handle
decimal arithmetic either, without help. CBasic came
with BCD math built-in, but it cost $4,000.
Borland's Turbo Pascal 3.0 offered a version with
a built-in BCD type. Later versions dropped support for
this. Guess it wasn't very popular.
Regards.
Irv
2. RE: arithmetic
- Posted by irv at take.maxleft.com
Jun 02, 2002
rforno at tutopia.com wrote:
> You should investigate the same problem in FORTRAN, BASIC, C, C++, Java,
> Pascal and other languages.. None of these allows for exact equality for
> floating point data. C does not allow = sign to compare strings; instead
> you
> should use strcmp() function; and so on. COBOL, ABC (from the
> Netherlands)
> and APL are among the few that consider equality for float data, in
> different ways each of them.
Rob 'could' implement Theodore Belding's fcmp library.
It slows down floating-point comparisons (in C) by 9x,
but that shouldn't matter much. Even if he did, it wouldn't
solve George's problem, however. The solution to that is
either using integer math (easy) or a BCD math package
(also easy, except that someone has to write one first ;)
Regards,
Irv
3. 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
>
>
>
