So what should we do with `simplify(ImmutableMatrix)`. What is the preferred behavior?
On Tue, Oct 16, 2012 at 12:48 AM, Aaron Meurer <[email protected]> wrote: > I think the real question here is, do we want most functions in sympy > to automatically vectorize over matrices (or similar objects)? And I > think the answer is no. Consider for example if we had an unevaluated > Matrix type that didn't multiply through by default (what > ImmutableMatrix used to be). We might want something like > simplify(A*B + A*C) to give A*(B + C), where A, B, and C are all > explicit unevaluated matrices. > > It's similar to the reason that solve() does not automatically call > dsolve() on ODEs. It's useful to be able solve for the function > algebraically, i.e., both > > >>> dsolve(f(x).diff(x, x) + f(x) - 1, f(x)) > f(x) == C1*sin(x) + C2*cos(x) + 1 > > and > > >>> solve(f(x).diff(x, x) + f(x) - 1, f(x)) > [-Derivative(f(x), x, x) + 1] > > can be useful. > > Another good argument for matrices is exp(). We want exp(Matrix) to > give the exponential of a Matrix, which is not the matrix of > exponentials. And actually you can define f(Matrix) for any analytic > f. Won't it be a little confusing if math_function(Matrix) works > different from simplify_function(Matrix)? And again, what if you have > simplify_function(combination_of_math_functions(unevaluated_matrices))? > > And aside from that, automatic vectorization would be a mess, because > only the most popular functions would support it, and the rest > wouldn't. So we would end up with a situation where function `a` > works as expected, but very similar function `b` doesn't, and it's not > clear why (and even if `b` doesn't support it, it doesn't mean that > Matrix defines `_b`). It's similar to automatic sympification of > strings that some but not all SymPy functions support. > > Aaron Meurer > > On Mon, Oct 15, 2012 at 1:42 PM, Matthew Rocklin <[email protected]> > wrote: > > > > > > On Mon, Oct 15, 2012 at 2:16 PM, Julien Rioux <[email protected]> > > wrote: > >> > >> Hi, > >> > >> I certainly think I should be able to simplify(m) for m a matrix type. > As > >> I use sympy I expect that all objects interact together naturally. I > should > >> be able to combine objects (as long as they make mathematical sense) > and be > >> able to use the same functions on all objects. > > > > This is a good ideal. Unfortunately most of the Expr code was written to > > only work with scalars. I.e. people often use 0 when they mean "additive > > identity" (I use this example a lot, please forgive me). I don't think > that > > incremental bug fixes will solve this problem. > > > >> It used to be that simplify wasn't built to deal very well with > >> noncommutative symbols, so e.g. simplify(A*B - B*A) would return 0. > Those > >> were considered bugs and were eventually fixed. I think the same > approach > >> should be taken about simplifying matrices, any issue should be > considered a > >> bug and fixed. > >> > >> I stopped using Matrix and have since used ImmutableMatrix because I > could > >> use most regular sympy functions on it. By the way, I wish I could do > >> factor(m), too. Although it doesn't do anything useful at the moment, we > >> should improve upon it. > > > > I think that the easiest way to improve upon it is to have factor call > > ImmutableMatrix._factor. Trying to make one giant function to do > factoring > > for all classes sounds difficult to me. It's hard to write a single > function > > that factors all sorts of things. > > > >> I think the inheritance on Expr ensures that a lot of functions such as > >> simplify will work (possibly for free) or at least they won't error out. > > > > This is not my experience. It is very easy to stress the system and get > into > > very weird states; or at least it was until I monkey patched some things. > > Now it is only moderately easy :) In these cases I would rather error > out at > > a higher level than at a very low level. My experience is that the > > MatrixExpr(Expr) inheritance is very hard to reason about and has high > > potential for bugs. I've duct-taped things together so that they appear > to > > usually work. It's very hard to develop new functionality with this > though. > > I always end up running into Expr trouble. MatrixExpr can't grow > effectively > > and will have many more bugs while it is still connected to Expr. > > > >> It doesn't bother me too much how it's implemented as long as it's not > >> overly complicated and it works. > > I think the easiest way to make it work is to remove the Expr dependence > and > > use classes for polymorphism (i.e. put `if hasattr(expr, '_simplify'): > > return expr._simplify()` in the publicly visible simplify funciton. ) > > > > -- > > You received this message because you are subscribed to the Google Groups > > "sympy" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group at > > http://groups.google.com/group/sympy?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/sympy?hl=en. > > -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
