[Numpy-discussion] Asking for opinions: Priops

[Dag Sverre Seljebotn]

Friedrich Romstedt wrote:
> 2010/9/23 Dag Sverre Seljebotn <dagss at student.matnat.uio.no>:
>   
>> Essentially, perhaps what you have sketched up + an ability to extend
>> the graph with object conversion routes would be perfect for my own
>> uses. So you can define a function with overloads (A, B) and (A, C), but
>> also that objects of type D can be converted to C (and how). For
>> instance, consider:
>>
>> np.array([1,2,3]) + [1,2,3]
>>
>> Here, list-> array could be handled through a defined coercion to array,
>> rather than having to add an overload for list for every method taking
>> an array.
>>     
>
> This seems to be a good thing.  Let's reason about this for some
> moment.  Atm, the relation is *not* transitive.  (I.e., (A, B) and (B,
> C) does imply nothing for (A, C).  A, B, C classes.)  But such kind of
> transitivity is what you mean, if (A, B) is defined and there is a
> graph egde in the "conversion graph" (B, C), then (A, C) can choose
> the (A, B) route via C -> B conversion; here the notation (B, C) in
> the conversion graph means "conversion from C to B".
>
> I don't see a clear solution at the end satisfying me.  It seems that
> one really has to conduct a search in the additional conversion graph.
>  Since this is expensive, I believe it would probably be good to
> derive a "ConversionPriop" from priop.Priop.
>
> What are your thoughts now?
>   

You can just cache all lookups in the conversion graph, so that after 
some initialization all lookups are O(1). There's a limited number of 
types in a Python runtime, and the actual distinct lookups performed are 
likely to not be many. I don't see that as a problem at all.

I'll try to remember to get back to the rest in a week or so...I'm 
handing in my MSc on Thursday :-)

Dag Sverre