Cool ideas, indeed. Very useful, I'm sure, and quite easy to implement. For the abstract Matrix part, A new constructor-less data-less class AbstractMatrix which inherits class Matrix. This class' objects will serve as pointers to Matrices. And the object would later be made to point to a concrete class. We can also make the other concrete classes sub-classes of this class, but that remains to be seen. Another slight modification will need to be done to the solve function, to solve simple eqns like Ax=B, where x is the abstract vector.
The second idea is simpler, Just make the matrix class accept Matrices as elements. We'll have to put in a flag though, a boolean contains_matrices, which will tell particular methods to compute the results with keeping this in mind, OR An alternate design : Another class BlockMatrix, which will accept matrices as elements, but when any computation is needed, it will call its BlockMatrix.expand() function, whose result will be feeded to the regular matrices functions. The expansion will be stored in a local cache in the object, to be re-used. Thank you Tim. If you're interested to do the Linear Algebra module, as Aaron says there is plenty of work to be done. We can discuss more of it on IRC or mail. Cheers, Sherjil Ozair On Mar 24, 12:12 pm, "Aaron S. Meurer" <[email protected]> wrote: > On Mar 23, 2011, at 10:20 PM, Tim Lahey wrote: > > > Hi, > > > I've been thinking about GSoC and looking at the various ideas people have > > been posting. By the way, I'd like to see perturbation theory included in > > general (i.e., not just for quantum mechanics) since it's used in stability > > analysis. > > Yes definitely. Another thing that should not be implemented only in physics. > > > > > > > > > > > > > I have a few linear algebra related ideas I'd like to see. One is > > "abstract" linear algebra. That is support for arbitrary matrix and vector > > calculations. So, one would just indicate that a symbol is a matrix/vector > > without stating the size. Then you could work with them. The > > non-commutative support is a start, but the transpose operation would need > > to be added along with derivatives. I have a Maple worksheet that has a > > crude version of this. This is used quite a bit in the Ritz approach to > > Finite Element Analysis. > > > The other linear algebra thing to add is support for block matrices. So, > > one could specify a matrix like > > > M = [[A,B],[C,D]] > > > where A, B, C, and D are arbitrary matrices. Then, you could take the > > inverse and other standard linear algebra. This fits in with the "abstract" > > linear algebra support. This kind of thing pops up a lot in control theory. > > > Cheers, > > > Tim. > > > --- > > Tim Lahey > > PhD Candidate, Systems Design Engineering > > University of Waterloo > >http://about.me/tjlahey > > These sound like good ideas. > > By the way, Sherjil Ozair is also applying to do some work on the matrices, > but I think he is planning on doing different stuff, like sparse matrices and > integration with the polys ground types (gmpy). Maybe you could collaborate > with him to apply to do different things. There are enough things to do in > the matrices to cover two projects, I think. That way (assuming you both had > high enough quality applications) you could both potentially be accepted at > the same time. > > Otherwise, if you apply to do the exact same thing, we will have to pick one > of you (again assuming both are good enough to be accepted). > > Aaron Meurer -- 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.
