Dear all, While looking at some of my code that no longer compiles under the new tinfo() system I started wondering about the new system for return_type_tinfo(). As this system always was always more or less separated from the rest of the type system there is as such no reason to remove it along with the revision of the tinfo() system. In fact, this has serious disadvantages: Why do all non-commutative symbols automatically get the same return_type_tinfo-value? What if A and B represent matrices in the same space and C is a matrix in a different space? Should A*C*B not get simplified to (A*B)*C then? Same question for functions. Why is it no longer possible to define your own function with the same return_type_tinfo as, say, Dirac matrices of a particular representation label? The fact that in ncmul::eval it is necessary to check for Dirac/color objects indicates bad design. 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. Does anyone feel like implementing this or shall I do it? Best, Chris
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
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
participants (2)
-
Chris Dams
-
Jens Vollinga