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 <mrock...@gmail.com> 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 <asmeu...@gmail.com> 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 <mrock...@gmail.com> >> 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 <sherjiloz...@gmail.com> >> > 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 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. >> > > -- > 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.
