From: Colin J. W. <cj...@sy...> - 2004-05-05 20:27:50
|
It would help to have some documentation on the purpose and usage of the class UsesOpPriority and its variable op_priority. |
From: Todd M. <jm...@st...> - 2004-05-05 20:51:36
|
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. The basic idea was that NumArray subclasses which want to use numarray operators would: 1. subclass from UsesOpPriority 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. Todd -- Todd Miller <jm...@st...> |
From: Colin J. W. <cj...@sy...> - 2004-05-05 23:00:54
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1"> <title></title> </head> <body text="#000000" bgcolor="#ffffff"> <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1"> <title></title> <br> <br> Todd Miller wrote:<br> <blockquote type="cite" cite="mid...@ha..."> <pre wrap="">On Wed, 2004-05-05 at 16:27, Colin J. Williams wrote: </pre> <blockquote type="cite"> <pre wrap="">It would help to have some documentation on the purpose and usage of the class UsesOpPriority and its variable op_priority. </pre> </blockquote> <pre wrap=""><!----></pre> </blockquote> Todd,<br> <br> Thanks for this, perhaps it could be added to the pdf . I like the basic idea.<br> <blockquote type="cite" cite="mid...@ha..."> <pre wrap="">The basic idea was that NumArray subclasses which want to use numarray operators would: 1. subclass from UsesOpPriority </pre> </blockquote> UsesOpPriority has no methods and thus, to access the methods of NumArray, it would appear to be necessary to subclass from NumArray.<br> <blockquote type="cite" cite="mid...@ha..."> <pre wrap=""> 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. </pre> </blockquote> 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.<br> <br> It would nice if this depth could be determined automatically. Perhaps something like the script below could be used.<br> <br> Colin W.<br> <blockquote type="cite" cite="mid...@ha..."> <pre wrap=""> Todd </pre> </blockquote> # tClassing.py<br> <br> class A:<br> def __init__(self):<br> self.p= 0<br> def prior(self):<br> self.p+= 1<br> class B(A):<br> def __init__(self):<br> A.__init__(self)<br> self.prior()<br> class C(B):<br> def __init__(self):<br> B.__init__(self)<br> self.prior()<br> <br> print A().p<br> print B().p<br> c= C()<br> print 'Priority for C methods:', c.p<br> </body> </html> |
From: Todd M. <jm...@st...> - 2004-05-06 18:08:27
|
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? > > 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. > > 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?" A float enables insertions of new members into the middle of an existing order. > > It would nice if this depth could be determined automatically. > Perhaps something like the script below could be used. I don't think we want something automatic here. The choices involved are arbitrary so we just need to be able to define what we want. Other than masked arrays, the problem we were trying to solve with UsesOpPriority is more like: class A(NumArray): op_priority = 1 class B(NumArray): op_priority = 2 whenever A op B is encountered, the result should be a B. That said, the solution we currently have is better described by: whenever A op B is encountered, B.__rop__(A) is called in preference to A.__op__(B). With the example above, even though B.__rop__ is called, the result is still an A. :-( I fixed this in CVS today to work more like the original description. Regards, Todd > > Colin W. > > Todd > > > # tClassing.py > > class A: > def __init__(self): > self.p= 0 > def prior(self): > self.p+= 1 > class B(A): > def __init__(self): > A.__init__(self) > self.prior() > class C(B): > def __init__(self): > B.__init__(self) > self.prior() > > print A().p > print B().p > c= C() > print 'Priority for C methods:', c.p > ------------------------------------------------------- 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 > _______________________________________________ Numpy-discussion > mailing list Num...@li... > https://lists.sourceforge.net/lists/listinfo/numpy-discussion -- Todd Miller <jm...@st...> |
From: Colin J. W. <cj...@sy...> - 2004-05-06 23:16:42
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1"> <title></title> </head> <body text="#000000" bgcolor="#ffffff"> <br> <br> Todd Miller wrote:<br> <blockquote type="cite" cite="mid...@ha..."> <pre wrap="">On Wed, 2004-05-05 at 18:59, Colin J. Williams wrote: </pre> <blockquote type="cite"> <pre wrap="">Todd Miller wrote: </pre> <blockquote type="cite"> <pre wrap="">On Wed, 2004-05-05 at 16:27, Colin J. Williams wrote: </pre> <blockquote type="cite"> <pre wrap="">It would help to have some documentation on the purpose and usage of the class UsesOpPriority and its variable op_priority. </pre> </blockquote> </blockquote> <pre wrap="">Todd, Thanks for this, perhaps it could be added to the pdf . I like the basic idea. </pre> </blockquote> <pre wrap=""><!----> OK. What is it you want to do?</pre> </blockquote> Re: Above.<br> Document whatever you decide to do with UsesOpPriority<br> Re: Below.<br> Access the methods of NumArray in a Pythonic manner.<br> Subclassing from UsesOpPriority doesn't appear to permit that.<br> <blockquote type="cite" cite="mid...@ha..."> <pre wrap=""> </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">The basic idea was that NumArray subclasses which want to use numarray operators would: 1. subclass from UsesOpPriority </pre> </blockquote> <pre wrap="">UsesOpPriority has no methods and thus, to access the methods of NumArray, it would appear to be necessary to subclass from NumArray. </pre> </blockquote> <pre wrap=""><!----> 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. </pre> </blockquote> Thus, if masked array require use of the UsesOpPrioity, then direct subclassing from there would appear to make sense. <br> <br> 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.<br> <blockquote type="cite" cite="mid...@ha..."> <pre wrap=""> </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">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. </pre> </blockquote> <pre wrap="">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. </pre> </blockquote> <pre wrap=""><!----> 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?" </pre> </blockquote> I agree, there is the possibility that one would wish to evaluate such expressions right to left and <br> the priority provides a way of doing this.<br> <blockquote type="cite" cite="mid...@ha..."> <pre wrap=""> A float enables insertions of new members into the middle of an existing order. </pre> </blockquote> True. I hope that there will be a database somewhere of all the various values for op_priority<br> <blockquote type="cite" cite="mid...@ha..."> <pre wrap=""> </pre> <blockquote type="cite"> <pre wrap="">It would nice if this depth could be determined automatically. Perhaps something like the script below could be used. </pre> </blockquote> <pre wrap=""><!----> I don't think we want something automatic here. The choices involved are arbitrary so we just need to be able to define what we want. Other than masked arrays, the problem we were trying to solve with UsesOpPriority is more like: class A(NumArray): op_priority = 1 class B(NumArray): op_priority = 2 whenever A op B is encountered, the result should be a B. That said, the solution we currently have is better described by: whenever A op B is encountered, B.__rop__(A) is called in preference to A.__op__(B). With the example above, even though B.__rop__ is called, the result is still an A. :-( I fixed this in CVS today to work more like the original description. Regards, Todd </pre> </blockquote> Thanks.<br> <br> Colin W.<br> <blockquote type="cite" cite="mid...@ha..."> <pre wrap=""> </pre> <blockquote type="cite"> <pre wrap="">Colin W. </pre> <blockquote type="cite"> <pre wrap="">Todd </pre> </blockquote> <pre wrap=""># tClassing.py class A: def __init__(self): self.p= 0 def prior(self): self.p+= 1 class B(A): def __init__(self): A.__init__(self) self.prior() class C(B): def __init__(self): B.__init__(self) self.prior() print A().p print B().p c= C() print 'Priority for C methods:', c.p ------------------------------------------------------- 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. <a class="moz-txt-link-freetext" href="http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3">http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3</a> _______________________________________________ Numpy-discussion mailing list <a class="moz-txt-link-abbreviated" href="mailto:Num...@li...">Num...@li...</a> <a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/numpy-discussion">https://lists.sourceforge.net/lists/listinfo/numpy-discussion</a> </pre> </blockquote> </blockquote> </body> </html> |
From: Todd M. <jm...@st...> - 2004-05-07 14:23:07
|
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 |