-
Notifications
You must be signed in to change notification settings - Fork 112
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
Update constants to CODATA 2018 #235
Conversation
Codecov Report
@@ Coverage Diff @@
## master #235 +/- ##
=======================================
Coverage 74.37% 74.37%
=======================================
Files 14 14
Lines 1073 1073
=======================================
Hits 798 798
Misses 275 275
Continue to review full report at Codecov.
|
It would be awesome if there were a mechanism to select the set of constants used, also for backward compatibility |
@giordano Yes, that might be useful. I guess the easiest way to implement this would be like in your Of course, users would then have to change their code, since they can no longer use these constants without We should probably also think about whether (and how) we want to enforce consistency between What are your thoughts on this? |
Actually, While using the new dataset |
const k = 1.380_648_52e-23*(J/K) # (79) Boltzmann constant | ||
const Na = 6.022_140_76e23/mol # exact, Avogadro constant | ||
const k = 1.380_649e-23*(J/K) # exact, Boltzmann constant | ||
const R = Na*k # molar gas constant |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎉
I think for now the correct thing to do would be to merge this and discuss in a dedicated issue if it makes sense for Unitful.jl to have both new and old versions of CODATA, when PhysicalConstants.jl exists and fills that role nicely already. This might be a bit radical but perhaps Unitful should not define any constants, given that PhysicalConstants does the job so well...? |
I think having the latest CODATA values used by default is highly desirable 👍 It would be possible to allow swapping out values to use different CODATA releases but you need a layer of indirection. Actually The types for the constants can be defined within In the simplest case the definitions of the values would be in a set of CODATA modules, only one of which could be loaded at a given time. Roughly speaking these would contain definitions such as Base.float(::typeof(PhysicalConstants.G)) = 6.6743e-11u"m^3*kg^-1*s^-2" However, dynamically choosing a different CODATA module isn't really natural in this setup and it's not clear how a default would work. Also this would imply a global choice of CODATA across all loaded modules within the julia session (that might arguably be a good thing). As another similar global option, you could have a function to force julia> load_codata2014() = eval(:(Base.float(::typeof(PhysicalConstants.CODATA2018.G)) = 6.67408e-11u"m^3*kg^-1*s^-2"))
load_codata2014 (generic function with 1 method)
julia> PhysicalConstants.CODATA2018.G
Newtonian constant of gravitation (G)
Value = 6.6743e-11 m^3 kg^-1 s^-2
Standard uncertainty = 1.5e-15 m^3 kg^-1 s^-2
Relative standard uncertainty = 2.2e-5
Reference = CODATA 2018
julia> load_codata2014()
julia> PhysicalConstants.CODATA2018.G
Newtonian constant of gravitation (G)
Value = 6.67408e-11 m^3 kg^-1 s^-2
Standard uncertainty = 1.5e-15 m^3 kg^-1 s^-2
Relative standard uncertainty = 2.2e-5
Reference = CODATA 2018 In this sketch, just pretend that I'm monkey patching |
I agree that for the time being the best thing to do is to just update the constants. About integrating functionalities with |
I would be fine with removing all constants from If I wouldn’t mind having to choose a dataset (in this case |
Certainly I think it'd be great it However, I think having to choose the particular version of CODATA will be rather bad for usability. Will choice of CODATA be a per-module or global decision? If per-module, how will units relying on different versions of CODATA interact? If global, a module which uses I'd much prefer a solution where |
Actually using PhysicalConstants doesn't load any dataset at all. Users have always to explicitly load the desired dataset, e.g., |
Sorry, poor wording on my part - I didn't mean to imply anything about what PhysicalConstants does right now. |
This updates the physical constants to use the 2018 CODATA recommended values.