On Apr 7, 2005, at 10:06, David M. Cooke wrote:

...

Hmm, I had misread your previous code. Here it is again, made more specific, and I'll assume this function lives in the ndarray package (as there is more than one package that defines ufuncs)

At the moment, there is one in Numeric and one in numarray. The Python API of both is nearly or fully identical.

...

The thing is obj.__ufunc__ must understand about the *particular* object cos: the ndarray one. I was thinking more along the lines of

No, it must only know the interface. In most cases, it would do something like

class MyArray: def __ufunc__(self, ufunc): return MyArray(apply(ufunc, self.data))

Exactly ! I see this as a very common use (masked arrays and all the other examples could live with that). Or more precisely (just to be explicity as the previous MyArray example is the simplest (purest) one), class MyArray: def __ufunc__(self, ufunc): metadata= process(self.metadata, ufunc) data = apply(ufunc, self.data) return MyArray(data, metadata) Or variations on this same theme. BTW, looking at Numeric3, the presence of a __mask_array__ in the array protocol looks like we want to add a specific case of "augmented array" to the core protocol. Hmmm, rather prefer to build a more generic mechanism as well as a clean interface for interacting with "augmented array".

...

obj.__ufunc__('cos'), where the name is passed instead.

That's also an interesting option. It would require the implementing class to choose an appropriate function from an appropriate module. Alternatively, it would work if ufuncs were also accessible as methods on array objects.

Why not have the ability to ask the name of an ufunc to be able to dispatch on it ?

...

For binary ufuncs, you could use (with arguments obj1 and obj2), obj1.__ufunc__('add', obj2)

Except that it would perhaps be better to have a different method, as otherwise nearly every implementation would have to start with a condition test to distinguish unary from binary ufuncs.

...

Output argument (obj3): obj1.__ufunc__('add', obj2, obj3) Special methods: obj1.__ufunc__('add.reduce') obj1.__ufunc__('add.accumulate') obj1.__ufunc__('add.outer', obj2)

Basically, special methods are just another ufunc. This suggests that add.outer should optionally take an output argument...

But they are not just another ufunc, because a standard unary ufunc always returns an array of the same shape as its argument.

I'd probably prefer a few explicit methods:

object.__unary__(cos) object.__binary__(add, other) object.__binary_reduce__(add)

What about : object.__unary__(cos, mode = "reduce") object.__binary__(cos, other, mode = "reduce") or object.__unary__(cos.reduce) object.__binary__(cos.apply, other) or object.__binary__(cos.__call__, other) with the ability to ask to the first argument its type (with cos.mode or cos.reduce.mode ...) However, for binary operations, how it the call dispatched if one of the operand is of a type while the other is another type ? This problem is related to multimethods http://www.artima.com/weblogs/viewpost.jsp?thread=101605 ======================================================= This message is confidential. It may also be privileged or otherwise protected by work product immunity or other legal rules. If you have received it by mistake please let us know by reply and then delete it from your system; you should not copy it or disclose its contents to anyone. All messages sent to and from Electrabel may be monitored to ensure compliance with internal policies and to protect our business. Emails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. Anyone who communicates with us by email is taken to accept these risks. http://www.electrabel.be/homepage/general/disclaimer_EN.asp =======================================================