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.
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 <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+unsubscribe@**googlegroups.com<sympy%2bunsubscr...@googlegroups.com>
>>>>> .
>>>>> For more options, visit this group at
>>>>> http://groups.google.com/**group/sympy?hl=en<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+unsubscribe@**
>>> googlegroups.com <sympy%2bunsubscr...@googlegroups.com>.
>>> For more options, visit this group at http://groups.google.com/**
>>> group/sympy?hl=en <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+unsubscribe@**
> googlegroups.com <sympy%2bunsubscr...@googlegroups.com>.
> For more options, visit this group at http://groups.google.com/**
> group/sympy?hl=en <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.
