Hello, On Mon, Sep 22, 2008 at 11:52:01AM +0200, Jens Vollinga wrote:
seems to be a bug, and a rather old one (2000/2001).
It's kind of feature. GiNaC's type system is extremely weak: a*b is a mul (or ncmul), no matter what was the type of a or b. Likewise, a + b is an add, no matter what was the type of a or b. IOW, GiNaC expressions are essentialy typeless. I think this is a problem, and not only for aesthetic reasons. Very often we need to recover the type information at the run time, which is usually a bit expensive. For example, have a look at the mul::expand. Here we need to recover the type information to make sure we treat the indexed expressions properly. Doing this at the run time is rather expensive, and it can't be done at the compile time because of the absence of proper type system. The same applies to eval_indexed() (which needs to check if the expression is consistent) and other functions/methods. On the other hand, mathematically consistent type system would be very complicated and annoying (have a look at Axiom). So I don't know how to solve this problem properly.
My only idea at the moment is to check explicitly for matrices in the epvector (mul.cpp lines 428-430) which is kind of stupid.
I don't quite like this idea. This check would slow down evaluation of each mul object. In particular, it would slow down evaluation of 0*some_huge_expression. I don't think this is acceptable.
Or we could introduce another info_flag for non-scalar objects (set by matrix then) and check for that flag? Any other ideas?
What about making matrix a stand alone type (as opposed to being subclass of basic)? The code dealing with matrices is very different from everything else anyway. Best regards, Alexei -- All science is either physics or stamp collecting.