[GiNaC-devel] Lst test in clifford.cpp

[Chris Dams]

Dear Vladimir,

On Thu, 11 May 2006, Vladimir Kisil wrote:

> >>>>> "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.

I am very much in favour of interactive programs based on GiNaC but am a
bit afraid that solving this problem within GiNaC (1) fixes something in
GiNaC that is not a bug and (2) fails to fix something that is a bug in
another package. Did you try to contact the autor/mailing list of pyGiNaC
on this?

>     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. 

Well, lst is a child of basic but Maybe the problem is that container is a
child class of both basic and container_storage. Maybe you could test
whether this is the case by trying an example for yourself where you try
to wrap a class that is multiply inherited. This could give an idea
whether the problem with pyGiNaC or with BoostPython.
 
>     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. ;-(

Maybe you could try to construct a minimal example that exhibits the
problem and mail that to the PyGiNaC mailing list or author.

Best,
Chris