Re: An explanation of the "atom floating point" bug
Joel Crook wrote:
snip
>So what I **think** Irv was trying to point out was an atom is really
>**approximation** of a float and **NOT** actually accurate as a c float of the
>same value.
An atom is...ooops... or can be a float32 or a float64 depending on where the
pimple is on which fly's but. According to the manual, it takes on the
form that it needs to express the number found in it at any particular time.
I don't think that a c float has any less problem with this kind of thing than
Euphoria. Floats are binary decimals and they do lose significance when
conversion back and forth to decimal representation is made. An atom may
be a float or a double float as in the case of 4.1 The difference is that
C does not automagically convert from type to type in the same way that
Euphoria does( or that is my impression from the code that I have read).
If you think that c floats are accurate, look at some of the remarks of
those trying to generate random number sequences.
> If you add .00001 to any atom you will better approximate the value of the
>original floating point number.
Mileage varies with precision required. My worry about the digits beyond
the 16 significant ones we are supposed to be able to get from a float64
is that if those are garbage, they could cause unpredictable rounding
errors. The fact that only 14 of the 16 significant digits appeared to be
correct made me wonder further about rounding when we are approaching
a number like 0.1 It should be 9's as far out as it is significant. Instead,
at the 15th digit, it changes. I don't know whether this is random, a garbarge
overlay or what. If it is garbage, it could cause this to erratically round
up or down by an integer in equations just like the one proposed. An
integer could be fairly significant in some of your calculations.
Scoff not at small numbers. They can grow to be big problems.
Everett L.(Rett) Williams
rett at gvtc.com
|
Not Categorized, Please Help
|
|
