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.
