[GiNaC-devel] multiplying a matrix with 0 makes it become a scalar 0
varg at theor.jinr.ru
Mon Sep 22 17:10:36 CEST 2008
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.
All science is either physics or stamp collecting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 827 bytes
Desc: Digital signature
Url : http://www.cebix.net/pipermail/ginac-devel/attachments/20080922/f0e4af80/attachment.sig
More information about the GiNaC-devel