Matthew,
On Thu, Jul 7, 2011 at 10:18 AM, Matthew Rocklin <mrock...@gmail.com> 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 class.
Other than shape checking, what types of things do you need to do?
> Do I have any options here other than to wait until the broader SymPy
> community decides what it's going to do about smarter handling of subclassed
> Expr's?
> Brian, you strongly recommend against subclassing Expr. Have you come up
> with a decent temporary alternative for the physics branch?
I may have said confusing things previously. I do think that
subclassing Expr is OK, just to override methods like
__mul__/__add__/__pow__ to provide custom Mul/Add/Pow logic. Here is
how we handle this...
We simply put the additional logic in standalone functions that walk
an expression tree and perform the needed logic. Something like this:
A = Matrix('A', (4,4))
B = Matrix('B', (4,4))
c = A*B
check_shape(c)
Here Matrix would be a custom subclass of Expr, that has the shape
information in args, but it wouldn't have any custom Mul/Pow/Add logic
implemented.
We have found this approach to be extremely simple to implement and
fully functional as well. For details of how we do this in the
quantum stuff see:
For our subclasses of Expr:
sympy.physics.quantum.qexpr
sympy.physics.quantum.state
sympy.physics.quantum.operator
For our functions that walk expressions:
sympy.physics.quantum.qapply
sympy.physics.quantum.represent
> I could look into fixing the larger SymPy issue. Is this likely beyond my
> scope?
Yes, I think it would be a much larger effort than you project would allow for.
Cheers,
Brian
> If anyone has suggestions I'm happy to hear them.
> Right now I think my best course of action is to continue subclassing Expr
> very very carefully.
> -Matt
>
> On Mon, Jul 4, 2011 at 12:29 AM, Brian Granger <elliso...@gmail.com> wrote:
>>
>> On Sun, Jul 3, 2011 at 1:41 PM, Matthew Rocklin <mrock...@gmail.com>
>> 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 property to the core
>> > Expr
>> > class. It won't be checked as operations happen (to optimize speed for
>> > the
>> > common non-matrix case) but will be computed on demand and raise errors
>> > at
>> > that time if things are misaligned. I might also push for a is_Matrix
>> > flag.
>> > i.e.
>>
>> I am -1 on putting shape into Expr itself. It is too specialized to
>> be there. It should only be in the classes that actually have shape
>> information. I agree though that we need to enhance sympy to know
>> about such things, but that logic type of logic should be in Mul and
>> should not be narrowly focused on shape but should include the
>> handling of all types that need custom logic upon multiplication.
>>
>> As I have said before, I would forget about shape checking *entirely*
>> at this point in the game though so you can focus on the more
>> interesting and relevant aspects of this work. Once sympy is extended
>> in the right way, you will get shape checking almost for free...
>>
>> Cheers,
>>
>> Brian
>>
>>
>>
>> >>>> A = MatrixSymbol('A', 3, 4)
>> >>>> B = MatrixSymbol('B', 4, 7)
>> >>>> C = 2*A*B # Nothing matrix-y happens here
>> >>>> C.shape # Shape is checked here
>> > (3, 7)
>> >>>> D = 1 + B*A # This passes even though it's invalid
>> >>>> D.shape # Error is found when asking for the shape
>> > ShapeError(....
>> >>>> print Symbol('x').shape # Normal expressions have no shape
>> > None
>> > I don't think this will affect computation at all for non-matrix
>> > situations.
>> > It adds a minimal amount of code complexity to the Add, Mul, Pow, etc...
>> > classes.
>> > I'm going to write something up for review later tonight. Please someone
>> > stop me if this is a poor idea.
>> > On Thu, Jun 30, 2011 at 6:14 PM, Aaron Meurer <asmeu...@gmail.com>
>> > wrote:
>> >>
>> >> 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 <ronan.l...@gmail.com>
>> >> 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 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, Jun 30, 2011 at 1:18 PM, Aaron Meurer <asmeu...@gmail.com>
>> >> >> wrote:
>> >> >>
>> >> >> On Thu, Jun 30, 2011 at 7:17 AM, Matthew Rocklin
>> >> >> <mrock...@gmail.com> 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 this problem but
>> >> >> it
>> >> >> seems like
>> >> >> > there are a few concepts of a derivative here.
>> >> >> >
>> >> >> > Given a matrix expression we can differentiate with
>> >> >> respect
>> >> >> to the various
>> >> >> > matrices themselves. This is likely very similar to
>> >> >> Aaron's
>> >> >> example using
>> >> >> > stock SymPy with non-commutative symbols. This should (I
>> >> >> think) work out of
>> >> >> > the box
>> >> >> > Given a function on vector valued inputs with possible
>> >> >> vector valued outputs
>> >> >> > we can define directional derivatives. I think this is
>> >> >> what
>> >> >> Alan is talking
>> >> >> > about. In this situation the objects can easily become
>> >> >> high
>> >> >> rank (Hessians
>> >> >> > of vector-valued functions are not matrices). This leads
>> >> >> me
>> >> >> to the idea that
>> >> >> > we should consider mathematical Tensors rather than
>> >> >> matrices.
>> >> >> >
>> >> >> > The tensor vs matrix issue makes me nervous. There is a
>> >> >> lot
>> >> >> of special stuff
>> >> >> > happening on rank two tensors (matrices) that we rarely
>> >> >> care
>> >> >> about at higher
>> >> >> > ranks. Maybe this work should be done on a Tensor class
>> >> >> and
>> >> >> Matrices should
>> >> >> > subclass Tensors? This is getting beyond the scope of what
>> >> >> I
>> >> >> was looking for
>> >> >> > with a Matrix Symbol. I probably won't pursue this
>> >> >> enhancement in the near
>> >> >> > future but would be happy to support someone else's
>> >> >> effort.
>> >> >> > For the moment I'm not working on Matrix Expressions
>> >> >> actually. I'm a bit
>> >> >> > stuck on how to proceed and would welcome any
>> >> >> suggestions. The best idea I
>> >> >> > have now is to insert symbols into standard sympy Exprs
>> >> >> and
>> >> >> have aspects
>> >> >> > like shape and is_invertible be functions which are called
>> >> >> on the Expr tree
>> >> >> > rather than fields or methods of the object. This will
>> >> >> fail
>> >> >> to raise
>> >> >> > exceptions when illegal operations are performed but
>> >> >> should
>> >> >> get the job
>> >> >> > done. The Indexed class is somewhat similar in flavor.
>> >> >>
>> >> >>
>> >> >> This is something that you would (hopefully) be able to do
>> >> >> with the
>> >> >> new assumptions system. In other words, without having to
>> >> >> modify the
>> >> >> core, you should be able to say ask(Q.invertable(A*B)) and
>> >> >> it
>> >> >> would
>> >> >> determine it based on whether you set A and B to be
>> >> >> invertible. Shape
>> >> >> should work too, though I'm not sure if the system can
>> >> >> currently
>> >> >> handle non-boolean assumptions (someone else will have to
>> >> >> fill
>> >> >> in
>> >> >> here).
>> >> >>
>> >> >> By the way, is_invertible is perhaps something that could be
>> >> >> implemented in the core directly, so you could have support
>> >> >> for
>> >> >> non-invertible symbols in any case. It should just be a
>> >> >> matter of
>> >> >> making ._eval_power do the right thing in any case.
>> >> >>
>> >> >>
>> >> >> Aaron Meurer
>> >> >>
>> >> >>
>> >> >> >
>> >> >> >
>> >> >> > On Thu, Jun 30, 2011 at 7:05 AM, Alan Bromborsky
>> >> >> <abro...@verizon.net>
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> 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
>> >> >> >> operation to determine the properties of a vector or
>> >> >> matrix
>> >> >> derivative.
>> >> >> >> Note that determining the operator properties would also
>> >> >> require a
>> >> >> >> definition for the scalar product of vectors and
>> >> >> matrices.
>> >> >> >>
>> >> >> >> Consider the vector directional derivative of a matrix M
>> >> >> that is the
>> >> >> >> function of a vector v, M(v), then if a is an arbitrary
>> >> >> vector (LaTeX
>> >> >> >> expression) the definition of the directional derivative
>> >> >> would be
>> >> >> >>
>> >> >> >> a\cdot\nabla M(v) \equiv \lim_{h \rightarrow 0}\frac{M(v
>> >> >> +ha)-M(v)}{h}
>> >> >> >>
>> >> >> >>
>> >> >> >> from this the properties of \nabla M(v) could be
>> >> >> determined
>> >> >> and if v is
>> >> >> >> expanded in a arbitrary basis the \nabla operator could
>> >> >> also be expanded. A
>> >> >> >> similar treatment is possible for a matrix that is a
>> >> >> function of a matrix if
>> >> >> >> the scalar product of two matrices is defined.
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> On 06/30/2011 04:20 AM, Aaron Meurer wrote:
>> >> >> >>>
>> >> >> >>> 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<amiti...@gmail.com>
>> >> >> wrote:
>> >> >> >>>>
>> >> >> >>>> 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.
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>
>> >> >> >> --
>> >> >> >> 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.
>> >> >
>> >> >
>> >> > --
>> >> > 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.
>> >
>>
>>
>>
>> --
>> Brian E. Granger
>> Cal Poly State University, San Luis Obispo
>> bgran...@calpoly.edu and elliso...@gmail.com
>>
>> --
>> 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.
>
--
Brian E. Granger
Cal Poly State University, San Luis Obispo
bgran...@calpoly.edu and elliso...@gmail.com
--
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.
