[Numpy-discussion] Re: Please chime in on proposed methods for arrays

Colin J. Williams cjw at sympatico.ca
Fri Mar 18 07:29:21 EST 2005


Travis Oliphant wrote:

> Joe Harrington wrote:
>
>> I'll start by saying something positive: I am very encouraged by all
>> the work that's going into resolving the small/big array split!
>>  
>>
> Thanks,  more-hands makes less work...
>
>
>> That said, I view a.Sin as a potentially devastating change, if
>> traditional functional notation is not guarranteed to be preserved
>> forever.
>>  
>>
>
> Hold on, everybody.  I'm the last person that would move from sin(x) 
> to x.Sin as a "requirement".   I don't believe this was ever 
> suggested.  I was just remembering that someone thought it would be 
> useful if x.sin() were allowed, and noticed that the PEP had not 
> mentioned that as a possibility.

My suggestion was that x.Sin be available as a method.  It was 
challenged as all the maths books use sin(x).  True, since the books in 
the main are dealing with scalar x.  Two things were suggested (1) with 
a method, one can drop the redundant parentheses, and (2) capitalize the 
first letter of the method to make it clear that the operation applies 
to the whole of an array structure and not just to a single value.

It was also pointed out that the Sin style focuses on order of 
evaluation and so the expression looks different than a nested 
expression.  Some, who prefer nesting can use the function.

As Konrad Hinsen has pointed out, this is implementation detail stuff 
but, I suggest, of some importance as it gives the face which is 
presented to the world.

>
> I'm inclined now to NOT add such computational methods and *require* 
> ufuncs to be called as is currently done.

Presumably, nothing would be done to inhibit the use of properties in 
sub-classes.

>
> It's interesting to see so many responses to something that in my mind 
> was not the big issue, and to hear very little about the 
> multidimensional indexing proposal.
>
My problem here is that I don't really understand just what the current 
proposal envisages.  Some example would help.

(1) How does a[..., 3] differ from a[:,3]?

(2) How does this differ from numaray's take/put?

    Setting array elements using advanced indexing will be similar
          to getting.  The object used for setting will be force-cast to
          the array's type if needed.  This type must be "broadcastable"
          to the required shape specified by the indexing, where
          "broadcastable" is more fully explained below.  Alternatively,
          the object can be an array iterator.  This will repeatedly
          iterate over the object until the desired elements are set.  The
          shape of X is never changed.

(3)  is this a typo?
              selects a 1-d array filled with the elements of A??
              corresponding to the non-zero values of B.  The search
              order will be C-style (last-index varies the fastest).

(4) I can see value in nonZero(X) or even nonZero(X, tolerance), which
     presumably delivers an Array with a Boolean element type, but
     I wonder about the need for nonZero with a Boolean array as an
     argument.  Shouldn't X[B] do the job?

(5) Mention is made of indexing objects.  These are Arrays of some sort?

Colin W.
    





More information about the NumPy-Discussion mailing list