[SciPy-dev] Accessible SciPy (ASP) project

eric jones eric at enthought.com
Tue Oct 19 14:55:41 CDT 2004


Hey Alan,

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
>direction.)
>  
>
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.))
 >>> a/0.
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). 

thanks,
eric

>I intend that claim to be too obvious to
>require justification; is it?
>
>Cheers,
>Alan Isaac
>
>
>
>_______________________________________________
>Scipy-dev mailing list
>Scipy-dev at scipy.net
>http://www.scipy.net/mailman/listinfo/scipy-dev
>  
>




More information about the Scipy-dev mailing list