Request for comment: package for scientific and mathematical constants

I’m refactoring some of our code and am wondering what to do with a few scientific constants we use, like speed of light, permittivity of free space, and the like. I was intrigued to see a stand-alone package, Tau.jl but that offers a bit more than just the τ constant.

Would it be appropriate to create a Constants.jl package and put these things in there? Would that be broadly useful to the community? Or would it attract controversy as we had to decide which constants were too specialized for inclusion, or naming, etc.?

At a minimum I’d consider adding the defined entries in Wikipedia’s physical constants article.


It would be nice if it was integrated with Unitful.jl so that way the quantities by default had units.


Speaking for myself, yes.

Such controversy should not stand against the existence of the package. What exactly to include, will likely be up for discussion, but I don’t see that as a fundamental problem.

As a tau partisan, I’d say put tau in Base and put pi in the constants package. Though that ship might have passed…

1 Like

I think this is an excellent idea. I suggest not exporting names at the top level, so users can pick and choose by name or domain. For example, h could be Planck’s constant in submodule Constants.Quantum and not bother someone using finite-difference methods in some other domain.

By “bother”, I mean not threaten with a trap for scoping errors. And since single-character variable names are often used in local scope…

This would also be a perfect destination for all the single-character-name constants now in Base. Once upon a time @StefanKarpinski recognized the unwisdom of such things, but less thoughtful developers prevailed.


Perhaps also being able to specify a family of useful units, c = 1, cgs vs mks systems, etc.

Sounds like this package will have the more bikeshedding than I could imagine. Totally subscribing to the issues.

:popcorn: :blush: :popcorn: :champagne:


Rather than Wikipedia, I would base them directly on CODATA. See e.g.

I’m in favour of this, and have made heavy use of SciPy’s constants package:

1 Like

I often thought about a package to provide physical constants, using a type similar to Irrational (there are constants that are multiple of pi), that can be automatically converted to the requested precision. In addition, it would be nice to have them with uncertainties, as provided by CODATA. Have a look to

Constants (physical and others) should definitely support uncertainty. There are a bunch of related packages in .

There is already a julia package for physical constants , though it is yet unregistered. Might be a useful starting point to get in touch and either PR to or fork off that.

1 Like

JuliaIntervals uses a mathematical arithmetic that isn’t what physicists would expect.

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: