[GiNaC-devel] Lst test in clifford.cpp

[Vladimir Kisil]

>>>>> "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
    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 at maths.leeds.ac.uk
--                      www: http://maths.leeds.ac.uk/~kisilv/