[Numpy-discussion] Simplifying array()

Colin J. Williams cjw at sympatico.ca
Thu Jan 13 16:45:04 EST 2005


Todd Miller wrote:

>On Thu, 2005-01-13 at 10:26 -0500, Colin J. Williams wrote:
>  
>
>>Todd Miller wrote:
>>
>>    
>>
>>>Someone (way to go Rory!) recently posted a patch (woohoo!) for
>>>numarray which I think bears a little discussion since it involves
>>>the re-write of a fundamental numarray function: array().
>>>The patch fixes a number of bugs and deconvolutes the logic of array().
>>>
>>>The patch is here if you want to look at it yourself:
>>>
>>>http://sourceforge.net/tracker/?atid=450449&group_id=1369&func=browse
>>>
>>>One item I thought needed some discussion was the removal of two
>>>features:
>>>
>>> 
>>>
>>>      
>>>
>>>> * array() does too much. E.g., handling file/memory instances for
>>>>   'sequence'. There's fromfile for the former, and users needing
>>>>   the latter functionality should be clued up enough to
>>>>   instantiate NumArray directly.
>>>>   
>>>>
>>>>        
>>>>
>>>I agree with this myself.  Does anyone care if they will no longer be
>>>able to construct an array from a file or buffer object using array()
>>>rather than fromfile() or NumArray(), respectively?  Is a deprecation
>>>process necessary to remove them? 
>>> 
>>>
>>>      
>>>
>>I would suggest deprecation on the way to removal.  For the newcomer, 
>>who is not yet "clued up"
>>some advice on the instantiation of NumArray would help.
>>    
>>
>
>That's fair.  The docstring for NumArray needs beefing up along the same
>lines as Rory's work on array().  
>
and, I would suggest, the documentation.

>I initially liked Florian's idea of
>frombuffer() but since I can't think of how it's not identical to
>NumArray(),  I'm not sure there's any point.
>
>  
>
>>Rory leaves in type and typecode.  It would be good to eliminate this 
>>apparent overlap.  Why not
>>deprecate and then drop type?  
>>    
>>
>
>Some people like type.  I don't want to touch this.
>  
>
The basic suggestion was to drop one or the other, since one is an _nt 
entry and either an instance of a function while the other is a string.  
I recognize that "type" has become accepted in the numarray community 
but the same word is used by Python for a utility function.

>  
>
>>It would be good to clarify the acceptable content of a sequence.  A 
>>list, perhaps with sublists, of
>>numbers is clear enough but what about a sequence of NumArray instances 
>>or even a sequence
>>of numbers, mixed with NumArray instances?
>>    
>>
>
>The patch has a new docstring which spells out the array() construction
>algorithm.  Lists of arrays would be seen as "numerical sequences".
>
>  
>
>>Is the function asarray redundant?
>>    
>>
>
>Yes,  but it's clear and also needed for backward compatibility with
>Numeric.  Besides, it's not just redundant,  it's an idiom...
>  
>
*asarray*( 	seq, type=None, typecode=None)

This function converts scalars, lists and tuples to a numarray, when 
possible. It passes numarrays through, making copies only to convert 
types. In any other case a TypeError is raised.

*astype*( 	type)

  The astype method returns a copy of the array converted to the 
specified type. As with any copy, the new array is aligned, contiguous, 
and in native machine byte order. If the specified type is the same as 
current type, a copy is /still/ made.


*array*( 	sequence=None, typecode=None, copy=1, savespace=0, type=None, 
shape=None)


It seems that the function array could be used in place of either the 
function asarray or  the method astype:

     >>> import numarray.numerictypes as _nt
     >>> import numarray.numarraycore as _n
     >>> a= _n.array([1, 2])
     >>> a
    array([1, 2])
     >>> a._type
    Int32
     >>> b= a.astype(_nt.Float64)
     >>> b._type
    Float64
     >>> a._type
    Int32
     >>> c= _n.array(seq= a, type= _nt.Float64)
    Traceback (most recent call last):
      File "<stdin>", line 1, in ?
    TypeError: array() got an unexpected keyword argument 'seq'
     >>> c= _n.array(a, type= _nt.Float64)
     >>> c._type
    Float64
     >>>

>  
>
>>I suggest that the copy parameter be of the BoolType.  This probably has 
>>no practical impact but
>>it is consistent with current Python usage and makes it clear that this 
>>is a Yes/No parameter,
>>rather than specifying a number of copies.
>>    
>>
>
>Fair enough.  Backward compatibility dictates not *requiring* a bool,
>but using it as a default is fine.
>
>
>  
>
Colin W.




More information about the NumPy-Discussion mailing list