Hi, Chris Dams schrieb:
label? The fact that in ncmul::eval it is necessary to check for Dirac/color objects indicates bad design.
I agree on that. And the new return_type_tinfo system is really just a quick and dirty fix that should be replaced by something better. 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/... So the workaround was to let return_type_tinfo return a reference to either its object or the first operand object in the case of add/mul/...
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)?
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! Regards, Jens