[SciPy-user] Installation on dual opteron ...

Arnd Baecker arnd.baecker at web.de
Wed Sep 28 01:30:16 CDT 2005


Hi,

On Tue, 27 Sep 2005, Robert Kern wrote:

> Stephen Walton wrote:
> > Arnd Baecker wrote:
> >
> >> scipy.test(10) gives:
> >>
> >> ======================================================================
> >> FAIL: check_round (scipy.special.basic.test_basic.test_round)
> >> ----------------------------------------------------------------------
> >> Traceback (most recent call last):
> >>  File
> >> "/scr/python3/lib/python2.4/site-packages/scipy/special/tests/test_basic.py",
> >>
> >> line 1789, in check_round
> >>    assert_array_equal(rnd,rndrl)
> >>  File "/scr/python3/lib/python2.4/site-packages/scipy_test/testing.py",
> >> line 715, in assert_array_equal
> >>    assert cond,\
> >> AssertionError:
> >> Arrays are not equal (mismatch 25.0%):
> >>        Array 1: [10 10 11 11]
> >>        Array 2: [10 10 10 11]
> >>
> > I'm getting this same error on my i386 systems using Absoft Fortran and
> > Fedora Core 4, so this problem is not unique to the Opteron
> > architecture.  I can't help with the X11 link problem, I'm afraid, as I
> > don't see it on my i386 systems.
> We've run into this several times before.

Indeed, I should have done a proper search
(but from home with modem ...;-( )

> The test is right according to
> the documentation.
>
> In [5]: round?
> Type:           ufunc
> String Form:    <ufunc 'round'>
> Namespace:      Interactive
> Docstring:
>     y=Returns the nearest integer to x as a double precision
>     floating point result.  If x ends in 0.5 exactly, the
>     nearest even integer is chosen.
>
> That's the round() from scipy.special which ought to be the one being
> called by this check_round(). You might want to add a "print round"
> statement to the check_round() method just to make sure that it is the
> ufunc from scipy.special and not the alias to around() from Numeric
> which follows Python's round-up-on-0.5 behavior.

It gives:  <ufunc 'round'>

Direct invocation gives
In [25]: scipy.special.round(10.5)
Out[25]: 11.0

Just to be sure:
In [26]: repr(scipy.special.round)
Out[26]: "<ufunc 'round'>"

So this is not the expected behaviour...

> The last time we came across it, I had Fernando check a C program that
> tries the underlying Cephes routine, and it gives the expected answer.

OK, I took the one from
  http://www.scipy.net/pipermail/scipy-user/2005-June/004577.html


This looks like the compiler matters

a) with gcc -v
Using built-in specs.
Target: x86_64-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,f95,java,ada --enable-checking
--with-gxx-include-dir=/usr/include/c++/4.0.2 --enable-java-awt=gtk
--disable-libjava-multilib --with-slibdir=/lib64 --with-system-zlib
--enable-shared --enable-__cxa_atexit --without-system-libunwind
--host=x86_64-suse-linux
Thread model: posix
gcc version 4.0.2 20050826 (prerelease) (SUSE Linux)


gcc round.c -lm
./a.out
10.4 -> 10
10.5 -> 11
10.6 -> 11
11.4 -> 11
11.5 -> 12
11.6 -> 12

So this result is different from the one you obtain(ed) on your Mac.

b) with gcc -v (the one which I thought I used for compiling scipy)
Reading specs from
/scr/python3/bin/../lib/gcc/x86_64-unknown-linux-gnu/3.4.4/specs
Configured with: ../gcc-3.4.4/configure --prefix=/scr/python3/
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --enable-languages=c,c++,f77,objc
Thread model: posix
gcc version 3.4.4

./a.out
10.4 -> 10
10.5 -> 10
10.6 -> 11
11.4 -> 11
11.5 -> 12
11.6 -> 12

Looks alright.

What I don't understand:
I am pretty sure, that I compiled scipy with gcc 3.4.4
(Is there a way to check this afterwards?).

If you have any further ideas what I could do so that
we can get rid of this problem, just let me know!

Best, and many thanks,

Arnd






More information about the SciPy-user mailing list