When we've talked about this in the past, we put the ideas at https://github.com/sympy/sympy/wiki/Canonicalization. So take a look at what is there, and add things if you have any more ideas.
Aaron Meurer On Wed, Jul 3, 2013 at 11:11 AM, Ondřej Čertík <[email protected]> wrote: > Hi, > > Prasoon has described here precisely the problems with extending sympy > with user defined types: > > https://groups.google.com/d/topic/sympy/QV6m9Nfp9kw/discussion > > Currently the only way to robustly do that is through _op_priority as > Julien described. > > The usual Python approach (NotImplemented) doesn't work, because if > for example Mul.__add__ thinks it knows how to work with user's type, > it will not return NotImplemented and thus the user has no way of > overriding it. > > The other way to implement this is called "multiple dispatch" > (http://en.wikipedia.org/wiki/Multiple_dispatch). I mention it at the > end of my blog post [1]. Julia has multiple dispatch implemented, see > here how it works there: > > http://docs.julialang.org/en/latest/manual/methods/ > > This is also related to Matthew's idea to use "mul" instead of "Mul": > > http://code.google.com/p/sympy/issues/detail?id=3909 > > since the new function "mul" would (or could) use multiple dispatch to > decide what exactly it will do based on parameters, and I think that > it would just be a quick O(1) dictionary lookup based on argument > types. Then Symbol.__mul__, Integer.__mul__, Add.__mul__, Mul.__mul__, > ..., would just call the function "mul". > So it should be fast. > > The user would then register his own new types into SymPy and register > his own function for "mul", which would get called whenever he wants. > > This would among other things allow to provide faster implementation > of SymPy core, as the faster core (implemented in Cython or C++ for > example) would simply register its own faster types and faster > implementation of "mul". We can also do multiple dispatch for things > like "series" etc., though for functions of just one argument the > default Python method resolution should work well (i.e. the faster > core simply implements its own "series" method). I think the problem > is for functions like "mul", which accept two arguments. > > I suggest to read the Julia docs and learn from there all the details > how exactly they decide which method gets called. I think they have > thought about this thoroughly and so we should learn from their > experience. > > Ondrej > > [1] > http://ondrejcertik.blogspot.com/2013/07/my-impressions-from-scipy-2013.html > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/sympy. > For more options, visit https://groups.google.com/groups/opt_out. > > -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sympy. For more options, visit https://groups.google.com/groups/opt_out.
