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

[Thomas Weber]

On Sun, Apr 18, 2010 at 07:39:32PM -0400, Judd Storrs wrote:
> On Sun, Apr 18, 2010 at 5:33 PM, Thomas Weber
> <address@hidden> wrote:
> > What makes you think it's not fixed? On my system, the code works as
> > expected. Did you compile the upstream libc yourself? Have you verified
> > that you are actually running GNU libc and not eglibc?
> 
> That's an interesting idea. No, I didn't compile the upstream libc. I
> wasn't really anticipating that a bug that was fixed in 2005 and
> included in glibc-2.3 would need a bleeding-edge compile in 2010, but
> sure, I can do that. I have now attempted to compile the latest GNU
> glibc from the git repository, but it looks like I'm my compiler can't
> handle some of the inlines so I'll probably have to go update that,
> too.
> 
> What version of libc are you using?

eglibc 2.10 and 2.11, both from Debian (the latter one in experimental).


> Based on what I've read online, I suspect the one installed on my
> computers (lenny, karmic and lucid--all x86_64) is eglibc. 
No, Lenny should have GNU libc.

> All of these computers have this problem. Is there an easy way to
> determine whether eglibc or glibc is used? 
As they should be both source- and binary compatible, there's probably
no easy way; you might want to check whether you have a file like
/usr/include/gnu/option-groups.h; I think (but am not sure) that option
groups are only in eglibc.

> I can say that > gnu_get_libc_version() reports:
> 
> lenny: libc version 2.7
> karmic: libc version 2.10.1
> lucid: libc version 2.11.1
> 
> Do you think that compiling a new libc will fix the problem? Or is
> this a problem with how debian/ubuntu built the packages? I don't see
> any source code differences between the glibc and eglibc versions of
> math/s_ctanh.c, math/s_ctanhf.c, math/s_ctanhl.c. None of those files
> seem to have been touched since 2005 according to the repositories
> which is why I question whether it was ever fixed in the first place.
> The bug tracker never showed that tanh() was fixed, just an annotation
> that something was done "upstream", which I interpret as FDLIBM and
> then the bug was closed. So I don't see any verification that the bug
> was ever fixed.

With the file testcoth.cc from
https://bugzilla.redhat.com/show_bug.cgi?id=160759, 
I get the following results (Debian unstable => eglibc 2.10):
x = (0,1.5708)
sinh(x) = (0,1)
cosh(x) = (4.48966e-11,0)
sinh(x)/cosh(x) = (0,2.22734e+10)
tanh(x) = (0,2.22734e+10)
cosh(x)/sin(x) = (0,-4.48966e-11)
1/tanh(x) = (0,-4.48966e-11)

These are the expected results from the bug report. This doesn't answer
the question abouth the bug with tanh(50000 + 50000I), though.

        Thomas