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.
>>> 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.
