[RFC]: add various physical constants (tracking issue)

itskdhere commented 6 months ago

Description

This RFC proposes adding various physical constants. The purpose of this issue is to serve as a tracking issue for adding various physical constants.

List of physical constants to be added:

[ ] c (speed of light in vacuum)
[ ] speed_of_light (speed of light in vacuum)
[ ] mu_0 (vacuum magnetic permeability)
[ ] epsilon_0 (vacuum electric permittivity)
[ ] h (Planck constant)
[ ] Planck (Planck constant)
[ ] hbar (h / (2 * pi))
[ ] G (Newtonian constant of gravitation)
[ ] gravitational_constant (Newtonian constant of gravitation)
[ ] g (standard acceleration of gravity)
[ ] e (elementary charge)
[ ] elementary_charge (elementary charge)
[ ] R (molar gas constant)
[ ] gas_constant (molar gas constant)
[ ] alpha (fine-structure constant)
[ ] fine_structure (fine-structure constant)
[ ] N_A (Avogadro constant)
[ ] Avogadro (Avogadro constant)
[ ] k (Boltzmann constant)
[ ] Boltzmann (Boltzmann constant)
[ ] sigma (Stefan-Boltzmann constant)
[ ] Stefan_Boltzmann (Stefan-Boltzmann constant)
[ ] Wien (Wien displacement law constant)
[ ] Rydberg (Rydberg constant)
[ ] m_e (electron mass)
[ ] electron_mass (electron mass)
[ ] m_p (proton mass)
[ ] proton_mass (proton mass)
[ ] m_n (neutron mass)
[ ] neutron_mass (neutron mass)

Related Issues

No.

Questions

No.

Other

No.

Checklist

[X] I have read and understood the Code of Conduct.
[X] Searched for existing issues and pull requests.
[X] The issue name begins with RFC:.

stdlib-bot commented 6 months ago

:wave: Hi there! :wave:

And thank you for opening your first issue! We will get back to you shortly. :runner: :dash:

kgryte commented 6 months ago

@itskdhere I'm not opposed the addition of various constants; however, my guess is that we'd need to resolve package organization before actually adding any of the specified constants. E.g., they may need to be categorized by domain.

And also, do note that your initial list above contains duplicates. We'd only want one package per constant.

kgryte commented 6 months ago

Also, can you articulate why you want these particular constants? Typically, we've only added constants as we've needed them. This RFC proposes adding them for their own sake and is likely to be lower priority.

itskdhere commented 6 months ago

Also, can you articulate why you want these particular constants? Typically, we've only added constants as we've needed them. This RFC proposes adding them for their own sake and is likely to be lower priority.

I want to add these constants like the physical constants of scipy.constants (https://docs.scipy.org/doc/scipy/reference/constants.html#physical-constants)

itskdhere commented 6 months ago

@itskdhere I'm not opposed the addition of various constants; however, my guess is that we'd need to resolve package organization before actually adding any of the specified constants. E.g., they may need to be categorized by domain.

Yes, maybe the proposed physical constants can be added in something like @stdlib/constants/physical/* . For example: @stdlib/constants/physical/speed_of_light

And also, do note that your initial list above contains duplicates. We'd only want one package per constant.

I just listed all physical constants available in scipy.constants (except CODATA ones) in my initial list above. And in case of duplicate ones, I think the full name ones might be preferred. For example, speed_of_light might be preferred instead of c

kgryte commented 6 months ago

I wonder if it would make sense instead to follow the dictionary API found in SciPy instead, as done for CODATA.

itskdhere commented 6 months ago

I wonder if it would make sense instead to follow the dictionary API found in SciPy instead, as done for CODATA.

Yes, that will be good.

I've checked the implementation of that in SciPy and it might be a little tricky but interesting thing to implement.

So, should I change https://github.com/stdlib-js/stdlib/issues/2119#issue-2226121341 according to that or open a new issue ?

stdlib-js / stdlib