There was some discussion of this in the sage group. The code will also work
in SymPy:
http://ask.sagemath.org/question/505/symbolic-matrices
(also see
http://stackoverflow.com/questions/5708208/symbolic-matrices-in-mathematica-with-unknown-dimensions/5710838
)
This type of approach seems to be
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
On Jun 27, 5:54 pm, Matthew Rocklin 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 method
On Jun 28, 4:32 am, Matthew Rocklin 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.
>
> Ho
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
There is something I'm doing as part of my project which maybe be
useful. I'm implementing a Matrix_ wrapper class which will wrap over
low-level matrices. Its being written to replace the current Matrix
class. Algorithmic code and user-level code is being separated into
different classes. Currentl
On Jul 13, 7:25 am, Aaron Meurer wrote:
> One thing that I have noticed with regard to overriding __mul__ and
> __rmul__ (for example) is that you can never completely control what
> happens to your class because of association. For example, suppose
> that A and B are MatrixExprs and x is some Ex
@Simon: Thanks for the pointer to those pages. They're good to look through
@Aaron: Hrm, yes getting Muls and Adds and such to recognize matrices
is quite a hurdle. Should I shy away from adding to flatten()?
Alternatively I could subclass all of these into MatrixExpr, MatrixMul
(MatMul?), MatrixA
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
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.wiki
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 tho
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
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 wrote:
> Option 3 might work. You should talk to Brian Granger about the
> advanta
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
@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 (o
As I pointed out in the other thread, non-commutative differentiation
already works in SymPy, so doing this should not be difficult.
Aaron Meurer
On Thu, Jun 30, 2011 at 1:58 AM, Amit wrote:
> Hi,
>
> I am not familiar with the internals of sympy. But I suggest that if
> you start working on the
Differentiation would only work with a scalar (communicative)
differentiation operator. If the matrix function is a function of a
vector or matrix one would have to define the directional derivative for
each case (which would be a scalar differential operator) and use the
results of that opera
I agree that support for derivatives on matrices is important; I would like
this myself. I haven't thought much about it in the context of SymPy before
though so thank you for bringing it up.
I haven't solidified my understanding of this problem but it seems like
there are a few concepts of a deri
On Thu, Jun 30, 2011 at 7:17 AM, Matthew Rocklin wrote:
> I agree that support for derivatives on matrices is important; I would like
> this myself. I haven't thought much about it in the context of SymPy before
> though so thank you for bringing it up.
> I haven't solidified my understanding of t
Where is the best place to read about the new assumptions system?
On Thu, Jun 30, 2011 at 1:18 PM, Aaron Meurer wrote:
> On Thu, Jun 30, 2011 at 7:17 AM, Matthew Rocklin
> wrote:
> > I agree that support for derivatives on matrices is important; I would
> like
> > this myself. I haven't thought
Le jeudi 30 juin 2011 à 13:25 -0500, Matthew Rocklin a écrit :
> Where is the best place to read about the new assumptions system?
I'm afraid that the best place is the source code in sympy/assumptions/.
I'm not aware of any comprehensive and current write-up on the new
assumptions.
>
> On Thu, J
There's some info at http://docs.sympy.org/0.7.0/modules/assumptions.html.
Aaron Meurer
On Thu, Jun 30, 2011 at 12:35 PM, Ronan Lamy wrote:
> Le jeudi 30 juin 2011 à 13:25 -0500, Matthew Rocklin a écrit :
>> Where is the best place to read about the new assumptions system?
>
> I'm afraid that th
It looks like the assumptions system would be a good place for the fancy
matrix questions (positive definite, invertible, etc...). I'm not sure that
it's appropriate for shape though.
I'm going to boldly propose that we add shape as a property to the core Expr
class. It won't be checked as operati
On Sun, Jul 3, 2011 at 1:41 PM, Matthew Rocklin wrote:
> It looks like the assumptions system would be a good place for the fancy
> matrix questions (positive definite, invertible, etc...). I'm not sure that
> it's appropriate for shape though.
> I'm going to boldly propose that we add shape as a
Hrm, I'm feeling blocked on this issue. I'd really like to be able to
generate matrix expressions for the next section of my project and I'd like
them to be able to do some things beyond what should go into the standard
Expr class.
Do I have any options here other than to wait until the broader Sy
Matthew,
On Thu, Jul 7, 2011 at 10:18 AM, Matthew Rocklin wrote:
> Hrm, I'm feeling blocked on this issue. I'd really like to be able to
> generate matrix expressions for the next section of my project and I'd like
> them to be able to do some things beyond what should go into the standard
> Expr
How do you envision symbolic block matrices working? Inversers and
transposes are trivial to implement (see my previous replies to this
thread).
Aaron Meurer
On Thu, Jul 7, 2011 at 4:02 PM, Matthew Rocklin wrote:
> "Other than shape checking, what types of things do you need to do?"
> Good ques
On Thu, Jul 7, 2011 at 8:03 PM, Matthew Rocklin wrote:
> In an ideal world they would probably subclass an immutable matrix and use
> an immutable matrix for storage. This brings up deeper questions.
> My main thesis here though is that we should start a matrix expression
> section of SymPy becaus
Yes, that's what I figured. Perhaps rather than being a ground type,
it should be implemented at the level of LIL and DOK (what do you call
this?). In other words, have a special representation of matrices that
works with block matrices. It could probably be dense in nature,
since block matrices
On Fri, Jul 8, 2011 at 4:00 AM, SherjilOzair wrote:
> There is something I'm doing as part of my project which maybe be
> useful. I'm implementing a Matrix_ wrapper class which will wrap over
> low-level matrices. Its being written to replace the current Matrix
> class. Algorithmic code and user-l
Subclassing Expr has some issues as well. This is what Brian was referring
to. Within all of our code we use Add and Mul and don't check if instead we
should use some subclass of Add or subclass of Mul. If I feed a matrix
expression into these objects then the special matrix structure is lost.
This
One thing that I have noticed with regard to overriding __mul__ and
__rmul__ (for example) is that you can never completely control what
happens to your class because of association. For example, suppose
that A and B are MatrixExprs and x is some Expr object (say, a
Symbol). Suppose that A*B shou
I have op_priority set to 11 so that basic arithmetic operations do use
MatMuls and MatAdds. MatMul and MatAdd check shape, then call regular
Mul/Add __new__ methods to take advantage of the already built flattening
functions. After that's done they go through and change classes back to
MatMul/MatA
Matthew,
Arron has provided a fantastic summary of the issues involve. The
summary is that even if you subclass Add/Mul/Pow, sympy will end up
creating expressions that don't use your subclasses everywhere. This
can't be fixed without changing the core, which is outside the scope
of your project
Matthew,
On Wed, Jul 13, 2011 at 6:39 AM, Matthew Rocklin wrote:
> I have op_priority set to 11 so that basic arithmetic operations do use
> MatMuls and MatAdds. MatMul and MatAdd check shape, then call regular
> Mul/Add __new__ methods to take advantage of the already built flattening
> function
Le mercredi 13 juillet 2011 à 10:51 -0700, Brian Granger a écrit :
> Matthew,
>
> Arron has provided a fantastic summary of the issues involve. The
> summary is that even if you subclass Add/Mul/Pow, sympy will end up
> creating expressions that don't use your subclasses everywhere. This
> can't
On Wed, Jul 13, 2011 at 11:19 AM, Ronan Lamy wrote:
> Le mercredi 13 juillet 2011 à 10:51 -0700, Brian Granger a écrit :
>> Matthew,
>>
>> Arron has provided a fantastic summary of the issues involve. The
>> summary is that even if you subclass Add/Mul/Pow, sympy will end up
>> creating expressio
tsimp(expr)" statement? If this sort of thing
isn't acceptable and if we want to allow the user to call the standard
simplify function on matrix expressions then we have a problem.
-- Forwarded message --
From: Brian Granger
Date: Wed, Jul 13, 2011 at 12:53 PM
Subject: Re: [symp
On Wed, Jul 13, 2011 at 1:19 PM, Ronan Lamy wrote:
> Le mercredi 13 juillet 2011 à 10:51 -0700, Brian Granger a écrit :
>> Matthew,
>>
>> Arron has provided a fantastic summary of the issues involve. The
>> summary is that even if you subclass Add/Mul/Pow, sympy will end up
>> creating expression
My suggestion would be to continue with the matrixify solution and
write functions to fix up the expression tree as need be. The whole
issue of making Add/Mul/Pow extensible is separate but the logic can
be transferred pretty easily.
-- Andy
On Wed, Jul 13, 2011 at 1:44 PM, Aaron Meurer wrote:
On Fri, Jul 15, 2011 at 9:17 AM, Andy Ray Terrel wrote:
> My suggestion would be to continue with the matrixify solution and
> write functions to fix up the expression tree as need be. The whole
> issue of making Add/Mul/Pow extensible is separate but the logic can
> be transferred pretty easily.
Hi,
On 16 July 2011 00:12, Ondrej Certik wrote:
> On Fri, Jul 15, 2011 at 9:17 AM, Andy Ray Terrel
> wrote:
> > My suggestion would be to continue with the matrixify solution and
> > write functions to fix up the expression tree as need be. The whole
> > issue of making Add/Mul/Pow extensible
I like your use of the phrase "interpretation of Matrix Expressions." It
makes it clear that we all probably have very different ideas for what
Matrix Expressions should be. Hopefully there is a system which can handle a
wide variety of needs.
My current branch is here
https://github.com/mrocklin/
I think your implementations are completely different, though perhaps
they could be merged. Mateusz's implementation is more about allowing
unevaluated functions on Matrices, whereas Matthews is more about
expressions where the variables are to be understood as matrices (I
use this instead of the
Hi,
On 30 July 2011 07:27, Aaron Meurer wrote:
> I think your implementations are completely different, though perhaps
> they could be merged. Mateusz's implementation is more about allowing
> unevaluated functions on Matrices, whereas Matthews is more about
> expressions where the variables ar
Also, Mateusz's MatrixExpr should be renamed to ImmutableMatrix.
Aaron Meurer
On Fri, Jul 29, 2011 at 11:27 PM, Aaron Meurer wrote:
> I think your implementations are completely different, though perhaps
> they could be merged. Mateusz's implementation is more about allowing
> unevaluated funct
On Sat, Jul 30, 2011 at 2:31 AM, Mateusz Paprocki wrote:
> I'm sure that, sooner or later, those approaches will have to be merged,
> because those are really two views of a very similar (if not the same)
> problem domain. My original motivation came from reading lecture notes
> for undergraduate
On Sat, Jul 30, 2011 at 1:40 AM, Tim Lahey wrote:
> On Sat, Jul 30, 2011 at 2:31 AM, Mateusz Paprocki wrote:
>
>> I'm sure that, sooner or later, those approaches will have to be merged,
>> because those are really two views of a very similar (if not the same)
>> problem domain. My original motiv
I see that Andy just posted while I was writing. I'll post anyway although
Ii thnk maybe the wiki page is a better start.
It seems like we have a few people who want to contribute to the same
concept. Should we put something on the master branch so that people can
start adding to it?
What would a
Start of a wiki-page is here if people want to go this route. I put down the
things that I think about.
https://github.com/sympy/sympy/wiki/Matrix-Expressions
I'm also happy to continue the conversation over e-mail.
What would be a good next step? How can I stimulate activity on this topic?
On S
On 08/02/2011 10:10 AM, Matthew Rocklin wrote:
Start of a wiki-page is here if people want to go this route. I put
down the things that I think about.
https://github.com/sympy/sympy/wiki/Matrix-Expressions
I'm also happy to continue the conversation over e-mail.
What would be a good next step?
Will do!
As a disclaimer I don't actually teach Linear Algebra (though I respect
those who do). The narratives posted are fictitious. I'm hypothesizing why
people might want Matrix Expressions.
On Tue, Aug 2, 2011 at 9:58 AM, Alan Bromborsky wrote:
> **
> On 08/02/2011 10:10 AM, Matthew Rocklin
On Tue, Aug 2, 2011 at 9:00 AM, Matthew Rocklin wrote:
> Will do!
> As a disclaimer I don't actually teach Linear Algebra (though I respect
> those who do). The narratives posted are fictitious. I'm hypothesizing why
> people might want Matrix Expressions.
That's a little misleading. Maybe you s
53 matches
Mail list logo
