Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Get exact values of constants from ROOT #18

Open
chrisburr opened this issue Feb 27, 2018 · 4 comments
Open

Get exact values of constants from ROOT #18

chrisburr opened this issue Feb 27, 2018 · 4 comments
Labels
enhancement New feature or request
Milestone

Comments

@chrisburr
Copy link
Member

No description provided.

@chrisburr chrisburr added this to the v0.1.0 milestone Feb 27, 2018
@eduardo-rodrigues eduardo-rodrigues added the enhancement New feature or request label Feb 28, 2018
@eduardo-rodrigues
Copy link
Member

You mean the constants in backends/numexpr.py? Are there are other constants defined elsewhere?
In any case it is probably a good idea to move all those to a separate file, to be easily checked and seen.
As for whether they should all come from ROOT, that needs a discussion perhaps, as I am pretty sure ROOT does not have all you need. In fact, why do you need all those constants?

@eduardo-rodrigues
Copy link
Member

Note that we have constants defined in scikit-hep, which we do want to use throughout the Scikit-HEP project for consistency ...

@chrisburr
Copy link
Member Author

chrisburr commented Feb 28, 2018

These constants are only used for compatibility with TFormula style expressions as numexpr doesn't have an equivalent. See backends/ROOT.py.

I see 4 options for how to interpret a constant from ROOT, for example using TMath::G() which is defined as exactly 6.673e-11 in ROOT but ~100x more precisely known to be 6.67408e-11.

  1. "TMath::G()" goes to "TMath::G()" in ROOT and "6.67408e-11" in numexpr (currently used)
  2. "TMath::G()" goes to "TMath::G()" in ROOT and "6.673e-11" in numexpr
  3. "TMath::G()" goes to "6.673e-11" in ROOT and "6.673e-11" in numexpr
  4. "TMath::G()" goes to "6.67408e-11" in ROOT and "6.67408e-11" in numexpr

(2)/(3) have the benefit that we exactly mirror ROOT's behaviour instead of assuming users just want the best possible value, and (3)/(4) would be simpler as it would allow me to remove the special named constants, at the cost making the result of from_root("...").to_root() ROOT uglier.

I'm inclined to use (2), in part due to the comments of @jpivarski:

it may even be preferable to hard-code them in formulate. Hear me out: users want formulate because it lets them run TFormula expressions in numexpr, without ROOT. They want these expressions to return the same result as they did in TFormula. If there are any differences between ROOT's values of these constants and Scipy's, or skhep's, the users would prefer ROOT's values. I believe the users would want all of the constants in formulate/backends/numexpr.py to be copied from ROOT, not taken from another authority, such as Scipy or skhep!

but I'm open to hearing other opinions.

@eduardo-rodrigues
Copy link
Member

eduardo-rodrigues commented Feb 28, 2018

Hmm, you need to have consistency across the board. No other way possible. So if I start with a ROOT expression that explicitly uses TMath::G() (for whatever reason) then whatever expression is returned at any point, it should have precisely the value behind TMath::G(). If I start from another backend and then ask for the ROOT-like expression then you cannot or should not use TMath::G() but rather the actual number you start from.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants