Hi, I am not familiar with the internals of sympy. But I suggest that if you start working on the implementation of symbolic matrices, you should take into consideration more complicated operators like differentiation. 'The Matrix Cookbook' has many matrix equalities that maybe can be implemented using some kind of pattern recognition.
Amit On Jun 28, 8:16 pm, Matthew Rocklin <mrock...@gmail.com> wrote: > @Brian - Thanks for the heads up Brian. I'll see what I can do with option > (1). My short term solution was to start a "matrixify" function a la > sympify. It would probably be too annoying to use everywhere though. > > @Vinzent - Where is a good place to start learning about the new assumption > system (or the old one... I'm not up to speed on these) > > On Tue, Jun 28, 2011 at 11:36 AM, Vinzent Steinberg < > > > > > > > > vinzent.steinb...@googlemail.com> wrote: > > On Jun 28, 4:32 am, 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 > > > > 1. 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) > > > 2. Enhance SymPy Expr's to play nice with Matrices > > > 3. 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. > > > I think all this '.is_*' stuff should rather be implemented using the > > new assumption system (not sure about shape, maybe this should really > > go into the core). If we use noncommutative symbols, I think we can > > avoid messing around with Mul and friends. > > > A.T could be implemented as a unary function. > > > Vinzent > > > -- > > 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.
