There’s also https://github.com/ggggggggg/Physical.jl
Would be nice to consolidate something in JuliaPhysics for sure.
3 Likes
@giordano @mkborregaard I like https://github.com/DataWookie/PhysicalConstants.jl, could you explain what features it needs before it’d be acceptable for JuliaPhysics?
I may not have drunk enough of the type-all-the-things koolaid yet but I’m wary of both carrying around interval/uncertainties and units in types, so PhysicalConstants.jl is really attractive—simple, offers some compromise by offering mks and cgs SI units. I’d probably get rid of the imperial module, and make the cgs constants dependent on mks (doing the dimensional analysis either manually or automatically using a units module). Would that be sufficient?
Looks like unmaintained.
It really should use real Units (Unitful.jl) instead of source code comments.
Adding to my previous short comment, the package looks just a collection of numerical constants in different unit systems (so probably there are some constants defined multiple times), but relying on a well-developed unit package is probably a better idea. As I said before, I’d appreciate that such package could take into account uncertainties. For example, something like this:
julia> using PhysicalConstants
julia> G
G = 6.67408e-11 m^{3} kg^{-1} s^{-2}
julia> float(G)
6.67408e-11 m^{3} kg^{-1} s^{-2}
julia> measurement(G)
6.67408e-11 ± 3.1e-15 m^{3} kg^{-1} s^{-2}
For these features, the package must be more developed and better designed than a simple collection of numerical constants and nothing more.
3 Likes
+1 for UnitFul. If there was ever a case for using units, this is it.
+1 for scoping (e.g. PhysicsConstants.Quantum).
?? about whether using JuliaIntervals for representing uncertainty is overkill or appropriate
Thanks for elaborating. About units, you’ve all convinced me it’s a good idea. We can probably do better than “all exported numbers are in SI units” and let users specify what units they want constants in. I do have concerns that marrying this constants library to a specific unit library might cause problems for downstream apps/libs that use a different units library (or none at all), but that can hopefully be smoothed over.
Could you elaborate a bit more on the measurement uncertainties? Propagating uncertainties from physical constants throughout the processing chain seems like something that (1) arises infrequently, and (2) when it does, I expect people to have different ideas about how to deal with the uncertainty: some might use uncertainty just for correct significant digits, others might interpret uncertainty as Bayesian priors (for which distribution? Normal? Rayleigh?), while still others might want to use interval arithmetic. I am wondering whether this library can make a reasonable decision on behalf of these specialized users, or if it’d be better to forego uncertainty for the majority of users who don’t need them.
I’ll take a look at drafting drafting a library.
Could have that each value is defined by a tuple (value, relative uncertainty). Similar to how data is presented at e.g. Fundamental Physical Constants from NIST
Yes, I agree, there are two good competing packages for units (but I have a slight personal preference for one of them), but unless there will be an AbstractUnits.jl package that enables unifying the interfaces of all units-related packages (something like AbstractFFTs.jl is doing with Fast Fourier Transform), you have to make a decision between the two packages.
I agree, indeed the approach proposed above you have to explicitly request the conversion of the constant to a Measurement type, otherwise float(G) gives you a simple Float64 wrapped by units. If you really want the constant with its uncertainty, ask for it, otherwise assume it to be exact. But if you’re doing extremely precise measurements, you may want to take into account physical constants’ uncertainties as well (Measurements.jl works with arbitrary precision arithmetic, a feature I couldn’t find in other similar packages).
Measurements.jl assumes linear error propagation theory, which looks to be the most widely used in Physics. Honestly, I’ve never seen interval arithmetic in Physics to track uncertainties (but makes much more sense in Mathematics, it gives how an interval in mapped into another by a function), I don’t understand why people keep mentioning it here.
I think that Unitful.jl has the possibility, in theory, to adapt to different unit systems (MKS, CGS, etc…), but I’m not 100% sure.
Yes, that’s a possibility, but I think that making it more similar to an Irrational is a better approach (as I proposed above), also because there are constants that are defined to be exact and multiple of irrational numbers.