MAINT: constants: revise way 'exact' values are recomputed #11345
Conversation
|
Cc @jakobjakobson13 for this one as well. Related to gh-11343 |
The pull request looks good in my eyes and also makes pull request #11343 obsolete (as far as I understand). |
The CODATA data sheets do not list exact constants to full double precision, but mark missing decimals with '...'. Revise the way the exact values are calculated: recalculate only values with missing decimals, and do it separately for each CODATA dataset.
Ensure the old names for electric/magnetic constants return the current codata values instead.
All the other constants are obtained from CODATA, so do the same for hbar.
|
@pv As scipy 1.5 got released and I still feel kind of responsible, I wanted to check on your pull pull request. Should it be discussed again? |
|
@pv Are there any news on this pull request? |
|
@pv ping |
1 similar comment
|
@pv ping |
|
This pull request looks very well. Would you consider to merge it into the master branch? |
|
@jakobjakobson13 is this PR still in good shape? We need to resolve the conflicts though. If you are interested to do this let me know. It would be fine to do another PR starting from this one. |
I have to recheck the PR as some time passed since the last time. Is it urgent? |
|
Nothing urgent 😃 I just saw the backlog is small and most things are actually in the pipeline and just need some push to get to the finish line. |
see scipy#11345 as reference
|
This hasn't had commit activity in years, bumping the milestone ahead of |
[lint only]
|
I've merged this with Here's a checklist before merge:
|
4706ed4 to
e351d2f
Compare
There was a problem hiding this comment.
Just some comments to record my thoughts during review. I still need to check the exact<year> functions for accuracy.
What was the reference for the formulas? When i go to the "Extensive Listings" and click a constant, I can get an equation when I click the symbol:
Is that what I should compare against? This could use a comment. Update: I'm not sure there is something very useful to say. These come from all over the place, so aside from showing the source and derivation of each one, there's not much to be written.
MAINT: constants: ensure `c` is defined in `_codata.py`
|
I think the pull request looks good. |
I don't understand. The value of the von Klitzing constant in the file has ellipses, so it is not as precise as it should be. All values with ellipses correspond with exact quantities, and all are re-calculated using the |
Sorry, you are right. I was looking in the wrong year for the Klitzing constant and since the redefinition of the SI system it's not exact anymore.
Good but fundamental question. From my point of view, I would accept the sources (and its content) listed on the CODATA NIST homepage as they list solid scientific papers. But I understand your issue. |
|
Thanks, that helps. (Except the von Klitzing constant is listed as exact now but has ellipses. My point is that everything with ellipses gets recomputed from a formula.) I'm surprised, but if NIST doesn't actually provide formulas for everything, then I suppose there's not much to be done about it. I wanted to make sure I wasn't missing anything. I'll check what I can, add a comment about this, then merge. In the meantime, If you'd be interested in updating gh-20055 according to Ralf's comment, I can help you finish that one, too. The "slim down module" PRs are a bit too sweeping as they are, but they have some good elements. For instance, we can't just remove the module attributes; we'd first need to emit a deprecation warning when a user tries to access them (for two versions). Please consider closing those PRs and, after we finish gh-20055, consider opening a PR with a narrower immediate goal. It's easier to get things through in small steps. |
There was a problem hiding this comment.
OK, I can't say I checked all of these, but I did check several. It is implausible to me that the author would have taken the time to find these definitions in terms of base constants and the 1990 conventional electric constants and for there to be some that give results correct to 9 decimal places without them actually being correct. This LGTM.
| 'reduced Planck constant in eV s': hbar / e, | ||
| 'reduced Planck constant times c in MeV fm': hbar * c / (e * 1e6 * 1e-15), | ||
| 'second radiation constant': h * c / k, | ||
| 'Stefan-Boltzmann constant': 2 * math.pi**5 * k**4 / (15 * h**3 * c**2), |
| 'molar volume of ideal gas (273.15 K, 100 kPa)': R * 273.15 / 100e3, | ||
| 'molar volume of ideal gas (273.15 K, 101.325 kPa)': R * 273.15 / 101.325e3, |
There was a problem hiding this comment.
| c = exact['speed of light in vacuum'] | ||
| h = exact['Planck constant'] | ||
| e = exact['elementary charge'] | ||
| k = exact['Boltzmann constant'] | ||
| N_A = exact['Avogadro constant'] |
| alpha_W = 2.821439372122078893403 # 3 + lambertw(-3 * exp(-3)) | ||
| x_W = 4.965114231744276303699 # 5 + lambertw(-5 * exp(-5)) |
SciPy 1.15.0 updated how exact constants are calculated (scipy/scipy#11345) and rewrote MINPACK in C (scipy/scipy#21131, used by fsolve), leading to roundoff diffs when running the test suite with earlier versions of SciPy. Summary of changes: * update the exact constants we provide in pynucastro.constants (k_MeV and hbar) to match the more accurate values from 1.15.0 * update the NSE tests to allow both of the MINPACK implementations to pass * fix one missed instance of constants.m_u_MeV in the mass values for Python networks * use constants.m_u_C18 in the screening routines for consistency
Closes gh-14467, gh-11341
The CODATA data sheets do not list exact constants to full double precision, but mark missing decimals with '...'.
Revise the way the exact values are calculated: recalculate only values with missing decimals, and do it separately for each CODATA dataset.
The previous way was error-prone, because it could also override values that are not listed as exact, and since the replacements were done on the final list, what value should be filled in was not clear. This PR changes the missing decimals to be filled in for each CODATA list separately, and only values that are marked to be truncated and exact in the listing are processed. The replacement computation is also now done so that it's harder to make mistakes by using inexact values or forgetting to supply some of the required values.
CODATA2018 contains many more derived exact values than the previous revisions, so their computation becomes now a bit more involved. That the computed values are compared against the listed ones should make errors unlikely.