I see that Andy just posted while I was writing. I'll post anyway although Ii thnk maybe the wiki page is a better start.
It seems like we have a few people who want to contribute to the same concept. Should we put something on the master branch so that people can start adding to it? What would a general framework for matrix expressions look like that could handle most of the use-cases? What are the use cases? So far we have - Expression that may contain matrices as atomic symbols - Expression that may contain immutable matrices - Derivatves of symbols - Derivatves over indices? - Block matrices On Sat, Jul 30, 2011 at 1:40 AM, Tim Lahey <tim.la...@gmail.com> wrote: > On Sat, Jul 30, 2011 at 2:31 AM, Mateusz Paprocki <matt...@gmail.com> > wrote: > > > 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". > > I would like to do things like differentiate c^T*A*c with respect to > the vector c. It's a common thing for finite elements. But I'd also > like block matrices. However, if you have symbolic matrix expressions, > you can put them in a matrix and then perform standard matrix > calculations on that and you'd have block matrix support. So, as long > as that's possible, there's no problem. > > I've got by handling differentiating matrix-vector expressions in > Maple using their non-commutative support along with hacking together > handling the transpose and differentiation of it. But, I'd like proper > support. > > If Sympy could support block matrices, that would be extremely useful > in control theory (where they're used all the time). > > Cheers, > > Tim. > > -- > Tim Lahey > PhD Candidate, Systems Design Engineering > University of Waterloo > http://about.me/tjlahey > > -- > 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.
