#9808: Upgrade numpy to 1.5.0 and scipy to 0.8
----------------------------------------------------------------------------------+
Reporter: maldun
| Owner: maldun
Type: task
| Status: needs_work
Priority: major
| Milestone: sage-4.6
Component: packages
| Keywords: numpy, scipy
Author: Stefan Reiterer, Francois Bissey, John Palmieri, David Kirkby
| Upstream: Fixed upstream, but not in a stable release.
Reviewer: Karl-Dieter Crisman, David Kirkby, Leif Leonhardy, Francois
Bissey | Merged:
Work_issues:
|
----------------------------------------------------------------------------------+
Comment(by drkirkby):
Replying to [comment:219 fbissey]:
> Back from snooze-land via morning teaching.
>
> I would have expected that the fortran settings in scipy and numpy would
have to match.
That seems not to the be case. It's probably a good idea if they do, but
it looks like setting FC in Numpy is enough. I've just verified with grep
by looking at the Numpy log that it only ever uses the GNU compiler when
compiling F90 code and does not attempt to use {{{/usr/bin/f90}}}
{{{
drkir...@hawk:~/new/sage-4.6.alpha2/spkg/logs$ grep f90 numpy-1.5.0.log |
grep bin
drkir...@hawk:~/new/sage-4.6.alpha2/spkg/logs$ grep f95 numpy-1.5.0.log |
grep bin
drkir...@hawk:~/new/sage-4.6.alpha2/spkg/logs$
}}}
It does not appear to have anything that's obviously using a Fortran 90
target, though it does compile files with the extension .f90.
> I am completely astonished that you had problems with scipy and not
numpy. In fact on Gentoo we currently have a bug open because numpy picks
up the intel fortran compiler when it shouldn't.
Have you reported that bug upstream to the Numpy developers? If so, do you
have the link handy? Do you have a link to the Gentoo bug? You could try
exporting F77, F90 and F95 in addition to FC and see if that fixes it. It
would be worth opening a bug report in Sage if this is affecting Sage too,
which I expect it will. I could try creating a file 'icc' on my Sun and
seeing if Numpy uses that, though since the Intel compiler does not run on
Solaris, there's less chance of that being an issue. Perhaps someone with
Linux can create a file {{{icc}}} that simply exits with 1.
{{{
#!/bin/sh
exit 1
}}}
and see if that screws up building Numpy. If so, it's a bug.
In fact, given the issues with Scipy and scipy_sandbox, it might be wise
we export all these variables in Numpy.
What puzzles me most is why it is now necessary do this in scipy_sandbox,
despite there have been no changes to the scipy_sandbox code at all! But
checking in the sage-4.6.1.alpha1 code, I see the f90 target is using
{{{sage_fortran}}} and not {{{/usr/bin/f90}}}.
{{{
drkir...@hawk:~/sage-4.6.alpha1/spkg/logs$ grep f90
scipy_sandbox-20071020.p5.log
Fortran f90 compiler: sage_fortran -Wall -fno-second-underscore -fPIC -O3
-funroll-loops
Fortran f90 compiler: sage_fortran -Wall -fno-second-underscore -fPIC -O3
-funroll-loops
}}}
Hence this Numpy or SciPy upgrade has needed some rather surprising
changes to be made to scipy_sandbox.
I know when you build gmp, mpfr will be build with the same compiler, as
the location of the compiler is actually stored in the gmp header files. I
thought Numpy/ScipPy might use some similar technique, but it appears not.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/9808#comment:229>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
