OpenEuphoria

RE: BUG! Erratic for loop behavior

• Posted by Chris Bensler <bensler at mail.com> Mar 23, 2002
• 511 views

While researching 3d math and related things, it was often recommended 
to use fixed point integer math instead of floating point.

Most of the references were fairly old, predating the coprocessor, so 
suggested fixed point as a faster alternative. Some recognized the use 
of an FPU, but still recommended fixed point as a more accurate method.

I never did figure out how fixed point math works.
How much slower is fixed point math in comparison?


Chris


Andy Serpa wrote:
> 
> Dan Moyer wrote:
> > Andy,
> > 
> > Although I assume this is at least obvious, you could just do this:
> > 
> > for i = 10*31.1 to 10*34.2  do
> >   ?i/10
> > end for
> > 
> > Same for whatever max "level" of floating point you have, ie, if *any* 
> > value
> > goes out to .001,multiply all by 1000, then divide, etc.
> > 
> 
> > Maybe there's some good reason that doesn't occur to me offhand why this
> > won't work?
> > 
> 
> No, that works fine for getting this particular loop to work.  But the 
> problem outside of a loop as well.  Let's say you make an application 
> that adds and subtracts dollars & cents a lot.
> 
> .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 
> if x = 1 then
>   puts(1,"TRUE.")
> else
>   puts(1,"FALSE.")
> end if
> 
> It will come up false.
> 
> So if you have a program that does any kind of floating-point 
> calculations, and then check to see if a particular value = some other 
> value, you'll often get the wrong answer.
> 
> I just didn't realize before it was so serious.  Those of use who don't 
> come from a low-level programming background or don't have a lot of 
> hardware knowledge aren't told this anywhere.  It really ought to be in 
> the manual....
> 
> 
>