Template talk:Physical constants

Display value of fine-structure constant

I am finding that articles overwhelmingly prefer to include the value 0.0072973525643 rather than 7.2973525643×10⁻³ as the fine-structure constant (including/especially with the rounded forms). So I intend to make this change along with checking uses, especially for the |round= parameter, which will need to change. Mostly, articles just manually put in the value, which means that it does not automatically update. —Quondum 19:54, 25 May 2024 (UTC)

Yeah, something in the milli- range of sizes can probably be written without the scientific notation. Primefac (talk) 11:25, 26 May 2024 (UTC)

Also when they display no longer in decimal notation, it seems appropriate to do so in this context (though this is complicated by the use of SI prefixes). A few of NIST's formats seem to be at odds with the reply that you got from them even after allowing for standard use of units (e.g. MHz/T for gyromagnetic ratios, and MeV for energy equivalents of particle masses), such as

• Josephson constant: 483597.8484...×10⁹ Hz⋅V⁻¹
• electron-xxx mass ratios, e.g. electron-muon mass ratio: 4.83633170(11)×10⁻³
• Fermi coupling constant: 1.1663787(6)×10⁻⁵ GeV⁻²
• fine-structure constant: 7.2973525643(11)×10⁻³

Perhaps with these few, I'll see what more WP-friendly versions can be used. I've already implemented the change for the fine-structure constant. —Quondum 12:34, 26 May 2024 (UTC)

Unit replacement

Primefac, I thought that making the units replaceable would be uncontroversial, but evidently I was mistaken. The idea was that the template should behave as before for existing uses, but where units were to be replaced (e.g. to provide a linked unit, or to expand the unit name, as is done in a number of articles), this would allow a cleaner way to do this than the existing kludges. What have I missed? —Quondum 22:14, 1 December 2024 (UTC)

Okay, I think I might have misread the change; I read it as making the default "no unit" (or rather, {{{unit}}}) and needing to explicitly state that |unit=yes to turn on the units (which as my edit summary stated, is the opposite of how it currently works). I don't think it's the best idea to assume that a blank |unit= means that no unit should be given, so my suggestion would be to use {{if empty|{{{unit| }}}|yes}} in the #switch statement. Primefac (talk) 22:39, 1 December 2024 (UTC)

Okay, let's go through the interesting cases; we can tweak some.

• omitted |unit=: use the template unit (no change from before and must not be changed)
• |unit=no: omit the unit (no change from before); we could even strip out this case if we wanted, but that would be a significant change and would entail adjusting a number of articles
• explicit empty |unit=: my tendency is to treat an explicit parameter as providing a string, empty or otherwise, but this would be a change from previous behaviour, even though likely as yet unused. My guess is that your preference would to keep this as before, but this makes the logic slightly more convoluted
• |unit=yes: my preference would be to omit this case altogether (the fewer special cases, the better), despite my implementation of it
• anything else: provide the unit from the parameter; you seem happy with this, and it is the main purpose of the change

I generally go for maximal simplicity of logic (which would be if the parameter is present, use what is given; quite a change): every extra condition seems to exponentially increase the gotchas. But I'm in a minority here. I'm guessing that the only point you'll not care about is whether to support the |unit=yes case at all. —Quondum 22:59, 1 December 2024 (UTC)

How about as {{physical constants/sandbox}} is now implemented:

• omitted |unit=: use the template unit (no change from before and must not be changed)

  1.602176634×10⁻¹⁹ C‍

• explicit empty |unit=: use the template unit (no change from before), and according to your suggestion

  1.602176634×10⁻¹⁹ C‍

• |unit=no: omit the unit (no change from before)

  1.602176634×10⁻¹⁹‍

• anything else: provide the unit from the parameter; you seem happy with this, and it is the main purpose of the change

  1.602176634×10⁻¹⁹ coulomb‍

This drops the 'yes' case. —Quondum 23:17, 1 December 2024 (UTC)

Looks okay to me, thanks. Primefac (talk) 20:43, 3 December 2024 (UTC)

References

A "nice" prefixed unit

In the infobox of Proton, I included |charge_radius={{val|0.84075|(64)|ul=fm}}{{physconst|rp|ref=only}} to have the constant displayed with the unit fm rather than m, as this unit is preferred in this context. This hard-codes the current value, which in this instance nullifies the purpose of this template to provide the latest CODATA value. I recognize that this is fairly uncommon, but I'd be interested to hear whether anyone would be averse to supporting such cases. A simple proposal would be to provide a "nice" alternative form that has no power-of-ten multiplier, and uses a metric prefix instead (only for some values where this is of interest). Maybe selected by a suitable string value for |unit=? —Quondum 19:32, 25 August 2025 (UTC)

Blargh... my immediate no-thinking-about-it reply is that the CODATA values are given in standard SI units without prefixes because that's less likely to be misinterpreted. I do see your point, however, about converting when a value is commonly given as a prefixed unit. Not sure how best to deal with it; maybe cross-post this discussion to WT:PHYS and WT:CHEM? Primefac (talk) 21:10, 29 August 2025 (UTC)

After a little thought, I haven't been able to come up with a concrete approach to this that I am confident will stand the test of time. So I'm retracting this suggestion, pending many more examples where it might be used. —Quondum 22:07, 29 August 2025 (UTC)

Planck constant is not per source.

The Definition of the SI says

• the Planck constant, h, is 6.626 070 15 × 10−34 J s,

The template produces J/Hz. We should just be identical the source, not equivalent to. Johnjbarton (talk) 03:56, 11 October 2025 (UTC)

The unit is that given in its source: 6.62607015×10⁻³⁴ J⋅Hz⁻¹‍. —Quondum 11:08, 11 October 2025 (UTC)

Then we need to change {{Infobox physical quantity}} to replace SI with CODATA. Is that what we want to do? Johnjbarton (talk) 15:52, 11 October 2025 (UTC)

I don't follow your logic. The CODATA values are SI values. The infobox claims to give the SI values, so the editor providing the value must provide the SI value. That template makes no specific reference to any source. In the SI, J/Hz and J⋅s are the same thing, so providing the CODATA value with SI units is as required. I see no implication that specific values that occur on the SI definitions must necessarily be given in the form that they are used in their definitions in the SI brochure. If the SI value given is referenced to CODATA, as this (physconst) template will do unless suppressed, the units will be exactly as per the cited source. I do not see any change needed. —Quondum 21:48, 11 October 2025 (UTC)

The issue is " In the SI, J/Hz and J⋅s are the same thing, ". Do we have a source for this? As you probably know the Planck constant bounces back and forth between J/Hz and J⋅s. I just want to be able to revert changes with verified sources, not with arguments. Johnjbarton (talk) 23:02, 11 October 2025 (UTC)

That Hertz is 1/s and thus 1/Hz = s is WP:BLUESKY territory; no sources needed. I do understand your argument, and I agree that consistency is ideal here, but J⋅s is more concise and probably why it gets used more often even though the "official" units are J/Hz. Primefac (talk) 12:20, 12 October 2025 (UTC)

No, the official units are J⋅s. See "2.2 Definition of the SI" https://www.bipm.org/documents/20126/41483022/SI-Brochure-9-EN.pdf.

I also think this form is clearer and more consistent. But that is not my complaint here. My complaint is that we use CODATA J/Hz then claim it is SI. The fact that these are equivalent is not WP:BLUESKY as evidenced by the many edits that switch them back and forth. Johnjbarton (talk) 15:27, 12 October 2025 (UTC)

That we have two reputable sources that use alternative but equivalent forms is sufficient explanation of any switching between them that editors might make, so your argument that editor behaviour is evidence that it id not WP:BLUESKY does not seem valid. The SI brochure says that Hz can be expressed as s⁻¹, if you want a source (there should be no claim that they are not exactly equivalent in the SI, though in non-SI contexts this might not hold), and the choice is thus simply a matter of editor preference. Switching within WP should be minimized, simply for WP:RETAIN-type reasons. So really, the debate here appears to be about editor behaviour. —Quondum 15:50, 12 October 2025 (UTC)

References

g factor not per source

We give the electron g factor source to https://physics.nist.gov/cgi-bin/cuu/Value?gem but then in a hidden comment we say:

• note that the sign differs from NIST: here the convention of using the particle's own mass and charge applies

Why are we making changes in convention? Johnjbarton (talk) 18:12, 6 February 2026 (UTC)

Just noting, this was added in Special:Diff/1294582292. Primefac (talk) 18:54, 6 February 2026 (UTC)

We use - sign for neutron g factor, agreeing with NIST. We use + sign for electron and muon disagreeing with source. I think we should use exactly the value in the source and change our content if we want a different convention in some cases. Johnjbarton (talk) 19:06, 6 February 2026 (UTC)

An observation: the "g-factor" of composite particles is defined differently to that of elementary fermions (it is a sort of stand-in that ignores the charge of the composite particle). They are not the same concept, despite their common same name and apparent similarity. So referencing the neutron "g-factor" has no logic this context. Even the term "g − 2" (g minus two) does not work for a negative g-factor or in the context of the composite-particle definition. Before using the NIST choice of sign, survey the literature to determine the dominant convention used for electrons and muons. —Quondum 23:06, 8 February 2026 (UTC)

If we cite NIST we should use their number. If we have another source that tells us with the dominant convention is, we can cite it. What are doing now is citing a source but not explaining that we don't use their number. Johnjbarton (talk) 04:03, 9 February 2026 (UTC)

You said it. If you want to make a change (adding an explanation or suitable source), do the work of researching conventions and finding sources for that. NIST is a reliable source for CODATA values (the actual precision), not for conventions, as that is not the purpose of CODATA. Adapting template content with no other reason than that the current citation (possibly carelessly) adopts a particular convention, with no care for impact on the articles in which it is used, would be irresponsible IMO. —Quondum 12:55, 9 February 2026 (UTC)

Wikipedia editors should not "do the work of researching conventions". That is for experts and the experts create CODATA recommendations. The irresponsible party put the incorrect value in the content. Johnjbarton (talk) 02:04, 10 February 2026 (UTC)