[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