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 sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to