There is a barebones implementation of a Matrix Expression class here: https://github.com/mrocklin/sympy/tree/matrix_expr/sympy/matrices
Comments/criticism welcome. On Mon, Jun 27, 2011 at 10:08 PM, Aaron Meurer <[email protected]> wrote: > Option 3 might work. You should talk to Brian Granger about the > advantages and disadvantages of defining your own Expr objects, as > that's what is done in the quantum code. > > Note that you should be able to handle the other stuff with the > assumptions (in theory anyway; assumptions are kind of a mess right > now, so I couldn't say how well it would work). > > But even if we fix the core and option 1 becomes feasible, the code > can be refactored, so if you want something now, I am +1 to trying > option 3. I would rather prefer to avoid option 2, unless you are > going to fix it in a more general way (like issue 1941). > > Aaron Meurer > > On Mon, Jun 27, 2011 at 8:32 PM, Matthew Rocklin <[email protected]> > wrote: > > Yeah, definitely. I must confess that a hidden passion of mine is > optimizing > > linear algebra (we all have our quirks). I was just looking at Theano a > > minute ago actually - I think it would be cool to easily dump Matrix > > expressions onto them. > > How should matrix expressions be represented in SymPy though? The way I > see > > it there are three options > > > > Leave it as a SymPy Expr, forget shape, transpose, rank, etc... for now. > > Maybe future SymPy elegance will make clever things possible (such as > issue > > 1941) > > Enhance SymPy Expr's to play nice with Matrices > > Subclass a family of MatrixExpr classes that live outside the core > > > > Probably there are things I'm missing but this is how I separate things. > > Because I'd like this done sooner rather than later I'm obviously in > favor > > of 2 or 3 with a preference for 3. I don't know enough about SymPy > however > > to tell whether this is the "right way" and I'd rather not work on > something > > unless it has a chance at getting in. > > I'll push again for three by saying that there is a lot going on in > Matrix > > Expressions other than just non-commutativity and shape. Inverses, > > transposes, rank, symmetry, positive_definiteness, conditioning, etc... > all > > play a big role in computational decisions made on matrices. Additionally > > matrix expressions are ubiquitous and important in the scientific > computing > > world. From my (strongly biased) perspective they deserve special > > treatment. > > But for my Summer project I just need something. Even 1 might work for > me. > > Does anyone have any thoughts or suggestions? > > Best, > > -Matt > > On Mon, Jun 27, 2011 at 9:07 PM, Aaron Meurer <[email protected]> > wrote: > >> > >> Unless you can make matrices sympifyable, you probably won't be able > >> to use .subs. That isn't to say that you can't write your own > >> specialized function to do the substitution. > >> > >> There's also some cool stuff you could do here, like implementing a > >> matrix chain multiplication algorithm > >> (http://en.wikipedia.org/wiki/Matrix_chain_multiplication) to compute > >> the most efficient way to multiply a product of matrices ABCD... > >> > >> Aaron Meurer > >> > >> On Mon, Jun 27, 2011 at 9:54 AM, Matthew Rocklin <[email protected]> > >> wrote: > >> > Regarding expr.subs(x,matrix): > >> > This is tricky because Matrices aren't sympifiable. I think you would > >> > need > >> > to substitute all matrix symbols for matrices at once and then turn > the > >> > expression into a Matrix object using the Matrix.__add__ etc methods. > Or > >> > maybe any substituted Matrix would become some sort of ImmutableMatrix > >> > object so that it could live inside an Expr. > >> > Regarding other differences: > >> > Being able to substitute computational elements like > >> > Matrices/SparseMatrices/LinearOperators into matrix expressions is > >> > definitely the main motivating application behind symbolic matrices. > >> > This is > >> > not my major focus right now though. I'm focusing on turning > statistical > >> > statements into computational ones. I've been generating integrals for > a > >> > while now and would like to start generating Matrix Expressions like > >> > what's > >> > found here. Being able to check the shape of an expression is likely > >> > going > >> > to be useful for me. I suspect that there will be more features of > >> > matrices > >> > that I'd like exposed other than just that they're not commutative. > >> > Knowing > >> > if it is invertible or not is a good example. > >> > Of course, after I generate and simplify these expressions I'll need > to > >> > substitute in actual matrices of some form or another, I just haven't > >> > gotten > >> > there yet :) > >> > Haven't tried anything yet. > >> > -Matt > >> > > >> > > >> > > >> > > >> > On Mon, Jun 27, 2011 at 10:19 AM, SherjilOzair < > [email protected]> > >> > wrote: > >> >> Hello Matthew, > >> >> As Aaron says correctly, work on matrices and work on the matrix > symbol > >> >> is > >> >> quite separate. > >> >> The Matrix class provides fundamental operations like addition, > >> >> multiplication. We only have to make Add, Mul call the required > >> >> routines > >> >> in > >> >> the Matrix class. > >> >> I'm not sure what .flatten does, and my knowledge about the core is > >> >> only > >> >> minimal. But I think the only time there is a difference between a > >> >> regular > >> >> symbol and a matrix symbol is when expr.subs(x, matrix) is > >> >> done. Possibly, > >> >> this could be achieved only by adding some code to the subs function. > >> >> Instead of focussing on things like is_symmetric, > is_positive_definite > >> >> (which I agree, are useful), I think making expr.subs(x, matrix) work > >> >> should > >> >> be the first step. x here could be a regular non-commutative Symbol. > >> >> Even if its inelegant, i.e. involves making Add, Mul Matrix-aware, I > >> >> think > >> >> it would be good if we could try out stuff making .subs work for > >> >> matrices > >> >> by > >> >> adding code to the present core (.flatten, .subs, etc.). If we > succeed, > >> >> then > >> >> more code could be added to get more functionality, even if we don't > >> >> push > >> >> in > >> >> stuff to the master. Later if this successful, all the Matrix > >> >> expressions > >> >> code could be ported to a separate MatrixMul, MatrixAdd, etc. Making > >> >> new > >> >> classes that belong to the core for a small functionality feels like > >> >> overkill right now. > >> >> Have you tried anything out regarding this, Matthew ? > >> >> Regards, > >> >> Sherjil Ozair > >> >> > >> >> -- > >> >> You received this message because you are subscribed to the Google > >> >> Groups > >> >> "sympy" group. > >> >> To view this discussion on the web visit > >> >> https://groups.google.com/d/msg/sympy/-/uyTjPpzKQhQJ. > >> >> 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. > >> > > > > -- > > 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.
