# Template talk:Convert

(Redirected from Wikipedia talk:ACONVERT)
Frequently asked questions (FAQ) edit Q: When using {{convert}} why does the answer not seem right sometimes? 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 Help:Convert. Q: What are all the possible units (kg, lb, m, cm, ft, in, °C, °F, km, mi, nmi, mph, km/h, and so on)? A: See: Help:Convert units. For more, see the FAQ.

• {{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 (talkcontribs) 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)

## 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)

## Converting feet to meter is weird

770 feet is NOT converting correctly in the top example, but the second example is correct.

Why is the first example NOT showing 234 or 235, instead of 230?

• `{{convert|770|ft|m}}` creates "770 feet (230 m)" --- captured text output is "770 feet (230 m)" on feb 13 2017.
• `{{convert|770|ft|m|1}}` creates "770 feet (234.7 m)" --- captured text output is "770 feet (234.7 m)" on feb 13 2017.
• Hand calculation is (770 feet) / (3.280839895 feet per meter) = 234.696 meter

SbmeirowTalk • 01:02, 14 February 2017 (UTC)

Perhaps it is an issue with significant figures? I notice that `{{convert|770.|ft|m}}` (with a decimal) creates "770 feet (235 m)". Master of Time (talk) 01:06, 14 February 2017 (UTC)
Indeed. Sbmeirow, see the FAQ at the top of this page. Huntster (t @ c) 01:15, 14 February 2017 (UTC)
Has it occurred to you, Sbmeirow, that 770 feet by convention has only two significant figures and, in the absence of other information, represents a distance somewhere in the range 765 feet (233 m) to 775 feet (236 m)? There's nothing weird about 230 metres – which also has two significant figures and conventionally represents a distance somewhere between 225 and 235 metres – being a reasonable conversion for that. --RexxS (talk) 01:48, 14 February 2017 (UTC)
Oh, so sloppy math is the default for encyclopedia use. 770 feet is not 770 feet +/- 5 feet, unless you state the distance is a multiple of 10 feet. If slop is the default stupid way that Wikipedia does it, then in the future I'll make sure that I force the output to be more accurate. • SbmeirowTalk • 04:06, 14 February 2017 (UTC)
The way most people use convert is to plonk it around a value like 770 ft without much thought. For that situation, convert gives the the best possible result because no one can guess whether "770" means 770±0.5 or 770±5. For example, the following shows two possible ways of converting 980,000 ft.
• `{{convert|980,000|ft|m}}` → 980,000 feet (300,000 m)
• `{{convert|980,000|ft|m|0}}` → 980,000 feet (298,704 m)
There is no way to know which of those is "correct", but the result of the first is less likely to be misleading. At any rate, rounding is explained at Help:Convert. Johnuniq (talk) 04:33, 14 February 2017 (UTC)
Sbmeirow: ... then in the future I'll make sure that I force the output to be more accurate. That's a good approach for starters. However, even better would be to know and use the precision of the input. (You only implicitly admit knowing, since you use the wording more accurate). Without having the source being specific on precision, it is not possible to tell which accuracy must be applied. For these situations, {{Convert}} uses significant figures, so as to not introduce more accuracy than the source gives. This is sound both by convention and by mathematics.
And re your 770 feet is not 770 feet +/- 5 feet, unless you state the distance is a multiple of 10 feet: that unless is what {{convert}} actually states, implicitly. This is the reasonable and mathematically sound convention, in absence of more indications (see RexxS @ 01:48). -DePiep (talk) 08:10, 14 February 2017 (UTC)
• Sbmeirow, why do you expect "234 " at all (per your OP)? -DePiep (talk) 08:13, 14 February 2017 (UTC)
I would expect 234 if the algorithm didn't round to the nearest integer digit, 235 if it rounded to the nearest integer digit. Either of them are more accurate and less offensive to me than 230, which I didn't expect at all, unless I added "|round=10". If I were to use 230 without this template in an article, I would add "approximately" or "about" or something else to clarify to the reader that the number is a rough or rounded conversion. • SbmeirowTalk • 09:06, 14 February 2017 (UTC)
The reason I'm ticked off right now is that I've been using this template for years expecting rounding to be at the right most digit when using the minimum number of parameters, as I would do if I calculated the conversion with a calculator then state the conversion in text without this template. • SbmeirowTalk • 09:06, 14 February 2017 (UTC)
If you pursued a bachelor's degree in a subject like physics or engineering you would have been made to realise that one can't simply copy a result from the display of a calculator to your finished written work. The result must at least be rounded to indicate the precision of the input; in more important results the precision is more explicitly stated with "±". The precision is as much a part of the result as the value, and a wrong precision will draw deductions from the professor as surely as a wrong value. Jc3s5h (talk) 09:34, 14 February 2017 (UTC)
The last I checked, Wikipedia isn't a physics / engineering / math class where you are expected to show all math steps to get to the final answer, and still in college most answers weren't a simple numeric answer. • SbmeirowTalk • 11:02, 14 February 2017 (UTC)
(ec) re Sbmeirow. Again, "more accurate" is an assumption you make about the input (sourced) value. If you know from the source that it is like a laboratory measurement, stating that it was "770, not 769 or 771 ft", then you could claim more accuracy (and add that to the converted value). Without such source knowledge, there is no reason to require more precision. On top of this, arguing by "I expect" is not a base to discuss this rational topic, nor is "sloppy math", "the default stupid way", "less offensive to me" -DePiep (talk) 09:41, 14 February 2017 (UTC)
Excuse me, template users expecting a conversion template to act like a calculator by default is a very reasonable and rational assumption. Since this template doesn't work like a calculator by default, then an obvious disclaimer should be stated at the top of the template documentation (above the TOC). If such a disclaimer already existed at the top, then people might not be complaining in the talk section in past years. • SbmeirowTalk • 11:02, 14 February 2017 (UTC)
There is an obvious disclaimer at the top of the template documentation talk page (above the TOC). Can you suggest some way in which it could be made clearer than it already is? Kendall-K1 (talk) 18:36, 14 February 2017 (UTC)

### Converting 770 ft as 230 m is wrong

For 10 years, {convert} has been calculating the wrong results, as the default precisions. It is NOT engineering measurements, no it is totally wrong, even for engineers. For example, I tried to explain the fallacy of the so-called "engineers rounding" algorithm, where "770 ft" represents a rounded range between 765-775 ft (233-236 m). However, for the prior 10 years, {convert} has generated "770 ft (230 m)" and sorry, but 230 is not within the result range of 233-236. The underlying problem is that engineers do not round unit-conversions that way. Instead, in conversion mathematics, the simple rule of thumb is to round a conversion to +1 digits of precision. Hence 28 grams would be converted as "1.0 ounce" not "1 ounce" but rounded to tenths of an ounce by default. Now, when considering "dimensional analysis" then the precision difference is actually noted as 28-to-1 for grams-to-ounces, where 28 is a 2-digit difference in dimensional granularity, and so engineers should convert grams with 2-digit extra precision:

• {convert|28|g|oz|2} -> 28 g (0.99 oz)
• {convert|29|g|oz|2} -> 29 g (1.02 oz)
• {convert|30|g|oz|2} -> 30 g (1.06 oz)
• {convert|31|g|oz|2} -> 31 g (1.09 oz).

Some years ago, a user, who had used typical conversion mathematics, also noted the simple +1 precision rule when not setting dimensional precision. In any event, the calculation for 770 ft should auto-set rounding as 3-digit results: {convert|770|ft|sigfig=3} -> 770 feet (235 m). Otherwise, it is just plain wrong for 770 ft to show "230 m" rather than the engineering conversion as 235 m, which is within the range 233-236 m. Immediately, {convert} should be fixed to calculate +1 digit default precision, but also long-term, the dimensionality should set the extra precision of default results, where grams-to-ounces would default +2 digits, or miles-to-ft would show +4 digits. -Wikid77 (talk)

First replies:
1. The fact that 230 is not within the result range of 233-236 is worth consideration.
2. The notion 28-to-1 for grams-to-ounces, where 28 is a 2-digit difference and so engineers should convert grams with 2-digit extra precision: I doubt this off-the-cuff. First I'd expect "28 is order of decimal magnitude 1.447" (28 log 10), so the precision should be related to that number (either 1 or a secondary calculation(?)). In other words, saying "28 so show 2 extra digits" will lead to a greater, unbased precision.
By the example '29 g', revers calculation (we understand that the original precision is the range [28.5–29.5>). Then claiming the converted value is "1.02 oz", this would claim the precision range to be between:
{convert|1.015|oz|g|3} -> 1.015 ounces (28.775 g) and
{convert|1.025|oz|g|3} -> 1.025 ounces (29.058 g)
See: this range (0.283 g) is much smaller than the source range (1 g).
3. Immediately, {convert} should be fixed to ... — what an arrogant approach. If this does not change, no reason to change the module can be conveyed. -DePiep (talk) 13:29, 15 February 2017 (UTC)
By saying, "immediately" increase precision by +1, then the intention is as step 1, where the next step would be to actually consider the digits of the conversion factor, where 1 mile is 5,280 feet as 4 significant digits of precision. As for 28-to-1, then the magnitude difference of log 28 as 1.4471580313422 is well over +1 digit, and hence 2 digits is needed to cover the full magnitude difference. The tactic is to "err on the side of extra precision" rather than over-round to less precision. -Wikid77 (talk) 21:23, 15 February 2017 (UTC)
Not "hence", you deceiter. You wrote: 28 is a 2-digit difference. You just counted 1, 2. No 10log involved at all. -DePiep (talk) 21:58, 15 February 2017 (UTC)
For some reason (conversion factor 28-to-1 and, maybe, the source number of 29?), the result being "1.0 oz" gives the precision range of: between 0.95 ounces (26.932 g) and 1.05 ounces (29.767 g) (2.835 g). That is fully overlapping the source range [28.5–29.5>. No addition of precision, so OK. -DePiep (talk) 13:53, 15 February 2017 (UTC)
As with all "rules", sometimes they make sense and sometime they do not. Should {{convert|2|ft|in}} start outputing 2 feet (24.0 in) ? -- WOSlinker (talk) 15:21, 15 February 2017 (UTC)
The "extra digit" is as a significant digit, where the one-digit "2 ft" would become 2-digit "24 inches" rather than "20 inches" as would match the original one-significant-digit of 2 ft. Currently, {convert} already has some ad hoc precision tricks, so the 1-digit {convert|2|ft} already changes to the 2-significant-digit result: 24 in. -Wikid77 (talk) 21:23, 15 February 2017 (UTC)
(edit conflict) @Wikid77: the simple rule of thumb is to round a conversion to +1 digits of precision. But by that rule, 13 grams (2 sig fig) is 0.459 oz (3 sig fig) and the implied range 0.4585 ounces (13.00 g) to 0.4595 ounces (13.03 g) is 33 times the precision of the conventionally understood range of 12.5 grams (0.44 oz) to 13.5 grams (0.48 oz). How would anyone justify that spurious extra precision? Naturally, you can always ensure that ranges overlap by insisting on a tiny range for the output precision, but only at the cost of unwarranted implied precision.
Other conversions can be worse with your rule: 11 psi (2 sig fig, representing a quantity somewhere between 10.5 and 11.5 psi) would become 0.758 bar (3 sig fig) and the implied precision 0.7575 bars (10.99 psi) to 0.7585 bars (11.00 psi) has now become a hundred times greater. You'd be laughed out of a high-school maths class with that sort of error in rounding.
Looking back at the OP, would the argument be as tempting if we were to say that 77 feet should be converted as 23 m? The apparent oddness will always occur in the edge cases when one quantity converts to almost exactly the half-way point, i.e. the back conversions 23 metres (75 ft) and 24 metres (79 ft) both look like reasonable representations (in this case, the former is very slightly closer). --RexxS (talk) 15:34, 15 February 2017 (UTC)
Again, the general rule of thumb is to risk showing more precision, rather than less precision where the over-rounding would incorrectly convert two amounts to the same number, as in nonsense range 30–31 grams (1.1–1.1 oz) to become better 30–31 grams (1.06–1.09 oz). What has been laughable to a high-school class is the nonsense results, not the extra precision. Consider a mountain peak of 2,700 m (8,900 ft) loses 2 metres of top snow as 2,698 m (8,852 ft), where ~7 feet of snow drops the peak elevation by 48 feet! That is the nonsense to be avoided by better default precision. -Wikid77 (talk) 21:23, 15 February 2017 (UTC)
The real rule is not to create precision where none exists. You'll find that 0.92 oz and 0.95 oz are perfectly good conversions for 26 and 27 grams, rather than the ridiculous 0.917 oz and 0.952 oz that your made-up rule would give. Consider a mountain peak that is known to be somewhere between 2,650 and 2,750 metres above sea level. Its height would be given as 2,700 metres. Losing 2 metres of top snow wouldn't make the slightest scrap of difference and its height would still be given as 2,700 metres. If you want to consider a real mountain like Watzmann whose Mittelspitze is given as 2,713 metres (8,901 ft) above sea level, then losing 2 metres of top snow would make that 2,711 metres (8,894 ft), a drop of 7 feet. There's no problem with convert. --RexxS (talk) 22:20, 15 February 2017 (UTC)
Those examples totally miss the point; please re-read above re "dimensional analysis" as 2-decimal ounces. -Wikid77 (talk) 13:29, 17 February 2017 (UTC)
"The fact that 230 is not within the result range of 233-236" is worth consideration – no, it is within the range when all the figures involved are expressed to the same precision, which is the only fair and correct way of doing it. 230 is within the range 230-240 (all at 2 s.f.), just as 235 is within the range 233–236 (all at 3 s.f.). Peter coxhead (talk) 18:45, 15 February 2017 (UTC)
Thanks, Peter coxhead, for resolving the consideration I contemplated at first instance. Allow me to note that this was the main OP's point. I've split the quote btw. -DePiep (talk) 21:51, 15 February 2017 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Well, the problem with that line of thinking as 230-240 is to overlook the sanity check of maximum range of 233-236 m for the original amount 770 within 765-775 ft. Even if the result showed "230.000" that number is outside 233-236. Someone could also argue an answer in wider range 200-300, but that is also wider with wrong answers outside max range 233-236 m. Instead consider the granularity of 10 feet as spanning only 3 metres, where the equivalent metres should be rounded to the nearest 3 units, not the nearest 10. Of course that would also be a better conversion, to round 770*12/39.37 to nearest 3 metres (not nearest 10), as 234.69647 rounded to 234 m. Again the problem is the over-rounding of metres to nearest 10, rather than nearest 1, or even nearest 3 metres (10/3) would be better as default precision. -Wikid77 (talk) 21:23, 15 February 2017 (UTC)

• Best rule for improved accuracy: I will drop any 'discussion' Wikid77 crashes whenever I like. Could be now and here. -DePiep (talk) 22:02, 15 February 2017 (UTC)

Am I the only one who thinks this problem isn't even worth discussing? The template can't read your mind. If it gives you a result with incorrect precision, you can fix it. It's not a substitute for your brain. The default behavior works fine in 90% of cases from my experience, and when it doesn't, I override it. Kendall-K1 (talk) 00:52, 16 February 2017 (UTC)

No, Kendall-K1, you're not the only one. Again, Wikid77 is soaking energy from the best editors around, see RexxS's below. Best approach is as Johnuniq does. -DePiep (talk) 23:40, 16 February 2017 (UTC)
Well, the over-rounding (of many amounts) has been so confusing, that for years, the #1 FAQ question has remained: "When using {convert} why does the answer not seem right sometimes?" And still, even some experienced users complain, as above, "Converting 770 feet...is weird". Think about the general users, who see {convert|1|mile|ft} show "1 mile (5,300 ft)" rather than "5,280" or {convert|10|USqt|USfloz} show "10 US quarts (320 US fl oz)" rather than "300 oz" if a mile is rounded to 5,300 feet. I suspect the extra 1-digit auto-rounding should only apply to input amounts above 10,000, such as 10,000 miles (53,000,000 ft). For users ready to round special cases, let them round 770 ft with 235 m by "-1". Otherwise, we will still get a 2-metre drop show only 3 feet in 2,720 m (8,920 ft) down to 2,718 m (8,917 ft), rather than 7 feet less. Currently, most mountain peaks are forced as round "|0" because the risk of over-rounding has been so feared, for years. When so many users keep overriding the automatic rounding, then it should be turned off. It is a huge problem.-Wikid77 (talk) 08:30, 16 February 2017 (UTC)
When I over-ride the auto-rounding, it's more often to reduce s.f. than increase it. If it were turned off there would be a huge number of misleadingly over-precise conversions. A particular problem in many contexts is 'back conversion'. A classic example in the areas in which I mostly work is when an older source gives the height of a plant as "up to 112 ft". This is converted to "up to 45 cm" in a more recent scientific paper which is used as the Wikipedia source. By default {{cvt}} produces "up to 45 cm (1.48 ft)". The current default is the most sensible one; editors need to take responsibility for those cases where the precision needs either decreasing or increasing. Peter coxhead (talk) 10:10, 16 February 2017 (UTC)

I am coming to suspect that there may be a mismatch between usage of standard engineering rounding conventions and user expectations. Standard engineering practice is that the data output should match the same level of precision as the data input, as measured by the number of significant figures. This works well as long as all the units involved are of the same base 10 scale. 0.9 metres (90 cm) and 90 millimetres (0.090 m) both give results that match expected precision standards. However, 136 yard (1.0 in) does not (1.0 inches might be technically correct, but people would expect "1 inch"). 770 feet (230 m) and 230 metres (750 ft) likewise give unexpected results for those not expecting engineering precision standards.

Given that the primary usage of this template is not converting between different base-10 SI units, but between metric and "imperial" units (scare quotes because its more complicated than that), and further than the common usage is to convert real-world situations (distances, heights of buildings, weights, etc.) rather than contexts where knowing the scientific precision of a value is critical, I'm not sure enforcing scientific conventions of precision as the default behaviour is desirable.

I would suggest that the expected behaviour for a conversion is not the engineering convention of "match the number of significant figures", but rather "match the number of decimal places" (and all whole number inputs should match "0" decimal places, so that "10" should match 0 dp, not -1 dp). As a followup to this, in addition to the sigfig=# option (and all the other options), there should be a dp=# option, to allow users to specify the number of decimal places the output should be rounded to.

Rhialto (talk) 11:24, 16 February 2017 (UTC)

Matching the number of decimal places gives nonsensical results in many cases. 1.5 ft (45.7 cm)? 0.1 mm (0.0 in)? There's already a "dp parameter", namely a positive value for the unnamed parameter in {{cvt|30|cm|ft|3}} → 30 cm (0.984 ft). I guess `|dp=` could be provided as an alternative syntax, but it's then odd if a negative value is given. I can only repeat that the present default is the correct one, but editors need to check the output and deal with the few case in which it doesn't work. Peter coxhead (talk) 17:12, 16 February 2017 (UTC)
For years, we have used option "p=" (or "r=") in the Convert wp:wrapper templates to set the precision of decimal digits: p=3 for 3 decimals, p=-2 to round to hundreds, etc. Also, the option "near=3" allowed rounding metres to the nearest 3. However, all that functionality was lost when all the wrapper templates were deleted. Formerly, we could use:
• {convert/f|770|ft|m|near=3} —> 770 feet (234 m), rather than "230 m".
I could write a "smart convert" which fixes the current precision errors, such as fix nonsense range: {convert|30|-|31|g|oz} —> 30–31 grams (1.1–1.1 oz), to show "1.06–1.09 oz" etc. -Wikid77 (talk) 13:29, 17 February 2017 (UTC)
Just to clarify, I don't think as standard usage people should not be specifying the precision to which the conversion is made. I think people should always specify how precise the conversion (in either significant figures or decimal places) to convert. That should be considered good usage with this sort of template. What we are discussing is how to handle default, "no precision specified" usage. For that, I think "match the decimal places" works best, because it more closely matches layman expectations. Rhialto (talk) 14:43, 17 February 2017 (UTC)
@Rhialto: editors should certainly always check the default conversion, but the mark of a good default is that it usually doesn't need changing. As for your point about "match the decimal places", I can only say that you're wrong. Matching significant figures is right in the largest proportion of cases. Matching decimal places is particularly idiotic when the conversion factor is large, e.g. inches to millimetres or ounces to grams. Peter coxhead (talk) 14:57, 17 February 2017 (UTC)
Well, the "match decimal places" works for large-to-small but not small-to-large conversions, where 1 USgal would show "128" oz rather than:
• {convert|1|USgal|USfloz} —> 1 US gallon (130 US fl oz)
The result as "130" would likely shock many users who expect the typical "128" ounces in a gallon. -Wikid77 (talk) 17:36, 17 February 2017 (UTC)
@Wikid77: this example is irrelevant; the default behaviour of the template is designed to convert real world information from one system to another, not to show exact conversion ratios. Peter coxhead (talk) 17:46, 17 February 2017 (UTC)
Yes, that’s a nonsensical example. Here is a real world one with the same numbers: the Elephant, when it sneezes, produces up to 1 US gallon (130 US fl oz) of snot. Giving the exact number of ounces for this would be overly precise. My example is made up, but shows how the template is meant to be used. It does not by default produce exact conversions.--JohnBlackburnewordsdeeds 17:53, 17 February 2017 (UTC)

### Convert has other rounding problems

There are also cases where extra decimal digits have no effect on {convert} auto-rounding, beyond the obvious over-rounded {convert|30|g|oz} as 30 grams (1.1 oz), which leads to nonsense range 30–31 grams (1.1–1.1 oz), versus "1.06–1.09 oz". For extra digits, consider the simple mile-to-feet conversions:

• {convert|1|-|1.0|mi|ft} —> 1–1.0 mile (5,300–5,300 ft)
• {convert|1|-|1.1|mi|ft} —> 1–1.1 miles (5,300–5,800 ft)

The use of "1.0" might seem to indicate more engineering precision than "1" (with no decimal ".0"), but for years, {convert} has treated "1.0" same precision as "1" for conversion to feet or inches, etc. Examples:

• {convert|1|-|1.0|yd|in} —> 1–1.0 yard (36–36 in)
• {convert|1.00|mile|ft} —> 1.00 mile (5,280 ft)
• {convert|10|mi|ft} —> 10 miles (52,800 ft)
• {convert|10.0|mi|ft} —> 10.0 miles (52,800 ft)

Note how "1.00 mile" is better, to trigger extra default precision for 5,280. The core issue is that {convert} has an internal trick to force the default conversion to, at least, 2 significant digits. For 9 ft, the exact total would be 108 inches, but "9" is treated as 2-digit for rounding:

• {convert|9|ft|in} —> 9 feet (110 in)

There are other issues about unusual rounding as well. Overall, the complex rounding makes Convert act like Frankenvert, to new users, who wonder why 9 feet, of 108 inches, appeared as 110. -Wikid77 (talk) 17:08, 17 February 2017 (UTC)

Again, these examples are largely irrelevant, because they are taken out of context and don't correspond to sensible uses in context, in articles. No-one should be using the template to show the value of a distance in miles in feet. Peter coxhead (talk) 17:51, 17 February 2017 (UTC)
Another thing to note: we normally would not be converting measurements within the same system SI/metric to SI/metric or US to US. There would be exceptions, of course, but the normal course is to convert US to SI/metric or the reverse. In those case, we would not have the issue of the template presenting a rounded output that fails to match an exact definition. Imzadi 1979  18:56, 17 February 2017 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Of course, we often use {convert} to show conversion of basic definitions, but the over-rounding is tolerated as "close 'nuf fo wikapeda werk" such as "wingspan 1–1.5 inches (2.5–3.8 cm)" but hand-code "1 inch is 2.54 cm". Otherwise, I have learned to fear use of {convert} in basic measurements, such as:

"In U.S. stores, softdrinks are typically sold in 16-or-20-US-fluid-ounce bottles (470 or 590 ml), while milk is often sold in 1-US-gallon jugs (130 US fl oz; 3,800 ml) while rarely in 12-US-pint milk cartons (8.0 US fl oz; 240 ml)."

Now if an 8-ounce carton is "240 ml" then why is a 16-oz bottle not 2x240=480 but rather "470 ml"? Once I realized how {convert} was over-rounding everywhere (not just gallon 128 oz as "130 oz" but 1/2 pint of 237 ml as "240"), then I stopped using it, and looked for Internet precise conversions to hand-code into articles. Hence, the mega-realization: "Convert can do everything, with adjectives or wikilinks or fractions, except correctly calculate conversions". That is why users have complained about the over-rounding for years and years. The extreme rounding is only needed for immense units, such as 10 AU (929,558,073 mi; 1.495978707×109 km), where the detailed precision would overwhelm typical text. Otherwise the conversion rule-of-thumb, as significant digits +1 is often better, except in rare cases of close conversion factors. Each unit needs to be studied to set reasonable default rounding, as we were trying in 2013. -Wikid77 (talk) 21:56, 17 February 2017, clarified Wikid77 (talk) 01:54, 18 February 2017 (UTC)

Again, why would we convert gallons to fluid ounces? The main purpose in supplying converted values is so that American and British readers are given useful values in customary/imperial measurements for SI/metric values, and so that other readers are given useful values in American and British articles for measurements given in customary/imperial units. The default, based on significant figures, is not only a perfectly sensible approach, it's the same approach taught in school on how to deal with converting values from one measurement to another. Imzadi 1979  02:08, 18 February 2017 (UTC)
To follow on to your example, a better sentence would be: "while milk is often sold in 1-US-gallon (3.8 l) jugs while rarely in 12-US-pint (240 ml) milk cartons". The extra units are unneeded, and the output units should be matched up better to the input units in terms of scaling. Imzadi 1979  02:14, 18 February 2017 (UTC)
The conversion of US gallons to 128 oz is because sodas are sold in 16- or 20-ounce bottles, not 18 gallons. Actually, in U.S. schools, the way metric-to-customary conversions have been taught, in math or science classes, matches the way Google shows "1 meter in inches" (39.37, search) or "1 inch in cm" (2.54), and any calculations are based on those exact numbers, not rounded to 2 digits. For engineering estimates, the conversions often add 1 extra digit to avoid reduced precision, where 1.0 miles would be 1.61 km. The over-rounding in {convert} has persisted for almost 10 years, but is unusual to many new readers. The {convert-old|1|mile|ft} gave "1 mile (5,300 ft)" from several years ago, as in Lua {convert} from 2013. -Wikid77 (talk) 03:27, 18 February 2017 (UTC)
@Wikid77: again you're not taking context into account. The template's primary use is to show conversions for measurements not defined quantities. I work mainly on organisms. There's a world of difference between saying that "1 metre is 39.37 in" and saying that "the plant's height is around 1 m (40 in)". It would be completely stupid to write "the plant's height is around 1 m (39.37 in)". Even the default "1 m (39 in)" is too precise and needs "-1" added to give "1 m (40 in)".
Anyway, this is clearly a dialogue of the deaf; enough from me. There's no consensus to change the existing behaviour of the template. Peter coxhead (talk) 09:02, 18 February 2017 (UTC)
That it certainly is. I used to heavily work on the various weights and measures articles, which includes conversion of traditional to SI units. I never tried to use the convert template, simply because the method for getting the desired level of precision is so non-intuitive for non-engineers. Rhialto (talk) 10:01, 18 February 2017 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Indeed, a "dialogue of the deaf" is the way discussions about the over-rounding in {convert} have been debated for years, with very few improvements since 2008. Meanwhile, every few months, people are thinking {convert} is "broken by design, voluntarily misleading, even hostile to readers and editors" (dif913). Currently, {convert} will still over-round simple conversions: 2 mi (11,000 ft) rather than "10,560 ft" or 9 ft (110 in) rather than "108". We get "1 mile (5,300 ft)" when even 0.99 mile is 5,227 ft, as far below an imagined rough mile as "5,300 ft". At this point, we need to broaden the discussion, to get more math experts to help define standard algorithms for auto-rounding conversions to practical numbers. -Wikid77 (talk) 00:12, 20 February 2017 (UTC)

### Different conversions by context

Several years ago, I had concluded that we need a "different" conversion template for each context of subject area, where the current rounding would be {Econvert} as "engineers convert" so 1 mile is 5,300 ft, 1 metre is 39 inches, 1 US gallon is 130 ounces (or not), and 1 US pint (16 US fl oz; 470 ml) rounded, or 9 ft (110 in) (for 108). Then a practical Convert would default to closer precision, with 1 US pint (16 US fl oz; 473 ml), where 12 US pint (8 US fl oz; 237 ml) is truly half, or a mountain peak of 2,699 m (8,855 ft) is 3 feet less than peak 2,700 m (8,858 ft), not as now 45 feet lower for 1 metre: "2,700 m (8,900 ft)". For precise conversions, then "exact convert" would show 1 inch as 2.54 cm, 1 US gallon as 128 oz, 1 mile as 1.609344 km or 1 metre (39.370078740157 in), and 1 mile (160,934.4 cm) not as now "160,000 cm". The underlying {convert} has the precise conversion factors but does not calculate to match each context. -Wikid77 (talk) 17:01, 18 February 2017 (UTC)

Thankfully, no one else came to the same conclusion. Plastikspork ―Œ(talk) 17:55, 18 February 2017 (UTC)