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 <[email protected]> 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 <[email protected]> wrote: >> >> Matthew, >> >> On Thu, Jul 7, 2011 at 10:18 AM, Matthew Rocklin <[email protected]> >> 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 <[email protected]> >> > wrote: >> >> >> >> On Sun, Jul 3, 2011 at 1:41 PM, Matthew Rocklin <[email protected]> >> >> 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 <[email protected]> >> >> > 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 <[email protected]> >> >> >> 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 >> >> >> >> <[email protected]> >> >> >> >> wrote: >> >> >> >> >> >> >> >> On Thu, Jun 30, 2011 at 7:17 AM, Matthew Rocklin >> >> >> >> <[email protected]> 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 >> >> >> >> <[email protected]> >> >> >> >> > 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<[email protected]> >> >> >> >> 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<[email protected]> >> >> >> >> 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< >> >> >> >> >>>>> >> >> >> >> >>>>> >> >> >> >> >>>>> >> >> >> >> >>>>> >> >> >> >> >>>>> >> >> >> >> >>>>> >> >> >> >> >>>>> >> >> >> >> >>>>> [email protected]> wrote: >> >> >> >> >>>>>> >> >> >> >> >>>>>> On Jun 28, 4:32 am, Matthew >> >> >> >> Rocklin<[email protected]> 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 >> >> >> >> [email protected]. >> >> >> >> >>>>>> To unsubscribe from this group, send email to >> >> >> >> >>>>>> [email protected]. >> >> >> >> >>>>>> 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 >> >> >> >> [email protected]. >> >> >> >> >>>> To unsubscribe from this group, send email to >> >> >> >> >>>> [email protected]. >> >> >> >> >>>> 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 >> >> >> >> [email protected]. >> >> >> >> >> To unsubscribe from this group, send email to >> >> >> >> >> [email protected]. >> >> >> >> >> 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 >> >> >> >> [email protected]. >> >> >> >> > To unsubscribe from this group, send email to >> >> >> >> > [email protected]. >> >> >> >> > 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 >> >> >> >> [email protected]. >> >> >> >> To unsubscribe from this group, send email to sympy >> >> >> >> [email protected]. >> >> >> >> 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 [email protected]. >> >> >> >> To unsubscribe from this group, send email to sympy >> >> >> >> [email protected]. >> >> >> >> 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 [email protected]. >> >> >> > To unsubscribe from this group, send email to >> >> >> > [email protected]. >> >> >> > 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 [email protected]. >> >> >> To unsubscribe from this group, send email to >> >> >> [email protected]. >> >> >> 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 [email protected]. >> >> > To unsubscribe from this group, send email to >> >> > [email protected]. >> >> > 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 >> >> [email protected] and [email protected] >> >> >> >> -- >> >> You received this message because you are subscribed to the Google >> >> Groups >> >> "sympy" group. >> >> To post to this group, send email to [email protected]. >> >> To unsubscribe from this group, send email to >> >> [email protected]. >> >> 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 [email protected]. >> > To unsubscribe from this group, send email to >> > [email protected]. >> > 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 >> [email protected] and [email protected] >> >> -- >> You received this message because you are subscribed to the Google Groups >> "sympy" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> 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 [email protected]. > To unsubscribe from this group, send email to > [email protected]. > 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
