Re: [Numpy-discussion] Request for clarification from Travis
Yes, but it is directed at the interpreter, which will raise a TypeError if needed. But the interpreter doesn't know that some generic function might return NotImplemented and wouldn't know what to do if it did. What the user should see when they call something like right_shift(a,b) and it fails is an exception, they shouldn't have to check the return value Yes, you are right. So, the questions is how to handle this correctly. I think what you want is that subtypes of ndarray can override some ufuncs so that, for instance, right_shift() should interpret itself as a call to arg2.__rrshift__ if it exists, even if it isn't called through the interpreter friendly slot function . Is that correct? If so, I would rather have an explicit overload flag in the subtype so that the ufunc can easily do the right thing. So, how would this overload flag work and how would a subtype set it? Would this be a per-instance flag in the FLAGS field? I can't find __array_priority__ in your book, what exactly does it imply? The subtype with the largest priority wins in any decision about which subtype to create during operations involving more than one subtype (like adding a matrix to an array --- what should be returned?). -Travis ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Request for clarification from Travis
Hi Travis, On Thu, Jun 26, 2008 at 1:50 AM, Travis E. Oliphant [EMAIL PROTECTED] wrote: Yes, but it is directed at the interpreter, which will raise a TypeError if needed. But the interpreter doesn't know that some generic function might return NotImplemented and wouldn't know what to do if it did. What the user should see when they call something like right_shift(a,b) and it fails is an exception, they shouldn't have to check the return value Yes, you are right. So, the questions is how to handle this correctly. I think what you want is that subtypes of ndarray can override some ufuncs so that, for instance, right_shift() should interpret itself as a call to arg2.__rrshift__ if it exists, even if it isn't called through the interpreter friendly slot function . Is that correct? If so, I would rather have an explicit overload flag in the subtype so that the ufunc can easily do the right thing. So, how would this overload flag work and how would a subtype set it? Would this be a per-instance flag in the FLAGS field? It's been a few days, but my last thoughts were that ufunc_generic _call, or one of the other gateways, should play the role that the interpreter does for NotImplemented. How exactly it determines that some function is overridden I'm not sure. Subtypes could, for instance, have a method with the ufunc name, but we need to be sure we don't end up in an endless loop. I can't find __array_priority__ in your book, what exactly does it imply? The subtype with the largest priority wins in any decision about which subtype to create during operations involving more than one subtype (like adding a matrix to an array --- what should be returned?). So it has a numeric value? Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Request for clarification from Travis
So it has a numeric value? Yes, it's just a floating point number. It's not a very elegant thing, but it does allow some ability to specify an ordering. -Travis ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Request for clarification from Travis
Charles R Harris wrote:
Hi Travis,
Could you expand on your thinking concerning NotImplemented? The
relevant code is:
/*
* FAIL with NotImplemented if the other object has
* the __rop__ method and has __array_priority__ as
* an attribute (signalling it can handle ndarray's)
* and is not already an ndarray
*/
if ((arg_types[1] == PyArray_OBJECT) \
(loop-ufunc-nin==2) (loop-ufunc-nout == 1)) {
PyObject *_obj = PyTuple_GET_ITEM(args, 1);
if (!PyArray_CheckExact(_obj) \
PyObject_HasAttrString(_obj, __array_priority__) \
_has_reflected_op(_obj, loop-ufunc-name)) {
loop-notimplemented = 1;
return nargs;
}
}
And the check is made after the needed promotions have been determined
and stored in arg_types. Consequently if a type is promoted to an
object array, as happens for the shift operations with floating
scalars, the rest of the conditions will be checked and pass because
numpy scalar types aren't arrays. I wonder if that is what you
intended here?
I'm not sure, I don't understand what problem you are trying to solve.
The reason I ask is that this determination should be associated with
the standard slot functions when the call is made and I don't want to
worry about type promotions. Further, I wonder why you want this
return before the attempt to run the function with the current
arguments is made. So it would be very helpful if you could clarify
what you aim to achieve here.
This is to ensure that object arrays get a chance to run their own code
if they have the required right-hand special name (e.g. __radd__).
The problem is that NumPy is very aggressive and tries to handle
everything so if I let the code get past this point, it would run
successfully as an object array which is not what is necessarily wanted
-Travis
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Request for clarification from Travis
On Tue, Jun 24, 2008 at 12:46 PM, Travis E. Oliphant [EMAIL PROTECTED]
wrote:
Charles R Harris wrote:
Hi Travis,
Could you expand on your thinking concerning NotImplemented? The
relevant code is:
/*
* FAIL with NotImplemented if the other object has
* the __rop__ method and has __array_priority__ as
* an attribute (signalling it can handle ndarray's)
* and is not already an ndarray
*/
if ((arg_types[1] == PyArray_OBJECT) \
(loop-ufunc-nin==2) (loop-ufunc-nout == 1)) {
PyObject *_obj = PyTuple_GET_ITEM(args, 1);
if (!PyArray_CheckExact(_obj) \
PyObject_HasAttrString(_obj, __array_priority__) \
_has_reflected_op(_obj, loop-ufunc-name)) {
loop-notimplemented = 1;
return nargs;
}
}
And the check is made after the needed promotions have been determined
and stored in arg_types. Consequently if a type is promoted to an
object array, as happens for the shift operations with floating
scalars, the rest of the conditions will be checked and pass because
numpy scalar types aren't arrays. I wonder if that is what you
intended here?
I'm not sure, I don't understand what problem you are trying to solve.
1) NotImplemented is associated to specific types, hence the CHECKABLE flag
on the type.
2) It is a message to the python interpreter, not to the user.
3) It is associated with the slot functions of numeric types, not with
general functions.
When python encounters something like a + b, it looks at the CHECKABLE flag
on a. If set, it calls a.__add__ with b as is, not attempting to promote the
type. If that fails, a.__add__ returns NotImplemented, telling the
interpreter to do something, probably try the b.__radd__. If that fails it
raises an error.
If the *user* ever sees NotImplemented, it is a bug. Some of the numpy
ufuncs exhibit this bug and we should fix it.
The problem is that NumPy is very aggressive and tries to handle
everything so if I let the code get past this point, it would run
successfully as an object array which is not what is necessarily wanted
The problem is that numpy has a *bug*. I am trying to fix it and I want your
help figuring out how to do so while preserving the behavior you had in
mind. So if you could point out specific cases you were thinking of it would
help me with this.
Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Request for clarification from Travis
The problem is that numpy has a *bug*. I am trying to fix it and I want your help figuring out how to do so while preserving the behavior you had in mind. So if you could point out specific cases you were thinking of it would help me with this. This is a hack to support matrices and other subclasses of ndarray like masked arrays. -Travis ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Request for clarification from Travis
On Tue, Jun 24, 2008 at 1:41 PM, Travis E. Oliphant [EMAIL PROTECTED] wrote: The problem is that numpy has a *bug*. I am trying to fix it and I want your help figuring out how to do so while preserving the behavior you had in mind. So if you could point out specific cases you were thinking of it would help me with this. This is a hack to support matrices and other subclasses of ndarray like masked arrays. That's what I was thinking. Do you have a test case? One that failed without the NotImplemented return would be very helpful. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Request for clarification from Travis
Charles R Harris wrote: On Tue, Jun 24, 2008 at 1:41 PM, Travis E. Oliphant [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: The problem is that numpy has a *bug*. I am trying to fix it and I want your help figuring out how to do so while preserving the behavior you had in mind. So if you could point out specific cases you were thinking of it would help me with this. This is a hack to support matrices and other subclasses of ndarray like masked arrays. That's what I was thinking. Do you have a test case? One that failed without the NotImplemented return would be very helpful. There should be some in the test suite, but I'm not sure. Perhaps the masked array test suite also has test cases. The NotImplemented is being returned so that the other operation will try and use it if it can. -Travis ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Request for clarification from Travis
On Tue, Jun 24, 2008 at 8:40 PM, Travis E. Oliphant [EMAIL PROTECTED] wrote: Charles R Harris wrote: On Tue, Jun 24, 2008 at 1:41 PM, Travis E. Oliphant [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: The problem is that numpy has a *bug*. I am trying to fix it and I want your help figuring out how to do so while preserving the behavior you had in mind. So if you could point out specific cases you were thinking of it would help me with this. This is a hack to support matrices and other subclasses of ndarray like masked arrays. That's what I was thinking. Do you have a test case? One that failed without the NotImplemented return would be very helpful. There should be some in the test suite, but I'm not sure. Perhaps the masked array test suite also has test cases. The NotImplemented is being returned so that the other operation will try and use it if it can. Yes, but it is directed at the interpreter, which will raise a TypeError if needed. But the interpreter doesn't know that some generic function might return NotImplemented and wouldn't know what to do if it did. What the user should see when they call something like right_shift(a,b) and it fails is an exception, they shouldn't have to check the return value. I think what you want is that subtypes of ndarray can override some ufuncs so that, for instance, right_shift() should interpret itself as a call to arg2.__rrshift__ if it exists, even if it isn't called through the interpreter friendly slot function . Is that correct? If so, I would rather have an explicit overload flag in the subtype so that the ufunc can easily do the right thing. I can't find __array_priority__ in your book, what exactly does it imply? Chuck -Travis ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
