Template talk:Convert/Archive October 2018

Template does not always convert tonnes to imperial units correctly.

Using the Convert template to convert between 1100 and 3100 (metric) tonnes (inclusive) to imperial units returns an incorrect answer as in:

1,099 tonnes (1,082 long tons)

1,100 tonnes (1,100 long tons) (Should be 1083)

2,000 tonnes (2,000 long tons) (Should be 1968)

3,100 tonnes (3,100 long tons) (Should be 3051)

3,101 tonnes (3,052 long tons)

and if converting to imperial pounds

1,099 tonnes (2,423,000 lb)

1,100 tonnes (2,400,000 lb) (Should be 2,425,000)

2,000 tonnes (4,400,000 lb) (Should be 4,409,000)

3,100 tonnes (6,800,000 lb) (Should be 6,834,000)

3,101 tonnes (6,837,000 lb)

This holds true for conversion of metric tonnes to any imperial units of mass including ounces, stones, troy ounces and troy pounds. Something screwy is going on because converting metric tonnes to long tons gives results that are too large whereas converting to pounds gives answers that are too small. Converting metric tonnes to short tons also gives answers that are too small:

1,099 tonnes (1,211 short tons)

1,100 tonnes (1,200 short tons) (Should be 1,216)

2,000 tonnes (2,200 short tons) (Should be 2,205)

3,100 tonnes (3,400 short tons) (Should be 3,417)

3,101 tonnes (3,418 short tons)

DocFergus (talk) 16:48, 12 September 2018 (UTC)

These all look correct to me. Did you read the FAQ? Kendall-K1 (talk) 17:13, 12 September 2018 (UTC)

How can they possibly be correct? 3100 tonnes is wrongly converted as 3100 long tons (it hasn't actually converted it at all) but a mass increase of one tonne gives a mass reduction of 48 long tons. Similarly 1099 tonnes is correctly converted as 2,423,000 lb, but a mass increase of one tonne gives a mass reduction of 23,000 lbs. DocFergus (talk) 17:24, 12 September 2018 (UTC)

I haven't bothered to review DocFergus's post in detail, because these kind of questions are almost always due to the poster failing to consider precision. The template considers the rightmost non-zero digit to establish the precision. To two significant figures, 3100 tonnes is equal to 3100 long tons. Jc3s5h (talk) 17:32, 12 September 2018 (UTC)

(edit conflict)The reason Kendall-K1 asked if you had read the FAQs is that it is explained there. {{convert}} uses rounding (as do virtually all unit conversions), and if not instructed otherwise will use the precision of the input for the output precision. 1,099 ± 0.5 tonnes is indeed 1,082 ± 0.5 long tons, just as 1,100 ± 50 tonnes is 1,100 ± 50 long tons. Likewise 1099 ± 0.5 tonnes is 2,423,000 ± 500 lb and 1,100 ± 50 tonnes is 2,400,000 ± 50,000 lb. Hope that clears it up for you, Martin of Sheffield (talk) 17:34, 12 September 2018 (UTC)

(ec) See documentation: Template:Convert#Rounding:_100_ft_is_30_m_or_30.5_m_or_30.48_m?, Help:Convert#Rounding. -DePiep (talk) 17:36, 12 September 2018 (UTC)

So what you are saying is that it is impossible to give a mass as 2000 tonnes and correctly convert to long tons without specifying that the mass is '2000.0 tonnes'. That '.0' is superfluous (as is the '.4' in the conversion) when discussing something the size of a battleship. DocFergus (talk) 17:51, 12 September 2018 (UTC)

No, the template & documentation say: bare "2000" has an implied precision of 1 significant figure (the "2"). If the measurement was more precise, like when the source says 2000±10, then use |sigfig= or the fourth unnamed parameter. Accept that the calculated conversion may always have a different precision than the input value, preferably smaller. -DePiep (talk) 18:06, 12 September 2018 (UTC)

This is the English Wikipedia, not the Simple Wikipedia. It is impossible to write "2000 tonnes" without implying a precision. Written that way, the implication is there might be some uncertainty in the thousands digit, and definitely uncertainty in the hundreds digit. If that implication is wrong, then you should write the quantity in a way that the uncertainty is clear. The converted value should be expressed with an uncertainty (stated or implied) consistent with the uncertainty in the unconverted quantity. Jc3s5h (talk) 18:08, 12 September 2018 (UTC)

There is no need to specify decimal places that are not in the source. If you know that 2,000 tonnes is exact (to the nearest tonne) and not an approximation, use {{convert|2000|t|LT|sigfig=4}} → 2,000 tonnes (1,968 long tons); if you know that it is an approximation to within 10 tonnes, use {{convert|2000|t|LT|sigfig=3}} → 2,000 tonnes (1,970 long tons), etc. --Redrose64 🌹 (talk) 21:26, 12 September 2018 (UTC)

The big problem at Turpitz is that the 2000 tonnes is most likely a very very rough rounding of the actual increase in mass over the Bismark (and no one probably knows the exact figure), so much so that even giving a conversion is rather pointless as tonnes and long (or short) tons are close enough that any real conversion is meaningless within the available precision. Anyway, thanks for all your input - at least I learnt something. DocFergus (talk) 17:17, 13 September 2018 (UTC)

Not to change any result, but maybe there is an other reason to convert to long tonnes: long tons may be the familiar unit for those reading the topic. That is, if LT is commonly used too, readers might not know beforehand that metric tonnes ~~ long tonnes. In this case then, no problem mentioning 2000 twice. -DePiep (talk) 22:48, 13 September 2018 (UTC)

U.S. conversion precision

Just a reminder, in the U.S. there are legal regulations to increase the precision of measurement conversions, such as for danger limits (to not overround) or for product sizes (to not fail measurement validation tests), by using calculations developed in 2006 by NIST. In general, when the output number drops to lower first digit, then increase precision by +1, as in 2,000 tonnes treated as 2 significant digits but with 3-digit output:

• {{convert|2,000|t|LT|sigfig=3}}
• 2,000 tonnes (1,970 long tons)

To match product labeling, truncate the output amount, rather than risk rounding up to an untrue larger amount. The NIST temperature conversions round Celsius output to 0.5 increments, as in 78 °F (25.5 °C), but that would expand climate tables to show many extra ".5" digits, and WP would need to use extra rounding in climate tables, to keep the Celsius numbers shorter as they appear now. The over-rounding in the Lua version of Convert tends to be within a 2% error margin, but many of our users still notice the peculiar amounts, compared to typical U.S. calculations which have better precision. -Wikid77 (talk) 12:02, 14 October 2018 (UTC)

I'd like to read the NIST source on this (their prescription). Then, if we add this layer of conversion rules (say, add |level=NIST), we move from physical quantity values to legal values. Until now, all precision & rounding in {{Convert}} is based on physical precision, not legal requirements (of course I understand the need to not-oversize a danger level etc.). Related: is this encyclopedia required or supposed to provide such (semi-)legal information? Need to research pages like WP:NOLEGAL. -DePiep (talk) 18:33, 14 October 2018 (UTC)

I would be very much opposed to adding any "product labelling" cruft to the template. Product labeling not only has its own rounding rules, it has its own units too. For example the "US food labelling fluid ounce" is not the same as the "US customary fluid ounce". Kendall-K1 (talk) 16:49, 23 October 2018 (UTC)

It seems to me Wikipedia is inherently incapable of being used as a product label or as a placard in a dangerous situation. Let people writing articles about such matters convert by hand, and leave this complexity out of the template. It's too bad one template can't detect other templates on the same page. If this were possible we could create a template to disallow the convert template on a given page, and display a giant red warning if one were present. Jc3s5h (talk) 17:40, 23 October 2018 (UTC)

Jc3s5h, It's too bad one template can't detect other templates on the same page. But it can. Just have to use WP:LUA, grab the text of the page, and do a search for "{{(.-)|" to get all the templates. Not sure of the utility though. Galobtter (pingó mió) 18:18, 23 October 2018 (UTC)

inherently incapable of being used as a product label: inherently yes. We create an encyclopedia, not a how-to or label-printing vehicle. -DePiep (talk) 18:22, 23 October 2018 (UTC)

T&Fcalc

I just noticed Template:T&Fcalc which implements "Track and field marks". basically, this is "convert from m to ftin, but _round down_ to the nearest 1⁄4 inch". not sure if it would be useful to have a "round down" option in {{convert}}. Frietjes (talk) 15:32, 23 October 2018 (UTC)

I put an experimental version in the sandbox to trial this. I'm not sure that convert should replace every special-purpose template but if there is some reason that would be helpful in this case, it should be ok. Rounding is handled in several places in the module and I only modified what happens when the result includes a fraction. Examples:

• {{convert|1.826|m|frac=64|abbr=on}} → 1.826 m (5 ft 11+57⁄64 in)
• {{convert|1.826|m|frac=4|abbr=on}} → 1.826 m (6 ft 0 in)
• {{convert/sandbox|1.826|m|frac=4|round=down|abbr=on}} → 1.826 m (6 ft 0 in)
• {{convert|1.8349|m|frac=64|abbr=on}} → 1.8349 m (6 ft 15⁄64 in)
• {{convert|1.8349|m|frac=4|abbr=on}} → 1.8349 m (6 ft 1⁄4 in)
• {{convert/sandbox|1.8349|m|frac=4|round=down|abbr=on}} → 1.8349 m (6 ft 1⁄4 in)

The syntax might not be desirable since it suggests round=down would work without frac=x. We can think about that if it is useful. Johnuniq (talk) 04:31, 24 October 2018 (UTC)

Use |round=IAAF (+describe in doc)? There might be asked for more named rulesets (see NIOSH, above). - DePiep (talk) 07:22, 24 October 2018 (UTC)

Template:T&Fcalc also mentions the reverse calculation: {{T&Fcalc2}}. -DePiep (talk) 07:24, 24 October 2018 (UTC)

Since this is no regular (mathematical/physical) quantity rounding and imprecision, shouldn't there be added like:

• 8.87 m (29 ft 1 in; IAAF rounding); this optionally (once per article). -DePiep (talk) 07:36, 24 October 2018 (UTC)

Or, present the calculation as a range:

• 8.87 m (29 ft 1 in to 29 ft 1+1⁄4 in; IAAF rounding)

But as with the product labelling discussion above, should this template really cater to every specific custom system out there? Heck, should *Wikipedia*? — Huntster (t @ c) 13:05, 24 October 2018 (UTC)

Covert meters to feet and vice-verse with m a.s.l.

Is it possible to create meters/feet convert template with "m/ft a.s.l." (above sea level)? Instead of specific article links, I will refer you to most of "Geography infobox templates" where you have item "Elevation", or any article very you need to designate geo-elevation within text body.--౪ Santa ౪^99° 01:15, 27 October 2018 (UTC)

At San Bernardino Mountains, {{Infobox mountain range}} shows:

Elevation    11,499 ft (3,505 m)

Are you saying that should be 11,499 ft a.s.l. (3,505 m a.s.l.)? Is there a discussion somewhere (a wikiproject) about this? Johnuniq (talk) 02:41, 27 October 2018 (UTC)

Not needed, not wished even per SI brochure. A height specifier like "a.s.l." should bepart of the quantity (elevation), not incorporated in the unit (do not create: "m a.s.l.", or "a.s.l. meters"). formally "a.s.l." could be a suibscript ("elevation_a.s.l."), but descriptive is readible too ("elevation a.s.l."), and in this situation it can be added after the value but not part of it (e.g. in infoboxes): "Elevation: 123 m (404 ft) a.s.l.". This way it does not even have to be merged into {{Convert}} gramatically (like adjectives are). -DePiep (talk) 09:01, 27 October 2018 (UTC)

Johnuniq Yes, and unlike above editor "DePip" I believe additional template is very much needed. It's an issue especially within body of an article, where some editors indicate elevation with abbreviation a.s.l., but most don't, often not knowing that this geographical parameters consists of both "elevation" and "prominence", which, than, under the specific circumstances should be imperative to designate and distinguish - and this is beside an issue of uniformity, where all article should at least try to take uniformed layout and style, particularly dealing with physical gauging and values.--౪ Santa ౪^99° 21:24, 28 October 2018 (UTC)

Yes. And that uniformity wrt units, values and quantities is well-defined in the SI brochure, I linked. "a.s.l." should not be part of the unit. - DePiep (talk) 21:36, 28 October 2018 (UTC)

There should be a link to a wikiproject discussion where a consensus that this would be desirable can be seen. I cannot imagine that displaying "a.s.l." twice in a convert would be desirable, and the a.s.l. would have to be linked or at least have a popup "above sea level" explanation. For elevation in an infobox, that can be done by including the a.s.l. after the convert. Johnuniq (talk) 04:24, 29 October 2018 (UTC)