Re: numarraycore
Todd Miller <jmiller <at> stsci.edu>
2004-05-07 14:22:49 GMT
On Thu, 2004-05-06 at 19:16, Colin J. Williams wrote:
>
> Todd Miller wrote:
> > On Wed, 2004-05-05 at 18:59, Colin J. Williams wrote:
> >
> > > Todd Miller wrote:
> > >
> > > > On Wed, 2004-05-05 at 16:27, Colin J. Williams wrote:
> > > >
> > > >
> > > > > It would help to have some documentation on the purpose and usage of the
> > > > > class UsesOpPriority and its variable op_priority.
> > > > >
> > > > >
> > > Todd,
> > >
> > > Thanks for this, perhaps it could be added to the pdf . I like the
> > > basic idea.
> > >
> > OK. What is it you want to do?
> Re: Above.
> Document whatever you decide to do with UsesOpPriority
I put more comments in numarraycore. If a lot of people want to
subclass NumArray, it will probably require more discussion because
UsesOpPriority is a limited scheme. For now, MaskedArrays do mostly
what I want and it should work for PyMatrix as well.
> Re: Below.
> Access the methods of NumArray in a Pythonic manner.
> Subclassing from UsesOpPriority doesn't appear to permit that.
No, it doesn't.
> >
> > > > The basic idea was that NumArray subclasses which want to use numarray
> > > > operators would:
> > > >
> > > > 1. subclass from UsesOpPriority
> > > >
> > > UsesOpPriority has no methods and thus, to access the methods of
> > > NumArray, it would appear to be necessary to subclass from NumArray.
> > >
> > For limited but important uses (e.g. masked array) subclassing from
> > NumArray is not necessary; I'd summarize these as the cases where a
> > class wants to take control of operators from NumArray.
> >
> Thus, if masked array require use of the UsesOpPrioity, then direct
> subclassing from there would appear to make sense.
>
> However, where one wishes to use some of the NumArray methods, then,
> contrary to 1, above, subclassing from NumArray should, I suggest, be
> the way to go.
That's true... I overlooked the fact that UsesOpPriority is inherited
automatically by NumArray subclasses. Sorry for the confusion.
> >
> > > > 2. set a class level op_priority > 0.
> > > >
> > > >
> > > > NumArrays have op_priority 0, higher priorities are given "precedence".
> > > >
> > > >
> > > > Thus, given A=NumArray(...) and B=NumArraySubclass(...), and
> > > > A.op_priority==0 and B.op_priority==1, then:
> > > > A+B would execute as B.__radd__(A) rather than A.__add__(B) and hence
> > > > the type(A+B) could be NumArraySubclass rather than NumArray. Different
> > > > subclasses could use higher or lower op_priorities to perform the same
> > > > kind of operator resolution among themselves.
> > > >
> > > >
> > > I wonder about the desirability of having different levels of priority
> > > for the same level of subclassing and am puzzled that a float variable
> > > is used for the priority.
> > >
> > Different levels of priority for the same level of sub-classing makes
> > sense to me: it let's you answer the question "What's the result type
> > of a PyMatrix instance + a SomeOtherSubclass instance?"
> >
> I agree, there is the possibility that one would wish to evaluate such
> expressions right to left and
> the priority provides a way of doing this.
> > A float enables insertions of new members into the middle of an existing
> > order.
> >
> True. I hope that there will be a database somewhere of all the
> various values for op_priority
Here's the database:
class op_priority
NumArray 0
MaskedArray 1
Regards,
Todd
-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver
higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3