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

[Jaroslav Hajek]

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

Brilliant, thanks.

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