[SciPy-dev] Now new svn of numpy is ready

[Arnd Baecker]

On Wed, 4 Jan 2006, Fernando Perez wrote:

> Travis Oliphant wrote:
>
> > But these need to be there.  We need some way to update the functions in
> > numpy if scipy is installed (so that you  can always call the numpy
> > functions but get the scipy functions if they are there)...
>
> Mmh, I'm not sure I agree with this approach.  I think this may lead to
> surprising behavior, hard to find bugs, etc.  I really don't think that the
> presence of scipy should change the behavior of numpy's internals, esp. when
> we're advertising the dependency chain to be
>
>    	numpy < scipy
>
> Finding out that in reality, there's a hidden
>
>         |-> numpy   scipy--|
>         |                  |
>         |------------------|
>
> cycle kind of threw me for a loop :)
>
> I would argue that users should know whether they want to call scipy's
> libraries or numpy's, and be clearly aware of the differences.

Valid point (as your other one below)

> For example, publishing a benchmark based on code that uses numpy on one
> system may be misleading: you write
>
> from numpy import foo
> foo()
>
> and publish that it takes 0.1s to run.  Then somebody downloads your code,
> they run it and get significantly different results.  Still, you swear that's
> what you get.  It turns out the other user didn't have scipy installed, only
> numpy, but you had scipy on your system, and the difference in performance was
> being caused by this hidden overwriting.

I don't buy this argument about benchmarking, as numpy can be
installed with and without ATLAS (ACML/MKL/scsl/...).
Depending on this, very different results will show up.

> IMHO, we should follow here the whole 'explicit is better than implicit'
> thingie.  If people want to get the benefits of scipy, they should say so
> explicitly and use scipy.
>
> I can also see the flip side of the argument: installing scipy can give you a
> 'magical' performance boost in your numpy code, without having to rewrite
> anything.  But the more I write larger codes, the more I end up disliking
> hidden side-effects: in the long run, they always seem to cause more headaches
> than their apparent initial benefit.

So it boils down to a performance-vs-possible-side-effects issue.
Performance is good, side-effects are evil - what is better?

> Perhaps a compromise solution would be to have something like
>
> numpy.scipy_enable()
>
> which would trigger the overwriting.  At least this would force the users to
> make an explicit call, so they are aware of what's going on.  This would
> obviously be a no-op if scipy isn't present, nicely wrapping the 'import
> scipy' in a try/except (as it is today).

What about a `numpy.scipy_disable()`?

Best, Arnd