[SciPy-dev] Some concerns on Scipy development

Jochen Küpper jochen at unc.edu
Tue Mar 26 13:38:28 CST 2002

Hash: SHA1

On Tue, 26 Mar 2002 11:42:47 -0500 (EST) Travis Oliphant wrote:

>> To my mind there is a big "problem" with using scipy currently: It's
>> in too much flux.  While there is great progress and that is really
>> appreciated in view of a great product at some later time, it makes it
>> hard to use for now.  (So that I decided not to put any "scipy"-effort
>> into code I write for now.)

Travis> The biggest problems was with linalg, and it was related to the fact that
Travis> Pearu changed f2py for the better, but did so withouth changing the
Travis> interface to linalg (who can blame him we all do this in our "spare"
Travis> time).

I have not and will not blame anybody.  The worst thing I would do is
to ignore it. (And that shouldn't bother you too much.)

Travis> I disagree with this.  I've been using the current CVS copy of SciPy
Travis> regularly for my work and my teaching and had no real problem until this
Travis> linalg thing came up.

Well, I have been following the scipy development for a while and have
tried to build scipy fairly regularly.  And since there are no
"releases" cvs is the only way to follow it's progress.  Sometimes it
builds, soemtimes it doesn't.  Then you have to see whether it works.
(And more often than not it hasn't worked for me.)  Initially I tried
to dig into the problems ("long" ago), but lately I am just waiting
for a new release.

Then there are these issues with ATLAS.  We have a full ATLAS named
libblas.a in a path where every linker finds it, not so scipy.  It
isn't even happy with liblas.a, it needs all these atlas, cblas,
f77blas stuff.

Travis> Regarding the umbrella verses modules approach.  SciPy is an
Travis> umbrella package.  I used to distribute lots of modules
Travis> separately.  I'm not going back to that approach.  For me it's
Travis> too much trouble to make sure they work together.  SciPy
Travis> ensures that they do work together.

I can see this.  I am actually using quite some code written by you

But I have to write code now that works.  I have just tried to use
scipy a few days ago.  All the sudden I had wierd errors where 
  "array / scalar"
wouldn't work.  Reproducing it in a small example of course didn't
work either, so I just skipped scipy again.

Yep, I should probably spend some more time to figure out what's going
on and send a bug-report, but I am sorry I don't have the time currently.

Travis> If others want to grab pieces of SciPy and make them available
Travis> cleanly, then they naturally have that right.

Sure.  I actually have some of them.  And I really just see them as a
interim solution up to the time scipy is more nature -- whenever that

Travis> I won't be upset if other people make them available, but I
Travis> doubt I'll spend much time worrying about it.  Sorry.  I'd
Travis> like to be helpful, but I've just got to draw the line
Travis> somewhere.

Of course.  I can just support that.  Put your time into scipy, I'd
seriously say.

Travis> Why do you think that.  How "far" is it for you.  What's
Travis> missing.  

Stability.  Portability, in a second step.  Documentation.

Functionality? None for now.

Travis> With the linalg fixes and the "stats" fixes it's a lot farther
Travis> than you think.

Maybe it is.

Travis> What packages are people so opposed to that they don't want to
Travis> install all of SciPy.  I've never heard anybody discuss that.

I have no problems installing all of scipy, besides having problems
with the installation process itself.  Some problems are mentioned

- -- 
Einigkeit und Recht und Freiheit                http://www.Jochen-Kuepper.de
    Liberté, Égalité, Fraternité                GnuPG key: 44BCCD8E
        Sex, drugs and rock-n-roll
Version: GnuPG v1.0.6-cygwin-fcn-1 (Cygwin)
Comment: Processed by Mailcrypt and GnuPG <http://www.gnupg.org/>


More information about the Scipy-dev mailing list