On Wed, Jul 3, 2013 at 6:30 PM, Ondřej Čertík <[email protected]> wrote: > On Wed, Jul 3, 2013 at 4:40 PM, Ronan Lamy <[email protected]> wrote: >> 2013/7/3 Ondřej Čertík <[email protected]> >>> >>> On Wed, Jul 3, 2013 at 1:48 PM, Aaron Meurer <[email protected]> wrote: >>> >>> Why wouldn't simple type based dispatch work? >>> You might be right, I just want to understand the problem more. >>> >>> To answer Aaron's question: >>> >>> On Wed, Jul 3, 2013 at 12:58 PM, Aaron Meurer <[email protected]> wrote: >>> > So, going back to what we discussed the first time we met in Los >>> > Alamos, how would you reimplement something like the oo logic so that >>> > it lives entirely in the Infinity class, not in Add.flatten (say for >>> > simplicity, oo + 3 should go to oo, but oo + 3*I should remain as oo + >>> > 3*I)? >>> >>> This, and another example is x + O(x). Let's stick to oo + 3. >> >> >> x + O(x) is a bad example, because it should really not be represented by an >> Add. > > So the Order class would simply contain both the expression and the > "x", so for example to put this into sympy: > > x^2 + x + O(x) > > the user would write: > > Order(x^2 + x, x) > > ? I think that's a good idea.
I think he meant it should be some kind of series class. But it doesn't matter. You still need dispatch to let Add + Series => Series. > >> >>> This is a very good question and it is one of the details that I don't >>> know the answer 100% yet. >>> But I feel it is solvable. >>> >>> I think the best would be to create a demo (from scratch) where we can >>> play with these ideas. Hopefully I'll get to this eventually. >> >> >> How about this: https://github.com/rlamy/sympy/commits/binop ? > > Yes! Thanks. Here is how to view changes once you are in this branch: > > git diff c84e5df > > > So I can see that you defined the __pow__ operator in Expr to return > power(a, b) instead of the Power(a, b) class directly. The power(a, b) > is just a function, double dispatched. Then you change all Pow(a, b) > occurrences in sympy to a**b, which gets dispatched to power(a, b) > then. I assume you could have also just changed Power -> power? > > Finally power() is then defined as follows: > > [email protected](Expr, Expr) > +def _power_basecase(x, y): > + return Pow(x, y) > > [email protected](Expr, One) > +def _pow_Expr_One(x, one): > + return x > > [email protected](One, Expr) > [email protected](One, NaN) > [email protected](One, One) > [email protected](One, Zero) > +def _pow_One_Expr(one, x): > + return one > > etc. (there are some more rules, not important here) > > So from this it is clear that power(Expr, One) is used first if > available, otherwise pow(Expr, Expr) is used as a backup plan. > > Here are my questions: > > * how is performance doing? > > * currently your dispatch implementation uses issubclass(c_left, left) > etc., which potentially might be quite slow. Is there any way to just > check the types in a dictionary and only if it is not there, only then > do the slow dispatch that you implemented based on inheritance? > > So for example if you put in (Add, One), then on the first run it > would figure out that it should call (Expr, One), and this first run > might be slower, that's ok. But on subsequent runs it would simply > return it from the dictionary directly, so this should be very fast? > > Currently we can't use __class__ for it, because: > > In [9]: Symbol.__class__ > Out[9]: sympy.core.assumptions.ManagedProperties > > In [10]: Zero.__class__ > Out[10]: sympy.core.singleton.Singleton > > In [11]: One.__class__ > Out[11]: sympy.core.singleton.Singleton > > Due to some sympy metaclasses machinery or something. > But we can create some attribute like _sympy_class_, which would be a > string or a number, unique for each sympy class. User defined types > would write there the name of the class, so that Expr, One, Zero, NaN > would all return unique name. Be careful replacing isinstance with something else. I get the need for speed, but we also want subclasses to be able to do the right thing. Aaron Meurer > > > * What are your other conclusions or impressions from implementing it? > > Ondrej > > -- > 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.
