Re: Same .m file: different results with different versions of Octave

[Judd Storrs]

Here's an updated patch and c99 test code for the bug that was
reported. I removed the pre-determined threshold and instead check for
overflow of den but only for the real component, the same code works
for singles and long double. I think I got all the "l"s and "f"s where
they need to be... If you agree there are no problems, I think it's
ready to submit to glibc. I only tested the double version for
accuracy.

 Error magn  Real part  Imag part  Both
 ----------- ---------- ---------- ---------
  >= 1 eps       12990      71680       6208
  >= 2 eps           0          4          0
  >= 3 eps           0          0          0
  >= 4 eps           0          0          0
  >= 5 eps           0          0          0
  >= 6 eps           0          0          0
  >= 7 eps           0          0          0
  >= 8 eps           0          0          0
  >= 9 eps           0          0          0
  >=10 eps           0          0          0

 Grid size:                1025 x 1025
 Top Left corner:           -8.000000 + +8.000000 i
 Bottom Right corner:       +8.000000 + -8.000000 i
 Time to evaluate grid:     131.600000 (sec) [10000 loops]
 Internal inconsistencies:  0


On Wed, Apr 21, 2010 at 5:04 AM, Jaroslav Hajek <address@hidden> wrote:
> Wow. I guess that if the rest of glibc's math received the same level
> of attention, I would rely on it for anything up to a flight to Mars
> :)

This was probably obvious to you guys but my problem was it had never
occurred to me to recompile glibc--when you guys would say fix it in
glibc, for some silly reason I thought that ultimately meant to wait
for a new vendor release (obviously stupid in retrospect).

My new philosophy is that glibc is part of octave. Then I don't have
to be grouchy.


--judd

glibc-ctanh-4.diff
Description: Text Data

test-c99.c
Description: Text Data