[GiNaC-devel] New return_type_tinfo-system seems broken.

Chris Dams Chris.Dams at mi.infn.it
Wed Feb 15 18:37:01 CET 2006


Dear Jens,

On Wed, 2006-02-15 at 17:58 +0100, Jens Vollinga wrote:

> The problem with the adaptation of the original return_type_tinfo to the 
> new tinfo system was, that not only did return_type_tinfo return a 
> mixture of type information and representation label (bit patterns ...), 
> but also it also returned this information from the first operand of 
> objects like mul/add/...

Yes, this looks like a bug to me. I think in the case of a mul it should
be:
one non_commutative element -> use that for the return type
more non_commutative elements -> use noncommutative_composite.

> > Although the tinfo()-system has, arguably, been improved the
> > return_type_tinfo-system has been demolished. What about the following
> > replacement? Make return_type_tinfo return something of type tinfo_t. In
> > that case the user can generate his own objects tinfo_t as he pleases
> > and e.g. dirac_gamma could take an argument of type tinfo_t instead of a
> > representation label.
> 
> I do not fully understand your idea, yet.
> Instead of choosing a representation label the user chooses the tinfo 
> for the the dirac_gamma object? But tinfo is static, isn't it!? What if 
> he chooses something equal to another tinfo (unlikely but possible)?

That would probably not cause trouble, although it would be strange.
Look this spinor line is labeled by the tensdelta class! And the other
one by the add class! What I had in mind was that the user would declare
his own as in
tinfo_static_t rtt_first_spinor_line_static;
tinto_t rtt_first_spinor_line=&rtt_first_spinor_line_static;
As these are pointers they cannot very well point to the same thing at
the other tinfo_ts.

> > Does anyone feel like implementing this or shall I do it?
> 
> Currently I try to demolish the function system :-), so if you would 
> volunteer to solve this problem, please do!

I think I will do this then. After all, I do have some code that breaks
because it needs a function and a symbol to have the same
return_type_tinfo().

Best,
Chris



More information about the GiNaC-devel mailing list