[SciPy-dev] Now new svn of numpy is ready
arnd.baecker at web.de
Thu Jan 5 01:15:00 CST 2006
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
> 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
> 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()`?
More information about the Scipy-dev