[Issue 3751] Optimalization error in some floating point code
d-bugmail at puremagic.com
d-bugmail at puremagic.com
Fri Jan 29 15:50:23 PST 2010
http://d.puremagic.com/issues/show_bug.cgi?id=3751
Witold Baryluk <baryluk at smp.if.uj.edu.pl> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
--- Comment #9 from Witold Baryluk <baryluk at smp.if.uj.edu.pl> 2010-01-29 15:50:21 PST ---
(In reply to comment #8)
> (In reply to comment #7)
> > Yes I know, but I was relaying of IEEE 754 semantic, in which my code should
> > work (there will be point in execuion when left == half or right == half
> > exactly!). I was just trying to write this routine to be slightly faster just
> > by not using EPSILONS and substractions.
>
> Are you sure? I'm not really a floating point expert, so I don't know what the
> rules of IEEE are, but I have written floating point convergence algorithms for
> things like programming competitions, and I had to learn that things will get
> stuck if you don't use an epsilon.
>
> You can picture what's happening if you make left and right integers. What
> ends up happening when left - right == 1? half becomes left + .5, so it does
> not compare equal to left or right, but if your calculation then assigns left
> equal to half, the .5 is dropped and left is stuck in the same loop.
Whell it can't be that "half is not equal to left", and then after assigning it
is actually the same value. It is only becuase we have intermidiate half in
higher precision than double precision.
I'm actually using formula half = left + 0.5*(right-left); which is safer in
regards of overflows, but this doesn't really metter.
> I would say that this is not a bug, but again, not a floating point expert.
Closing it. Sorry for a problem.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
More information about the Digitalmars-d-bugs
mailing list