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.
