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

[Judd Storrs]

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.
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? 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.


--judd