Template talk:Convert/Archive July 2018

sp= param

Is there any reason the value for the sp= param should be case sensitive? I can never remember whether it's sp=US or sp=us, and usually get it wrong, since "us" is normally capitalized in other contexts. Kendall-K1 (talk) 23:02, 13 June 2018 (UTC)

My flash response: uppercase "US" = the region (country), while lowercase "us" is the language. - DePiep (talk) 23:26, 13 June 2018 (UTC)

ISO (and posix) would say the language is "en" and the region is "US". But I see what you're saying, and it is a convenient way to remember how the parameter works. Kendall-K1 (talk) 23:33, 13 June 2018 (UTC)

But? So? -DePiep (talk) 00:16, 14 June 2018 (UTC)

There are two schools of thought about parameters: (1) accept as many variations as possible for user convenience, or (2) require that all options are entered in a consistent manner so people don't have to wonder if sp=us is subtly different from sp=US (like spell=in is different from spell=In). I agree that maybe US would be a reasonable exception but I'm not sure because where does it stop: why should abbr=OFF be rejected? Currently, all convert's options are lowercase except where the uppercase means something such as with spell=In. Johnuniq (talk) 01:24, 14 June 2018 (UTC)

I'd suggest keeping it exactly as it is. Flexibility might seem to be convenient to the lazy, but in my experience, something rigid that complains at you immediately is far less work in the long run. Add this to this that the template does have case sensitive parameters as you point out, and I think there is little choice. I am reminded of a computer science lecturer mentioning a compiler that was flexible in what it accepted (it probably chose the closest valid construct or inferred what might have been meant), but this was found to be counterproductive; simply flagging the error was less problematic. —Quondum 01:20, 1 July 2018 (UTC)

Reliable sources?

Since this template is widely uses on many articles, including those with FA status, I have to ask why aren't the conversions reliably sourced? I would kindly request that the keepers of the template documentation provide reliable information as to the source of all the formulae. To do otherwise would be a violation of WP:VERIFY and the second pillar. Thank you. Praemonitus (talk) 21:46, 25 June 2018 (UTC)

Please provide a proposal at WP:RSN after considering WP:CALC. Johnuniq (talk) 22:38, 25 June 2018 (UTC)

Yes, well WP:CALC specifically says "a meaningful reflection of the sources". Okay, so I'm asking what are the sources you're using to be in compliance? I'm not questioning the validity of the calculations, I'm asking for a source for the conversion constants. Are they from a reliable source, or has somebody just made them up? If they are valid, are they up to date or obsolete? Thanks. Praemonitus (talk)

FTR the discussion started here. 93.136.38.21 (talk) 01:01, 26 June 2018 (UTC)

There is an article at Conversion of units which has some references, but is not fully referenced. -- WOSlinker (talk) 08:20, 26 June 2018 (UTC)

WP:VERIFIABILITY says that "All material in Wikipedia mainspace [...] must be verifiable"; no exceptions. This also applies to converted units and their conversion factor, roundings, calculations, &tc. (The original value, which includes the unit, should be verifiable through its regular reference).

First, for uncommon units, MOS:UNITNAMES says "Units unfamiliar to general readers should be presented as a name–symbol pair on first use, linking the unit name" (italics added): 2.3 megaelectronvolts (MeV). I would add, per WP:V again, those units "challenged or likely to be challenged" (exotic or unstable defined ones) should be treated the same. So in these cases WP:V is solved through the link; the article should contain conversion factor(s).

Second: for commonly known units, advised to be names at first mentioning and from there the symbol can be used, no linking is required. Those can be verified by wiki-searching them: "Search" wikipage "millimeter" or "mm" (mm leads to a dab page).

So theoretically all units used in {{Convert}} are verifiable within Wikipedia. One could make this point: do all units have a target page, e.g., also when a SI-prefix is added? This would be a leak when: 1. the prefix+symbol is not an article title (not even a DAB page), and the full unit symbol was not once written by name in the article. The second omission is up to the article editor, not {{Convert}}. DePiep (talk) 13:08, 26 June 2018 (UTC)

In other words:

1. The original value (= number × unit) should be available in RS, likely through a reference. This is with or without using {{Convert}}.
2. The converted value (= new number × new unit) should be WP:VERIFIABLE always (is not: sourced in the article).
3. The new unit name can be wikilinked to the [new] unit's article, which gives direct access to the unit's definition, its conversion factors and the sources thereof.
4. When the unit name is not linked, it is searchable in wiki by name.
5. When only the unit's symbol is given in the article, a search could/should lead to a wiki article, possibly a disambiguation page containing the actual unit wikilink.
6. Name or symbol variations (like secret plural form, SI prefix added) should also be covered (wikilinked): one cannot expect the reader to reform these deviant spellings into their root.
7. With this, each converted value can be verified within wiki.
8. Caveats: it is not certain that all unit variants (both name and symbol: plurals, SI prefix, ...) have a target page. Also, and existing unit article musty have the conversion factor(s) [...when not SI?].

-DePiep (talk) 13:35, 26 June 2018 (UTC)

I'll just note that Wikipedia itself is not an acceptable source for verification, per WP:USERG. What I'd really like to see is a table at the bottom of the documentation page with a list of reliable sources used for the conversion units, preferably in order of priority. That way anyone can look at the template source code and verify the units. Thanks. Praemonitus (talk) 15:48, 26 June 2018 (UTC)

The conversion data seems to be located in Module:Convert/data. There's no indication of a source. I took a look a quick look at one random entry: ft/s2 into m/s2 is 0.3048. The Foot per second squared article is barely sourced; one link is inaccessible, the other doesn't list the conversion factor. The Metre per second squared is a little better, but doesn't cite the conversion scale. Where does it come from? Praemonitus (talk) 20:30, 26 June 2018 (UTC)

I wouldn't expect to find it there, I'd expect to find it at Foot (unit), which currently has 46 sources listed. Kendall-K1 (talk) 20:47, 26 June 2018 (UTC)

• re Wikipedia itself is not an acceptable source for verification: sure. What I described is: the source of a converted unit, and its unit conversion factors & roundings &tc., is RS-sourced in the unit's article and such, like significant figure. If not: improve per wiki — but {{Convert}} is not responsible.
• When you would like to see a table: good question, won't happen. As I described: conversion is RS'ed through the unit article.
• The only test you could require from {{Convert}} is: are all possible unit descriptions (name, symbol, variants like plurals & SI-prefixed), as applicable in articles, linked to the right article (the one that sources that unit)?

-DePiep (talk) 21:53, 26 June 2018 (UTC)

Even worse: The Foot per second squared article is barely sourced. Ugh, how is {{Convert}} to blame for this? That article is bad, but that does not say Convert is bad. (Even if you don't use {{Convert}} in your article, that issue is there!).-DePiep (talk) 22:07, 26 June 2018 (UTC)

If this is the template policy then why not simple state this in the documentation? (Say in the Units section.) That way editors can address the data source, rather than speculating. I'm also checking the various units page and finding in a number of cases the citation is horribly bad. I can see a slew of {{Refimprove}} templates are in order. Thanks. Praemonitus (talk) 22:19, 26 June 2018 (UTC)

NOOOOOO. There is no "template policy" re this. There is WP:V re all we publish at Wikipedia, and {{Convert}} supports that. -DePiep (talk) 23:19, 26 June 2018 (UTC)

The masterlist for what units are converted, using what conversion factors, is at Module:Convert/documentation/conversion data/doc. The National Institute of Standards has conversions; I'll see if that is the source. The British Standards Institute changes £272.00 for their version. StarryGrandma (talk) 22:12, 26 June 2018 (UTC)

For measurements of length (and derived measurements of velocity or acceleration) the conversion should need no debate. One inch is exactly 25.4 millimetres. From this, all other length conversions may be produced by simple multiplication or division: for example, the above-mentioned conversion of ft/s2 into m/s2 (acceleration) simplifies to a conversion of feet to metres (because they have a common denominator) and since there are 12 inches to the foot and 1000 mm to the metre, it works out as 25.4 * 12 / 1000 or 0.3048 and this is exact, there has been no rounding or truncation of decimal places. --Redrose64 🌹 (talk) 22:43, 26 June 2018 (UTC)

User:Redrose64 wrote "One inch is exactly 25.4 millimetres." That's false. Jc3s5h (talk) 22:55, 26 June 2018 (UTC)

No, it isn't? At least not since the sixties. --tronvillain (talk) 23:01, 26 June 2018 (UTC)

(edit conflict)What do you mean by that? By the definition of English units in terms of metric units, one inch comes out to exactly 25.4 mm. StarryGrandma (talk) 23:04, 26 June 2018 (UTC)

See https://www.ngs.noaa.gov/INFO/Policy/files/DRAFT_SPCS2022_Policy.pdf

That document makes it clear the US survey foot has a long future. There is probably a survey inch which would be 1/12 of a survey foot, and a survey foot sure as heck isn't 12 international inches. Jc3s5h (talk) 23:09, 26 June 2018 (UTC)

quite boring: someone stating on a talkpage what a definition is. Now that is self-wiki sourcing. -DePiep (talk) 23:16, 26 June 2018 (UTC)

The NIST list is just the list at BIPM website, the SI people. We should document that the conversion factors are those of the international standards and where to find them. StarryGrandma (talk) 23:07, 26 June 2018 (UTC)

The sources are:

• Organisation Intergouvernementale de la Convention du Mètre (2014) [2006]. The International System of Units (SI) (PDF). Bureau International des Poids et Mesures. Retrieved 26 June 2018. This document links to the NIST document below in section 4.2 "Other non-SI units not recommended for use".
• Thompson, Ambler; Taylor, Barry N. (November 2008). Guide for the use of the International System of Units (SI) - Publication 811, 2008 Edition, 2nd printing (PDF). National Institute of Standards and Technology, U.S. Department of Commerce. Retrieved 26 June 2018.

StarryGrandma (talk) 23:33, 26 June 2018 (UTC)

Nahhhhh. WP:CALC is very clear that references are not required for conversions: "Routine calculations do not count as original research, provided there is consensus among editors that the result of the calculation is obvious, correct, and a meaningful reflection of the sources. Basic arithmetic, such as adding numbers, converting units, or calculating a person's age are some examples of routine calculations.".

So as long as we agree between us the conversions are being done correctly, it's all good. And if we decide they aren't we change it until they are.GliderMaven (talk) 00:29, 27 June 2018 (UTC)

So references would not be necessary for this edit, then, right? That is a conversion from magnitudes (logarithmic scalar) to percentages (linear scalar). 93.139.1.106 (talk) 01:46, 27 June 2018 (UTC)

No, you need to show how it was calculated and the source that provides the basis of the calculation. Otherwise editors can just make up rubbish and have people questioning its authenticity. Praemonitus (talk) 01:56, 27 June 2018 (UTC)

IMO it is you who needs to show that this is materially different than the km/h-mph conversion. When people type in "50 km/h (31 mph)" instead of using the convert template, surely you agree it would be ridiculous to tag that with some problem template. 93.139.1.106 (talk) 02:10, 27 June 2018 (UTC)

Your calculation involves the 'log' function plus a decent knowledge of math and how magnitudes work in astronomy. Your average lay person is not going to know how to do that, whereas they can probably do a metric to English conversion without a great deal of difficulty. Ergo, it's not a "routine" calculation. QED. Besides, you did it wrong since you only computed the variation range in one direction then assumed it was the same in the opposite. The log function is non-linear. Praemonitus (talk) 02:30, 27 June 2018 (UTC)

I did nothing wrong -- in fact I anticipated what you incorrectly derived here. The range is almost the same for such a small magnitude/percentage value, and while I could have written 2.7-2.8 or 2.73-2.80, I chose not to since 2.8 is already one sigfig more than the original value. That this calculation is difficult for you doesn't imply that it is less complicated than say, 9 litres per 100 kilometres (31 mpg_‑imp; 26 mpg_‑US), which again needs and uses no citations. 93.139.1.106 (talk) 02:56, 27 June 2018 (UTC)

I'm familiar with Taylor's theorem, thanks. The fact that it required you several sentences to explain the entire derivation makes it clear that it is non-trivial. WP:CALC necessarily doesn't apply. Praemonitus (talk) 03:03, 27 June 2018 (UTC)

I was describing my reasoning in choosing the number of significant figures. According to your logic we should make a footnote every time we write 200 kilometres per hour (120 mph) instead of 200 kilometres per hour (124.27424 mph) because it takes more than one sentence to describe the concept of significant figures. A reference from that article should also by your logic be included in every article using Convert with rounding. 93.139.1.106 (talk) 03:08, 27 June 2018 (UTC)

Now you employ a straw man argument. I see. No, I'm suggesting that the data used in the Convert template should be provided with demonstrated sources. If a non-obvious calculation is presented in an article, then it should be clarified in a footnote along with a reference where a lay reader may gain further enlightenment. You, however, would hide all that and deny the reader useful knowledge. How is that useful for an encyclopedia? Praemonitus (talk) 03:15, 27 June 2018 (UTC)

I was merely responding to your own straw man argument about me taking up several sentences (to in fact describe the concept of significant figures). Your lay reader will gain further enlightenment through the link to the stellar magnitude page which is already present, just as they will through the link to the miles per gallon page, etc. Up until today the agreement has been that that is indeed satisfactory. Explaining the concept of stellar magnitude on each and every page about a star is redundant and quickly becomes annoying to the regular reader, not to mention takes extra effort to maintain. Stellar magnitude is not the topic of Vega and there's no need to make it so. 93.139.1.106 (talk) 03:24, 27 June 2018 (UTC)

I've checked 93.139.1.106's conversion and it seem reasonable, and anyone likely to use apparent magnitude should be capable of doing the same conversion.GliderMaven (talk) 03:33, 27 June 2018 (UTC)

Thanks. The correctness of the conversion is not the element in dispute. Unfortunately WP:CALC is very open to interpretation, so we're not likely to reach a useful conclusion in this matter. I took care of my issue in a footnote, so as far as I was concerned the matter was settled. Praemonitus (talk) 03:43, 27 June 2018 (UTC)

It appears you're interpreting it quite incorrectly. The phrase "meaningful reflection of the sources" pretty clearly shows that sources are required to execute a calculation. How else can you explain its presence in the statement? We don't want just random calculations; they have to be based on sources. Praemonitus (talk) 01:50, 27 June 2018 (UTC)

I always assumed that meant reflection of the sources for the number, not for the conversion factor. So for example if a London newspaper said "a gallon of petrol" I would convert that to 4.5 litres, but if a New York newspaper said "a gallon of gasoline" I would convert that to 3.8 liters. In neither case would I supply a source for the conversion factor I used, unless some pedant tagged it with a cn. Kendall-K1 (talk) 02:15, 27 June 2018 (UTC)

It probably needs some clarification then. Here I am challenging a widely used template for not following the five pillars and I'm just getting brushed aside. Praemonitus (talk) 02:35, 27 June 2018 (UTC)

You are being overly pedantic. All these conversions are verifiable, just through other WP articles, which are usually linked nearby anyways, and that satisfies it. 93.139.1.106 (talk) 02:56, 27 June 2018 (UTC)

Welcome to the recording of encyclopedic knowledge, where pedantry is entirely appropriate. Praemonitus (talk) 03:04, 27 June 2018 (UTC)

Wikipedia certainly isn't going down the rabbit hole of referencing all manual unit conversions. Nor should convert. WP:CALC is setting a perfectly reasonable standard here.GliderMaven (talk) 03:33, 27 June 2018 (UTC)

WP:Calc is irrelevant to my OP. The accuracy of the conversion data is my issue, but I can address that on my own. Praemonitus (talk) 03:45, 27 June 2018 (UTC)

Issues and concerns

• The conversion scale for the elementary charge (Module:Convert/documentation/conversion_data/doc#Charge) doesn't appear to be "current", or at least it doesn't match the value on the elementary charge page. Do we know where it came from? Praemonitus (talk) 04:07, 27 June 2018 (UTC)

  It was sourced from the old version of convert, from the Template:Convert/e page (now deleted), which as created by User:Jimp in Feb 2010. Looking at elementary charge from Feb 2010, the figures are the same at that point in time. -- WOSlinker (talk) 08:23, 27 June 2018 (UTC)

  Well I'm impressed you were able to run that down. Thanks. Meanwhile the Convert template is now "inaccurate" since the NIST reference has changed. Praemonitus (talk) 13:23, 27 June 2018 (UTC)

  Bingo! You just answered your OP yourself. This is how wikipedia validation works. - DePiep (talk) 21:24, 27 June 2018 (UTC)

  No I didn't; I needed help to find out where the value came from. Praemonitus (talk) 14:47, 28 June 2018 (UTC)

• On Module:Convert/documentation/conversion_data/doc#Charge, the conversion unit for BTU is 1055.05585262 Joules. On the BTU article, the ISO conversion unit is 1055.06. On Conversion_of_units#Energy, it is 1.05505585262×10³ J, so presumably that is the source for the Convert template? The former is cited; the latter doesn't appear so. At present I have no idea which value is correct. Praemonitus (talk) 15:07, 28 June 2018 (UTC)

Both are correct; published ISO values have fewer significant figures. For the more precise value see the footnote on page 45 of the 2008 NIST document I mentioned above. StarryGrandma (talk) 15:19, 28 June 2018 (UTC)

Oh I see, you have various different BTU variants listed. Thanks. I wonder though, would it make some sense to migrate all these standard data values to WikiData and reference it there? Praemonitus (talk) 15:40, 28 June 2018 (UTC)

The BTU is not a precise or standard unit, and it has several different definitions. Sources that give heat in BTUs rarely specify which BTU they're talking about. For this reason I would be reluctant to use more than four significant figures when converting BTUs. Did you have some particular article in mind where this would make an actual difference in practice? Kendall-K1 (talk) 15:28, 28 June 2018 (UTC)

No, I just edit a lot of science articles where Convert gets used so I'm checking the sources for my own peace of mind. Thanks. Praemonitus (talk) 15:40, 28 June 2018 (UTC)

• In Module:Convert/documentation/conversion_data/doc#Energy, the eV (electron volt) has a scale of 1.602176487e-19 Joules. In the electronvolt article, it is 1.6021766208(98)×10⁻¹⁹ J, based upon NIST. Praemonitus (talk) 18:18, 28 June 2018 (UTC)

The first is from the 2008 NIST doc I gave, referenced to CODATA 2006, the second is from CODATA 2014, the upcoming CODATA 2018 will probably change since measurement progresses. For the purpose of this convert template any of them will do. The point is they all come from reliable secondary sources, the result of committees putting together the current best values. We don't need all those significant figures for the usual conversions. These are easy to find online with Google - just google the number and the unit and NIST or CODATA to bypass all the conversion sites that use Wikipedia's data. StarryGrandma (talk) 19:39, 28 June 2018 (UTC)

Yes I understand, but I was given the impression above that the values were being referenced from the specific unit articles. In some cases those articles aren't as well cited as they should be. Thanks for the clarification. Praemonitus (talk) 19:53, 28 June 2018 (UTC)

• The infobox for inch of Mercury relies upon the Convert template for the SI unit value of 3.38639 kPa. The Module:Convert/documentation/conversion_data/doc#Pressure gives a scale of 3386.388640341. This NIST web page lists a "inch of mercury, conventional (inHg)" value of 3386.389 Pa, so possibly it was standardized at some point. Praemonitus (talk) 14:38, 29 June 2018 (UTC)

• Pound-foot (torque) relies on the Convert template for its values without providing citations. Praemonitus (talk) 14:56, 30 June 2018 (UTC)
• Why do I still get the impression that NIST is presented as being equal to SI? I'd expect: SI (BIMP) is leading, NIST is for non-SI situations. -DePiep (talk) 22:16, 1 July 2018 (UTC)

  It's more complex than that. BIPM adopts what amount to recommendations. Individual countries decide if they want to follow the recommendations or not, and if they do, individual countries (or political subdivisions thereof) are the ones who send inspectors into the marketplace to enforce the regulations, and fine or imprison violators. The US has one of the world's largest economies. Jc3s5h (talk) 23:17, 1 July 2018 (UTC)

  ("Imprison"?) To address the concern, I think we can reasonably trust regional bodies like NIST to accurately represent BIPM's guidance. But it would be nice to see references to other national equivalents. —Quondum 23:57, 1 July 2018 (UTC)

Conversion triplets

In some articles the sources come from multiple countries that use different units but we still want to present them in a consistent order (eg metric first for most articles). |order=flip is really great for the most common case of 2 units (eg hp and kW) but its a bit tricky for mixing 3 units (eg PS, hp, kW). If a references says a car has 200 PS but we want to display kW first then {{convert|200|PS|kW hp|0|abbr=on|order=flip}} gives us the rather weird 147 kW; 197 hp (200 PS). Is there some way to shift the hp figure back inside the brackets?  Stepho  talk  09:35, 2 July 2018 (UTC)

Yes, order=out allows an exact specification of what is wanted. The first output unit is displayed as the input, then the other output units are displayed as the outputs. The real input can be displayed by repeating it in the output, or can be omitted.

• {{convert|200|PS|kW hp PS|0|abbr=on|order=out}} → 147 kW (197 hp; 200 PS)
• {{convert|200|PS|kW hp|0|abbr=on|order=out}} → 147 kW (197 hp)

OMG I just looked for where this has previously been discussed and found January 2017. I don't remember that either! Johnuniq (talk) 10:13, 2 July 2018 (UTC)

Thanks, |order=out is exactly what I need. I feel a bit foolish for not remembering the Jan 2017 response to my question. Probably a consequence of age and IQ converging :(  Stepho  talk  11:24, 3 July 2018 (UTC)

As suggested by the description above ("rather weird"), it is difficult to imagine |order=flip with three units being used (with its current behaviour). Might it not make sense to make it do something more intuitive, like switching only the input and the first output parameter? —Quondum 12:10, 2 July 2018 (UTC)

I guess my question is, why is |order=out not documented on the template page? I would go ahead and add it, but is there a reason? — Huntster (t @ c) 12:40, 2 July 2018 (UTC)

It is: |disp=out. Johnuniq, which version is preferred? One should probably be deprecated (missed earlier), and the documentation adjusted. To me, |order=out seems to be what should be preferred. —Quondum 13:13, 2 July 2018 (UTC)

Compare:

• {{convert|200|PS|kW hp PS|0|abbr=on|order=out}} → 147 kW (197 hp; 200 PS)
• {{convert|200|PS|kW hp PS|0|abbr=on|disp=out}} → 147 kW; 197 hp; 200 PS

Default (not using |abbr=):

• {{convert|200|PS|kW hp PS|0|order=out}} → 147 kilowatts (197 hp; 200 PS)
• {{convert|200|PS|kW hp PS|0|disp=out}} → 147 kW; 197 hp; 200 PS

It occurs to me that |disp is logically phrased as #Displaying_parts_of_the_result, while |order=out is addressing the order of parameters. Both are sound, I see no reason to deprecate one. -DePiep (talk) 23:18, 2 July 2018 (UTC)

Added to documentaion #Fixed_ordering_of_output_units. - DePiep (talk) 23:28, 2 July 2018 (UTC)

disp=out is for special cases like customized text or in a table; the result is different as shown by DePiep above. Re documentation, I have kept out of that but I list module versions here because each link points to release notes documenting changes. It would be desirable for the template documentation to reflect that, and I would recommend basing any new text on the release notes. Johnuniq (talk) 23:32, 2 July 2018 (UTC)

Okay, I see – different results. Fair enough. And so capturing it in the doc, as DePiep just did, makes sense. —Quondum 02:23, 3 July 2018 (UTC)

I did not add to the documentation starting & citing from the release notes... In general, Editor's /doc may have different approach than technical background. Als, little space (for example, should doc detail the formatting varinat effects as we saw in the examples here?).

And can we conclude that for triplets, using flip is never a good idea? (it is confusing; see OP). -DePiep (talk) 12:01, 3 July 2018 (UTC)

Electron-volt <=> Kelvin

Another useful conversion. This says the rate is 1 K = 8.621738 X10^-5 As always, thanks! Lfstevens (talk) 06:16, 1 July 2018 (UTC)

That's probably the Boltzmann constant. Praemonitus (talk) 13:28, 1 July 2018 (UTC)

Should be: "1 degree kelvin= 8.621738 X10-5 eV" (with the unit),

or: 1 K = 8.621738×10⁻⁵ eV. -DePiep (talk) 13:43, 7 July 2018 (UTC)

The word "degree" has not been used with the kelvin since 1968. --Redrose64 🌹 (talk) 16:05, 7 July 2018 (UTC)

'The word "degree" has not been' officially 'used with the kelvin since 1968.' :-) It's often used when speaking, even if the SI police disapprove. Martin of Sheffield (talk) 16:47, 7 July 2018 (UTC)

So what & so what? -DePiep (talk) 00:27, 8 July 2018 (UTC)

It should be: "1 Kelvin = 1.380649×10⁻⁵ eV" per CODATA (2017). Praemonitus (talk) 14:12, 8 July 2018 (UTC)

Energy and temperature do not generally have the same units. The conversion scale linked is for use when using units that set the Boltzmann constant k=1. Only in that case does the equation hold. Notice that the same conversion web page says 1 eV = 8065.54 cm^-1. See Boltzmann constant#Planck units. StarryGrandma (talk) 14:26, 8 July 2018 (UTC)

• Anyway, is there any practical use in wiki vfor this requested {{Convert}} conversion? Any articles? - DePiep (talk) 15:07, 8 July 2018 (UTC)

  DePiep and StarryGrandma raise cogent points (I suspect the answer to DePiep's question is "Few or none"). Units of energy and temperature are treated as independent quantities in the ISQ and hence SI (which is the framework that guides the MoS and {{convert}}). This means that it does not qualify as a conversion. There is also a problem of the conversion factor: is it the average thermal (i.e. kinetic) energy per degree of freedom (⁠1/2⁠k), or per free particle (⁠3/2⁠k), neither of which is k. I think it should be abundantly clear that this is problematic, and this is enough reason to avoid providing such a conversion. —Quondum 13:32, 9 July 2018 (UTC)

Links

@Johnuniq: For conversions involving more than two units, is it possible to only link some of the units independent of which side the units are on? For example, in 10.35 mi (10 mi 28 ch; 16.7 km), I would like to only link to chain (unit) from "ch". If it's not possible, it would be nice if something like |lku=ch be added to link the first instance of a unit or units. Jc86035 (talk) 07:32, 14 July 2018 (UTC)

@Jc86035: Hah, I was just getting ready to post at WT:WikiProject UK Railways#Compromise proposal for adoption (V). Use chlk instead of ch if a linked ch is wanted (or use chainlk for chain).

• {{convert|10|mi|28|ch|mi michlk km|abbr=on|order=out}} → 10.35 mi (10 mi 28 ch; 16.7 km)
• {{convert|10|mi|28|ch|mi michainlk km|abbr=on|order=out}} → 10.35 mi (10 mi 28 chain; 16.7 km)

Johnuniq (talk) 07:41, 14 July 2018 (UTC)

Ah so!  — SMcCandlish ☏ ¢ 😼  07:44, 14 July 2018 (UTC)

Support for formatting numbers with gaps as per MOS:DIGITS?

Is there any way convert formats numbers with gaps as per MOS:DIGITS? For example, to work in harmony with template:val? Betterkeks (talk) 01:10, 20 July 2018 (UTC)

Yes, searching the doc page for "gaps" finds |comma=gaps. Please be careful with that because a general encyclopedia should almost always use commas despite the glowing endorsement at MOS:DIGITS. There are science topics where gaps are good but they usually don't bother with conversions. Johnuniq (talk) 04:01, 20 July 2018 (UTC)

Is that preference for commas still true? With increasing exchange of data with Europe, commas occasionally cause confusion (is 123,456 approximately 10^5 or 10^2?). Before I retired, I got the impression standards committees were leaning away from the use of commas in numbers, with committee members going out of their way to avoid text which would use them. Tarl N. (discuss) 05:16, 20 July 2018 (UTC)

Looking around shows that commas are standard in numbers here, although that's just my opinion and in typical fashion MOS:DIGITS avoids giving firm guidance. As it happens, I just reverted some attempts to replace commas but I would be hard pressed to find a guideline to support my revert and have to rely on the maxim that we don't arbitrarily change existing styles. Johnuniq (talk) 05:48, 20 July 2018 (UTC)

Well, it looks like the Chicago Manual of Style prefers commas too (although only for five digits and more - 2314 doesn't get a comma). I suspect this is going to be one of those evolving usage things like what "billion" means. Tarl N. (discuss) 23:48, 20 July 2018 (UTC)

Citing this template

I just added the following to The Station nightclub fire § Investigation:

...(4,484 square feet [412 m²] [sic]...

with the note:

Page 3-1 of the source gives both the figure of 4,484 square feet and of 412 m². However, 4,484 square feet equals 416.6 m².)...

Is there any way to cite this template when providing the correct conversion in the note? —  AjaxSmack  01:50, 22 July 2018 (UTC)

I don't think you should cite this template; Wikipedia is not a WP:RS. The right thing to cite would be a reliable reference specifying the conversion of square feet to square meters. E.g., CRC. Tarl N. (discuss) 02:58, 22 July 2018 (UTC)

​Thanks. I'll do that. In an earlier discussion on this talk page, something came up about whether use of this template was permitted under WP:RS. One editor said to the effect that basic calculations don't require sourcing, but in this case I am contradicting a source. That's why I asked. —  AjaxSmack  15:57, 22 July 2018 (UTC)

Yup. The basic arithmetic to do the conversion is not WP:OR (as this template does), and referencing the correct conversion factor suffices for pointing out where a WP:RS is incorrect. Obviously, with the information you have, you can't specify which value is correct, just that they don't agree. I will suggest, however, that the citation could be improved. Rather than "NIST Manuscript Publication Search". nist.gov. Retrieved October 31, 2015., perhaps "NIST NCSTAR 2, Report of the Technical Investigation of The Station Nightclub Fire, Vol 1". nist.gov. Retrieved October 31, 2015.? (Use the url of the destination document, rather than the search url). Regards, Tarl N. (discuss) 16:33, 22 July 2018 (UTC)

I will also suggest, doing some OR, that it looks like the areas for each room were calculated separately (and rounded), and then added up. See diagram on page 7-14. So it's not bad conversion that was done, but instead rounding errors that are causing the small discrepancy. Tarl N. (discuss) 16:46, 22 July 2018 (UTC)

I was going to suggest a transcription error, since 412 m² is very close to 4434 square feet, which could be mis-transcribed as 4484. Kendall-K1 (talk) 16:50, 22 July 2018 (UTC)

References

Margin of error and the sigfig option

If I convert a value with a margin of error, the 'sigfig' setting is applied to a different decimal range for a variance smaller than 1. For example:

{{Convert|54.8|+/-|1.1|Gm|AU|abbr=on|sigfig=3}} → 54.8 ± 1.1 Gm (0.366 ± 0.00735 AU)

It should look like this:

54.8 ± 1.1 Gm (0.366 ± 0.007 AU)

Praemonitus (talk) 16:19, 20 July 2018 (UTC)

If you have a desired outcome, it's typically just easier to set the number of decimal places. The template tries to be intelligent, but it simply cannot account for every user's preference, and in your example, sigfig is doing exactly what it is supposed to be doing. Instead, just use:

{{Convert|54.8|+/-|1.1|Gm|AU|3|abbr=on}} → 54.8 ± 1.1 Gm (0.366 ± 0.007 AU)

— Huntster (t @ c) 20:53, 20 July 2018 (UTC)

So, the |3| is the formal route (not a trick): the 'latest' unnamed param is doing it right (doc). - DePiep (talk) 00:23, 22 July 2018 (UTC)

Thanks. Praemonitus (talk) 16:32, 23 July 2018 (UTC)