[Numpy-discussion] packaging scipy (was Re: Simple financial functions for NumPy)
Mon Apr 7 17:49:35 CDT 2008
On Mon, Apr 7, 2008 at 4:03 PM, Perry Greenfield <firstname.lastname@example.org> wrote:
> On Apr 7, 2008, at 5:54 PM, Brian Granger wrote:
> > The only problem is that if we keep adding things to numpy that could
> > be in scipy, it will _never_ be clear to users where they can expect
> > to find things. It is already bad enough. How do I explain to a
> > user/student/scientist that ffts and linear algebra are in numpy, but
> > that integration and interpolation are in scipy. That doesn't make
> > any sense to them. Oh but wait, linear algebra and ffts are also in
> > scipy! Random numbers - take a guess - wrong, they are in numpy.
> > As far as I am concerned, financial fucntions are completely outside
> > the conceptual scope that numpy has established = arrays, fft, linalg,
> > random. In fact, they are far outside it. Simply putting things into
> > numpy because of convenience (numpy is easier to install) only
> > encourages people to never install or use scipy. If scipy that much
> > of a pain to install and use - we should spend our time improving
> > scipy.
> > Cheers,
> > Brian
> To me, the biggest characteristic difference between the two is the
> ease of installation. If installation weren't an issue, I would tell
> everyone to use scipy and then the confusion would be ended. But the
> installation issue is not trivial one to solve (if it were, we'd
> already be there).
I definitely understand the installation issue. Is the main thing
people run into the fortran compiler, BLAS and LAPACK? To me it seems
like the scipy install is pretty simple these days. Do we need better
Deep down I so wish we could ditch fortran! In almost all cases I
know of projects that have fortran involved are the worse for it.
> But a nice ideal is that the numpy namespace should map directly into
> scipy's so that if I expected numpy.xxx to work, the scipy.xxx should
> also work. That would lessen the confusion of finding things. If it
> isn't in numpy, it's in scipy. But otherwise one is a subset of the
> other. (I say this from complete ignorance, I'm not sure what
> prevents this, and there may be very good reasons why this can't be
I think this is a very good idea to follow, at least for things that
do happen to in both places. But, I still don't think it we should
have many things that are in both places.
> Numpy-discussion mailing list
More information about the Numpy-discussion