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

[Stuart Edwards]

........ trying hard to follow this thread - but for what it's worth on OS X 
10.6.2 with Octave 3.2.2 I see:

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

hth

Stu


On Apr 18, 2010, at 3:28 PM, Jaroslav Hajek wrote:

> 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
> 
> _______________________________________________
> Help-octave mailing list
> address@hidden
> https://www-old.cae.wisc.edu/mailman/listinfo/help-octave