Re: [GiNaC-devel] [GiNaC-list] multiplying a matrix with 0 makes it become a scalar 0
Dear all, concerning this question from the GiNaC-list: dummy-address@web.de schrieb:
cout << "(3*blah).evalm(): " << (3*blah).evalm() << endl; // output: // [[3*a], [3*b], [3*c]]
cout << "0*blah: " << 0*blah << endl; // output: // 0
seems to be a bug, and a rather old one (2000/2001). 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. Or we could introduce another info_flag for non-scalar objects (set by matrix then) and check for that flag? Any other ideas? Regards, Jens
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.
Hi, Alexei Sheplyakov schrieb:
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.
I completely agree.
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.
Mmmh, have to think about that. It looks like a good idea. But I am not sure about the implications, yet. In case we do this, the matrix stuff probably looks like an incomplete copy of one of the many existing LA packages. Maybe it can be removed completely then and replaced by some interface code to an existing LA package? Regards, Jens
Hi! Jens Vollinga wrote:
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.
Mmmh, have to think about that. It looks like a good idea. But I am not sure about the implications, yet. In case we do this, the matrix stuff probably looks like an incomplete copy of one of the many existing LA packages. Maybe it can be removed completely then and replaced by some interface code to an existing LA package?
I don't know of any existing LA package that works well in the symbolic domain. As a matter of fact, the rules of the game turn out to be quite different from the numeric domain, in terms of complexity. You wouldn't want to bother about Bareiss elimination and such things when considering only numbers. (This is one of the traps about symbolic computation, people keep running into. Cf. the IMHO bad textbook by Steeb and Shi.) OTOH, I don't really oversee the pros and cons of making matrix a standalone type. It could enhance things, or it could make things more cumbersome. One would have to give it a try and see how things work out. Cheers -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
participants (3)
-
Alexei Sheplyakov
-
Jens Vollinga
-
Richard B. Kreckel