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

[Judd Storrs]

On Tue, Apr 20, 2010 at 3:55 AM, Jaroslav Hajek <address@hidden> wrote:
> I think we can simply use the original author's den == 0 branch, it's
> supposed to be very infrequent. In fact I doubt that it can happen at
> all on my platform, as I said, I can't find an exact root of cos() at
> all, even if walking the doubles via nextafter()/nexttoward(). If
> there was one, then den == 0 could happen as an underflow in
> sinhx*sinhx, so the original author's approach may perhaps still
> deliver something slightly better than NaN + NaN*i, although the
> accuracy is questionable at best.

I haven't been able to deliberately hit that branch either. I agree
there's not much of a risk to keeping the original den==0 branch. As
you say, it would only get executed when underflow has already
occurred and underflow may be less of a problem. The other option of
omitting the branch altogether and immediately performing the division
by zero is also an option but that doesn't seem to give any
performance advantage on my machine.

> How do you try the modified libm in Octave? I'm able to link C
> programs against the modified libm, but I can't get Octave to use it.
> If I do "LD_LIBRARY_PATH=path/to/libm octave", octave still seems to
> use the system libm. Or do I need to substitute the whole libc?

I use:

LD_PRELOAD=/path/to/new/libm.so octave

You can verify that the linker is substituting libm by:

LD_PRELOAD=/path/to/new/libm.so ldd /full/path/to/octave | grep libm


I'm trying to determine the accuracy to verify that the changes result
in improvements. So far I see some differences comparing the glibc
versions mostly around the singularities. However, Matlab's results
are way different. Spot checking a few points seems to place the
updated code closer to Mathematica's results--but is that
"authoritative"? Any suggestions on the best way to compute the
"reference" values? GMP? Mathematica?


--judd