RE: BUG! Erratic for loop behavior
- Posted by dm31 at uow.edu.au Mar 24, 2002
- 472 views
floating numbers should not have a problem stored most decimals like
0.1 and 0.01 since they since they store it with a mantissa(in 0.1
this is 0001) and an exponent( it becames 1111 in two's comple') I
could be wrong, but I don't see why and atom wouldn't store decimals
in this way, I fact what other way is there.
Dan
> I just did some further testing, and it seems that magnifying a
decimal
> value doesn't help either.
>
> ? magnify(0.12345678901) = 12345678901 -- 0
> ? magnify(0.12345678901) = 123456789 -- 0
> ? magnify(0.12345678901) = 12345679 -- 0
>
> This seems like a devastating problem. We use fractional numbers all
the
> time. How is it possible that it doesn't show up more often?
>
> Do we need to resort to binary math? Would that even help?
>
> What can be done to ensure that my program is calculating the math
> properly?
>
>
> Chris
>
>
> Chris Bensler wrote:
> > How does atom_to_float help?
> >
> >
> > sequence x x= atom_to_float32(0.1)
> >
> > ? x
> > ? float32_to_atom(x+x+x+x+x+x+x+x+x+x)
> >
> >
> > How do other languages deal with the general use of decimals?
> >
> > Chris
> >
> > Andy Serpa wrote:
> > > > .1 + .1 + .1 + .1 + .1 + .1 + .1 + .1 + .1 does not equal 1 --
just try
> > > > it. It will display as one if you print it, but if you do
this:
> > > >
> > > > x = .1 + .1 + .1 + .1 + .1 + .1 + .1 + .1 + .1
> > >
> > > Oops. One ".1" short, but you get the point...
> > >
> > >
>
>
