On Dec 13, 9:06 am, "Fernando Perez" <[EMAIL PROTECTED]> wrote:
> On Dec 13, 2007 12:51 AM, William Stein <[EMAIL PROTECTED]> wrote:
>
> [...]
Hello,
>
> > So basically, at no point were there any real non-documented bugs
> > or problems with numpy or scipy that we fixed. It was more that
> > installing those libraries and all they depend on *from scratch*
> > in the context of the constraints imposed by Sage had a steep
> > learning curve. But at the end it wasn't that anything was broken
> > in numpy/scipy, so there isn't anything to give back or upstream.
>
> > I just hope that Sage somehow ends up increasing the
> > number of people who are numpy/scipy users but don't
> > have time for much of a learning curve (and who won't use Debian
> > or the Enthought Python distribution for whatever reason).
>
> I see, your summary is very clear. And it makes complete sense: for
> Sage, you're trying to do something vastly harder than even a
> from-source scipy build, since you are giving your users a fully
> self-contained environment, fortran and all.
Well, the problem here is that we support more than one version of
Fortran. The main problem is that each Fortran implementation has its
own helper runtime library that are mutually incompatible. On top of
that even different releases can be incompatible and what is even
worst is when you start mixing runtime library and modules form
different Fortran compilers. I could tell you horror stories about
insane memory leaks and crashes by mixing g77 and Sun's f77 library,
but I will refrain myself from doing so. I used to joke, that if I
were given the choice between
(a) eternal peace and prosperity for mankind
(b) infinite personal power and wealth
(c) having the people responsible for designing Fortran run time
libraries and linker modes/modules beamed into space
I would choose (c) without having to think about it.
And it isn't feasible to build the Fortran compilers from scratch due
to size & time of the build. That way we would get rid of the problem
once and for all, but due to Apple's brain dead decision not to ship
any Fortran compiler with XCode we supply binary G95 since they are
vastly smaller than binary GFortrans (3mb vs. 21mb). There are also
Fortran binaries for Linux x86 and x86-64, while on Linux PPC as well
as Solaris it is assumed that a working Fortran compiler (usually
GFortran is present).
> And I know that's highly
> non-trivial, especially once ATLAS is in the picture.
We haven't really tried hard on OSX regarding the dynamic F77 wrapper
lib yet. Every time I attempted to spend time on ATLAS on OSX
something else came up. ATLAS will only be build on non-OSX for 2.9,
while the goal for 2.9.1 is to get it to also work on OSX.
Alternatively we still might go with the AccelerateFW on OSX,
especially if the performance difference is negligible. I think Josh
told me that numpy/scipy already use that on OSX, but GSL, LinBox and
R should be switched over in that case, too. I wrote the patch for
LinBox, so that one will be trivial to do, while the other probably
aren't much more effort.
> That Sage builds at all is a near-miracle, given its size and
> complexity. That it pretty much never (that I've tried) fails to do
> so, and that it works on so many platforms out of the box, is flat out
> incredible.
>
> Having said that, if you ever need a hand, I'm sure people on the
> numpy/scipy list would be glad to help. There are quite a few of the
> core numpy developers running OSX these days (including both Travis
> Oliphant and Robert Kern, who both use MBPros), so they might be able
> to give you some useful pointers.
Help is certainly appreciated, especially if the changes flow back to
the ATLAS codebase :)
> But I'm glad to hear that the problem wasn't lack of help available.
> Just one more nasty build nightmare :)
:)
> Cheers,
>
> f
Cheers,
Michael
--~--~---------~--~----~------------~-------~--~----~
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-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~----------~----~----~----~------~----~------~--~---
