help-octave
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Juergen Rose
Subject: Re: Same .m file: different results with different versions of Octave
Date: Mon, 19 Apr 2010 07:09:17 +0200

Am Sonntag, den 18.04.2010, 16:28 -0400 schrieb Judd Storrs:
> On Sun, Apr 18, 2010 at 3:28 PM, Jaroslav Hajek <address@hidden> wrote:
> > 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
> 
> I don't agree that NaN is an appropriate approximation of 1. But
> what's even the point of stating this? Not to even bother to try and
> fix it upstream because you think it's good enough already?
> 
> > 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.
> 
> So, you like octave because it serves you garbage faster? The
> traditional approach to optimization starts with working code and
> attempts to make it faster. Demanding that correct code be as fast as
> broken code is somewhat a novel stance. Frankly, I'm not confident
> that numerical accuracy is important upstream. The C standard
> libraries have always placed performance as the priority over
> numerical accuracy and directed people that demand accuracy to
> specialized libraries (such as GSL). Perhaps the "correct"
> implementation is *always* going to be slower.
> 
> > And I've checked that my gcc 4.3.3 implements complex tanh simply as 
> > sinh/cosh.
> > perhaps an optimization is interfering here?
> 
> Picking up compiler optimization problems is why octave needs a
> numerical accuracy battery (but I get the impression it is
> discouraged--hear no failures, see no failures, blame others for
> failures). What do you get for the tanh bug that was fixed upstream 5
> years ago:
> 
> > tanh(complex(0,pi/2))
> > tanh(complex(0,3*pi/2))
> 
> On my machine the fix (if it ever existed) is gone:
> 
> octave> tanh(complex(0,pi/2))
> ans = 0.0000e+00 + 1.6332e+16i
> octave> tanh(complex(0,3*pi/2))
> ans = -0.0000e+00 + 5.4439e+15i
> 

I get the same issues with gentoo on old AMD/K9:
address@hidden:/usr/local/portage/sci-libs/gdal(73)# octave
GNU Octave, version 3.2.4
...
octave:1> arg = 710*(1+i)
arg =  710 + 710i
octave:2> sinh(arg) / cosh(arg)
ans =  1
octave:3> tanh(arg)
ans = NaN
octave:4> tanh(complex(0,pi/2))
ans = 0.0000e+00 + 1.6332e+16i
octave:5> tanh(complex(0,3*pi/2))
ans = -0.0000e+00 + 5.4439e+15i
octave:6> 
address@hidden:/usr/local/portage/sci-libs/gdal(74)# qlist -Iv gcc glibc
sys-devel/gcc-4.4.3
sys-devel/gcc-config-1.4.1
sys-libs/glibc-2.11-r1
x11-misc/gccmakedep-1.0.2
address@hidden:/usr/local/portage/sci-libs/gdal(75)# uname -a
Linux grizzly 2.6.33 #1 PREEMPT Mon Apr 5 18:09:56 CEST 2010 x86_64 AMD
Athlon(tm) 64 Processor 3200+ AuthenticAMD GNU/Linux

at a new Intel-I9:

address@hidden:/home/rose(2)$ octave
GNU Octave, version 3.2.4
...
octave:1> arg = 710*(1+i)
arg =  710 + 710i
octave:2> sinh(arg) / cosh(arg)
ans =  1
octave:3> tanh(arg)
ans = NaN
octave:4> tanh(complex(0,pi/2))
ans = 0.0000e+00 + 1.6332e+16i
octave:5> tanh(complex(0,3*pi/2))
ans = -0.0000e+00 + 5.4439e+15i
octave:6> 
address@hidden:/home/rose(4)$ qlist qlist -Iv gcc glibc
sys-devel/gcc-4.4.3
sys-devel/gcc-config-1.4.1
sys-libs/glibc-2.11-r1
x11-misc/gccmakedep-1.0.2
address@hidden:/home/rose(5)$ uname -a
Linux orca 2.6.33-gentoo #1 SMP Wed Mar 10 19:50:01 CET 2010 x86_64
Intel(R) Xeon(R) CPU W3520 @ 2.67GHz GenuineIntel GNU/Linux

With a mobile pentium I get a litte bit other results, which aren ot
better:

address@hidden:/usr/src/digitemp-3.6.0(50)# octave
GNU Octave, version 3.2.4
...
octave:1> arg = 710*(1+i)
arg =  710 + 710i
octave:2> sinh(arg)/cosh(arg)
ans =  1
octave:3> tanh(arg)
ans = 0
octave:4> tanh(complex(0,pi/2))
ans = 0.0000e+00 + 1.6332e+16i
octave:5> tanh(complex(0,3*pi/2))
ans = -0.0000e+00 + 5.4439e+15i
octave:6> 
address@hidden:/usr/src/digitemp-3.6.0(51)# qlist -Iv gcc glibc
sys-devel/gcc-3.4.6-r2
sys-devel/gcc-4.4.3
sys-devel/gcc-config-1.4.1
sys-libs/glibc-2.11-r1
x11-misc/gccmakedep-1.0.2
address@hidden:/usr/src/digitemp-3.6.0(52)# gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured
with: /var/tmp/portage/sys-devel/gcc-4.4.3/work/gcc-4.4.3/configure
--prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.4.3
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.4.3/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.3
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.3/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.3/info
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.4.3/include/g
++-v4 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu
--disable-altivec --disable-fixed-point --without-ppl --without-cloog
--enable-nls --without-included-gettext --with-system-zlib
--disable-checking --disable-werror --enable-secureplt
--disable-multilib --enable-libmudflap --disable-libssp --enable-libgomp
--enable-cld
--with-python-dir=/share/gcc-data/i686-pc-linux-gnu/4.4.3/python
--enable-java-awt=gtk --with-arch=i686 --enable-languages=c,c
++,java,objc,fortran --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.4.3
p1.0'
Thread model: posix
gcc version 4.4.3 (Gentoo 4.4.3 p1.0) 
address@hidden:/usr/src/digitemp-3.6.0(53)# uname -a
Linux thinkpad 2.6.32-gentoo-r3 #1 PREEMPT Sun Jan 31 23:18:15 CET 2010
i686 Intel(R) Pentium(R) M processor 2.00GHz GenuineIntel GNU/Linux

With a probability of 99 % I used gcc-4.4.3 to compile octave.



> Why didn't anyone know that this regression had recurred?
> 
> > Let me reverse your question somewhat: What's so special about GSL
> > that makes you think a regression in GSL is much less probable?
> 
> Ugh. Really?
> 
> 
> --judd
> _______________________________________________
> Help-octave mailing list
> address@hidden
> https://www-old.cae.wisc.edu/mailman/listinfo/help-octave




reply via email to

[Prev in Thread] Current Thread [Next in Thread]