[Numpy-discussion] numarray unfriendly to user defined types

Todd Miller jmiller at stsci.edu
Mon Sep 29 06:09:02 CDT 2003


On Sat, 2003-09-27 at 15:53, Colin J. Williams wrote:
> 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?
> 

It's not the wrong tree,  but there's more than one case:  objects which
look like numeric sequence work but always return numarrays,  objects
which do not look like a numeric sequence raise an exception.

Here's a link to the numpy-discussion-list archives on Source Forge:

http://sourceforge.net/mailarchive/forum.php?thread_id=3154046&forum_id=4890


> 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
> >>>>Numpy-discussion at lists.sourceforge.net
> >>>>https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>    
> >>
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
-- 
Todd Miller 			jmiller at stsci.edu
STSCI / ESS / SSB





More information about the Numpy-discussion mailing list