@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 < [email protected]> wrote: > On Jun 28, 4:32 am, 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 > > > > 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 [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.
