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

[Jaroslav Hajek]

On Sun, Apr 18, 2010 at 8:26 PM, Judd Storrs <address@hidden> wrote:
> On Sun, Apr 18, 2010 at 1:22 PM, John W. Eaton <address@hidden> wrote:
>> I think it is beyond the scope of the Octave project to fix bugs in
>> standard library functions.  So the right place to report the problem
>> is to the maintainers of the C and C++ libraries.
>
> I agree. But I don't think correct results are beyond the scope of
> octave. So many platforms may be broken in unique ways--and yet I
> don't think I'm alone with the expectation that octave will work.

Octave is a system for *numerical* computations. The results of its
computations are, in general, approximations. The fact that some
approximations are not accurate enough for your purposes does not
necessarily mean Octave doesn't work. It works well for me (in this
case at least).

Btw, it may be just an issue with the complex division. I see this:

octave:1> arg = 710*(1+i)
arg =  710 + 710i
octave:2> sinh(arg) / cosh(arg)
ans =  1
octave:3> tanh(arg)
ans = NaN

And I've checked that my gcc 4.3.3 implements complex tanh simply as sinh/cosh.
perhaps an optimization is interfering here?

> FreeBSD's doesn't seem to work either. Perhaps that means that MacOS
> doesn't work either. Thankfully Windows seems to get this right (in
> this case).
>
> When numerical accuracy/correctness matters, use Windows?
>
>> Or, if you think it
>> is worth making temporary workaround fixes that could appear sooner
>> that fixes in released versions of glibc/libstdc++ or your proprietary
>> vendor's corresponding libraries, then maybe gnulib is the right place
>> for doing that. But so far, I think gnulib is focused on the C
>> library functions and tanh of complex values in Octave uses the
>> std::complex class from the standard C++ library, so it might take
>> some effort to add fixes for standard C++ library defects to gnulib.
>
> I agree that in a purely ideal world you would fix the compilers and
> support libraries. However, it seems that problems are widespread and
> even when fixes are made to the standard libraries they disappear. For
> example, the bug in glibc's implementation of tanh (the debian bug
> report leading to the glibc bug report attributes the test code to
> you, btw) was apparently fixed in 2005. It's not fixed now 2010.
> Either it wasn't actually fixed or it has now regressed or perhaps
> we're still waiting for a released version with the fix five years
> later.
>
> What's so special about the C/C++ standard libraries numerics when
> we've got a high-quality free numerics library? Would anyone be
> shocked if GSL was a dependency of octave? Is there some problem with
> GSL that makes its use unacceptable or why we should avoid it?

I would expect a performance penalty. I do not consider the issue
serious enough to justify an arbitrary performance penalty, so a
proposal should be first measured before committed.
Also, last time I checked, GSL essentially only provided double
precision complex math (although there was a float complex type),
which is another drawback.

Let me reverse your question somewhat: What's so special about GSL
that makes you think a regression in GSL is much less probable? And
why can't the same be done for glibc/libstdc++?

> From
> octave's point of view, if the goal is to punt the problem why not
> punt it to numerical people? Let the GSL maintainers worry about
> whether they want to use gnulib to port the numerics.
>



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