[Numpy-discussion] numarray unfriendly to user defined types

Colin J. Williams cjw at sympatico.ca
Sun Sep 28 11:32:04 CDT 2003


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
>>>>Numpy-discussion at lists.sourceforge.net
>>>>https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>>>>   
>>>>
>>>>        
>>>>
>>    
>>






More information about the Numpy-discussion mailing list