Am 06.05.2012 00:47, schrieb [email protected]:
To continue on what Joachim and Aaron started discussing:
"Add" and co. do not support Basic but they do support Expr.
Would it make sense for them to support Basic?
If it would, it's something that should be implemented as throwing a
NotYetImplemented exception for now and be fixed later.
Wheter it makes sense or not depends on what Basic's nature is supposed
to be. That's why I advocated defining the role of each class.
Keeping this in mind should any of the following subclass Expr instead of Basic:
1) AbstractVector (from an imaginary abstract linear algebra module)
- I think that it should subclass Expr so we can have sums of
AbstractVectors and products of scalars times AbstractVectors
- Something should check that we do not create nonsensical stuff like
scalar to the power of AbstractVector but this is rather tangential to
the discussion
2) MatrixSymbol - same arguments as for 1)
3) Manifold (from my gsoc project)
- we want Cartesian products of manifolds. Is this Mul? I think not.
Then we subclass from Basic
I think we have two choices here:
1) Have everything in Basic and let it detect the types.
2) Split each kind of mathematical object into a subclass.
That choice isn't clearcut. Either design can go awfully wrong, but you
don't know which one will work out better before you actually try.
(Sometimes you use both: a single central class plus
per-mathematical-object helper classes that get specific operations
delegated to. That's a rather complicated setup that you use only after
the other two approaches have failed.)
--
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.
