Menu
▾
▴
Re: [Numpy-discussion] numarray unfriendly to user defined types
|
From: Colin J. W. <cj...@sy...> - 2003-09-27 20:38:09
|
Tim, Todd refers to your original post. The only thing I've found is a reference to a pre and post addition of zero, the latter was said not to work. Both work for me, see below: >>> zero= 0 >>> zero + _num.arange(5) array([0, 1, 2, 3, 4]) >>> _num.arange(5) + zero array([0, 1, 2, 3, 4]) If I'm barking up the wrong tree, could you point me to your original posting in the archive please? Colin W. >>> Todd Miller wrote: >On Fri, 2003-09-26 at 13:31, Colin J. Williams wrote: > > >>Todd, >> >>This scheme seems rather complex. The purpose isn't clear to me. >> >>What is the problem which this arrangement is intended to solve? >> >> > >Bottom line, currently: > >numarray + another_class --> exception > >It would be nice if: > >numarray + another_class --> another_class.__radd__(numarray) > >Also, look backward at Tim's original post on this subject. > > > >>Could I suggest that some scheme along the lines of the Python PEP's be >>used to set out the Why's and Wherefore's? >> >> >> >Sounds good for next time. > > > >>It might also be useful to copy this discussion to comp.lang.python as >>that newsgroup has people experienced with classes. >> >> > >OK, I'll stop being a chicken. Everyone, get ready for the sound of a >pin dropping on c.l.py. > > > >>The problem appears >>to be Python related rather than a problem of numerical analysis. >> >> > >Yes indeed. > > > >>Colin W. >> >>Todd Miller wrote: >> >> >> >>>I tried out DeferredToByNumArray yesterday morning and was able to get >>>it to work as planned with numarray and MA. So yay! >>> >>>Yesterday afternoon, I stopped by Perry's office for a final check, and >>>not surprisingly, there are some aspects of this solution that we've >>>overlooked. So not yay! >>> >>>Perry pointed out two ways that the DeferredToByNumArray scheme may fall >>>apart as our inheritance hierarchy becomes richer: >>> >>>1) Imagine not one, but two independent subclasses of NumArray, each of >>>which want NumArray to defer to them. Now imagine them trying to >>>inter-operate with each other. In this case, the meaning of the >>>expression is determined by the order of the operands, so A+B and B+A >>>will either return an A or a B depending on the expression order. >>> >>>2) Imagine again two subclasses of numarray, but this time imagine B as >>>a subclass of A. Here again, both might want to defer to numarray, and >>>again, A+B and B+A return different types driven by the type order of >>>the expression. >>> >>>I don't have a solution yet, but am hopeful that more free candy will >>>fall from the sky... or YAGNI. Perry pointed out that similar problems >>>exist for *any* Python class hierarchy, so we're not alone, and perhaps >>>should forget about this until it matters. If someone sees an easy >>>fix, now would be better than later. >>> >>>Todd >>>On Wed, 2003-09-24 at 19:55, Tim Hochberg wrote: >>> >>> >>> >>> >>>>Todd Miller wrote: >>>> >>>> >>>> >>>> >>>> >>>>>On Wed, 2003-09-24 at 18:27, Tim Hochberg wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>Hi Todd, >>>>>> >>>>>>There are three ways to spell "defer to me" on the table (the precise >>>>>>details of >>>>>>each spelling are, of course, still open for debate): >>>>>> >>>>>> 1. numarray.defer_to(my_class) >>>>>> >>>>>> 2. class ArrayLike(numarray.DeferTo): >>>>>> # ... >>>>>> >>>>>> 3. class ArrayLike: >>>>>> _numarray_defer_to = True >>>>>> # ... >>>>>> >>>>>>I'd prefer a non-registration solution since those are both >>>>>>aesthetically displeasing and leave you open to the situation where a >>>>>>class in module A gets registered by module B, but module C expects it >>>>>>not to be registered and everything breaks. Not all that likely, I >>>>>>admit, but let's avoid the registration version if we can. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>I was picturing this as module A registering it's own classes only. >>>>>Nevertheless, inverting the problem and distributing the registration as >>>>>you suggested is better. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>The case you describe probably will describe the majority of actual use >>>>cases, and in fact describes mine. I'm trying to think ahead a bit to >>>>cases may encounter as start using NumArray more extensively. Let's hope >>>>this solution still looks good in six months! >>>> >>>> >>>> >>>> >>>> >>>>>>The other two solutions are almost equivalent. The one case where 3 has >>>>>>an edge over 2 is if I have an object (not a class), I could potentially >>>>>>set a _numarray_defer_to on the object before passing it to numarray >>>>>>without having to mess with the class >>>>>>of the object at all. YAGNI, though. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>I was more concerned about the potential impact of lots of multiple >>>>>inheritance, but that's probably just my own personal blend of FUD. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>The advantage of 2 in my view is that it *does* force you to subclass. >>>>>>With 3, there will be the temptation to poke into some other module and >>>>>>set _numarray_defer_to on some poor unsuspecting class. This has the >>>>>>same disadvantage as 1, that it could confuse some other poor >>>>>>unsuspecting module. The correct way to do get a deferred class from a >>>>>>third party module is to import and subclass. This works with either 2 >>>>>>or 3:: >>>>>> >>>>>>import A >>>>>> >>>>>>class Klass2(a.Klass, numarray.DeferTo): #2 >>>>>> #... >>>>>> >>>>>>class Klass3(a.Klass): #3 the good way >>>>>> _numarray_defer_to = True >>>>>> # ... >>>>>> >>>>>> A.Klass._numarray_defer_to = True #3 the evil way. >>>>>> >>>>>>Version 2 is cleaner and encourages you to do the right thing, so I'd >>>>>>prefer that solution. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>Good enough for me. If no one else has any comments, then >>>>>numarray.DeferTo is where I'll start implementing. Tomorrow. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>One more minor thing. I'm not sure tha DeferTo is ideal as the mix-in >>>>class name. It was perfect for the registration function name, but I'm >>>>not sure it's so clear whether the class or numarray is being deferred >>>>to when you say numarray.DeferTo. DeferToMe is more descriptive, but >>>>seems sort of slangy. DeferredTo is better than DeferTo, but still not >>>>as descriptive as DeferToMe. numarray.DefersTo reads perfect as long as >>>>numarray is included but is a disaster if you read it on your own. >>>>Below I've put down all the ideas I could come up with >>>> >>>>class CustomArray(numarray.DeferTo) >>>>class CustomArray(numarray.DefersTo) >>>>class CustomArray(numarray.DeferredTo) >>>>class CustomArray(numarray.DeferToMe) >>>>class CustomArray(numarray.DeferredToByNumarray) >>>>class CustomArray(DeferTo) >>>>class CustomArray(DefersTo) >>>>class CustomArray(DeferredTo) >>>>class CustomArray(DeferToMe) >>>>class CustomArray(DeferredToByNumarray) >>>> >>>>For me it's a toss up between DefferedTo, DeferToMe and >>>>DeferredToByNumarray. The first is a little lacking in descriptive >>>>power, the second is slangy and the third is wordy. >>>> >>>>-tim >>>> >>>>[not that this matters much....] >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>regards, >>>>>> >>>>>>-tim >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>Thanks again, >>>>>Todd >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>>------------------------------------------------------- >>>>This sf.net email is sponsored by:ThinkGeek >>>>Welcome to geek heaven. >>>>http://thinkgeek.com/sf >>>>_______________________________________________ >>>>Numpy-discussion mailing list >>>>Num...@li... >>>>https://lists.sourceforge.net/lists/listinfo/numpy-discussion >>>> >>>> >>>> >>>> >> >> |
