Hi, On 30 July 2011 07:27, Aaron Meurer <asmeu...@gmail.com> wrote:
> I think your implementations are completely different, though perhaps > they could be merged. Mateusz's implementation is more about allowing > unevaluated functions on Matrices, whereas Matthews is more about > expressions where the variables are to be understood as matrices (I > use this instead of the ambiguous "symbolic matrices"). > > Both have their advantages. For example, the laplace_expand() from > Mateusz's version doesn't make sense in Matthew's version. On the > other hand, Matthew's version truly lets you manipulate undefined > matrices, and can be a more efficient way of manipulating defined ones > (e.g., Identity(100000) vs. eye(100000)). > > But other than some functions like laplace_expand() only making sense > for one, I don't see any reason why these two approaches can't or > shouldn't be merged. Actually, this is basically what was being > suggested when people said subs should work on symbolic matrices (a la > Matthew). > I'm sure that, sooner or later, those approaches will have to be merged, because those are really two views of a very similar (if not the same) problem domain. My original motivation came from reading lecture notes for undergraduates about the finite element method. As usually there was an introduction to basics of algebra needed to understand the later material, and my question was why it must be so hard to do it in SymPy (if possible at all). My branch is about "symbolic matrices" with explicit content. However, I don't see any problem with allowing transition between those two views (well at least in one direction). Suppose we have expr = Eq(A*x, b), where A, x, b are matrices/vectors of appropriate shape. First, I would like to be able to manipulate the expression alone, check various shapes (and ask SymPy if it makes sense), etc. Then I would like to write something like expr.expand(fullform=True) and get the same but with MatrixExpr with explicit indexed symbols or values (if entities like zeros or ones matrix was used in expr). Then I would like to make further transformation on this "full form". > > Aaron Meurer > > On Fri, Jul 29, 2011 at 7:54 PM, Matthew Rocklin <mrock...@gmail.com> > wrote: > > I like your use of the phrase "interpretation of Matrix Expressions." It > > makes it clear that we all probably have very different ideas for what > > Matrix Expressions should be. Hopefully there is a system which can > handle a > > wide variety of needs. > > My current branch is here > > https://github.com/mrocklin/sympy/tree/matrix_expr > > The main difference between our two interpretations is that I think of > > MatrixExpr's as being built up mainly of MatrixSymbol's rather than > Matrix > > objects. Probably there is a nice way to make both feasible. For my GSOC > > project I needed Block Matrices so those are better developed. There is a > > blogpost demonstrating them here. > > > > > > On Fri, Jul 29, 2011 at 7:49 PM, Mateusz Paprocki <matt...@gmail.com> > wrote: > >> > >> Hi, > >> > >> On 16 July 2011 00:12, Ondrej Certik <ondrej.cer...@gmail.com> wrote: > >>> > >>> On Fri, Jul 15, 2011 at 9:17 AM, Andy Ray Terrel < > andy.ter...@gmail.com> > >>> wrote: > >>> > My suggestion would be to continue with the matrixify solution and > >>> > write functions to fix up the expression tree as need be. The whole > >>> > issue of making Add/Mul/Pow extensible is separate but the logic can > >>> > be transferred pretty easily. > >>> > >>> Exactly. Just get the job done, implement the necessary code, and > >>> whether or not Add/Mul/Pow classes can be extended is a separate > >>> issue, and I would suggest not to, to keep things simple in the core, > >>> so that we can refactor once we finish the assumptions refactoring. > >> > >> btw. Here is my interpretation of matrix > >> expressions: https://github.com/mattpap/sympy/tree/matrix_expr. > Currently it > >> doesn't implement matrix expression arithmetic, but most certainly I'm > not > >> going to allow a*M or A + B to "doit" by default, rather I will > implement > >> this within expand() framework. What I need are semi evaluated matrix > >> expressions, so det(A^T) can be rewritten to det(A), but a*M must remain > >> unevaluated. This branch is very preliminary, there are no tests for the > new > >> stuff and I didn't run tests so a few things may be broken > >> > >>> > >>> Ondrej > >>> > >>> -- > >>> You received this message because you are subscribed to the Google > Groups > >>> "sympy" group. > >>> To post to this group, send email to sympy@googlegroups.com. > >>> To unsubscribe from this group, send email to > >>> sympy+unsubscr...@googlegroups.com. > >>> For more options, visit this group at > >>> http://groups.google.com/group/sympy?hl=en. > >>> > >> > >> Mateusz > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "sympy" group. > >> To post to this group, send email to sympy@googlegroups.com. > >> To unsubscribe from this group, send email to > >> sympy+unsubscr...@googlegroups.com. > >> 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 sympy@googlegroups.com. > > To unsubscribe from this group, send email to > > sympy+unsubscr...@googlegroups.com. > > 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 sympy@googlegroups.com. > To unsubscribe from this group, send email to > sympy+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/sympy?hl=en. > > Mateusz -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
