[Numpy-discussion] What is Numeric3 anyway?

Travis Oliphant oliphant at ee.byu.edu
Sat Mar 26 22:43:34 EST 2005

Michiel Jan Laurens de Hoon wrote:

> I'm a bit confused about where Numeric3 is heading. Originally, the 
> idea was that Numeric3 should go in Python core. Are we still aiming 
> for that? More recently, another goal was to integrate Numeric and 
> numarray, which I fully support. 

I would prefer to re-integrate the numarray people "back" into the 
Numeric community, by adding the features to Numeric that they need.

> However, from looking at the Numeric3 source code, and from looking at 
> the errors found by Arnd

These errors are all due to the fact that umath functions are not 
available yet.   Please don't judge too hastily.  At this point, I'm 
really just looking for people who are going to pitch in and help with 
coding or to offer suggestions about where the code base should go.   I 
have done this completely in the open as best I can. I have no other 
"hidden" plans. 

All of the scalar types will get their math from the umath functions 
too.  So, of course they don't work either yet (except for those few 
that inherit from the basic Python types).  

> it looks like that Numeric3 is a complete rewrite of Numeric. 

I really don't understand how you can make this claim.  All I've done is 
add significantly to Numeric's code base and re-inserted some 
code-generators (code-generators are critical for maintainability --- in 
answer to your previous question). 

> This goes well beyond integrating Numeric and numarray. Now I realize 
> that sometimes it is necessary to rethink and rewrite some code. 
> However, Numerical Python has served us very well over the years, and 
> I'm worried that rewriting the whole thing will break more than it 
> fixes. So where is Numeric3 going?

You really need to justify this idea you are creating that I am 
"re-writing the whole thing"  I disagree wholeheartedly with your 
assessment.   Certain changes were made to accomodate numarray 
features,  new types were added, indexing was enhanced.    When 
possible, I've deferred to Numeric's behavior. 

But, you can't bring two groups back to a common array type by not 
changing the array type at all.

Numeric3 is going wherever the community takes it.  It is completely open.

Going into the Python core is going to have to wait until things settle 
down in our own community.      It's not totally abandoned just put on 
hold (again).  That was the decision thought best by Guido, Perry, 
myself, and Paul at our lunch together.

We thought it best to instead suggest interoperability strategies. 

Numeric3 is NOT a re-write of Numeric.  I've re-used a great deal of the 
Numeric code.  The infrastructure is exactly the same.   I started the 
project from the Numeric code base.  I've just added a great deal more 
following the discussions on this list.    At worst, I've just expanded 
quite a few things and moved a lot into C.   Little incompatibilties are 
just a sign of alpha code not a "direction."

Some have thought that zeros returning ints was a bug in the past which 
is why the change occured.  But, it is an easy change,  and I tend to 
agree that it should stay returning the Numeric default of Intp.

>> In [1]:from ndarray import *
>> In [2]:x=arange(10.0)
>> In [3]:scalar=x[3]
>> In [4]:print scalar+1
>> --------------------------------------------------------------------------- 
>> exceptions.TypeError                 Traceback (most recent call last)
>> TypeError: unsupported operand type(s) for +: 'double_arrtype' and 'int'
>> In [5]:print type(scalar)
>> <type 'double_arrtype'>

All scalar types by default will do math operations as rank-0 arrays 
(which haven't been brought back in yet).   That is why the error.   I 
believe that right now I am inheriting first from the Generic Scalar 
Type instead of the double type (so it will use Scalar Arithmetic 
first).   Later, special methods for each scalar type could be used (for 

>> A couple of things seem to be a bit unusual, e.g.:
>> In [9]:x=arange(10.0)
>> In [10]:x
>> Out[10]:array([0.0, 1.0, 2.0, 3.0, 4.0, 5.0, 6.0, 7.0, 8.0, 9.0], 'd')
>> In [11]:x.argmax()
>> --------------------------------------------------------------------------- 
>> exceptions.TypeError                                 Traceback (most
>> recent call last)
This is an error.  I'll look into it.  Notice all method calls that take 
an axis argument are defaulting to None (which means ravel the whole 
array).    The function calls won't change for backward compatibility.

>> /home/scratch/abaecker/INSTALL_SOFT/TEST_NUMERIC3/<console>
>> TypeError: function takes exactly 1 argument (0 given)
>> In [12]:x.argmax(None)
>> Out[12]:9
>> In [13]:t=x.argmax(None)
>> In [14]:type(t)
>> Out[14]:<type 'int_arrtype'>
>> So argmax also returns an array type, but I would
>> have really thought that this is an integer index?!
Remember, array operations always return array scalars!

>> Also a couple of attributes (E.g. x.sum() are not yet
>> implemented) or lack documention (I know this comes last ;-).
Hmm.  x.sum should be there.   Believe me, it was a bit of a pain to 
convert all the Python code to C.  Have to check this.


More information about the NumPy-Discussion mailing list