Yes, that's what I figured. Perhaps rather than being a ground type,
it should be implemented at the level of LIL and DOK (what do you call
this?). In other words, have a special representation of matrices that
works with block matrices. It could probably be dense in nature,
since block matrices aren't generally very big. This could define the
methods that make sense on block matrices (like multiplication if the
block shapes work out), and raise NotImplementedError for the rest (or
however the other representations do this).
Aaron Meurer
On Fri, Jul 8, 2011 at 3:25 AM, Sherjil Ozair <sherjiloz...@gmail.com> wrote:
> Implementing symbolic block matrices by using matrices as groundtypes of
> Matrix is a reasonable idea. But, with the way I have planned groundtypes,
> it could only support homogenous blocks, i.e. the shape of each block should
> be the same. I can't think of an elegant way to implement non-homogenous
> block matrices using the groundtypes method, though.
> - Sherjil Ozair
>
> On Fri, Jul 8, 2011 at 7:45 AM, Aaron Meurer <asmeu...@gmail.com> wrote:
>>
>> 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.
>>
>
> --
> 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.
