[GiNaC-devel] Lst test in clifford.cpp
kisilv at maths.leeds.ac.uk
Thu May 11 18:27:49 CEST 2006
>>>>> "CD" == Chris Dams <Chris.Dams at 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
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
Vladimir V. Kisil email: kisilv at maths.leeds.ac.uk
-- www: http://maths.leeds.ac.uk/~kisilv/
More information about the GiNaC-devel