Jump to content

Template talk:Convert/Archive March 2017

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia


Sorting Order Problem Tag

On List of state-named roadways in Washington, D.C., there is a sortable table of roadways that includes their length. All of the lines in the table use Convert but, for reasons I cannot figure out, Massachusetts Avenue's length is sorted as somewhere between 1.7 and 2.4 miles even though it is listed as 10 miles. Increasing it to 70 or 80 miles gets it to sort properly, but many smaller increases do not fix the problem. I haven't a clue what's going on with this. I also looked in vain for a way to tag that there appeared to be a problem there; if there is some template I could have used to alert others to the issue, I would love to know what it is. Czrisher (talk) 16:01, 9 March 2017 (UTC)

The problem here is that the output of the convert function is not a number, but a text string. As text, "1." is sorted before "10". One possibel solution is that used in List of former national capitals.
See this change which fixes it. -- WOSlinker (talk) 18:07, 9 March 2017 (UTC)
  • Option for "sortable=on" began May 2009: In early 2009, users discussed the problem of sorting conversions in numerical order, and option "sortable=on" was added 7 May 2009 (see diff: [1]). When sortable=on, a 50-character hidden span tag was prepended onto a conversion to allow sort by the input amount as 16-digit, zero-padded numerals. -Wikid77 (talk) 11:11, 13 March 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

• Sbmeirow • Talk • 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. • Sbmeirow • Talk • 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)
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. • Sbmeirow • Talk • 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. • Sbmeirow • Talk • 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. • Sbmeirow • Talk • 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. • Sbmeirow • Talk • 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)
Add to #2, the range:
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)

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 11⁄2 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, 1⁄36 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 1⁄2-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 1⁄2-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 1⁄8 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 "" 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)

A lot of complaints would be removed if the template required either "sf=N" or "dp=N" to specify either a number of significant figures or a number of decimal places in the output. The problem keeps cropping up because everyone assumes the default output precision will be suitable for their needs, and everyone has different expectations about what the default level of precision should be. Simply removing the option for a default would resolve the confusion. Rhialto (talk) 11:45, 13 March 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 1⁄2 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)

Additional units: msw, fsw

In underwater diving it is a common convention to specify pressure in terms of metres seawater (msw) where 10 msw=1 bar. The imperial equivalent is feet seawater (fsw). It would be useful to have a conversion template allowing conversion from msw to fsw and vice versa, and from fsw to atm or psi. Cheers, • • • Peter (Southwood) (talk): 05:58, 15 March 2017 (UTC)

A quick response is that yes, this is the correct place. I changed the heading so it will be easier to find the topic in the archives. I will think about the issue and post later. Johnuniq (talk) 07:16, 15 March 2017 (UTC)
@Peter (Southwood): I created the new units. Our convention is that they will be kept for a month or more, but the next time an update to the convert module occurs, any proposed units which are not used are removed. That is, units which are used in articles will be kept.
Some demonstrations follow. Please check carefully.
Johnuniq (talk) 09:12, 15 March 2017 (UTC)
Johnuniq, Thanks. That was an astonishingly quick response. I will start using them today. Not sure I will get round to using all of them within a month though. Cheers, • • • Peter (Southwood) (talk): 09:59, 15 March 2017 (UTC)
Johnuniq, Sorry, I neglected to explain that msw and fsw are almost exclusively quoted as gauge pressure, and the equivalent bar, psi, kPa in the same context are almost always used as absolute pressures. The conversion factors per unit appear to be correct a bit inaccurate, but and in practice a pressure of 10 msw would normally be converted to 2 bar (absolute) rather than 1 bar (gauge). These pressures are used to refer to the pressure on a diver at depth in water or in a hyperbaric chamber, where the external pressure is assumed to be normal atmospheric pressure at sea level. Another way of putting it is that a pressure in msw or fsw is the absolute pressure at that depth in the sea measured in the equivalent metres or feet. I didn't explain in detail before as I didn't expect things to happen so fast. I see that our articleMetres sea water does not mention this, and nor do its two references, so I will research this for better references and update the article. • • • Peter (Southwood) (talk): 10:32, 15 March 2017 (UTC)
Johnuniq, I have mostly fixed the Metres sea water article, using what I consider a more reliable source. The correction of the templates should be relatively simple, and I can probably fix them myself if I can find the code. Cheers, • • • Peter (Southwood) (talk): 20:00, 15 March 2017 (UTC)
I see it is in Lua, so probably not a good plan, even if I could edit the code. Nevertheless I would be interested to see it if you could give me a link. Cheers, • • • Peter (Southwood) (talk): 20:26, 15 March 2017 (UTC)
Any problems should be discussed here. After everything is settled, I can attend to the technical side of convert—getting the module right is trivial, but getting agreement on what should happen can be tricky.
I used the values from Metres sea water which used to say that 1 msw = 10.0518 kPa. That was before your recent edits which say that 1 msw = 10.0 kPa. The original value (10.0518) agrees with the two old (weak) references, but more importantly, it agrees with simple calculations—assuming that 1 msw is defined as the pressure exerted by 1 m of sea water. The new value (10.0) is based on the following mystical statement in U.S. Navy Diving Manual:
"In the metric system, 10 MSW is defined as 1 BAR.
Note that pressure conversion from MSW to FSW is different than length conversion;
i.e., 10 MSW = 32.6336 FSW and 10 M = 32.8083 feet."
To quibble, 10 m = 32.8084 feet.
No one using msw or fsw would care about whether the value is 10 or 10.0518 so there is unlikely to be a knock-out reference that settles what value applies as a world-wide defacto standard.
Please start a discussion at the relevant wikiproject and get agreement that the values in the article are correct, and that convert should be based on the definition that 1 msw = 10 kPa exactly, and that 1 fsw = what?
There is some confusion, for example, concerning whether 10 msw means the pressure exerted by a 10-m column of sea water, or whether it is the total pressure (absolute) on an object under 10 m of sea water which is under the atmosphere. The latter would be 1 atm more than the former. Johnuniq (talk) 03:03, 16 March 2017 (UTC)
OK, I will open a discussion at WikiProject Scuba diving and report back on any conclusions. Cheers, • • • Peter (Southwood) (talk): 06:26, 16 March 2017 (UTC)

Educational years

If you ever venture into articles related to schools there is an interesting conversion problem. American writers use a K-12 system to referring to the year groups which is deceptive simple but leads to a lot of errors. Grade 6 ≠ UK Year 6, the former refers to people between the age of 11 and 12, while in the UK we are in the main talking about the age 10-11 (Scotland is different).

So when we see in Secondary education the line "grades 7 to 11 (ages 12 to 16)"- I believe this is an error, and what we need is "years 7 to 11 ( grade 6 to 10; ages 12 to 16)" maybe coded up with {{ed year convert|7|11|USgrade|age}}.

  • This is far too heavy to add to {{convert}}
  • Sufficiently similar to hack the {{convert}} source code
  • Requires a lot of discussion within interested parties
  • Expandable to add new systems.See Educational stage for scope
  • To start with the example I have given could be a starting point and we could add the unit ISCED but note the use of "typically".{{ed year convert|8|USgrade|ISCED|full}} and {{ed year convert|8|USgrade|US|age|full}} to give "grade 8 (ISCED Lower secondary) and "grade 8 (Junior High School; ages 14 to 15)"

I am putting this here to generate a few comments- not for an instant fix- it could however be an interesting starting point for someone's template coding career. ClemRutter (talk) 11:46, 27 March 2017 (UTC)

It's an interesting idea. It would be quite a different thing to this template. Maybe have a look at WP:RT and Portal:Education. Jimp 00:25, 29 March 2017 (UTC)

Pure powers of ten in scientific or engineering notation

I'd like a switch that can suppress the base in this case, e.g. displaying 100,000,000 as 108 instead of clumsy 1 ×108 -85.240.221.35 (talk) 13:06, 25 March 2017 (UTC)

Any chance of an example of a convert which would warrant new behavior?
Meanwhile, try engineering notation:
  • {{convert|12,000,000|m|ft}} → 12,000,000 metres (39,000,000 ft)
  • {{convert|12|e6m|e6ft}} → 12 million metres (39×10^6 ft)
  • {{convert|12|e6m|e6ft|abbr=off}} → 12 million metres (39 million feet)
  • {{convert|12|e6m|e6ft|abbr=on}} → 12×10^6 m (39×10^6 ft)
Johnuniq (talk) 04:08, 26 March 2017 (UTC)
Those examples are not pure powers of 10, intended to give only an order of magnitude. Example from Gas-filled tube#Gas purity: "Thorough degassing is required for high-quality tubes; even as little as 1×10−8 Torr (1.3 μPa) of oxygen is sufficient for covering the electrodes with monomolecular oxide layer in few hours."
"10-8 torr (≈1 μPa)" would look better here, and probably allowing sigfig=0 for scientific notation (defaulting to sigfig=1 for all other formats) should suffice, but it will need logarithmic rounding: 10n means the interval from 10n-0.5 to 10n+0.4999...-85.240.215.208 (talk) 19:08, 26 March 2017 (UTC)
Sorry, I misunderstood the initial message (because there was no example). The closest convert can achieve at the moment is:
  • {{convert|1e-8|torr|uPa|disp=x| (≈|)|sigfig=1}} → 1×10−8 torrs (≈1 μPa)
  • {{val||e=-8|u=torr|sortable=off}} (≈{{convert|1e-8|torr|uPa|disp=out|sigfig=1}}) → 10−8 Torr (≈1 μPa)
I'm not convinced that convert should be used for everything—just use plain text for cases which do not fit how convert does things. One problem comes from considering what new parameters would be required to implement the suggestion. Johnuniq (talk) 01:26, 27 March 2017 (UTC)
To "108 instead of clumsy 1 ×108". I don't hhnink the former format is 'clumsy'. In fact it is very common for writing quantities (especially modern SI). Howevver, if there are areas or domains where writing the bare "108" number is common, please provide examples. Torr is not a good example. -DePiep (talk) 06:32, 29 March 2017 (UTC)

Angles

How about degrees/minutes/seconds/radians/grade/circle/... and square degrees/steradians/sphere/...? TomS TDotO (talk) 18:22, 29 March 2017 (UTC)

There was a discussion in September 2015 which did not go anywhere because no realistic examples of where such conversions would be useful were provided. Several editors commented that it did not seem warranted particularly because radians were often used with exact values (such as π/2 radians). Johnuniq (talk) 00:55, 30 March 2017 (UTC)

Best to convert to

Hi people, I believe this is the best forum for this - I didn't see any info on the standard for what second unit should be used when applying this template, or in general. Many or most FAs on cities convert acres to hectares, like "180 acres (70 ha)", but some use "180 acres (XY km2)" or similar, or are inconsistent. This exists not only for area, but for linear distances and other conversions. Should there be a standard? Why should hectares be used over square kilometers or the other way around? ɱ (talk) · vbm · coi) 05:12, 31 March 2017 (UTC)

That is handled with the default output unit. Omit the output unit and a default (the "standard") will be applied.
  • {{convert|180|acre}} → 180 acres (73 ha)
  • {{convert|12|m}} → 12 metres (39 ft)
Johnuniq (talk) 05:18, 31 March 2017 (UTC)
Sure but why? And then when, if ever, would it be preferable to use square kilometers over hectares? ɱ (talk) · vbm · coi) 05:24, 31 March 2017 (UTC)
I don't follow that. As far as this template is concerned, a discussion could change what the default output for a particular unit is if another had some advantage. As far as articles are concerned, what units are used is not really a concern for this page (although it's a good place to start thinking). I imagine there is some MOS guideline saying that an article should use units that match common usage for the topic, backed by reliable sources. Some articles use cm for the height of an athlete, and others use m, while others show ft/in first, then either cm or m second. That is supposed to be determined by WP:ENGVAR issues. Johnuniq (talk) 07:16, 31 March 2017 (UTC)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Template_talk:Convert/Archive_March_2017&oldid=1142972209"