Re: Possible compiler bug?

From: anon (noone_at_nowhere.spam)
Date: 01/04/05 

Date: Tue, 4 Jan 2005 01:50:18 -0000

If I could find a small bit of code which showed the problem I would post
it - but even tiny changes to the code seem to alter the situation so I am
doubtful of the chances of finding a small example. The problem is in the
middle of a large library.

What you are saying seems to make sense (at least, yet another straw to
clutch at :) Do you know how the compiler would choose which type of float
to use? Why would it be different for the IDE?

Would it help to use doubles? Your theory would explain why my alternative
flag implementation works, at least.

Dom

"cody" <deutronium@gmx.de> wrote in message
news:#7OtIsf8EHA.3840@tk2msftngp13.phx.gbl...
> Would be nice if you could post some code.
> But the float comparison could be the reason since calculated float values
> are sometimes stored into 80 bit registers and sometimes into 64 bit
> registers.
> And if you assign a flaot that is stored in a 80 bit register to one that
is
> stored in a 64 bit register you can lose some digits and successive
equality
> tests will give false even the same value was originally assigned to both
of
> them.
>
> "anon" <noone@nowhere.spam> schrieb im Newsbeitrag
> news:41d9e4e2$1_1@alt.athenanews.com...
> >I am not quick to leap to this conclusion, but...
> >
> > I have a bit of code for doing a color space conversion (RGB to HSB).
This
> > is not a trvial conversion but it isn't that complicated either. It is
> > just
> > really a 3D coordinate conversion.
> >
> > It works perfectly well in the IDE. When running the application
direcly,
> > it
> > mainly works, except for a certain narrow band of colors the calculation
> > goes wrong.
> >
> > Unfortunately, any attempt to add debug seems to make the problem
> > disappear.
> > Indeed, even the inclusion of a line of code which has no effect, eg int
x
> > =
> > y; when x is never used again, makes the problem go away.
> >
> > The only remotely dodgy thing about the code (it is "standard" code, at
> > least in its C++ form, I didn't write it) is that it compares 2 floats
for
> > equality. To be fair, it first assigns a to b, and then later tests if
> > a==b,
> > so it should work.
> >
> > Howevr I wonder if some compiler bug is mistakenly deciding the values
> > cannot be equal in some cases.
> >
> > Anyway I changed the logic to use flags and it works. But that diesn't
> > prove
> > much.
> >
> > Dom
> >
> > Stunning fractal photographs
> > http://www.morello.co.uk/fractal.htm
> >
> >
>
>

Relevant Pages

  • Re: Possible compiler bug?
    ... > But the float comparison could be the reason since calculated float values ... > stored in a 64 bit register you can lose some digits and successive ... >> equality. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: OoO VAX (was: Code density and performance?)
    ... For arith/logic instructions an x86 can have 1 memory address ... >> is too small and causes lots of register spills. ... >> time moving float values over to float registers and back. ... > architecture have the same "problem". ...
    (comp.arch)
  • Re: Meaning of Double.Epsilon
    ... Yes in memory, but you do not know which CPU registers will be used. ... The following program outputs "true true false false" on my machine: ... float f1=1.0f; ... stored in a register with *at least* 32 bit or more. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: weird problem
    ... I already told you that the comparison between an integer and a float ... value for equality is rather likely not to work - you have to round ... I find top-posting a PITA - I need the question to understand ... that usenet etiquette wasn't made up just on a whim to "push down ...
    (comp.lang.c)
  • Re: perl style: can I combine two steps into one?
    ... > should never test floating point numbers for equality. ... > incremented in some fashion. ... It wasn't a float. ...
    (comp.lang.perl.misc)
Quantcast