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