[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
- Re: Same .m file: different results with different versions of Octave, (continued)
- Re: Same .m file: different results with different versions of Octave, John W. Eaton, 2010/04/18
- Re: Same .m file: different results with different versions of Octave, Judd Storrs, 2010/04/18
- Re: Same .m file: different results with different versions of Octave, John W. Eaton, 2010/04/18
- Re: Same .m file: different results with different versions of Octave, Judd Storrs, 2010/04/18
- Re: Same .m file: different results with different versions of Octave, Jaroslav Hajek, 2010/04/18
- Re: Same .m file: different results with different versions of Octave, Judd Storrs, 2010/04/18
- Re: Same .m file: different results with different versions of Octave,
Juergen Rose <=
- Re: Same .m file: different results with different versions of Octave, Jaroslav Hajek, 2010/04/19
- Re: Same .m file: different results with different versions of Octave, Søren Hauberg, 2010/04/19
- Re: Same .m file: different results with different versions of Octave, Judd Storrs, 2010/04/19
- Re: Same .m file: different results with different versions of Octave, Jaroslav Hajek, 2010/04/19
- Re: Same .m file: different results with different versions of Octave, Søren Hauberg, 2010/04/19
- Re: Same .m file: different results with different versions of Octave, Jaroslav Hajek, 2010/04/19
- Re: Same .m file: different results with different versions of Octave, Judd Storrs, 2010/04/19
- Re: Same .m file: different results with different versions of Octave, Judd Storrs, 2010/04/19
- Re: Same .m file: different results with different versions of Octave, Jaroslav Hajek, 2010/04/19
- Re: Same .m file: different results with different versions of Octave, Judd Storrs, 2010/04/19