-
Notifications
You must be signed in to change notification settings - Fork 9
Sensitivity to variable name ? #23
Comments
|
What would be a meaning of using a constant like e or pi in this context ? |
It would be part of a calculation. The strings are mathematical expressions that might use e and pi. But I can see how this is an unintended consequence in the car you were attempting: if the whole expression resolves to a single constant, the user probably meant it as a field name. Less so if the constant were a literal number like "3". To distinguish between "algebraically constant" and "literally constant," the expression nodes would have to carry more information about how they were derived. For instance, to know that you got 2.71... by typing One formal way to remove this ambiguity would be to remove all named constants from the default namespace. (You can add your own with the I've been wanting to check this function namespace to see if it's compatible with numexpr, which would be a good feature to have. I'll look at how they handle e and pi. |
Yes, I see what you mean. In my example, the expressions in line 1 and 3 are legitimate expressions, which happen to evaluate to a constant.
I wonder if it is possible to determine that the expression in bin() or step() is evaluated to constant and give some sort of a warning, although I can not think of a good way to deliver such a warning. An exception is too harsh. Printing to stderr or stdout can get lost or annoying. What is really weird, is that the result of my code. The histogram gets filled with 1 in all bins. |
Yeah, the filled result is unexpected, something I need to investigate. I explicitly remember thinking that I haven't given enough thought to the case where an expression is a pure constant (though I hadn't foreseen that named constants like "e" would be confused for variables: my bad). |
Maybe you could name constants in capitals, and/or use underscores like |
That's what I was thinking about making them zero-argument functions. Like, if you had to type I want to check first, though, about what numexpr does. histbook ships have some kind of synergy with numexpr— it's an existing language with about the same scope and target audience. I may even use it in the execution plan to avoid some costly intermediary arrays. And finally, the SciKit-HEP project has a nice "formulate" package that converts TTree::Draw syntax into numexpr syntax. Possibly, I could make histbook's expression language exactly equal to numexpr's expression language, and that might help people in the long run. So I should check to see how they handle e and pi. (If at all: "e" is "exp(1)" and "pi" is "acos(-1)", which would be easy to put in a |
Yes, but if you use functions, would not you want to know that pi() + pi() - pi() == pi() always? |
Actually, Thus, That said, it would be possible to introduce such functions. I would have to make a new AST node that isn't equal to itself ( |
Reproduced:
Note that any constant will do this. |
The actual bugginess of this has been resolved by #24:
That is, an axis whose expression is a constant just fills like a constant. If we bundled this with a non-scalar fill, it would fill more than one:
|
But this leaves the issue of user confusion over whether "e" is a constant or a variable name. I've got an idea for that. |
Names like
The first fill specifies
|
I have different results for these 2 cases, which differ only by the variable name, "z" vs. "e":
and
It works correctly with "z", but with "e", it uniformly fills all bins with 1
The text was updated successfully, but these errors were encountered: