http://d.puremagic.com/issues/show_bug.cgi?id=3751
Witold Baryluk <bary...@smp.if.uj.edu.pl> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
--- Comment #9 from Witold Baryluk <bary...@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: -------
