[SciPy-dev] Accessible SciPy (ASP) project
eric at enthought.com
Tue Oct 19 14:55:41 CDT 2004
Alan G Isaac wrote:
>On Tue, 19 Oct 2004, eric jones apparently wrote:
>>I'm sorry you don't like it.
>That is really not my objection, although
>of course everyone has preferences.
>If Numeric and numarray were to adopt the
>SciPy convention, I would be perfectly
>satisfied. (It seems hard to go that
There were long discussions about this when numarray was built.
>Or, if SciPy provided its own names and
>used its own convention, instead of
>over-riding Numeric (or numarray) names,
>I would also be happy. Especially if
>SciPy names were readily identifiable
>as such. (Of course, one can always
>be careful on one's own, but relying on
>users to be careful is generally a bad
>idea when it is avoidable.)
>The issue is consistency.
Yes. We both argue for that. It is just that you are for consistency
across libraries (a good thing). SciPy has chosen to rectify an
inconsistency (the axis argument) among functions within for numeric
computing (also a good thing). The disagreement is which consideration
trumps the other.
>Can you find me a SciPy user who never uses
>Numeric or numarray directly? Unless this
>is most of SciPy users, conflicting defaults
>for the same function names will eventually
>lead someone to make a terrible mistake.
I agree that the inconsistency is unfortunate. So are the other
inconsitencies with Numeric. For example, SciPy allows comparisons
between complex numbers by comparing the real part (like Matlab).
>>> from scipy import *
>>> a = array((1,2,3+3j))
>>> b = array((1,3,3+4j))
>>> a < b
array([0, 1, 0],'b')
It doesn't throw exceptions and stop computation for div-by-zero and
other floating point exceptions.
>>> a = array((-1.,0.,1.))
array([ -1.#INF0000e+000, -1.#IND0000e+000, 1.#INF0000e+000])
So there are other differences besides 'axis" arguments. They number is
small, but there are strong feelings about the benefit of each of the
ones that stayed.
The SciPy namespace includes everything from Numeric, and the intent is
that you would use one or the other in your application (either use
scipy for all imports, or use Numeric). Using them together indeed will
result in different behaviors and therefore is a potential problem. In
practice, this has not be a major issue at least for us. We just always
use SciPy for everything.
When Numarray was implemented by STSci, it used the same conventions
used in SciPy and chose to maintain backward compatibility with Numeric
in others. Experience with new users has led me to believe that the
SciPy "axis" approach is more intuitive and so I was disappointed in the
decisions to maintain backward compatiblity with Numeric in these
areas. But not terribly so. It hasn't presented major problems. So,
SciPy is destined to have a few different behaviors than either Numeric
or Numarray (which also behave differently than each other in places).
>I intend that claim to be too obvious to
>require justification; is it?
>Scipy-dev mailing list
>Scipy-dev at scipy.net
More information about the Scipy-dev