This is an
essay. It contains the advice or opinions of one or more Wikipedia contributors. This page is not an encyclopedia article, nor is it one of
Wikipedia's policies or guidelines, as it has not been
thoroughly vetted by the community. Some essays represent widespread norms; others only represent minority viewpoints. |
This
essay is currently
orphaned. Few or no
project pages link to this page. This may result in the page having
low readership and little or no improvement. Please help by introducing links to this page from other related project pages. |
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.
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:
Unless rounding was specified, then Convert generated some very unusual conversions. For example:
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:
Because of the complexity of Template:Convert, including over 3,150 subtemplates, improvements have taken weeks or months to fully implement for all cases.
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.
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:
Focus: make allowing commas a priority change in Convert.
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.
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:
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.
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"
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.
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:
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):
Instead, for small amounts, put round as "2" as with 2-kg or 2-kilometer amounts (less than 10):
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.
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.
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.
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.
(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.
The following examples use experimental code to compare results:
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.
This is an
essay. It contains the advice or opinions of one or more Wikipedia contributors. This page is not an encyclopedia article, nor is it one of
Wikipedia's policies or guidelines, as it has not been
thoroughly vetted by the community. Some essays represent widespread norms; others only represent minority viewpoints. |
This
essay is currently
orphaned. Few or no
project pages link to this page. This may result in the page having
low readership and little or no improvement. Please help by introducing links to this page from other related project pages. |
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.
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:
Unless rounding was specified, then Convert generated some very unusual conversions. For example:
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:
Because of the complexity of Template:Convert, including over 3,150 subtemplates, improvements have taken weeks or months to fully implement for all cases.
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.
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:
Focus: make allowing commas a priority change in Convert.
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.
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:
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.
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"
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.
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:
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):
Instead, for small amounts, put round as "2" as with 2-kg or 2-kilometer amounts (less than 10):
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.
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.
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.
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.
(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.
The following examples use experimental code to compare results:
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.