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.
