"CD" == Chris Dams <Chris.Dams@mi.infn.it> writes: >> (e.g. pyGiNaC) and the later are passed. I did the change in >> clifford.cpp and wondering if it should be applied everywhere.
CD> Shouldn't this be considered a problem that is to be solved in CD> pyGiNaC instead of in GiNaC? I do not understand all internals deeply, but this may be a problem with the BoostPython, which is the engine of pyGiNaC. In this case it may be rather difficult to correct. On the other hand I really enjoy the interactivity of pyGiNaC and think its is worth for GiNaC to make a small step towards it. CD> Does it go wrong with other types than lst? It seems like the root of problem in the GiNaC::lst itself, since this is the only(?) class in GiNaC which is not a child of basic. So far I did not notice problems with other GiNaC derived classes. CD> After all I think that users of pyGiNaC should be able CD> to use is_a<lst> for the lists that they CD> create. There two level there. First it is necessary to write a C++ wrapper in BoostPython for any class derived from GiNaC (we are doing it now for my library for cycles). For some reasons which I do not understand this does not work for lst. Hence each time the wrapper should explicitly convert Python lists to GiNaC::lst, and the later fail to pass is_a<lst> test. ;-( CD> Does it also go wrong in user code? After a library is already wrapped the user code is written in Python, and is_a<lst> is not required anymore. CD> Another point against this is that I just measured that CD> is_a<lst> is faster if one uses -O2 optimization than CD> .info(info_flags::list) (but slower if -O2 is not used). This CD> could, however, be platform/compiler/whatnot-dependent. However there is no consistency in the GiNaC code which method should be used to test lst class. For example, lsolve() uses info_keys... Best, Vladimir -- Vladimir V. Kisil email: kisilv@maths.leeds.ac.uk -- www: http://maths.leeds.ac.uk/~kisilv/