Template talk:Convert/Archive September 2012

Conversion of long tons and long hundred weights

For Railway brake#Early days convert 203t 4cwt (long tons and long hundredweights)into tonnes + short tons. 203 long tons 4 hundredweight (206 t; 228 short tons), the Lcwt go missing and the short tons do not show up. Or should it be 203 long tons (206 t; 227 short tons) + 4 long hundredweight (0.20 t; 4.5 short hundredweight) 4 long hundredweight (200 kg; 4.5 short hundredweight)? Peter Horn User talk 00:21, 16 August 2012 (UTC)

I started creating some of the templates, but will need modifications to template:convert/LT to get the first example working. please check the sandbox version ({{convert|203|LT/sandbox|4|Lcwt|t ST|0|abbr=on}}) and we can make an edit request. also, what is the plural of hundredweight? Frietjes (talk) 15:15, 21 August 2012 (UTC)

I try 203 LT/sandbox, and it works! The plural of hundredweight would be hundredweights, but check a dictionary. To make things more interesting there is also the short, or American, hundredweight and it would be nice if it could also be incorporated in the conversion. Peter Horn User talk 14:20, 22 August 2012 (UTC)

{{convert|203|LT|4|Lcwt|t ST}}	203 long tons 4 hundredweight (206.5 t; 227.6 short tons)	should match after update
{{convert|203|LT/sandbox|4|Lcwt|t ST}}	203 LT/sandbox
{{convert|203|LT|4|Lcwt|t ST|abbr=on}}	203 long tons 4 cwt (206.5 t; 227.6 short tons)	should match after update
{{convert|203|LT/sandbox|4|Lcwt|t ST|abbr=on}}	203 LT/sandbox
{{convert|203|ST|4|Scwt|t LT}}	203 short tons 4 hundredweight (184.3 t; 181.4 long tons)	should match after update
{{convert|203|ST/sandbox|4|Scwt|t LT}}	203 ST/sandbox
{{convert|203|ST|4|Scwt|t LT|abbr=on}}	203 short tons 4 cwt (184.3 t; 181.4 long tons)	should match after update
{{convert|203|ST/sandbox|4|Scwt|t LT|abbr=on}}	203 ST/sandbox
{{convert|203|LT|t ST}}	203 long tons (206 t; 227 short tons)
{{convert|203|LT|t ST|abbr=on}}	203 long tons (206 t; 227 short tons)
{{convert|4|Lcwt|t Scwt}}	4 long hundredweight (0.20 t; 4.5 short hundredweight)
{{convert|4|Lcwt|t Scwt|abbr=on}}	4 long hundredweight (0.20 t; 4.5 short hundredweight)
{{convert|4|Lcwt|kg Scwt}}	4 long hundredweight (200 kg; 4.5 short hundredweight)
{{convert|4|Lcwt|kg Scwt|abbr=on}}	4 long hundredweight (200 kg; 4.5 short hundredweight)

okay, check the table above and let me know if there are any errors in the conversions, unit spelling, etc. . Frietjes (talk) 15:37, 22 August 2012 (UTC)

In WD Austerity 2-8-0 (infobox) I found 70 long tons 5 cwt (157,400 lb or 71.4 t) or 70 long tons 5 cwt (157,400 lb or 71.4 t), I'll check the above table later. Peter Horn User talk 02:23, 2 September 2012 (UTC)

Reducing Convert depth for precision

The 2 edit-requests are in the 2 talk-threads below.

As many know, Convert has been discussed for years about too many levels (28) of the "wp:Expansion depth limit" (40-41) and hopes for reduction. Every "year" when I reduce the depth a litte, then new features increase the depth back to 28 or 29. Instead, I plan to change the internal struture to drastically reduce the depth by 6-7 levels by calculating the precision in a higher template when running a conversion. See example:

• Template:Convert/LoffAoffDpSoff - set precision in lower expansion depth

Preliminary tests show that the calculated results are the same, with the improvement of expansion depth as 22, rather than 28 levels. The extra depth has become a wide-spread problem, also in other templates, but Convert is being used in more double-nested infoboxes which cannot run the current Convert without setting the rounding as "|0" or "|-2" or such. Long-term, the depth levels for rounding can also be reduced, and that is another protracted upgrade. The plan is to reduce the depth of the most-common options, but for all unit-codes, or unit names, at the same time. Whether converting metres or pascals or kilowatts, the expansion depth would be 6-7 levels fewer, for use in infoboxes or other complex templates. -Wikid77 (talk) 06:26, 2 September 2012 (UTC)

Fix Template:Convert/LoffAoffDbSoff for depth

Actual sandbox: Template:Convert/LoffAoffDbSoff/sandbox

The conversion unit formatter Template:Convert/LoffAoffDbSoff needs to be updated (from the /sandbox) to correctly set the precision of the input amount (unless sigfig=n or a round "|0" is specified). Formerly, the precision calculation was left until deep inside the nested subtemplates, causing the template expansion depth to increase by 6-7 levels, which has been fatal in double-nested infoboxes, or inside other large templates. Hence, the simple calculation of precision in this template will fix the exceeded-depth error in hundreds, or thousands, of articles.
Testing: After the change, the results can be tested by checking the "Category:Pages where expansion depth is exceeded" to have fewer articles, especially for railroad trains or NRHP historic sites. The {PAGESINCATEGORY} count of 4,750 (live: 3) should drop to less than 4,600 pages in error. Some example calculations should appear as follows:

• Expected: {{convert| -23.56|ft|m}} → −23.56 feet (−7.18 m)
• Currently: {{convert|-23.56|ft|m}} → −23.56 feet (−7.18 m)
• Sandbox : {{convert|-23.56|ft|m}} → −23.56 feet (−7.18 m)

• Expected: {{convert| 21.600|in|cm}} → 21.600 inches (54.864 cm)
• Currently: {{convert|21.600|in|cm}} → 21.600 inches (54.86 cm)
• Sandbox : {{convert|21.600|in|cm}} → 21.600 inches (54.86 cm)

• Expected: {{convert| 30,000|km|mi}} → 30,000 kilometres (19,000 mi)
• Currently: {{convert|30,000|km|mi}} → 30,000 kilometres (19,000 mi)
• Sandbox : {{convert|30,000|km|mi}} → 30,000 kilometres (19,000 mi)

Impact: After copying the /sandbox, more than 273,100 articles will be reformatted, during the subsequent hours, to reset precision and reduce the expansion depth where the round value "|0" or sigfig=n is not specified. The new sandbox version also shows a template documentation page.

Edit-preview the above, after update, and expect identical numbers, for each 3 Expected/Currently, to ensure results. This update should be run together with the request below, to avoid double-reformatting of most articles which use both templates. Edit-preview the upper topic with all 3 threads. -Wikid77 18:35, 2 September 2012 (UTC)

Fix Template:Convert/LoffAonDbSoff for depth

Actual sandbox: Template:Convert/LoffAonDbSoff/sandbox

The conversion symbol formatter Template:Convert/LoffAonDbSoff needs to be updated (from the /sandbox) to correctly set the precision of the input amount (unless sigfig=n or a round "|0" is specified). Formerly, the precision calculation was left until deep inside the nested subtemplates, causing the template expansion depth to increase by 6-7 levels, which has been fatal in double-nested infoboxes, or inside other large templates. Hence, the simple calculation of precision in this template will fix the exceeded-depth error in hundreds, or thousands, of articles.
Testing: After the change, the results can be tested by checking the "Category:Pages where expansion depth is exceeded" to have fewer articles, especially for railroad trains or NRHP historic sites. The {PAGESINCATEGORY} count of 4,750 (live: 3) should drop to less than 4,600 pages in error. Some example calculations should appear as follows:

• Expected: {{convert| -23.56|ft|m|abbr=on}} → −23.56 ft (−7.18 m)
• Currently: {{convert|-23.56|ft|m|abbr=on}} → −23.56 ft (−7.18 m)
• Sandbox : {{convert|-23.56|ft|m|abbr=on}} → −23.56 ft (−7.18 m)

• Expected: {{convert|21.600|in|cm|abbr=on}} → 21.600 in (54.864 cm)
• Currently: {{convert|21.600|in|cm|abbr=on}} → 21.600 in (54.86 cm)
• Sandbox : {{convert|21.600|in|cm|abbr=on}} → 21.600 in (54.86 cm)

• Expected: {{convert|30,000|km|mi|abbr=on}} → 30,000 km (20,000 mi)
• Currently: {{convert|30,000|km|mi|abbr=on}} → 30,000 km (19,000 mi)
• Sandbox : {{convert|30,000|km|mi|abbr=on}} → 30,000 km (19,000 mi)

Impact: After the change, more than 260,500 articles will be reformatted, during the subsequent hours, to reset precision and reduce the expansion depth where the round value "|0" or sigfig=n is not specified. The new sandbox version also shows a template documentation page.

Edit-preview the above, after update, and expect identical numbers, for each 3 Expected/Currently, to ensure results. This update should be run together with the request above, to avoid double-reformatting of most articles which use both templates. Again, edit-preview the upper-level topic to view all 3 threads together.-Wikid77 18:35, 2 September 2012 (UTC)

Not done

The edits have been implimented. Earlier calculation of precision is the way forward for this template. I wonder, however, about the determination of precision. The autoprecision had been using the rule that the magnitude of the least significant digit of the output is to be between 0.2 and 2 times that of the input unless this would give less than two significant figures in which case the output would be rounded to two significant figures. Thus we had the following.

• Formerly: 21.600 in (54.86 cm) → 21.600 in (54.86 cm)
• Formerly: 30,000 km (19,000 mi) → 30,000 km (19,000 mi)

I'm not claiming that the former rule is necessarily better (sometime it is and sometimes it isn't, thus there are manual ways to set the precision), indeed there has been discussion about changing the rule (one idea was to change the range to $\scriptstyle {\sqrt {3}}$ to $\scriptstyle {\frac {1}{10}}{\sqrt {3}}$), but the rule did make things predicatble. JIMp _talk·cont 23:33, 2 September 2012 (UTC)

On further examination I have uncovered even more disturbing results, for example, this new code gives "30 micrometres (0 in)" instead of the former "30 micrometres (0.0012 in)" for {{convert|30|um|in}}.

I'm sorry but I'm going to have to revert the change until this issue is properly ironed out. JIMp _talk·cont 00:15, 3 September 2012 (UTC)

• Okay, we need to use some other parameter to pass the precision where it bypasses {precision}, but favors the last-minute exception to precision, in a case like "30 um (0.0012 in)" as a kind of recommended precision but using the round-value parameter. -Wikid77 (talk) 01:06, 3 September 2012 (UTC)

More examples

• a yard is a metre and a metre is a yard, a mile is a nautical mile and a nautical mile is a mile, a kilometre is a mile and a nautical mile but a mile or a nautical mile is two kilometres,
  • 1 metre (1.1 yd)
  • 1 yard (0.91 m)
  • 1 mile (0.87 nmi)
  • 1 nautical mile (1.2 mi)
  • 1 kilometre (0.62 mi)
  • 1 mile (1.6 km)
  • 1 kilometre (0.54 nmi)
  • 1 nautical mile (1.9 km)

• a foot is nothing so an inch must be a twelfth of nothing, a centimetre is nothing too
  • 10,000 square centimetres (1,600 sq in)
  • 1 foot (0.30 m)
  • 1 inch (0.025 m)
  • 1 centimetre (0.39 in)
  • 1+1⁄4 centimetres (0.49 in)

JIMp _talk·cont 01:02, 3 September 2012 (UTC)

• Now the above "More examples" have been handled (for sandbox option "disp=p"). The precision of fractions is also improved:

• {{convert|100|m|ft}} → 100 metres (330 ft)
• {{convert|100+1/2|m|ft}} → 100+1⁄2 metres (330 ft)
• {{convert|100+1/125|m|ft}} → 100+1⁄125 metres (328.1 ft)
• {{convert|100+1/125|m|ft|disp=p}} → 100+1⁄125 metres (328.1 ft)
• {{convert|1/1000|m|ft}} → 1⁄1000 metre (0.0033 ft)
• {{convert|1/1000|m|ft|disp=p}} → 1⁄1000 metre (0.0033 ft)
• {{convert|-1/10|mi|km|disp=p}} → −1⁄10 mile (−0.16 km)

I have not found any more problems. -Wikid77 (talk) 13:50, 5 September 2012 (UTC)

Using parameter 5/prec as precision

Instead of passing precision as parameter 3, then we can use 5. Because Convert must choose precision for rare cases, such as "30 micrometres (0.0012 in)" then parameters 3/4 (for round/sigfig) should remain unchanged, and instead, the new (year 2010) parameters 5-8 can be used to pass the "recommended precision" as parameter 5 (after 3/4), then pass 5 as "prec=" into Convert/round, where if "prec" has not been passed, then it still calls {precision/2010} or such. The call tree would be like:

Convert (top level)

| Convert/ft

| | Convert/LoffAoffDbSoff - should set 5={precision|{1} }

| | | Convert/{3} or /{o} - already passes 5 among parameters 1-7 or 1-8

| | | | Convert/LoffAonSoff - should pass 5 as new prec={5|} where 5={j}

| | | | | Convert/round - should check if prec set, else use {precision/2010}.

| | | | | | precision/2010 - runs 7 levels deeper when no prec is passed.

In that scheme, then 3 subtemplates (2 more) would be changed:

• Template:Convert/LoffAoffDbSoff - should set 5={precision|{1} } not 3=...
• Template:Convert/LoffAonSoff - should pass 5 as new prec={5|} where 5={j}
• Template:Convert/round - should check if prec set, else use {precision/2010}.

The use of parameter 5 has become an option ever since expanding each Convert/xxx to pass parameters 1-7 or 1-8 as "{{{4|}}}{{{5|}}}{{{6|}}}{{{7|}}}..." which were not available back in 2007. Meanwhile, I am working on Convert/round/sandbox to check operation there. -Wikid77 (talk) 04:30, 3 September 2012 (UTC)

• Now Order_of_magnitude too deep: The {Order_of_magnitude} should be changed to a one-line calculation. Testing insideTemplate:Convert/round/sandbox has revealed how avoiding {pround} and using {round} can still deepen the expansion nesting by the 2nd "elephant in the room" as Template:Order_of_magnitude (depth 7) which was never properly simplified. Since I have degrees in mathematics+computer science, I knew about the problems of calculated magnitude using logarithms with computer truncation error in the digital storage. The trick to allow a one-line calculated magnitude is to add a truncation shift, such as tiny 1E-14 to fix the computer math, and then the formula becomes:

• magnitude of x: {{#expr: floor( (ln abs( {{{2}}} ) / ln 10) +1E-14 ) }}

where, log₁₀x = ln x / ln 10 (so for 100, ln 100/ln10 = 2)

So, we can get magnitude of 999,999 versus 1 million, or 1 billion by tiny shift 1E-14 in the formula. Compare:

• {{Order_of_magnitude|999 999}} → 5
• {{#expr: floor( (ln 999999 /ln 10)+1E-14) }} = 5
• {{Order_of_magnitude|1 000 000}} → 6
• {{#expr: floor( (ln 1000000 /ln 10)+1E-14) }} = 6

Using a one-line calculation, for magnitude, will avoid the 7 depth levels of {Order_of_magnitude}, just as using parameter "prec={{{5}}}" will avoid 7-11 depth levels there. But because logarithms cannot use negative numbers, the value is handled as the absolute value, abs(x). Although reportedly, the WP servers run better than 16-digit precision, I advise to keep the factor within 1E-14 to allow calculation on lower-bit servers. Now, with both parameter "prec" and one-line magnitude, then Convert/round can be reduced by 7 fewer levels deep, while still allow "30 micrometres (0.0012 in)" to override the precision passed in parameter 5. -Wikid77 07:33, 3 September, revised 12:37, 5 September 2012 (UTC)

pounds per square foot

I have looked at the list of units and see pounds per square inch (psi) however I have a source which says "pressure equal to 50lbs per square foot" and I am unsure how to represent this (and what metric unit it should be converted into). The article is Clevedon Pier (which incorrectly says 50 p.s.i. (2.4 kPa).) although current edits are at User:Rodw/Sandbox/Clevedon Pier in the "collapse" section which you are welcome to edit.— Rod ^talk 10:39, 2 September 2012 (UTC)

• DONE: The new Template:Convert/psf converts a pressure amount in pounds per square foot (psf) with other units. The conversion factor used is: 1 pound per square foot (psf) is equal to 0.047880258888999994 kilopascals (kPa).

• {{convert|1.0|psf}}   → 1.0 pound per square foot (0.048 kPa)
• {{convert|1.0|psf|psi}} → 1.0 pound per square foot (0.0069 psi)
• {{convert|1.0|psi|psf|0}} → 1.0 pound per square inch (144 psf)

Any other units of pressure can be used as well. -Wikid77 (talk) 14:41, 2 September 2012 (UTC)

• Thanks for quick & efficient service. I have used it on Clevedon Pier and found out that 50psf is 2.39 kPa. Now if I just had a method for standardising imperial -> metric or metric -> imperial (as some measurements in the article are in one form & the rest in another) than my life would become much easier.— Rod ^talk 14:56, 2 September 2012 (UTC)
• Use disp=flip of imperial/metric: Remember to use option "disp=flip" to swap imperial -> metric, or reversed, depending on the appropriate unit system for each article. That way, the {convert} markup in each article will match the source document measurement, as imperial or metric, for direct verification, but also show the converted result first when "{convert|...|disp=flip}". Many sources have reported the same event while using data in imperial or metric units for their readership. -Wikid77 21:19, 2 September 2012 (UTC)

Error from above

Would anyone like to comment on the error I reported above at Template_talk:Convert#Some_wishes_I_have? This is still unresolved. I like to saw logs! (talk) 05:09, 3 September 2012 (UTC)

Plans to warn of invalid units: We have some unit-codes which are checked for incompatible units, or ambiguous abbreviations, such as "qt" or "mile". So, the plan is to warn of "mi|kg" where incorrect "kg" (kilograms) is used for "km" (kilometres).

Example for "qt" - { convert|36|qt}}: 36 qt

Example for "mile" - { convert|4|mile|km}}: 4 miles (6.4 km) Example for "miles" with "kg" - { convert|4|miles|kg}}: 4 miles ()

That last example is close to mismatching "mi" with "kg". However, the idea has been on hold until we reduce the expansion depth, to allow more space for extra processing. So, we agree with your idea to catch unit mismatches. -Wikid77 (talk) 12:58, 5 September 2012 (UTC)

Problems with this template in Book namespace

I noticed today that when this template is used in books within the book namespace, it causes an error which reads: (unknown operator: u'strong' to unknown operator: u'strong' t). I'm not quite sure how to fix that but I am hoping that someone does. Kumioko (talk) 01:25, 7 September 2012 (UTC)

Convert isn't one template... it's hundreds of subtemplates, any one or more of which could be doing this. To determine precisely which, we need to know either which page you see the error on, or exactly which parameters are being used, leaving nothing out - even something apparently trivial like |lk=off can make a huge difference. --Redrose64 (talk) 10:31, 7 September 2012 (UTC)

No problem, frankly it appears to be happening on every article in every book that itilizes the convert template. One example is Book:State highways in Marquette County, Michigan and the article M-553. Kumioko (talk) 10:36, 7 September 2012 (UTC)

Sorry, but I don't see a problem on either of these pages. Exactly whereabouts does it show; better still, can you give a sample of the wikicode from the page? --Redrose64 (talk) 15:38, 7 September 2012 (UTC)

The problem isn't in the pages themselves but in the PDF document that is generated for the book when you hit the download PDF button. When you look within that PDF at the articles, the convert template is rendering the above error rather than generating the convert calculations. It could very easily not be in the template itself but in how the PDF generation software is reading the template when creating the PDF. Kumioko (talk) 16:27, 7 September 2012 (UTC)

OK, I have downloaded PDF copies of these two (it would have helped if you had stated that the problem only occurred with PDF). But I still don't see a problem with Book:State highways in Marquette County, Michigan; but I do see that on the PDF version of M-553 (Michigan highway), the infobox has one row stating: "Length: 19.618 mi[1] (unknown operator: u'strong' km)". This appears to be associated with the |length_mi=19.618 parameter of {{Infobox road}}. The conversion in there is not done by {{convert}} at all, but by {{Infobox road/meta/length}}:

{{Infobox road/meta/length|mi|length=19.618|length_ref=<ref name=PRFA/>|round=}}

19.618 mi<xref name=PRFA/> (31.572 km)

the conversion inside that is

({{rnd|{{#expr:19.618 * 1.609344}}|{{precision|19.618}}}} km)

(31.572 km)

I'm going to post notes at both WP:VPT and Template talk:Infobox road. --Redrose64 (talk) 17:02, 7 September 2012 (UTC)

Sorry about that. The problem isn't just in the Infobox. If you look down in the text you will see that error in tables and in regular text as well. I am sure its something with the convert template or at least how the PDF software sees that template. Kumioko (talk) 17:08, 7 September 2012 (UTC)

Does {{Convert}} have this same issue? TwinsMetsFan (talk · contribs) is the one who created that Infobox road subtemplate. It was created specifically so a reference could be inserted at the appropriate place, like so:

<length><ref> (<conversion>)

Rather than:

<length> (<conversion>)<ref>

Now, if Convert can output like it was originally desired (ref in the middle), we can just rework the subtemplate to use Convert. –Fredddie™ 17:39, 7 September 2012 (UTC)

The Infobox does appear to have the same problem but Convert definately is also having a problem when being rendered in the PDF documents. Its not just in KM to MPH but also in other metric calculations such as ton. Kumioko (talk) 17:31, 7 September 2012 (UTC)

Actually, I just looked at the PDF myself. Any usages of {{convert}} in the text of the articles comprising the rendered book PDF have the error message instead of a conversion. The infoboxes all have the same error message, and the junction list tables have it. Those tables use {{MIint}} which uses {{jctint/core}}. So it isn't just one template, but I would suspect how the PDF creator handles multiple similar templates/subtemplates. Imzadi 1979 → 17:40, 7 September 2012 (UTC)

I've narrowed it down to the following bit of code in the {{rnd}} template

• {{#expr:(1E5round0)E5}} which gives 10000000000.

Try converting User:WOSlinker/list to a pdf to see the error. -- WOSlinker (talk) 17:49, 7 September 2012 (UTC)

• Please note that the two notices I posted directing people here (WP:VPT#Problem with conversion of miles to kilometres when page is rendered as PDF and Template talk:Infobox road#Problem with conversion of miles to kilometres when page is rendered as PDF) are both attracting comment, which goes against WP:MULTI. --Redrose64 (talk) 15:49, 8 September 2012 (UTC)

  The solution is to replace {{#expr:(1E5round0)E5}} with {{#expr:(1E5round0)*1E5}}. See User:Ruslik0/Sandbox4. Ruslik_Zero 18:30, 8 September 2012 (UTC)

  I made a change to the {{rnd}} template and the problem now appears to be solved, at least with M-553 article. Ruslik_Zero 18:53, 8 September 2012 (UTC)

• Consider (1E5round0)*(1E5round0): As I recall, the whole issue with 1E5 (versus 1E6 or others) was due to a digital truncation error, where the value of 1E5, or 1E5round0 was not really 100,000. This was a documented bug, and the easiest live test was to subtract the 2 values, expecting zero: {{#expr: 100000 - (1E5round0) }} = 0 (live), or perhaps {{#expr: 1E10 - (1E10round0) }} = 0 (live). Now, I am unsure of the implication for the PDF documents, so I just note this issue for future consideration. However, we all hope the computer math calculations have been fixed (enough) so that "{#expr:(1E5round0)*1E5}" will work okay for all related numbers. -Wikid77 (talk) 07:44, 12 September 2012 (UTC)

Unexpected bold in 'kWh/100 km' conversion

{{convert|11|kWh/100 km|abbr=on}} -> 11 kW⋅h/100 km (0.40 MJ/km; 0.18 kW⋅h/mi) gives unexpected bold and newlines.  Stepho  talk  06:20, 17 September 2012 (UTC)

Fixed --Redrose64 (talk) 14:12, 17 September 2012 (UTC)

Convert/spell

For Fortescue Metals Group#Solomon Hub, five billion tonnes (4.9×10⁹ long tons; 5.5×10⁹ short tons) instead of five billion tonnes. Peter Horn User talk 02:05, 18 September 2012 (UTC)

How about {{convert|5|e9t}} → "5 billion tonnes (4.9×10⁹ long tons; 5.5×10⁹ short tons)"? JIMp _talk·cont 02:00, 22 September 2012 (UTC)

• Fixed problems with Convert/spell for billions or trillions: Today, I have increased Convert/spell to handle 999 billion (up to 20 trillion), but many large numbers round into x-notation numbers with span-tags. It will work when the output number is a much smaller number, such as feet to kilometres, or trillions of miles to light-years, but now works when the output unit is also very large and uses x-notation. Examples:

• {convert/spell|500,000,000|t|LT}} → five hundred million tonnes (490,000,000 long tons)
• {convert/spell|5,000,000,000|t|LT}} → five billion tonnes (4.9×10⁹ long tons)
• {convert/spell|5,000,000,000|t|LT|-3}} → five billion tonnes (4.921033×10⁹ long tons)
• {convert/spell|37,000,000,000|ft|km}} → thirty-seven billion feet (11,000,000 km)
• {convert/spell|14,000,000,000,000|mi|ly|abbr=off}} → fourteen trillion miles (2.4 light-years)
• {convert/spell |7.6E12|mi|ly|abbr=off}} → seven trillion six hundred billion miles (1.29 light-years)

On 25 September, I changed Template:Convert/LoffAonSoffu2 to allow x-notation numbers. I am working on a new rounding template, Template:Rndpad, which avoids x-notation to allow larger numbers in Convert/spell. -Wikid77 (talk) 09:54, 23 Sep., revised 05:06, 25 September 2012 (UTC)

Dekameters

Why do acre feet convert to cubic dekameters, not meters? Art LaPella (talk) 19:53, 28 September 2012 (UTC)

They will convert to whatever the editor using the template requests them to convert to: the problem is that there seems to be no clear policy about what ought to be used as target units. Kevin McE (talk) 20:02, 28 September 2012 (UTC)

Resolved

on the other page. Art LaPella (talk) 01:06, 29 September 2012 (UTC)

A bad example?

I don't understand this example:

"skip the precision parameter (the 3rd or 4th unnamed parameter) e.g. {{convert|100|km|kn}} gives 100 kilometres (190,000 kn) and {{convert|100|km}} gives 100 kilometres (62 mi)."

kn is the abbreviation for "knot", a unit of speed, not distance. Therefore, km should never display knots as a conversion.

This is not just an error in the example, since {{convert|100|km|kn}} actually displays "100 kilometres (190,000 kn)" as shown in the quoted sentence above. Not only is this a mix of units, but even if you allow "knot" as standing for one nautical mile, the conversion is wrong -- a nautical mile is 1,852 meters (exactly), so that 100km is 54 nautical miles.

. . Jim - Jameslwoodward (talk to me • contribs) 12:50, 28 September 2012 (UTC)

currently, this is nothing preventing the user from using this template with incorrectly matched units. for example, {{convert|4|mi|kg}} actually shows something other than an error message. it would be great to see this sort of thing addressed. you will find this discussed many times in the talk archives. I believe the only thing preventing a solution is problems with the template complexity (e.g., expression depth). Frietjes (talk) 15:40, 28 September 2012 (UTC)

OK, I completely understand that. This template is already complex enough. But why does one of the examples show mismatched units with a silly result? Normally, I'd just fix it, but I'm afraid I'm missing something. . . Jim - Jameslwoodward (talk to me • contribs) 16:35, 28 September 2012 (UTC)

no idea. I changed it to km -> ft. Frietjes (talk) 17:32, 28 September 2012 (UTC)

• Change Convert/km to style of Convert/miles: I guess, because attempts to simplify Convert have stalled (again), we should proceed with rejecting the most-common mismatched units. A simple example for rejecting invalid units is Template:Convert/miles:

• {{convert|5|miles|km}} → 5 miles (8.0 km)
• {{convert|5|miles|kg}} → 5 miles ()
• {{convert|13|km|miles}} → 13 kilometres (8.1 mi)
• {{convert|5|miles|kn}} → 5 miles ()
• {{convert|5|miles|ft.}} → 5 miles ()
• {{convert|5|miles|yds}} → 5 miles (8,800 yd)

Hence, Template:Convert/km could be changed to reject "kn" or any non-length unit (or gibberish) in that manner, without increasing the expansion depth beyond 28/40 by showing the orange error message in the middle of the template parameters. -Wikid77 (talk) 06:09, 29 September 2012 (UTC)

Yes, the template needs simplification but it'll take a while. This issue it up the top of the list of needed improvements but until we manage to overhaul the template and introduce a general solution we'll have to made do with partial solutions like the above. JIMp _talk·cont 23:38, 30 September 2012 (UTC)