Wikipedia

Wikipedia:Analysis of Template:Convert problems

There have been numerous issues of converting measurements, using Template:Convert, during 2008-2009. That template-family is becoming increasingly harder to update, due to the growing complexity of the 20-to-26 nested templates for each conversion, and the continual deletion of similar templates that could have been used to compare for errors. The problems have persisted because it is very difficult, for volunteers, to continually maintain the Convert template-family, with all the complex range options. Even the dedicated volunteers seem slow and clumsy against such a task.

Default rounding to nearest 10 units edit

Several users had kept noting that Convert was rounding numbers far off the world-standard amounts, which tended to be over-rounded by 10s-of-units: kilometers rounded by 10 miles, kilograms by 10 pounds, or feet-inches by 10 cm. As a workaround, the Convert template allows specifying a count for rounding the converted amount. For example:

  • For feet/inches-to-cm, append 0: {{Convert|6|ft|2|in|cm|0}}
  • For feet-to-meters, append 1:       {{Convert|6|ft|m|1}}
  • For large km-to-miles, append 0:     {{Convert|6|km|mi|0}}
  • For small km-to-miles, append 2:     {{Convert|2|km|mi|0}}
  • For liters-to-gallons, append 2: {{Convert|7|L|2}}

Unless rounding was specified, then Convert generated some very unusual conversions. For example:

  • {{Convert|32|m|ft}}      gave: 32 metres (100 ft)          - standard is 105 ft
  • {{Convert|300|km|mi}} gave: 300 kilometres (190 mi)   - standard is 186 miles

Numerous people had noticed the problems, but there were not enough people available to get the template changed to display the standard conversion amounts. Clearly, the idea of equating 32 meters to 100 feet, was a violation of policy WP:NOR, because no reliable source would support the result as "100 ft" rather than the standard of 105 ft. Currently, those 2 conversions give the following results:

  • {{Convert|32|m|ft}}      today gives: 32 metres (105 ft)           - standard is 105 ft
  • {{Convert|300|km|mi}} today gives: 300 kilometres (190 mi)   - standard is 186 miles.

Because of the complexity of Template:Convert, including over 3,150 subtemplates, improvements have taken weeks or months to fully implement for all cases.

Template creep has km/miles using 20 to 26 templates edit

06-Oct-2009: In analyzing the actual performance of T:Convert in hundreds of articles during 2009, I have noticed that the template-creep for converting km to miles has reached 20-to-26 templates invoked for each conversion, depending on rounding. Instead, it is possible to convert km/miles with rounding, abbreviations, slashes, and adjective-hyphen using only 1 alternative template. Before it was deleted, Template:Kmbot demonstrated that the functionality of T:Convert for km/miles could be streamlined to be performed within just 1 template, while allowing other rare conversions to use the current 20-to-26 nested templates. I have restored that deleted template under User:Wikid77/Template:Kmbot for comparisons and proof-of-concept. The ability to handle km-to-mile conversions using a single template is not just a hypothesis, it was shown to be true all during 2009, by the workings of Kmbot. Naturally, because T:Convert performs a myriad of other conversions, plus the rare range-conversions, it could be expected to have several bugs and rounding problems, which are more difficult to fix, because it doesn't just use 1 streamlined template, but rather, {{Convert}} invokes 20-to-26 templates which might be the source of any of those bugs and more. As template-creep expands, it becomes more difficult to prove a complex template is still reliable.

Issues noticed for km/miles in actual articles edit

06-Oct-2009: There are numerous issues which surfaced while running the quick-deleted Template:Kmbot versus {{Convert}}. Templates which explore alternate conversion tactics are quickly deleted in Wikipedia, so there has been little comparison with better methods. Because of the diversity of ideas, between T:Kmbot and T:Convert, it was easy to see many issues to resolve:

  • {{Convert}} converts 20 km as "12 mi" rather than 12.4 miles. The default rounding seems too severe for a low distance such as 20 km. Focus: consider including tenths of miles for low distances.
  • {{Convert}} displays "20 kilometres (12 mi)" as the default, when "km" is the known measurement, and the "12 mi" is displayed as the foreign amount. The more logical display, considering an article's focus, would be "20 km (12 miles)" because the "km" is well known for the article's subject (and avoids the "metre/meter" bias), while the term "mi" is the foreign measurement better explained with the full word "miles" which is foreign to most articles about "kilometres". The choice to abbreviate "mi" but not "km" is logically backward for the culture of most articles using km. Focus: consider "km" as a typical, default item to display.
  • {{Convert}} insists on putting commas in a 4-digit amount, although it can be confusing for decimal-point versus decimal-comma numeric displays. It would be much better to follow the input format (if no commas, don't force them): so 4125 m would remain "4125 m" rather than be forced to "4,125 m" which might be a decimal-comma typo for 4.125 (4+1/8) meters. Remember: numerous multi-lingual readers work on the English Wikipedia, so it would be better to avoid excessive commas in numeric amounts, when those commas are not even needed. Amounts with zeroes are obviously large, such as "4,100" seems over 4 thousand, but most elevations do not have zeroes: "9,125" might be mistaken for "9+" metres. The forcing of commas makes it harder to detect actual typos from the decimal-comma cultures. Focus: avoid forcing commas everywhere, for numbers within 9999.
  • {{Convert}} still chokes on commas in the input number, such as converting a vast distance of 12 million km to miles: {{Convert|12,000,000|km}} has been dying all during 2008-2009. Currently, the live result of using commas as input for {{Convert|12,000,000 |km}} is as follows:12,000,000 kilometres (7,500,000 mi)

     Focus: make allowing commas a priority change in Convert.

  • {{Convert}} does not really handle number sense, whereas Template:Kmbot was designed to round logically, depending on distance, as the main design goal. Focus: consider if {{Convert}} could even handle number sense, or would it be too complex for a single template like that.

Of course, the simplest solution to those issues is: don't use {{Convert}}, and just use {{Kmbot}}, if only it weren't constantly deleted! So, instead, skip the 20-to-26 templates, and, just hard-code the "20 km (12.4 miles)" or other measurements with wording more logical for each article's culture. By hard-coding the digits, there will no rounding of 12.4 as 12, and no forcing of extra commas to clutter the page.

Convert thinks end-zeroes are rounded amounts edit

06-Oct-2009: There is a real problem with Convert being "too clever" about estimating the precision of the from-and-to amounts. If Convert sees a number "1,000" with 3 end-zeroes, it rounds the result as if the amount were estimated to the nearest hundred. Precision of rounding can be forced by adding digit "1" or "0.0" but that could appear bizarre in an article: the summit was at the 1000.0-meter level or writing deep dives are measured in 100s of metres, so the submarine paused at 201 m (what? why 201 not 200...oh ya, because Convert can't handle 200). Let's compare 200 & 201 in the live Template:Convert:

  • {{Convert|200|m}} gives:   200 metres (660 ft), and {{Convert|201|m}} gives:   201 metres (659 ft).
  • {{Convert|200.|m}} gives: 200 metres (656 ft); {{Convert|201.0|m}} gives: 201.0 metres (659.4 ft).

I think a better approach would be to round only thousands (not the hundreds) to the nearest 10, regardless of the accidental occurrence of multiple zeroes "00" in a number. Meanwhile, the values of 200 & 201, should convert differently, as 656 & 659 ft, not both as 660 ft. That's almost a shockingly poor level of sloppy results.

Convert can round end-zeroes to look suspicious edit

Another major problem, as judged within American culture, is that the rounding of double "00" amounts can produce conversions that seem "too slick" or "too convenient" to actually be accurate conversions. Consider the rounding for "600 meters"

  • {{Convert|600|m}} gives: 600 metres (2,000 ft)

The appearance of the result as exactly 2,000 looks "fishy" (because rounded to the nearest 100, it produced the nearest thousand). The underlying amount is 600m = 1968ft, but the rounding by 32ft as an even "2,000" just makes the whole conversion seem like a sloppy estimate. American culture typically does not deal with that level of rounding, in such matters. As a result, an entire article might become questionable because the amounts have been kludged by a number game that considers a rounded value of "1,970" to be even further rounded, to be just a ballpark figure of 2,000.

Damage control to fix Convert errors edit

07-Oct-2009: I think the severe rounding problems (noted above) can be handled, once we earnestly look for solutions. Step 1: Don't Panic. Don't conclude that all rounding is hopelessly doomed. For most mid-level amounts, the workaround for damage control will be to "always" use rounding parameter "0". So, in the case of multiple kilograms-to-pounds, use:

  • {{Convert|81|kg|0}} for: 81 kg (179 lb) and {{Convert|83|kg|0}} for: 83 kg (183 lb)
  • {{Convert|82|kg|0}} for: 82 kg (181 lb) and {{Convert|84|kg|0}} for: 84 kg (185 lb).

I think the fear of the 5-pound errors will go away, when adding round-parameter "0". The same will fix the fear of 5-mile errors in kilometer-to-miles. Many people should be thanked, who have confirmed that, yes, Convert has severe rounding problems, by default, but in most mid-level cases just force rounding as "0". Yes, Convert mis-rounds the weights by 5-pound errors, and distances by 5-mile errors. Note that for small numbers, the use of round "0" would be just as bad (only put "0" on amounts of many kg or km):

  • {{Convert|8.1|kg|0}} will give: 8.1 kilograms (18 lb)
  • {{Convert|8.2|kg|0}} will give: 8.2 kilograms (18 lb)
  • {{Convert|8.3|kg|0}} will give: 8.3 kilograms (18 lb) (all the same)

Instead, for small amounts, put round as "2" as with 2-kg or 2-kilometer amounts (less than 10):

  • {{Convert|1.81|kg|2}} as: 1.81 kg (3.99 lb) & {{Convert|1.83|2|kg}} as: 1.83 kg (4.03 lb)
  • {{Convert|1.82|kg|2}} as: 1.82 kg (4.01 lb) & {{Convert|1.84|kg|2}} as: 1.84 kg (4.06 lb)

Again, thanks to all who confirmed the shocking level of rounding errors in the Convert template. But don't panic, Convert can't "scar Wikipedia's reputation": Wikipedia has had a bad reputation for years: many articles are hacked stubs, articles of famous people are outdated, and vandalism remains months or years in many articles (at least 2 years). The recognition of Convert errors is just one more step along the way, toward making improvements. Let this be another lesson: the R.M.S. Convertanic has sunk, but let's move to the lifeboats and keep going, until we build the R.M.S. Convert II.

Convert is over-rounding common measurements edit

Several people noted, by October 2009, that Convert had rounding errors, as judged against common notions of measurement. Of course, anyone could invent broad-rounding rules, such as: "1 km = 10 miles (to nearest 10 miles) because rounding to 0 miles is no distance at all". However, when considering common measurements, it is not logical to say that 200 m is 660ft, and increasing the length of a warehouse to 201 m results in a new length of 660ft (the same). Bottom line: Convert has been defaulting to some shocking notions of rounding for common measurements. When did the Pope decree, "Round meters to 10ft"? Instead, treat 200m as 656ft and let the longer warehouse of 201m be 659ft, as the default. When people want to round to the nearest-10-ft (or 100-ft), then let them override the default higher precision. A distance of 300 km should be 186 miles (or rounded by 5 as "185 mi" not Convert's value of 190). Again, Convert rounds 300 km to the nearest 10 miles. The fundamental problem is that Convert has been "over-rounding" the measurements, beyond what is logical for most Wikipedia articles. If you re-read above, in all the examples that have been presented, then it is pretty obvious evidence of the rounding errors in Convert, when judged relative to common notions of accuracy and precision. That is what many people had all been saying, all during 2009.

Changing the Convert-family of 3,150 templates edit

The Template:Convert is actually only the top template in a massive tree of over 3,150 subtemplates, including over 40 templates used to determine precision of a number. Many of the subtemplates are named for the combination of options-in-effect: there are numerous templates named to calculate the conversion, and then other templates named to display the results (the amounts with separators such as "/" or parentheses). Each of the calculation-templates follows the naming pattern, and many of the display-templates follow the same pattern, with each template named by over 64 combinations of the options lk=on/off, abbr=on/off, disp=b/slash/or/semicolon, sp=us/en, adj=on/off, etc. The calculation-templates each pass the converted-results to various rounding-templates. Typically, a common conversion such as meters-to-feet, by {{Convert|31|m|ft}}, will invoke 20-26 templates. The following 20 templates are used during meters-to-feet conversion (to generate: "31 metres (102 ft)"). All the templates are listed in order by name (not the sequence as invoked):

The conversion factor "b", for m-to-feet, is defined in Template:Convert/ft (of some precision hopefully long enough to work for the larger numbers). That template invokes Template:Convert/LoffAoffDbSoff, where the actual calculation is done, as multiplying parameter 1 by the conversion factor "b". The output amount is passed to Template:Convert/round which determines the precision (using Template:Max/2 & Template:Ordomag) as passed to Template:Rnd which performs the rounding. To change results, based on a conversion involving feet, then parameters would need to be passed from T:Convert/ft, into T:Convert/LoffAoffDbSoff, then into T:Convert/round where the amount of rounding is calculated. For a shift in precision, a shift-value could be passed, as an extra named-parameter defaulting to zero, but included inside T:Convert/round as an extra term to add to the precision. That method would allow a shift-option to be set within T:Convert/ft, but affect the final value before display.

Shifting precision in Template:Convert/round edit

08-Oct-2009: The top-level rounding templates, such as Template:Convert/round can be altered to accept a precision-shift amount "pshift", such as to increase meter-to-ft conversions by +1 significant digits. A value of "65 m" would then default to yield 213 ft.

In Template:Convert/round - append "+{{{pshift|0}}}"
{{#ifexpr:{{{2}}}=0|0|{{formatnum:{{rnd|{{{2}}}|({{max/2|{{#expr:({{precision|1{{{1}}}}}+{{{5}}}-0.5+(ln2/ln10))round0}}|{{#expr:1-{{ordomag|{{{2}}}}}}}}}+{{{pshift|0}}})}}}}}}

(The coding has no spaces due to old 2007 template-size limits).
The pshift=1 would fix "32m" to give "32m (105 ft)" as matching the world-standard with 105ft, between rounding limits of 103.3-106.6 ft. The typical (teenage) user would just request {{Convert|32|m}} without needing to designate an appropriate sigfig=3 (or more for more digits). To re-program the templates and pass pshift, some other subtemplates would need to be changed to set the value of pshift, depending on larger units, but other templates/conversions would not be changed, and just use the default pshift=0. Also, we can add explanatory HTML comments into those templates now. A value of pshift=1 would be too large for other conversions, such as 196 km to miles. Hence, pshift would only be set for larger-scale units, NOT for all conversions. As a more elegant solution (in the future), I think, in general, if the scale factor is greater than 1, (or 2) then set pshift=1.

Examples for testing results edit

The following examples use experimental code to compare results:

Gconvert -
Gconvert - Invalid parameter: adj=yes; for adjective mode, try adj=on or adj=off.
Gconvert - 19 inches ()
Gconvert - 32 metres ()
Gconvert - 83 kilograms ()
Gconvert - 200 kilometres ()
Gconvert - 200 kilometres () - round 1
Gconvert - 8,848 metres ()
Gconvert - 88*100+48 metres ()
Gconvert - 29 * 1,000+29 feet ()
Gconvert - User:Wikid77/Template:Convert/
Gconvert - 8,848 metres () -rnd -1
Gconvert - 6 feet 2 inches ()
Gconvert - 6 feet 2 inches ()
Gconvert - 6 feet 2 inches () -rnd 0
{{Conve|8,848|pm=on}} - {{Convert/lengthcalc|8,848|pm=on}}
{{Convert/lengthcalc|67m}} - {{Convert/lengthcalc|67m}}
{{Convert|67m}} - [convert: invalid number]

Those are some of the isses noted so far, during 2008 and 2009. Many of them have been discussed in the template's talk-page: Template_talk:Convert. This essay is not intended as an exposé, but rather just a general alert that all these problems have persisted for years. Meanwhile, any alternate templates (such as {{Kmbot}} ), which attempt to calculate more appropriate or accurate conversions, have been quickly deleted (without discussion), thus forcing people to rely on the sloppy, inaccurate results generated by Template:Convert, even in October 2009.

See also edit

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Analysis_of_Template:Convert_problems&oldid=905903182"