On Thu, Jul 7, 2011 at 8:03 PM, Matthew Rocklin <mrock...@gmail.com> wrote:
> In an ideal world they would probably subclass an immutable matrix and use
> an immutable matrix for storage. This brings up deeper questions.
> My main thesis here though is that we should start a matrix expression
> section of SymPy because there's lots of good math there and it's tricky to
> integrate it cleanly into pure SymPy expressions. An experimental MatrixExpr
> codebase would allow us to develop a bit more freely until SymPy Expr
> evolves to allow easy integration. I'm just dreaming here though. I don't
> have a firm picture of how all of this should fit into SymPy and rely on you
> guys to set me straight.
Well, you're right that it would be good to have an experimental code
base. You will learn much better what should and should not be done
by trying it and seeing what does and does not work than you will
sitting here discussing it. Those of us with more experience can
definitely direct you away from things that we can already see won't
work, but the only way to know the way you *should* do it is to try
implementing it.
Block matrices would be much more work than everything else, because
now you're combining your symbolic matrices with actual matrices,
which themselves would have to be extended to support such things.
Maybe MatrixExpr should just be added as a ground type to Matrix.
That might not be so easy to do, though, since most stuff isn't
written to take anything but shape 1x1 into account. I'd see what
Sherjil thinks about this.
Aaron Meurer
> Block matrices is just the example that came up yesterday - I'd like to
> write down a more general version of this. I suspect that there are many
> more things that I (and others) might want to do with symbolic matrix
> expressions which are tricky to integrate into pure SymPy expressions.
>
>
>
> On Thu, Jul 7, 2011 at 8:39 PM, Aaron Meurer <asmeu...@gmail.com> wrote:
>>
>> How do you envision symbolic block matrices working? Inversers and
>> transposes are trivial to implement (see my previous replies to this
>> thread).
>>
>> Aaron Meurer
>>
>> On Thu, Jul 7, 2011 at 4:02 PM, Matthew Rocklin <mrock...@gmail.com>
>> wrote:
>> > "Other than shape checking, what types of things do you need to do?"
>> > Good question, one to which I do not have an exhaustive answer. So far
>> > Inverses, Transpose, and symbolic block matrices are on the list. I
>> > expect
>> > this to grow as my use of it continues. This sort of thing is likely to
>> > be
>> > useful for me outside of my GSoC project and I'd like to think others
>> > might
>> > find it useful and contribute as well.
>> > I think it would be good for the growth of symbolic matrix expressions
>> > to
>> > not be constrained by the purity of the core.
>> > I do like the idea of standalone functions to check properties inside
>> > SymPy
>> > Expr's. This is what I do with Random Expressions (my GSoC project). My
>> > personal intuition is that Matrix operations are sufficiently distinct
>> > to
>> > warrant a further deviation from SymPy Expr's though. This is just
>> > intuition
>> > though.
>> > I suspect that this is a topic for which there exist many diverse
>> > opinions.
>> > What is the best way to balance making progress on my project and
>> > building
>> > something that the community will agree with? There are a number of old
>> > e-mails and issues about immutable matrices and such. Should I start an
>> > issue or new e-mail thread to get input?
>> > -Matt
>> > On Thu, Jul 7, 2011 at 12:56 PM, Brian Granger <elliso...@gmail.com>
>> > wrote:
>> >>
>> >> Matthew,
>> >>
>> >> On Thu, Jul 7, 2011 at 10:18 AM, Matthew Rocklin <mrock...@gmail.com>
>> >> wrote:
>> >> > Hrm, I'm feeling blocked on this issue. I'd really like to be able to
>> >> > generate matrix expressions for the next section of my project and
>> >> > I'd
>> >> > like
>> >> > them to be able to do some things beyond what should go into the
>> >> > standard
>> >> > Expr class.
>> >>
>> >> Other than shape checking, what types of things do you need to do?
>> >>
>> >> > Do I have any options here other than to wait until the broader SymPy
>> >> > community decides what it's going to do about smarter handling of
>> >> > subclassed
>> >> > Expr's?
>> >> > Brian, you strongly recommend against subclassing Expr. Have you come
>> >> > up
>> >> > with a decent temporary alternative for the physics branch?
>> >>
>> >> I may have said confusing things previously. I do think that
>> >> subclassing Expr is OK, just to override methods like
>> >> __mul__/__add__/__pow__ to provide custom Mul/Add/Pow logic. Here is
>> >> how we handle this...
>> >>
>> >> We simply put the additional logic in standalone functions that walk
>> >> an expression tree and perform the needed logic. Something like this:
>> >>
>> >> A = Matrix('A', (4,4))
>> >> B = Matrix('B', (4,4))
>> >>
>> >> c = A*B
>> >> check_shape(c)
>> >>
>> >> Here Matrix would be a custom subclass of Expr, that has the shape
>> >> information in args, but it wouldn't have any custom Mul/Pow/Add logic
>> >> implemented.
>> >>
>> >> We have found this approach to be extremely simple to implement and
>> >> fully functional as well. For details of how we do this in the
>> >> quantum stuff see:
>> >>
>> >> For our subclasses of Expr:
>> >>
>> >> sympy.physics.quantum.qexpr
>> >> sympy.physics.quantum.state
>> >> sympy.physics.quantum.operator
>> >>
>> >> For our functions that walk expressions:
>> >>
>> >> sympy.physics.quantum.qapply
>> >> sympy.physics.quantum.represent
>> >>
>> >> > I could look into fixing the larger SymPy issue. Is this likely
>> >> > beyond
>> >> > my
>> >> > scope?
>> >>
>> >> Yes, I think it would be a much larger effort than you project would
>> >> allow
>> >> for.
>> >>
>> >> Cheers,
>> >>
>> >> Brian
>> >>
>> >> > If anyone has suggestions I'm happy to hear them.
>> >> > Right now I think my best course of action is to continue subclassing
>> >> > Expr
>> >> > very very carefully.
>> >> > -Matt
>> >> >
>> >> > On Mon, Jul 4, 2011 at 12:29 AM, Brian Granger <elliso...@gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> On Sun, Jul 3, 2011 at 1:41 PM, Matthew Rocklin <mrock...@gmail.com>
>> >> >> wrote:
>> >> >> > It looks like the assumptions system would be a good place for the
>> >> >> > fancy
>> >> >> > matrix questions (positive definite, invertible, etc...). I'm not
>> >> >> > sure
>> >> >> > that
>> >> >> > it's appropriate for shape though.
>> >> >> > I'm going to boldly propose that we add shape as a property to the
>> >> >> > core
>> >> >> > Expr
>> >> >> > class. It won't be checked as operations happen (to optimize speed
>> >> >> > for
>> >> >> > the
>> >> >> > common non-matrix case) but will be computed on demand and raise
>> >> >> > errors
>> >> >> > at
>> >> >> > that time if things are misaligned. I might also push for a
>> >> >> > is_Matrix
>> >> >> > flag.
>> >> >> > i.e.
>> >> >>
>> >> >> I am -1 on putting shape into Expr itself. It is too specialized to
>> >> >> be there. It should only be in the classes that actually have shape
>> >> >> information. I agree though that we need to enhance sympy to know
>> >> >> about such things, but that logic type of logic should be in Mul and
>> >> >> should not be narrowly focused on shape but should include the
>> >> >> handling of all types that need custom logic upon multiplication.
>> >> >>
>> >> >> As I have said before, I would forget about shape checking
>> >> >> *entirely*
>> >> >> at this point in the game though so you can focus on the more
>> >> >> interesting and relevant aspects of this work. Once sympy is
>> >> >> extended
>> >> >> in the right way, you will get shape checking almost for free...
>> >> >>
>> >> >> Cheers,
>> >> >>
>> >> >> Brian
>> >> >>
>> >> >>
>> >> >>
>> >> >> >>>> A = MatrixSymbol('A', 3, 4)
>> >> >> >>>> B = MatrixSymbol('B', 4, 7)
>> >> >> >>>> C = 2*A*B # Nothing matrix-y happens here
>> >> >> >>>> C.shape # Shape is checked here
>> >> >> > (3, 7)
>> >> >> >>>> D = 1 + B*A # This passes even though it's invalid
>> >> >> >>>> D.shape # Error is found when asking for the shape
>> >> >> > ShapeError(....
>> >> >> >>>> print Symbol('x').shape # Normal expressions have no shape
>> >> >> > None
>> >> >> > I don't think this will affect computation at all for non-matrix
>> >> >> > situations.
>> >> >> > It adds a minimal amount of code complexity to the Add, Mul, Pow,
>> >> >> > etc...
>> >> >> > classes.
>> >> >> > I'm going to write something up for review later tonight. Please
>> >> >> > someone
>> >> >> > stop me if this is a poor idea.
>> >> >> > On Thu, Jun 30, 2011 at 6:14 PM, Aaron Meurer <asmeu...@gmail.com>
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> 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.
>> >> >> >>
>> >> >> >
>> >> >> > --
>> >> >> > 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.
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Brian E. Granger
>> >> >> Cal Poly State University, San Luis Obispo
>> >> >> bgran...@calpoly.edu and elliso...@gmail.com
>> >> >>
>> >> >> --
>> >> >> 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.
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Brian E. Granger
>> >> Cal Poly State University, San Luis Obispo
>> >> bgran...@calpoly.edu and elliso...@gmail.com
>> >>
>> >> --
>> >> 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.
