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.
