I don't remember enough of the details to give you a comprehensive answer.
Here are a few thoughts that come to mind.
You won't be able to change much of the Add and Mul code to handle Vectors.
For example you won't be able to add shape checking at construction time.
This forces you to follow the "Garbage in, Garbage out" philosophy (which
isn't necessarily bad)
In [18]: A = MatrixSymbol('A', n, 1)
In [19]: B = MatrixSymbol('B', m, 1)
In [20]: x = Symbol('x')
In [21]: Add(x, A, B)
Out[21]: x + A + B
In [22]: MatAdd(x, A, B)
TypeError: Mix of Matrix and Scalar symbols
In [23]: MatAdd(A, B)
ShapeError: Matrices A and B are not aligned
Add and Mul inherit from Expr. The Expr codebase in general assumes that
its elements are scalars. This pops up in many of the methods on Expr
classes.
In [26]: Mul(A, A, B)
AttributeError: 'MatrixSymbol' object has no attribute 'as_base_exp'
I really don't think I should have to implement as_base_exp for matrices
but I do if I want to use Mul. Actually this sort of thing usually isn't
so bad, the defaults you get from inheriting from Expr are reasonable. I
remember having lots of trouble with some of the more aggressive scalar
functions. People kept using expand and factor on matrix expressions.
They sometimes got errors and filed bug reports that were very difficult
to resolve without completely rewriting these functions to be more general.
Using Mul and Add is fine. It'll work for a while. Every once in a while
you'll come across a wart. I'm personally biased against the Expr
codebase; I think it's the result of a lot of glomming on of special cased
code. By my aesthetic MatrixExprs are a lot cleaner and more extensible.
I'm personally happy with the choice *not* to inherit from Expr. Other
groups have gone other ways though. You could look at physics.quantum if
you wanted to see how Exprs work on non-scalars.
Also, just a thought, but if you're just using vectors you could presumably
build off of MatrixExprs. The container classes (MatAdd, MatMul) make very
few assumptions about the things they hold other than that they are Basics
and have a shape.
On Thu, Jun 13, 2013 at 1:52 AM, Prasoon Shukla <prasoon92.i...@gmail.com>wrote:
> @Matthew Rocklin:
>
> Can you please tell what exactly would be the advantage of having a
> separate VectAdd class? I mean I don't see the problems with using the
> current Add and Mul classes.
>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sympy+unsubscr...@googlegroups.com.
> To post to this group, send email to sympy@googlegroups.com.
> Visit this group at http://groups.google.com/group/sympy?hl=en-US.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy?hl=en-US.
For more options, visit https://groups.google.com/groups/opt_out.
