Request for comment: package for scientific and mathematical constants

Slightly a side-issue, but, suppose there is a good package for constants and I want to write a simple pendulum simulation for which I need only the force of gravity. How can I make sure all the constants in the world (and their uncertainties and units) don’t take up memory?

Memory for constants is not something you will have to worry about.


Not even if it’s all the constants in the world? :-p

Constants in math are precisely defined and have no associated uncertainty. In physics there could be measurement error, but by the time it gets to be called a “constant” this is usually not a concern, or the constant is defined to be something that forms the basis of other units (eg speed of light -> meter), so it is also exact. Consequently, I am not sure why you want uncertainty, can you give an example of a constant that requires it?

Acceleration due to gravity g would certainly be useful to have and has an intrinsic variation over the earth’s surface.

Apart from a few quantities defined to be exact, most physical constants do have measurement uncertainties. See the CODATA database:

@ChrisRackauckas was right, the bikeshedding is strong in this one :slight_smile:


By the way, this package would be a great candidate for :smiley:


There’s also

Would be nice to consolidate something in JuliaPhysics for sure.


@giordano @mkborregaard I like, 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.


+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.

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.

I’ve finally released the first version of PhysicalConstants.jl (see the announcement).