Template talk:Physical constants

Planck and reduced Planck

Related discussion: Talk:Planck_constant#Seconds_vs._per_hertz. fgnievinski (talk) 04:36, 6 November 2023 (UTC)

A second-level shared reference idea

Primefac, since you seem to be active, I was wondering whether you might know of some way of implementing the double-stage referencing as in the CODATA value references at Hartree atomic units. That still has some shortcomings: (a) I have not found how to integrate the final full-detail CODATA 2018 reference cleanly into the references list rather than as a separate item, and (b) creating this reference from within the {{Physical constants}} template, including avoiding duplication, is totally beyond me.

If we can figure out how to do this, we would be able to put all detail we wish into the final CODATA 2018 reference while keeping the individual value references compact. —Quondum 14:22, 1 January 2024 (UTC)

See related discussion WP:TEA#Suppressing a footnote tag.^[perma] A proposed solution outline is given there. Mathglot (talk) 22:08, 2 January 2024 (UTC)

Proposal

Opinions, please – I would like to get opinions on consolidating of the shared reference between all the references before I start sandboxing the changes to the template itself. I have a proposal with comparison here:

comparison of existing and proposed referencing
Existing Body text1. Body text2. Body text3. Body text4. Body text5. Proposed Body text1. Body text2. Body text3. Body text4. Body text4.

When there are few invocations in an article, the reference is simply split into two, but when there are many, around the space is used. We can also include more specific detail with the consolidated shared reference if we wish, without the extra multiplying in the article. Look at Hartree atomic units for an example that approximates the proposal. The only issue I see is that the list of back-links on the shared reference is nonfunctional. (Mathglot, thank you for the insightful input at WP:TEA.) —Quondum 16:23, 3 January 2024 (UTC)

Just to clarify the above: by your proposal as given above, you mean strictly what is rendered/viewable on the page; that is, the underlying wikicode is only a mockup and any successful implementation of your proposal will generate wikicode that will result in a page looking like what we see above, while most likely having wikicode done "the right way" and that looks quite different. I will respond to your specific proposal, but I'd like to put my response on hold for a moment, to place it in context by adding a sidebar below (forthcoming) reviewing how we deal with repetitive information in citations currently, which may affect either the proposal, or the implementation of it. Thanks, Mathglot (talk) 21:36, 3 January 2024 (UTC)

Correct. The wikicode on the page would be exactly as for the "Existing" case above: this template is already extensively used, and the only changes would be to the template itself. The proposal above is after template processing. However, I'm not sure that this is done "the right way", in the sense that it does some unusual things, especially hiding <ref>...</ref> code inside a string that the wikicode parser processes, but then gets dumped because it is inside an unused <span>...</span> parameter. I'm not very happy with it: it is still a hack, and would like to be able to do this more cleanly. My sandbox has two variants, where 'Variant 2' is less of a hack, but uses actual footnote tags rather than a bluelink, and is also not ideal in rendering. —Quondum 22:02, 3 January 2024 (UTC)

Sidebar on repetitive information in citations

There are some larger issues related to yours, and I think it would help to mention them, as it might clarify things by situating your issue in a larger context. Some questions arise when citing large sources or repositories:

1. How do you best target information in a large source, such as a thousand-page book, or a large, online repository of like items?
2. How do you avoid duplicating full citations in the References section that are exact duplicates of each other?
3. How do you avoid duplicating full citations in the References section that are nearly duplicates of each other, except for a small, varying part?

It seems to me that this template attempts to (or should) deal with all three of these questions. A is already handled, via the url in the data table reference footnote. B and C are not, if I understand it correctly (but I'm still learning more about this template, each time I look at it).

Wikipedia has different ways of dealing with these issues currently. The cases for book/journal-based citations are somewhat different than for web-based citations due to their nature. Here are four use cases that will help distinguish them:

1. multiple citations referring to the same page (or range) of a given book or journal article
2. multiple citations referring to different pages (or ranges) of a given book or journal article
3. multiple citations referring to the same web page (same URL) of a website database/repository on a single topic
4. multiple citations referring to different web pages (different URLs) of a website database/repository on a single topic

The first three are well understood and have well documented, conventional solutions (i.e., named refs, or short footnotes with {{sfn}} templates). However, to my knowledge, there is no single, standard, recommended solution for #4, and as a result, different solutions are seen (e.g., use a linked 'loc' param in sfn; use a linked 'at' param in {{cite web}} or {{rp}}; include location within <ref> tags but outside and following the CS1 template; write a wrapper template that does one of these, like {{sfn legifrance}}. Template:Physical constants falls under the fourth use case, and therein lies the rub, I believe. Mathglot (talk) 01:08, 4 January 2024 (UTC)

A proposed solution

As labeled at the top of the previous subsection, question 'B' could be addressed by using standard named refs, if the data table and template were upgraded to handle the name attribute of the <ref> tag. If this were done, it would result in one full citation in the references section for each unique constant with a-b-c backlinks if the same exact constant were cited. An additional full, long citation would be generated for each additional constant, so if I understand what you want, this isn't desirable, because most of the same information identifying the NIST CODATA db would be repeated in the References section for every unique constant; close to what you have now; so that wouldn't be enough.

'C' could be handled as a combination of the solution for 'B', with the addition of a linked {{rp}} param following the <ref> emitted by the template currently, by e "small, varying part" as the title and url. (Another way, would be switching to emitting {{sfn}} templates instead of <ref> tags inline, and while that might've been easier if you were starting from scratch, but as there are already 87 transclusions, it's probably not worth it now.) This would make all your emitted refs except for the first one coded like this:

<ref name="CODATA-2018" />{{rp|at=[https://physics.nist.gov/cgi-bin/cuu/Value?bwien Wien wavelength displacement law constant]}}

and look like this, which is very long for an inline {{rp}} link; maybe use an abbreviated title instead in the data table instead, like this? This {{rp}} approach would require a modification to the data table and the template (most likely under control of a new param like |reuse=yes or |named=yes or similar to pull the value out of a slightly modified table which would supply the url query string (bpwien in this case) and the title on separate lines of the data item. (Actually, you could parse the title out of the existing ref, but just adding duplicate info is cheap, and keeps the template code simpler.) If it were me, I'd actually code it so that you could put any value for |reuse= as an override of the default title and it would substitute that value in instead of the data table title, which would give you some transclusion-time control of the display string for the link, which might be useful in some situations.

Note that this solution would not look like the "References" section in your boxed proposed solution above; rather, you'd have only one, single citation for CODATA-2018 in the References section (just like the References section below), with a whole pile of backlink letters attached; so that if you had 20 transclusoins of the template in the body, youid have superscript letters a through t on the one reference (just a and b in this example), but all the links would work, back and forth. The links to the individual CODATA pages would be found inline, look like the examples above, and link to the citations below. If you wanted a situation where the twenty citations appear in the reference section rather than inline in the body, that would be doable, with inline <ref>s linking to the NIST page for the constant, and containing an embedded {{sfnlink}} targeting the |ref= param of the single COVID-2018 citation. That would look pretty close to your proposal. That could be done like this. Mathglot (talk) 02:12, 4 January 2024 (UTC)

That looks neat, but how would you insert the full citation in the into the reflist from the template? (My hack, or something else?) —Quondum 02:24, 4 January 2024 (UTC)

No hack, just paste the code from the 'Refs' section below into your Refs section (but change 'reflist-talk' to 'reflist'). I would recommend making that easier, too, maybe by passing a new value of |ref=, like, |ref=long or something; so you'd just code {{Physical constants|ref=long}} and it would just spit it out, hard-coded in the tmeplate. (You could add overridable values if you wanted, so that e.g., |access-date= would default to {{subst:TODAY}} but you could override it by setting it with a new param). Or maybe even simpler, same idea, but code |ref=long on only the first invocation of the template, so that one generates the long citation in the references section only for that one, and then all the other ones just pick it up because they use named refs; or they link to it via the other solution with {{sfnlink}} + citation |ref= param, if you like that style better. Mathglot (talk) 02:35, 4 January 2024 (UTC)

I only want to modify the template; we cannot require modification of the article that invokes the template. —Quondum 02:44, 4 January 2024 (UTC)

Okay, then the 'even simpler' one above. Mathglot (talk) 02:46, 4 January 2024 (UTC)

You say you generate the reference for the first one (for now ignoring that adding the parameter implies modifying the article), which the ref tag does, but without the variant part specific to the value. Unless we are happy with two footnote tags on the first invocation. —Quondum 02:52, 4 January 2024 (UTC)

If it were my decision, I wouldn't have two tags on the first one, I'd just have whatever variant part belongs to the first one, and then all the other ones just link to that. The situation is analogous to the common situation of a <ref name="Foo"> with a {{cite book|page=12}} embedded in it as the first one, and then later a <ref name="Foo" />{{rp|14–15}} later on which links to the first one. Everybody knows that the second one is pages 14–15, even if the first one says 12. This is perhaps just another aspect of the "we don't really have standards for #4" in the sidebar section above. Mathglot (talk) 08:34, 4 January 2024 (UTC)

That doesn't work for me: too clunky. I've come across an interesting possibility, which I'll add below. —Quondum 14:28, 4 January 2024 (UTC)

Refs (idea)

References

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)