Template talk:Convert

Template:Convert

... in conception

... and in reality

Am I reading this correctly?

There's no current ability to convert gross tonnage to cubic meters? — LlywelynII 16:49, 22 January 2023 (UTC)

According to our article, that's a non-linear conversion,

$V={\frac {50\times \ln 10\times GT}{W(5\times 10^{11}\times \ln 10\times GT)}}$

where $ln$ is the natural logarithm and $W$ is the Lambert W function.

That would seem to be well beyond Convert's algorithms. NebY (talk) 17:06, 22 January 2023 (UTC)

Potential error in certain mph to km/h conversion

Hi, I've spotted a bit of an oddity: {{cvt|90|mph}} is erroneously producing 140 km/h, but {{cvt|90|mph|0}} correctly produces 145 km/h. It doesn't seem to affect other input speeds; {{cvt|75|mph}} and {{cvt|75|mph|0}} both produce 121 km/h, and similarly 45, 60, and 100 mph all also produce the correct figure either way. Is there something I've overlooked? Thanks in advance. XAM2175 ^(T) 17:10, 26 January 2023 (UTC)

@XAM2175: from the FAQ at the top of the page:

Q: When using {{convert}} why does the answer sometimes seem a bit off?

A: This template takes into account the precision of the supplied value and generally rounds the output to the same level of precision. If you need to change from the default output precision, see rounding.

60 mph and 90 mph have one significant figure each, while 45 mph and 75 mph have two each. (Trailing zeros before a decimal place are not significant by default.) The template will add an extra sig fig in some default calculations, so the output with 60 mph and 90 mph each have two sig figs. The difference is that while 60 mph becomes 97 km/h with those two sig figs, when you round off 144.8 km/h to two sig figs, you get 140 km/h because the result has a digit in the hundreds place. You'd have to increase the output there to three sig figs to get 145 km/h, which is two more than the input of 90 mph.

When you add |0 to the template, you're overriding this default behavior and telling it to round the output to 0 decimal places regardless of the number of sig figs in the input. Imzadi 1979 → 19:41, 26 January 2023 (UTC)

Thank you for answering @Imzadi1979, but with respect, I don't view this as a "behaving as expected" situation – a casual user of the template will be expecting to see 90 mph converted to 145 km/h without needing any special configuration. I discovered this because I found a casual user manually replacing numerous applications of this template in an article with hard-coded conversions, presumably on the basis that the template was unreliable. XAM2175 ^(T) 20:26, 26 January 2023 (UTC)

I don't know about others, but we studied significant figures in my high school and college science courses, and it was drilled into us that you never give an answer more precise than your given input values. Strictly speaking, converting "90 mph" with 1 sig fig should give "100 km/h", also with 1 sig fig, but as a compromise, the template supplies an addition sig fig in certain cases based on the scaling factors involved, thus giving "140 km/h" as the result. The template won't add a second additional sig fig to give you "145 km/h" without the user taking an affirmative step to do so, like specifying the level of rounding or specifying the number of sig figs in the output, like adding |sigfig=2. This is all explained in the rounding explanation linked from the FAQ.

So for this template to do as it does is the expected behavior to me and many others. Imzadi 1979 → 20:56, 26 January 2023 (UTC)

I know way more cases where results have too many digits. I believe in this case, 140 is better than 100. 90+/-5 goes to 144.8+/-8, and so 140. 100 is closer to zero significant digits. Most often you should have one extra digit for intermediate results, to avoid over rounding. Gah4 (talk) 22:16, 26 January 2023 (UTC)

Convert has to handle a wide range of conversion of different units of values. So it has to handle things like converting 3000 miles to an equivalent km. More often than not, the 3000 mile input figure is hugely rounded, so it makes no sense to give an output as 3,000 mi (4,828 km). Instead, it estimates the rounding required from the number of zeroes at the end of the input figure to show 3,000 mi (4,800 km). The rounding of 90 mph works from the same generic principle. For a generic tool, there is no other course of action that won't cause more problems than it solves. So, convert has extra parameters so that you can specify how much rounding you want. You can specify significant digits, or how many digits before/after the decimal point or rounding by 5 or 50. The only 2 realistic choices that convert could have chosen for its default is to be ultra precise (knowing that the majority of users will convert 3000 miles to 4,828 km with far more precision than the input deserves) or to estimate the rounding from the trailing zeroes by default (as above, knowing that some values like 90 round a bit too much in some circumstances). Users will make mistakes no matter which default we choose.  Stepho  talk  22:41, 26 January 2023 (UTC)

I can see your point about having to handle a wide variety of inputs, but I'm still deeply troubled to find that the default behaviour across all applications is to actively produce a conversion less precise than the input because some of those applications might involve pre-rounded inputs. XAM2175 ^(T) 17:36, 27 January 2023 (UTC)

Defaulting to increases of precision such as from 90 to 145 would be yet more troubling. NebY (talk) 17:43, 27 January 2023 (UTC)

@NebY and @Imzadi1979: I'll freely admit to not having continued with mathematics after I finished high school, so I apologise if I'm stumbling over something that college students are expected to find easy – but I'm genuinely still unconvinced. This discrepancy popped up in describing a railway locomotive's maximum speed, which is given by the manufacturer as "90 mph". Now, obviously, giving "144.84096 km/h" as the equivalent is needlessly over-precise, but in my view "140 km/h" is not much better, and worse is counter-intuitive. That same manufacturer has similarly built locomotives with maximum speeds of 75, 100, and 125 mph, all of which are given with neither no more nor no less precision than when they specify 90 mph – but as the user of the template I'm expected to know that whole numbers ending in zero are converted differently, and that the degree of difference can vary depending on the relative 'size' of the result? Looking more closely I can see that the same behaviour affects the conversion of 100 mph, but it's much less egregious because "160 km/h" verses "160.9344 km/h" verses "161 km/h" looks like a much-more-simple choice of truncation or rounding. At the very very least this should be made much more clear in the template documentation. XAM2175 ^(T) 18:18, 27 January 2023 (UTC)

@XAM2175: put another way, "90 mph" is only precise to the tens place, unless notated differently. The default output of "140 km/h" is also only precise to the tens place. So looking at it that way, the input and output are equally precise. If "90 mph" is precise to the ones place, it needs to be notated differently because that 0 in the ones place is ambiguous: could the device measure in increments of 1 mph, or only in increments of 10 mph? There are a few ways to express intended precision unambiguously, like "90. mph" or "90 mph". The template can handle the former as an input, or a rounding factor can be used like |0.

{{cvt|90.|mph}} ➡️ 90 mph (145 km/h)

{{cvt|90|mph|0}} ➡️ 90 mph (145 km/h)

When converting 75 mph, the default output is 121 km/h; both are equally precise to the ones place. Because the last digit is not a 0, it is assumed that the measurement device can measure in increments of 1 mph.

Now, viewed in line with other stated measurements, a reader could assume that the "90 mph" is precise to the ones place because the other measurements in a series are also precise to the once place. The template cannot make that assumption because it only sees the individual input it's acting upon. If it's given a grouping of inputs, it can use all of them to figure a default precision:

{{cvt|75|,|90|,|100|and|125|mph}} ➡️ 75, 90, 100 and 125 mph (121, 145, 161 and 201 km/h)

That example uses precision from the "75 mph" and "125 mph" inputs for consistency.

As to the documentation, there's an entire section that explains how the template handles rounding, and it's the first FAQ at the top of this talk page. Imzadi 1979 → 18:30, 27 January 2023 (UTC)

Thank you for the explanation; it's helped me understand things better.

As to the documentation, there's an entire section that explains how the template handles rounding, and it's the first FAQ at the top of this talk page – this is part of the problem, though: without the better understanding I now have, neither of those explanations appeared to relate to the circumstances I was describing. Template:Convert § Default rounding (the first part of the "entire section" you mention) doesn't address the significant figures issue because the first example used is 123 ft; both {{convert|123|ft|m}} and {{convert|123|ft|m|0}} produce 37 m. The second example, 500 ft, does – I grant – illustrate the issue, but with the explanation same output as with -1 (above), because the conversion factor is between 0.2 and 2 (hence, it should produce same [sic] double-zero precision (−2) as in the input value), but the conversion must produce two significant digits at a minimum (hence, a higher single-zero precision (−1) is used)... which, to tell you the truth, I still don't really understand, and which appears to presuppose that users of the template already know the conversion factor of the conversion they're intending to perform. Remember, this is meant to be the standard guidance; the hatnote says that the "more mathematical description" is at Help:Convert § Rounding.

As for the the first FAQ on this talk page, 1) the discrepancy about which I was concerned seemed to be more than just a bit off, 2) it assumes that the reader's understanding of precision extends to significant figures before the decimal, and 3) it's only at the end of the linked Help:Convert § Rounding section that An input value such as 5000 is assumed to have one significant figure, while 5001 has four finally appears.

Neither of these, however, address my central concern: I'm only here because I know that 90 mph shouldn't convert to 140 km/h in practical applications. What happens for users who don't? XAM2175 ^(T) 19:30, 27 January 2023 (UTC)

I hesitate to add anything for fear of detracting from Imzadi's excellent account. Still, to be exact about this specific case, our article doesn't say it's the manufacturer's advertised top speed. It's a train unit specification which, without being able to see the paywalled journal describing the specification, may be more of a classification than a test speed, and certainly wasn't something like a speed record which would require precision. That specification was abandoned and replaced with one described as "75 mph (121 km/h)", also using Convert's default but in this case producing, to my eyes, excessive precision and thus an illustration that somehow reprogramming Convert to default to higher precision would have distinct disadvantages. It is disturbing that our article confuses speed and acceleration, calling for a maximum speed of 90 mph (145 km/h), acceleration comparable to contemporary EMUs. NebY (talk) 19:28, 27 January 2023 (UTC)

Re It is disturbing that our article confuses speed and acceleration..., this was accidentally introduced in this very recent edit where the editor removed five items from a seven-item list but failed to convert the comma between the remaining two items into "and". Thanks for pointing it out, and I've now corrected it.

Re It's a train unit specification which, without being able to see the paywalled journal describing the specification..., the exact quote from the source is

For the longest spacing, as typified by Birmingham–Norwich (17 miles station spacing), a 7 h.p./tonne unit geared for 90 mile/h is 0.5 per cent slower than a unit geared for 75 mile/h. 75 mile/h was, therefore, selected as this would show benefits in journey time on the vast majority of routes with shorter station spacing.

Additionally, in different places in the journal, the specifications are given as: 90 mile/h top speed (145 km/h) and 75 mile/h top speed (120 km/h). While I concede the difference between 120 and 121 km/h, I think it's reasonably evident that the descriptions intentionally include a level of precision higher than just "in the ballpark" (if I'm understanding your may be more of a classification correctly). XAM2175 ^(T) 19:50, 27 January 2023 (UTC) ETA: the journal is available via the Wikipedia Library, should you wish to view it yourself.

We may be getting a bit deep into the weeds here, but I do notice that quote refers to gearing for a higher speed actually achieving a lower overall speed, rather reinforcing my sense that these were to some extent nominal ratings. I'm reminded of the imperial series of pipe and flange sizes based on nominal bores, ½", ¾", 1", 1¼", 1½", 2", 2½", 3" etc which are now commonly designated as 15, 20, 25, 32, 40, 50, 65, 80 etc, many of which are values that Convert would not and should not produce by default. In that way, using equivalents taken from the source doesn't seem such a bad thing here. NebY (talk) 15:10, 28 January 2023 (UTC)

References

It's a basic question of significant figures. 9000, 900, 90, 9, and .9 all have one significant figure. 7500, 750, 75, 7.5, and .75 all have two significant figures. The default rounding behavior operates based on the number of significant figures in the input number (with the conversion adding one sigfig for most conversions). Frankly, it would be much more surprising if some conversions gave you additional precision. To write 90mph as having two significant figures, you would have to write 90. mph. This is not specific to WP, this is universal practice. Similarly, 90.0 has three significant figures.

Below see what conversion template does with one, two, and three sigfigs in the input:

{{cvt|90|mph}} 90 mph (140 km/h)

{{cvt|90.|mph}} 90 mph (145 km/h)

{{cvt|90.0|mph}} 90.0 mph (144.8 km/h)

But in the end, I would say that the numbers provided in the reference are actually rounded to fives and not to either one or two significant figures - which is actually another option: {{cvt|75|to|90|mph|round=5}} 75 to 90 mph (120 to 145 km/h). (this result may seem counterintuitive, as the more precise input number has a more rounded output and vice versa.) It is often up to the editor to figure out what level of precision is provided in the original source; the default converter cannot possibly know the context. Best,  Mr.choppers | ✎  01:58, 12 February 2023 (UTC)

Rounding for multiple units

I want to have an input of 1991 cc display as 2.0 L (1991 cc; 121 cu in) - ie L to 1 digit and cc and cuin to 0 digits. I was hoping that something like {{cvt|1991|cc|L cc cuin|order=out|adj=ri1|0}} would do it, based on |abbr=in abbreviating the first displayed param rather than the actual first. But it rounds the actual first param and shows as 2 L (1,991.0 cc; 121 cu in). Any clues?  Stepho  talk  09:42, 12 February 2023 (UTC)

Have you considered using {{Convert}} twice? (§ doc) DePiep (talk) 09:49, 12 February 2023 (UTC)

I did. It's my fall-back but it's kind of clumsy and I was hoping for something shorter and more elegant. And anything complex is harder for future (possibly novice) editors to replicate for new bits of info they want to add.  Stepho  talk  11:06, 12 February 2023 (UTC)

Yes. I did not research deeply, so maybe that more elegant solution exists. DePiep (talk) 11:55, 12 February 2023 (UTC)

I have been banging my head against this wall for a long time. In general, I just omit cubic inches since they are largely disused, even in the US. A better workaround is {{cvt|1.991|L|cc cuin|adj=ri1|0}} which produces:

• 2.0 L (1,991 cc; 121 cu in). Best,  Mr.choppers | ✎  13:35, 15 February 2023 (UTC)

Yes, that looks like a good work-around. Thanks.  Stepho  talk  21:45, 15 February 2023 (UTC)

Hundredweight

For Adler (locomotive), how does one convert 177 hundredweight (long) to pounds and kilograms? Peter Horn User talk 21:37, 10 March 2023 (UTC)

{{convert|177|Lcwt|lbs kg}} should do the trick: 177 long hundredweight (19,800 lb; 9,000 kg). XAM2175 ^(T) 21:58, 10 March 2023 (UTC)

@XAM2175: Thanks Peter Horn User talk 01:35, 11 March 2023 (UTC)

Special adjective

Most of the articles I write are related to 19th century military history, when cannon were generally known by the weight of the projectile they fired, so the general names for these guns are often things like 32-pounder, 12-pounder, 100-pounder, etc. Is there a way to make this template spit out the -pounder adjective, or will I just need to manually perform conversions of these weights into kilograms? Hog Farm _Talk 02:56, 15 March 2023 (UTC)

How about an example of what you would like displayed in an article? Help:Convert#Extra words shows some suggestions but convert shows the name of the unit so it will show "pound" which would look silly next to "pounder". If you explain what is wanted, we may have some ideas. Don't perform manual calculations. How many articles (roughly: 10? 1000?). Johnuniq (talk) 03:58, 15 March 2023 (UTC)

An example would be in the text at Battle of Grand Gulf - This fort mounted a 100-pounder Blakely rifle, another 8-inch Dahlgren piece, and two more 32-pounders., with pounds to kg for the gun sizes, or USS Marmora (1862) - Initially, Marmora was armed with two 12-pounder rifled cannons and two 24-pounder guns. (a change I've specifically been asked to make at the FAC). I'm unclear how many articles this could potentially be used in, but see Caliber#Pounds as a measure of cannon bore for a better explanation of the situation. Hog Farm _Talk 13:34, 15 March 2023 (UTC)

How about {{convert|100|lb|kg|disp=x|er (|)|0|sing=on}} to give "The fort mounted a 100-pounder (45 kg) Blakely rifle."

And {{convert|32|lb|kg|disp=x|ers (|)|0|sing=on}} to give "two more 32-pounders (15 kg)."  Stepho  talk  13:53, 15 March 2023 (UTC)

This usage will appear in a very large number of milhist articles even in the Cold War era. I've also seen it abbreviated as "pdr", though I'm not sure if that's considered acceptable. The form suggested by @Stepho-wrs seems to satisfy the request, but I wonder if perhaps it would be worth creating a new template employing the Convert module especially for this purpose? XAM2175 ^(T) 13:58, 15 March 2023 (UTC)

I don't think it's appropriate to supply kg conversions for x-pounder guns. Conversions are to help people who are more familiar with the other units in the field under discussion. If there were a tradition of rating guns in terms of kg, then we should give conversions, but there is no such kg tradition, only a pounder tradition. And for most of the guns that are described as x-pounder, there is no object with a mass of x pounds that is used with them. A bore diameter in mm is helpful to readers, but not a conversion to kg. Indefatigable (talk) 16:03, 15 March 2023 (UTC)

I agree with Indefatigable. Stepho's solution is very elegant (still trying to figure out what some of it does exactly), but I do not think there is a reason to convert these to metric as it is not how guns are measured. If anything, these would best be manually converted to cm or whatever unit of length is most suitable.  Mr.choppers | ✎  19:59, 15 March 2023 (UTC)

That's true for the specific case of weights. However, metric units of length are used for the caliber of artillery; even in the US, artillery intended for use in NATO has a metric caliber, e.g., 105 mm, 155 mm. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 11:17, 16 March 2023 (UTC)

I agree, that's why I suggested manually converting the weight into diameter, if that is even possible. Is there a clear conversion method from, say a 12-pounder to millimeters?  Mr.choppers | ✎  12:41, 16 March 2023 (UTC)

For modern US artillery, there's the millimeter caliber, but in Mexican War/Civil War/etc., the cannon were generally known by either an inch bore-diameter: see, for instance, 3-inch ordnance rifle or M1841 6-pounder field gun. I don't think I've ever seen a source refer to a Civil War cannon by a mm designation. Hog Farm _Talk 14:16, 16 March 2023 (UTC)

I'm not aware of a US metric caliber weapon prior to NATO. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:49, 17 March 2023 (UTC)

There's the 105mm M2/M101 to start. Orange Suede Sofa (talk) 18:46, 17 March 2023 (UTC)

They likely did not use mm, but a conversion is in order to explain obsolete units that would otherwise be meaningless to the majority of readers.  Mr.choppers | ✎  20:32, 17 March 2023 (UTC)

They did use mm, as can be seen from the technical manual from the time. Orange Suede Sofa (talk) 20:38, 17 March 2023 (UTC)

We've shown that convert can translate from pounder to kg (although it is a bit long to call it elegant). The question of whether it should be used, in what context and whether it should have a wrapper template is a question that belongs at WP:WEAPON. And of course we can't convert from pounder to mm but the question of converting inches to mm for cannons also belongs there.  Stepho  talk  20:55, 17 March 2023 (UTC)

Li unit

I was editing Heaven and I discovered the measure in the Theravada Buddhism is the lǐ. Is it possible to add it? Thanks.--Carnby (talk) 17:28, 24 March 2023 (UTC)

It seems to me the most appropriate units to support in the Convert template are ones that have a generally agreed value in SI units. The article about the li unit seems to indicate there are a variety of different values. It might be more appropriate to expect any editor who mentions this unit to explain what value is intended in the article where it is used, rather than rely on a conversion template. Jc3s5h (talk) 17:35, 24 March 2023 (UTC)

Well, I'm not sure SI is the touchstone, but in general {convert} should restrict itself to units that have been reasonably stable over time. EEng 20:09, 24 March 2023 (UTC)

If added it then we would have to be able to distinguish between the various values used over time - in much the same way that we distinguish between imperial and US gallons. Possibly we could have the units called "gongli", "li-xia", "li-qin", etc.  Stepho  talk  01:32, 25 March 2023 (UTC)