First of, thanks a lot for this great package!
Numexpr supports where whereas ROOT supports an (equivalent) ternary operator from C++ (Expression1 ? Expression2 : Expression3). While the former is already implemented and works fine with the current function registry, the latter cannot (AFAIK) be supported with the current construction of joining the arguments withing brackets with ,.
Two ideas (using as an example sqrt):
-
To enable support for this conversion, I would propose a to_string method that can be registered with the function in PFunction. Defaults to the current conversion. This takes the name of the method and arguments.
Disadvantage: we have too much freedom (e.g. for sqrt:
('sqrt', 1, lambda f, args: f + "(" + args[0] + ")")
or duplicate the name
('sqrt', 1, lambda args: 'sqrt' + "(" + args[0] + ")").
-
use string formatting: require the signature to be contained in the string definition: '(sqrt({})', 1).
Disadvantage: arbitrary number of arguments?
I would propose to go for the first solution.
First of, thanks a lot for this great package!
Numexpr supports
wherewhereas ROOT supports an (equivalent) ternary operator from C++ (Expression1 ? Expression2 : Expression3). While the former is already implemented and works fine with the current function registry, the latter cannot (AFAIK) be supported with the current construction of joining the arguments withing brackets with,.Two ideas (using as an example sqrt):
To enable support for this conversion, I would propose a
to_stringmethod that can be registered with the function inPFunction. Defaults to the current conversion. This takes the name of the method and arguments.Disadvantage: we have too much freedom (e.g. for sqrt:
('sqrt', 1, lambda f, args: f + "(" + args[0] + ")")or duplicate the name
('sqrt', 1, lambda args: 'sqrt' + "(" + args[0] + ")").use string formatting: require the signature to be contained in the string definition:
'(sqrt({})', 1).Disadvantage: arbitrary number of arguments?
I would propose to go for the first solution.