Template talk:Physical constants

Another proposed solution

Here is something based on an attribute that I found:

Proposal view
Body text1. Body text2. Body text3. Body text4. Body text4.

This is clean (the wikicode is not a hack, as my previous one was), and it does everything exactly as I wanted, including remotely injecting the long citation into the start of reflist without any backlinks (unnumbered and slightly separated, though). It does not prevent duplication, though, so the template needs to determine whether this is the first time that it is being invoked on the page. If I can find a way to avoid wikicode from being active the second time it appears in a page, I think the result will be good. —Quondum 15:06, 4 January 2024 (UTC)

Hmm. So maybe this is undefined behaviour: it is a using a side effect of an unintended use: see [1].

Very nice, I should've thought of that. That's using embedded refs, and the rendered page is close to what you originally wanted, so if that works for you, that's great. (By the way: if you want to cite a page at mediawiki (or meta, or commons, or wiktionary, and so on) you dont need to use a full url, just use the sister project shortcut, e.g., [[mw:Help:Cite]] ⟶ mw:Help:Cite, and so on.) Mathglot (talk) 01:21, 5 January 2024 (UTC)

Except that I still need to solve the duplication problem: the template must only emit the long ref once. It is useless until I solve that ... —Quondum 01:30, 5 January 2024 (UTC)

2022 CODATA values

I see that the 2022 CODATA values have been published. We should have a strategy for creating a history of values, keeping the older version. For example, we could have

{{physconst|alpha}} to mean 'latest'

{{physconst|alpha|dataset=2018-CODATA}} or similar to retrieve a specific year.

This will naturally need some template development, which I am no expert in. It would be nice to retain a copy if the current Template:Physical constants/data page of 2018 CODATA values accessible via the parameter, and progressively edit the new values into the current page as time allows. —Quondum 22:48, 14 May 2024 (UTC)

I am genuinely curious why we need to keep old values; we have at least 5 sets of past years... if a specific value for a specific year is needed on a specific page, we should subst that template use and carry on. I suspect 99% of the uses of this template are "the current value is XYZ" which does not need a historical backup. Primefac (talk) 11:18, 15 May 2024 (UTC)

I confess that I did not think too closely about that; maybe it was just the latent librarian in me on autopilot. Each of those "sets" is simply a citation, which is reasonable, aside from CODATA2010, which provides values that are apparently unused. Also, even "making a copy" involves modifying the citations to link to the new location of the 2018 values on the NIST website. In all, there seems to be no "why", but there would be a cost to keeping the values (including bitrot). As to "the uses of this template", the documentation states explicitly that it gives the latest use, so if there is a divergent 1% use, that should not concern us. Your question has successfully talked me out of the suggestion.

Accordingly, it probably makes sense to simply substitute the new values, taking care it update the corresponding citation at the same time, which will also serve to track how far the replacements have occurred if not all done simultaneously. As a side project, it probably also makes sense to strip {{CODATA2010}} of its data values, leaving it as only a citation, to fit the pattern of the other CODATA templates. —Quondum 13:15, 15 May 2024 (UTC)

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