Where is the best place to read about the new assumptions system?
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.
