Matthew, I *strongly* recommend against subclassing Mul/Pow/Add as you will find that it is *impossible* even with op_priority to have your Mul/Pow/Add used all of the time. In a variety of contexts, you will *want* your subclasses to be used, but sympy's base Mul/Add/Pow will be used. There is no way to prevent this with the current design. Just use the sympy's existing Mul/Add/Pow and live with its limitations for now.
Cheers, Brian On Tue, Jun 28, 2011 at 9:00 AM, Matthew Rocklin <[email protected]> wrote: > 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. >> > > -- Brian E. Granger Cal Poly State University, San Luis Obispo [email protected] and [email protected] -- 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.
