Template talk:Convert/Archive February 2017

Error with lb-f-ft

Torque conversion broke with {{convert|xxx|ft-lb|Nm|abbr=on}}. Erkinalp9035 (talk) 18:29, 1 February 2017 (UTC)

Erkinalp9035, try {{convert|5|ft.lbf|Nm|abbr=on}}. Frietjes (talk) 19:08, 1 February 2017 (UTC)

Thanks, now need to fix all occurrences in engine template documentation. Erkinalp9035 (talk) 19:09, 1 February 2017 (UTC)

{{convert}} or {{cvt}}?

My edit inserting {{convert}} into an article was changed by other editor by replacing it with {{cvt}}. The edit summary said: ce: In a technical article, keep proper SI notation ([1]). I know that there has been previously deletion discussions of {tl|cvt}} and there is no consensus; however, is there any guidelines which says that in technical articles we should use {{cvt}} instead of {{convert}}, or that is not a proper SI notation? I am asking because I never seen that kind of claims before; however, I have not followed all relevant discussions about this topic. Thank you in advance. Beagel (talk) 13:41, 12 February 2017 (UTC)

Not really an answer to your question, but shouldn't the first use of "miles" be at least spelled out, maybe even linked? Kendall-K1 (talk) 14:15, 12 February 2017 (UTC)

To answer your question, absolutely not. There is not nor has there ever been, to my knowledge, consensus that CVT should be used over Convert in any circumstance. That template is just another fork that has been aggressively pushed out into the article space. — Huntster (t @ c) 15:25, 12 February 2017 (UTC)

The OP is not about {{cvt}} existence, but about applying |abbr=on in {{convert}}: should symbols or names be used? -DePiep (talk) 20:14, 12 February 2017 (UTC)

Well, your absolute certainty is misplaced, since there are such circumstances per Wikipedia:Manual_of_Style#Units_of_measurement: "Where space is limited (such as tables, infoboxes, parenthetical notes, and mathematical formulas) use unit symbols", which is what the default use cvt achieves over the default use of convert. Whether you feel that the introduction of cvt has been 'aggressively pushed out' seems irrelevant, given that cvt has a justified use. So the question is, in highly technical articles (Viking Link, COBRAcable) with plenty of SI-notation, should the unit symbols be allowed over unit names in order to maintain some consistency in the notation? Lklundin (talk) 15:55, 12 February 2017 (UTC)

The quote from Wikipedia:Manual_of_Style#Units_of_measurement is irrelevant here as these templates were in the body text, not in the tables, infoboxes, parenthetical notes, or mathematical formulas. Beagel (talk) 16:11, 12 February 2017 (UTC)

The guideline is Wikipedia:Manual of Style/Dates and numbers #Unit names and symbols: "In prose, unit names should be given in full if used only a few times, but symbols may be used when a unit ... is used repeatedly, after spelling out the first use". I've edited Viking Link to comply. --RexxS (talk) 16:19, 12 February 2017 (UTC)

• {{cvt}} is not about SI/non-SI writing. It is exactly equal to {{convert|abbr=on}}, and so only pertains to abbrevated/spelled out (or: unit symbol vs unit name).

The es by Lklundin In a technical article, keep proper SI notation is incorrect: writing names is equally correct. 'proper' SI does not dictate so, and Lklundin admits so by referring to MOS (no SI). All in all, 'abbr=on' is a matter of MOS and style, so the edit was badly motivated in the es, and thereby unhelpful for Beagel. -DePiep (talk) 20:14, 12 February 2017 (UTC)

• As DePiep notes above, the section heading is misleading: this has nothing whatsoever to do with {{cvt}} versus {{convert}} but about whether units should be abbreviated or not in a particular case. My only comment on the real issue is that I find the original 740 kilometres (460 mi) odd. I don't care whether it's 740 km (460 mi) or 740 kilometres (460 miles). Peter coxhead (talk) 22:21, 12 February 2017 (UTC)
  • That's actually quite rational. The reason for spelling out a unit name on first occurrence is that the reader might not be familiar with its abbreviation. However, any reader who needs a conversion into their own familiar units will most likely already be familiar with the abbreviation. The default for {{convert}} spells out the first unit and abbreviates the converted unit, which fits that design philosophy. It's not so important for units that most people recognise, like kilometres and miles, but it makes good sense when you're writing less common quantities like 100 kilopascals (15 psi). Annoyingly, MOSUNIT tries to simplify that too much, hence the advice to spell out all units on first occurrence. --RexxS (talk) 02:18, 13 February 2017 (UTC)

@RexxS: it might be rational if "mi" were an easily recognized abbreviation for "miles". What makes you think that ordinary readers are more familiar with "mi" than "km"? Where do you see "mi" used in popular sources? Peter coxhead (talk) 09:35, 13 February 2017 (UTC)

Answer: because "mi" is used, unmistakably, in context with "kilometres": 740 kilometres (460 mi). This is the {{convert}} default and, as RexxS described, a slight improvement over the more crude MOS. -DePiep (talk) 09:47, 13 February 2017 (UTC)

Indeed, DePiep, thank you. I'm sorry I wasn't clearer, Peter, but if you ask yourself the question "who needs a distance in kilometres converted into miles?", the answer has to be someone who is much more comfortable visualising distances in miles, otherwise the conversion has no point. Anyone who comprehends distances in miles won't fail to spot "mi" as the abbreviation in that context. Hope that helps. --RexxS (talk) 15:47, 13 February 2017 (UTC)

RexxS, nothing to say sorry for, I was just trying to upgrade the replies into documentation-level for future reuse :-). If you want to, you could add this latest point to the quoted Recap below. -DePiep (talk) 07:45, 14 February 2017 (UTC)

Recap

• Recap: This is a recurring issue on this page. Allow me to quote/repeat the core replies here, for future reference and because they answer the issue most clearly imo. Note: What is called "abbreviation" and |abbr=on is, in SI wording, "write unit symbol" as opposed to "write unit name" (this does not change the unit definition itself: km = kilometre always).

The guideline is Wikipedia:Manual of Style/Dates and numbers #Unit names and symbols: "In prose, unit names should be given in full if used only a few times, but symbols may be used when a unit ... is used repeatedly, after spelling out the first use". (...) --User:RexxS 16:19, 12 February 2017 (UTC) [about writing 740 kilometres (460 mi), 740 km (460 mi) or 740 kilometres (460 miles):] That's actually quite rational. The reason for spelling out a unit name on first occurrence is that the reader might not be familiar with its abbreviation. However, any reader who needs a conversion into their own familiar units will most likely already be familiar with the abbreviation. The default for {{convert}} spells out the first unit and abbreviates the converted unit, which fits that design philosophy. It's not so important for units that most people recognise, like kilometres and miles, but it makes good sense when you're writing less common quantities like 100 kilopascals (15 psi). Annoyingly, MOSUNIT tries to simplify that too much, hence the advice to spell out all units on first occurrence. --User:RexxS 02:18, 13 February 2017 (UTC)

Intentional misleading Rounding

• {{convert|250|km/h|mi/h|abbr=on}} = 250 km/h (160 mph)
• {{convert|160|mi/h|km/h|abbr=on}} = 160 mph (260 km/h)

— Preceding unsigned comment added by 2001:a62:118b:7501:4b2:8d64:906:c50d (talk • contribs) 21:43, 29 January 2017 (UTC)

The FAQ at the top points out that convert takes into account the precision of the supplied value and rounds the output to the same level of precision.

The following shows that an inpute with two significant figures gives two sig figs in the output, while an input with three sig figs gives three in the output. The last two examples show how to round to 0 decimal places and how to specify three sig figs.

• {{convert|250|km/h|mi/h|abbr=on}} → 250 km/h (160 mph)
• {{convert|251|km/h|mi/h|abbr=on}} → 251 km/h (156 mph)
• {{convert|250|km/h|mi/h|0|abbr=on}} → 250 km/h (155 mph)
• {{convert|250|km/h|mi/h|sigfig=3|abbr=on}} → 250 km/h (155 mph)

Johnuniq (talk) 21:52, 29 January 2017 (UTC)

So that is an intentional error, it's broken by design, voluntarily misleading, even hostile to readers and editors. It has to be the default that all input digits are considered significant, in 250 just like in 249 or 251. Fix it! --2001:A62:118B:7501:4B2:8D64:906:C50D (talk) 00:00, 30 January 2017 (UTC)

That's not correct; in scientific literature, unless a specific error range is specified, the accuracy is presumed to be the number of non-zero digits. E.g., 980,000 is presumed to be accurate within about 1%, not within 1 ppm. Tarl N. (discuss) 01:19, 30 January 2017 (UTC)

Similar complaints, about {convert} over-rounding of common amounts, have been raging for almost 10 years. Resistance to fixing {convert} rounding has been intense because, "We've always done it that way" (or at least, always for several years). A major problem is that {convert} was modified after 2007 to treat numbers ending in "0" as rounded to nearest 10 units (rather than nearest 1 unit). So, "250" is not treated as 249+1 but rather 245-255 rounded mid-way, while the public's "number sense" of 250 mph (402 km/h) is typically 249+1 because many speed records are precise, and in the U.S., many traffic cops write speeding tickets for speeds exceeding a specific number+1. Another problem in {convert} precision is a misunderstanding about how to round significant digits after calculating a conversion with a constant conversion factor. See subtopics below for detailed explanations, at "#Fixing Convert for number sense" or "#Implied precision of smaller units". -Wikid77 (talk) 16:56, 19 February 2017 (UTC)

Fixing Convert for number sense

In recent years, schools have been teaching students "number sense" about common units in modern society ("Now class, which is more: 1 metre or 10 cm?"), to remind students how numbers are interpreted in various aspects of everyday life. Students should learn small items are priced to the cent $0.01, but larger items in whole $dollars like cars, or houses in $1,000s. There are many measurement units where numbers ending in zero "0" should be treated as n+1, such as temperature 49–50 °F (9.4–10.0 °C), because typical thermometers are calibrated to 1-unit marks, 49/50/51 etc. Likewise, 29–30 mph (47–48 km/h) is seen as 29+1 because U.S. cars show dashboard speed to 1-unit precision, 29/30/31, and traffic cops could fine a driver exceeding 30 mph in some residential neighborhoods. The number sense of "30 mph" is 29+1, rather than 25.1 rounded up, and likewise 249–250 mph (401–402 km/h) is typically viewed as with speed records, precise to the digit, not like estimating, "My boss gave me 250 tasks today". Hence, many units should treat end zero "0" as a significant digit like 249+1, rather than 245-255 rounded to middle. A related problem of {convert} precision is a misunderstanding about how to round amounts multiplied by a constant conversion factor, as explained below. -Wikid77 (talk) 16:56, 19 February 2017 (UTC)

Implied precision of smaller units

Another issue which implies higher precision is the conversion to a much-smaller measurement unit. When a conversion shows an amount in a smaller unit, then the implicit assumption is that the result would not generate over-precise nonsense. For example, a rough mile could be about 2 km, but a measured mile to tenths would be in the range of feet 0.9–1.1 mi (4,752–5,808 ft) or 1 ± 0.1 mi (5,280 ± 530 ft), or to hundreds as:
• 0.99–1.01 mi (5,227–5,333 ft) or 1 ± 0.01 mi (5,280 ± 53 ft), or thousands:
• 0.999–1.001 mi (5,275–5,285 ft) or 1 ± 0.001 mi (5,280.0 ± 5.3 ft).
Hence a conversion of miles-to-feet implies the measured mile is precise to 1.000–1.001 mi (5,280–5,285 ft); otherwise a single amount in feet cannot represent a roughly measured mile. Only a range of feet, 5,200-5,300 could fairly represent an approximate 1.00 mile. Therefore, the only sensible conversion of a mile-to-feet is as 5,280 ft because the implied precision of the input is 1.000. Any lower precision cannot be shown as a single amount in feet, only as a range of feet.

Next consider mph-to-km/h: The problem of treating "50 mph" as a 10-unit span provides a nonsense result which does not indicate the resulting 16-unit interval in km/h:

• 45–55 mph (72.4–88.5 km/h) or 50 ± 5 mph (80.5 ± 8.0 km/h). Hence, the number "50 mph" cannot be treated as roughly 45-55 to show a single equivalent km/h, but as precison in 49.5-50.5:
• 49.5–50.5 mph (80–81 km/h) or 50 ± 0.5 mph (80.47 ± 0.80 km/h). The treatment of "50 mph" as 1 significant digit is nonsense during a conversion to km/h. Instead, to convert a span of 10, use a range:
• 40–50 mph (64–80 km/h) or 45 ± 5 mph (72.4 ± 8.0 km/h). The very act of converting 250 mph (402 km/h) should be treated as 249+1 or 249.5-250.5. Otherwise to convert a 10-unit estimate, a user should put a range 240–250 mph (386–402 km/h) with 2 amounts for km/h. The fallacy of thinking a 10-unit estimate can be shown as a single km/h (ending in "0") will fail because a 10-unit mph span gives a 16-unit km/h span which will not fit an end-zero "0" representation. Conversions of single amounts to smaller units imply precision to 1-unit measurements or less. However, for many users, this issue will seem a complex topic (as a "Sherlock Holmes" deduction) which needs detailed explanation elsewhere in project pages. Meanwhile, I apologize for not fixing the excessive over-rounding years ago, when other users were shocked and angered by the conversion calculations. -Wikid77 (talk) 16:56, 19 February 2017 (UTC)