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

[Jaroslav Hajek]

On Wed, Apr 21, 2010 at 8:20 PM, Judd Storrs <address@hidden> wrote:
> 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.
>

Well, glibc is part of lots of software in this regard. So of course
improving glibc is much better than working on a replacement, because
it may help many others. Btw, I don't think that GSL ever intended to
replace standard C math functions, but rather provide those that were
missing once. I will not be very surprised if sometime in the future
when C99 becomes ubiquitous (it still isn't really), the GSL functions
become just wrappers.

and of course I'm happy with submitting the patch.

best regards

-- 
RNDr. Jaroslav Hajek, PhD
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz