On Sat, May 5, 2012 at 12:42 PM, [email protected] <[email protected]> wrote: > On 5 May 2012 20:34, Aaron Meurer <[email protected]> wrote: >> I think it is. Boolean, Set, Tuple, etc. all derive from Basic, not >> Expr. The issue is classes that derive from both Boolean and Expr, >> for example (such as Symbol). >> > > This is the result of a quick grep search. I posted only the classes > that look like subclassing Expr incorrectly. Especially the part in > `physics`, `tensor` and `matrix`. I really do not know what to make > out of this. Any comments will be appreciated. > > Also I would like to remark that neither Mathematica nor Lisp have the > notion of "expression limited to being only a complex number". I tend > to believe that such limitation is a bad idea, but I am not really > sure.
Well we do have Basic. The idea is to just separate the concepts, so for example, we can say Add(x, y) only makes sense for x and y that subclass from Expr (or can be coerced to a subclass of Expr). > > sympy/core/relational.py:class Relational(Expr, EvalfMixin): > sympy/core/function.py:class Lambda(Expr): > sympy/core/function.py:class Subs(Expr): > sympy/matrices/expressions/matexpr.py:class MatrixExpr(Expr): > sympy/physics/quantum/spin.py:class WignerD(Expr): > sympy/physics/quantum/qexpr.py:class QExpr(Expr): > sympy/physics/quantum/innerproduct.py:class InnerProduct(Expr): > sympy/physics/quantum/anticommutator.py:class AntiCommutator(Expr): > sympy/physics/quantum/tensorproduct.py:class TensorProduct(Expr): > sympy/physics/quantum/commutator.py:class Commutator(Expr): > sympy/physics/quantum/dagger.py:class Dagger(Expr): > sympy/physics/quantum/cg.py:class Wigner3j(Expr): > sympy/physics/quantum/cg.py:class Wigner6j(Expr): > sympy/physics/quantum/cg.py:class Wigner9j(Expr): > sympy/physics/gaussopt.py:class BeamParameter(Expr): > sympy/physics/secondquant.py:class Dagger(Expr): > sympy/physics/secondquant.py:class TensorSymbol(Expr): > sympy/physics/secondquant.py:class SqOperator(Expr): > sympy/physics/secondquant.py:class FockState(Expr): > sympy/physics/secondquant.py:class PermutationOperator(Expr): > sympy/series/order.py:class Order(Expr): > sympy/tensor/indexed.py:class Indexed(Expr): > sympy/tensor/indexed.py:class IndexedBase(Expr): > sympy/tensor/indexed.py:class Idx(Expr): I can't comment on the physics stuff. Likely much of it is wrong. I think Order is correct. O() doesn't represent a complex number, per se., but an arbitrary expression (on the complex numbers) that behaves a certain way at 0. Relational is probably wrong. At least the difference is not clear between that and Boolean. But that's http://code.google.com/p/sympy/issues/detail?id=1887. Lambda I'm not sure about. It seems to me that it should not be, because Lambda is not an Expr, Lambda(*args) is. The same for IndexedBase. Subs probably should just be Basic, because we can have Subs(Tuple, old, new), for example. MatrixExpr also raises a question. I guess we should try to come up with what exact invariants we want Expr objects to have (other than the ones also shared by Basic) and come up with a clearer definition than "something that is a complex number". I think that definition is wrong, because it doesn't consider things like non-commutative expressions, operators, or matrices. And we need to consider the move toward letting classes define how they behave themselves when used inside other classes (like Mul). Aaron Meurer -- 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.
