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. > >
It might be a good idea to collect these uses in a wiki page that descirbes the "User Stories", borrowing from the SCRUM process. @Mateusz, doing symbolic FEM is not crazy there are lots of people who have done it, including yours truly. The issue is that FEM is usually done for very large problems for which symbolics is prohibatively expensive. The FEniCS, Sundance, and others approach is to use symbolics to describe operators for building a numeric matrix, SyFi took your approach and build symbolics down to the matrix level but for difficult problems had real problems with the expansion of the symbolic expressions, Dohp is doing the symbolics at the quadrature points in a mesh to evaluate the residuals, but again is having trouble with the symbolic expressions. -- Andy -- 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.
