Template talk:Convert/Archive May 2013

Weird Result

{{convert|152.4|m|ftin|abbr=on}}

produces the strange result: 152.4 m (0×10−13 in). Change the input value to 152, 152.3 or 152.5 and things are fine! CrackDragon (talk) 01:29, 2 May 2013 (UTC)

Interesting, the programmer's nightmare! I've had a look, but it is too tricky for me. It is not the abbr; it is the fact that the input converts to exactly 500 feet, and somehow the 500 is being interpreted as zero, which causes it to be omitted. The same thing happens with other combinations:

• {{convert|152.4|m|ftin}} → 152.4 metres (500 ft 0 in)
• {{convert|304.8|m|ftin}} → 304.8 metres (1,000 ft 0 in)
• {{convert|3,175.14659|kg|stlb}} → 3,175.14659 kilograms (500 st 0 lb)
• {{convert|0.22321428571429|LT|lboz}} → 0.22321428571429 long tons (500 lb 0 oz)

Johnuniq (talk) 09:22, 2 May 2013 (UTC)

• Problems with 2-unit values near zero units: Due to truncation error in storage of floating-point numbers, the calculations must be shifted by tiny amounts to avoid errors in the 13th or 14th decimal digit. Until fixed, just append the trailing digits "001" such as "152.4`001" and use Template:Convert/f to show only the original one-decimal precision by "r1=1" as follows:

• {{convert/f |152.4001|m|ftin|0|r1=1}} → 152.4 metres (500 ft 0 in)
• {{convert|152.3|m|ftin}} → 152.3 metres (499 ft 8 in)
• {{convert|152.4|m|ftin}} → 152.4 metres (500 ft 0 in)
• {{convert|152.4000|m|ftin}} → 152.4000 metres (500 ft 0 in)
• {{convert|152.4001|m|ftin}} → 152.4001 metres (500 ft 0 in)
• {{convert|152.4|m|in}}     → 152.4 metres (6,000 in)
• {{convert|500.000|ft|in}} → 500.000 feet (6,000.00 in)

Even after Template:Convert/LoffAonSoffAnd has been fixed, the use of {convert/f} will still show the correct results, so there will be no need to redo the fixed conversions in whichever articles. -Wikid77 (talk) 14:04, 2 May 2013 (UTC)

• Fix {Convert/rand} to use #expr "round" not {rnd}: The Template:Convert/rand/sandbox should be used to update {Convert/rand}, to just round the output amounts by using a simple #expr with "round" rather than use Template:Rnd which puts scientific notation of x10 span-tags in tiny values near zero. Instead, a simple #expr rounding will keep all internal values as simple numbers. So there will be no x10 data such as "0×10^-13" in the numbers to format for ftin, lboz, or stlb, etc. Note the use of {convert/rand/sandbox} by "ftin/sandbox2" as the unit-code, to allow a clean conversion of 152.4 m as 500 feet (not "0 × 10^-13"):

• {convert|152.4|m|ftin}}               → 152.4 metres (500 ft 0 in)
• {convert|152.4|m|ftin/sandbox2}} → 152.4 metres ()
• {{convert|304.8|m|ftin}}               → 304.8 metres (1,000 ft 0 in)
• {{convert|304.8|m|ftin}/sandbox2} → 304.8 metres ()

Other problems with using Template:rnd, to round the intermediate results, have been noted for years, and we need to format the x10 notation (or trailing ".000") only in the final results. However, for "ftin" or "lboz" the trailing ".000" could be ignored for now. -Wikid77 (talk) 15:54, 2 May 2013 (UTC)

There is another solution. It is much easier to be consistent and accurate when using one Lua module (see Module talk:Convert for progress, and see here for some other template problems).

Following are the results using the module:

• {{convert/sandboxlua|152.4|m|ftin}} → 152.4 metres (500 ft 0 in)
• {{convert/sandboxlua|304.8|m|ftin}} → 304.8 metres (1,000 ft 0 in)
• {{convert/sandboxlua|3,175.14659|kg|stlb}} → 3,175.14659 kilograms (500 st 0 lb)
• {{convert/sandboxlua|0.22321428571429|LT|lboz}} → 0.22321428571429 long tons (500 lb 0 oz)

Johnuniq (talk) 23:52, 2 May 2013 (UTC)

Kelvin

Just wondered if there is a way to easily convert 5 degrees above absolute zero into both centigrade and Fahrenheit using this template ? EdwardLane (talk) 07:33, 2 May 2013 (UTC)

{{convert|5|K|C F}} → 5 K (−268.15 °C; −450.67 °F)

Since Celsius + Fahrenheit is the default, you can also have:

{{convert|5|K}} → 5 K (−268.15 °C; −450.67 °F)

Johnuniq (talk) 08:08, 2 May 2013 (UTC)

thanks EdwardLane (talk) 14:41, 3 May 2013 (UTC)

Problems with separation of Number from Units of Measurement at End of a Text Line.

75 feet (23 m) - It would be helpful if all conversion templates could be updated to avoid the first cited units of measurement from being separated from the number at the end of the line. When manually entering it, it would be accomplished by inserting "&" followed by "nbsp;" between 75 and "feet" in the example. However, the current template allows the 75 and "feet" to be separated at the end of the line. The template does allow the second conversion units, which in the example is meters, and number to stay together if it goes over the cliff at the end of a line.

The first number and unit of measurement is kept together when going over the cliff at the end of a line when adj=on is added, as shown in this example, 75-foot (23 m), but that is only when it is used in the context of an adjective.

Let me know if anything can be done to correct this.Wondering55 (talk) 15:54, 7 May 2013 (UTC)

Using a space between the value and the name of a unit was a design decision, although some templates have  , while most use a space. Abbreviated units (symbols) are preceded by  . Use {{nowrap}} for an exception like a conversion at the end of a line ({{nowrap|{{convert|75|ft|m}}}}), as done here:

Padding to test wrap aaaaaaaaaaa bbbbbbbbbbb ccccccccccc aaaaaaaaaaa bbbbbbbbbbb 75 feet (23 m).

Johnuniq (talk) 00:26, 8 May 2013 (UTC)

Thanks for the workaround advice. Is there any way to get someone to agree to change the design decision in order to eliminate this spacing problem for the first number and the fully spelled out unit of measurement. I would think that most editors would not like to see a number and its associated unit of measurement be separated at the end of a line. There is no problem with spacing when abbr=on is used with the template, 75 ft (23 m), since the first units are then abbreviated, and the template is set up so that abbreviated units do not get separated from a number. There is no problem with spacing when adj=on is used since a hyphen is placed between the number and the unit of measurement. By default, there is no problem with the secondary converted number and unit of measurement, which is abbreviated in all cases, regardless of whether abbr=on or adj=on is used.Wondering55 (talk) 04:50, 8 May 2013 (UTC)

there used to be an option (was it called |abbr=mos?) which would add a non-breaking space exactly where you indicated, but that was removed. Frietjes (talk) 14:43, 8 May 2013 (UTC)

One previous discussion was in March 2012. However the abbr=mos option was removed with the rationale that the convert template should conform to MOS by default (see edit summary here). Johnuniq (talk) 02:39, 9 May 2013 (UTC)

This is a test of narrow columns.

{{convert |75|ft |m |0}}→ 75 feet (23 m) Also 19.7 square inches (127 cm2)

• There were problems in narrow wikitable columns which needed wrapping: Some longer unit names (such as "square inches") need to wrap, when inside narrow columns. So, the default spacing has been set to allow full text-wrap of the input amount, where only an abbreviated unit symbol forces a non-breaking space ( ) after the numeral. The wikitable, at right, contains 2 conversions, which allow the numeral and unit name to wrap:

• {{convert |75|ft |m |0}} → 75 feet (23 m)
• {{convert |19.7 |sqin |cm2 |0}} → 19.7 square inches (127 cm²)

However, we could have a new option to join (no-wrap) the original amount and the unit name. Then, a numeral would always join as "19.7 square" within a line of text. Every year, someone raises the text-wrap issue, so I think it is time to find a workable solution. I guess it can be frustrating for people who do not know about the narrow-column cases in wikitables. -Wikid77 (talk) 08:19, 9 May 2013 (UTC)

OK. This would definitely get to a preferred workable solution, which really is needed by editors for all Wikipedia articles. The narrow-column case with a no wrap solution for the first full word in a unit of measurement can easily be addressed by slightly increasing the allowed width of that particular narrow-column, which is arbitrary for a particular article. Can anybody provide a link to a particular article that is so narrow that only the text for a number and the full first word of the unit of measurement cannot fit on one line? That would be one very narrow column, which I assume could easily be widened.Wondering55 (talk) 14:47, 9 May 2013 (UTC)

There have been some scientific data tables, perhaps some numbers such as: 1.234455 light-years (78,068.3 AU) where "light-years" would wrap underneath the number. With over 530,000 affected articles, it has been difficult to keep track of usage. -Wikid77 16:35, 9 May 2013 (UTC)

Testing default.

{{convert |530120 |mi}} → 530,120 miles (853,150 km)

Testing option adj=j.

{{convert |530120|mi |adj=j}} → 530,120 miles (853,150 km)

Testing adj=j & abbr=off.

Using abbr=off: 297 feet (91 metres)

• New option "adj=j" to join amounts to units: This new option "adj=j" will join the amount+unit for cases such as "9 miles" within the text (compared to adj=on showing "9-mile"). Any multi-word units, such as "square inches" units, will still wrap, to avoid excessive rigid text. So, the default spacing will allow full text-wrap of the input amount, but "adj=j" will join numeral and unit. The wikitables, at right, contain 2 conversions, which show how the numeral and unit name will stay joined (not wrap):

• {{convert |530,120|mi|km|adj=j}} → 530,120 miles (853,150 km)
• {{convert |297|ft|m|adj=j|abbr=off}} → 297 feet (91 metres)

The option "adj=j" is a first step, and we can develop better options later. However, a new option was needed immediately, because this text-wrap issue has been discussed every year, and we needed a workable solution. Now we have a way to join number+unit, while allowing full wrap in wikitables. I think this option was overlooked by us part-time volunteers, for years, due to distractions of handling 74,000 other combinations of options, with over 350 measurement units. I guess we need to have some way to sort out priorities, of which options affect more conversions, such as issues re-discussed every year, to focus on major improvements. -Wikid77 16:14, 9 May 2013 (UTC)

One item to note about using {{nowrap}} with this template: the line then won't/can't break between the input value and the conversion in parentheses. For example, enclosing {{convert|60|mi|km}} in the nowrap template means that the whole "60 miles (97 km)" grouping will appear on the same line, even though it would be desirable to allow the line to break between the mils and the kilometers. Imzadi 1979 → 17:28, 9 May 2013 (UTC)

Happy Days are here again. Go forth and spread this good news/option. I assume the explanation and details for this new option will be put on the Template: Convert page. Thanks for listening and coming up with a needed solution.Wondering55 (talk) 20:47, 9 May 2013 (UTC)

While I was updating articles with the new command adj=j, it worked great, except for Convert templates that also had the disp=flip command, which currently works when abbr=on or adj=on is used, i.e. 14,906-foot (4,543.5 m). Can someone update the Convert template with the disp=flip command so that it also works with adj=j? Wondering55 (talk) 15:25, 12 May 2013 (UTC)

fixed? Frietjes (talk) 19:15, 12 May 2013 (UTC)

Thanks, it now works with disp=flip as shown: 14,906 feet (4,543.5 m)Wondering55 (talk) 14:14, 13 May 2013 (UTC)

For locomotives

ton-force (short), ton-force (long) ton-force (short), ton-force (long) long ton force (LTf) long tons-force for |locobrakeforce = {{convert|37|LTf}}, see British Rail Class 13 etc. See Talk:Ton#What is this?. Peter Horn User talk 02:54, 13 May 2013 (UTC)

The reverse would be 370 kN (83,000 lb_f). Peter Horn User talk 16:16, 13 May 2013 (UTC)

Make that 370 kN (37 long tons-force). Peter Horn User talk 16:19, 13 May 2013 (UTC)

which units do you actually need, we have STf, LTf, and kN, so which one is missing? Frietjes (talk) 16:29, 13 May 2013 (UTC)

Or reverse 370 kN (37 long tons-force) also 370 kN (42 short tons-force) or 370 kN (42 short tons-force). LTf and STf are "missing" only in the sense that long tons-force (LTf) and short tons-force (STf) as in the current {{convert|37|LTf}} etc all misdirected to ton instead of being treated as a unit of pressure. Peter Horn User talk 16:43, 13 May 2013 (UTC)

I see, please correct the requests made at Template talk:Convert/STf and Template talk:Convert/LTf if I got it wrong. Frietjes (talk) 16:59, 13 May 2013 (UTC)

 Done Peter Horn User talk 22:04, 13 May 2013 (UTC)

LTf and STf or LTf and STf should have their own articles just as lbf. Peter Horn User talk 15:43, 14 May 2013 (UTC)

Removed that which did not belong here. Peter Horn User talk 04:56, 18 May 2013 (UTC)

Pluralising m/s

I am having some problems using the template with m/s. {{convert|750|m/s}} displays 750 metre per second (2,500 ft/s) rather than "metres per second". Can anybody help me? --John (talk) 12:08, 26 May 2013 (UTC)

I've fixed it. 750 metres per second (2,500 ft/s) -- WOSlinker (talk) 12:34, 26 May 2013 (UTC)

Thank you, that was fast. --John (talk) 12:36, 26 May 2013 (UTC)

Incorrect conversion of kg to lbs/rounding lb to 2 significant digits by default

All over the Wikipedia, so the formula (1 kg = 2.2 lb) must be screwed up in the template {{convert|value|in_unit|out_unit|round_to|...}}, e.g. 70 kg = 154 lb, but the template wrongfully produces 70 kg (150 lb), 62 kg = 136 lb, but the template wrongfully produces 62 kg (137 lb), but it converts correctly 100 kg (220 lb), 10 kg (22 lb), and 1 kg (2.2 lb); it seems it rounds lb to 2 significant digits, which is a primitive default especially for the people's weight template, and, instead, it should be accurate by default.--24.186.223.176 (talk) 19:44, 25 May 2013 (UTC) 70 kilograms (150 lb)

The template tries to keep the rounding the same as the number of zeroes in the input. But you can override it:

• {{convert|70|kg|lb|-1}} → 70 kilograms (150 lb)
• {{convert|70|kg|lb|0}} → 70 kilograms (154 lb)
• {{convert|70|kg|lb|1}} → 70 kilograms (154.3 lb)
• {{convert|70|kg|lb|2}} → 70 kilograms (154.32 lb)
• {{convert|70|kg|lb|sigfig=1}} → 70 kilograms (200 lb)
• {{convert|70|kg|lb|sigfig=2}} → 70 kilograms (150 lb)
• {{convert|70|kg|lb|sigfig=3}} → 70 kilograms (154 lb)
• {{convert|70|kg|lb|sigfig=4}} → 70 kilograms (154.3 lb)
• {{convert|70|kg|lb|sigfig=5}} → 70 kilograms (154.32 lb)  Stepho  talk  00:23, 26 May 2013 (UTC)

Not really, as 62 does not contain zeros, but 140 does; the conversion default is inaccurate, arbitrary, primitive, and results in inaccurate and thus misleading weight of almost all people described on Wikipedia contradicting its essence and purpose:

• {{convert|62|kg|lb|}} → 62 kilograms (137 lb). --24.186.223.176 (talk) 03:47, 27 May 2013 (UTC)

Hmm, curious. I'm not sure why it rounded off to an extra digit but you can always override it. To give some more examples with your new numbers:

• {{convert|62|kg|lb|-1}} → 62 kilograms (140 lb)
• {{convert|62|kg|lb|0}} → 62 kilograms (137 lb)
• {{convert|62|kg|lb|1}} → 62 kilograms (136.7 lb)
• {{convert|62|kg|lb|2}} → 62 kilograms (136.69 lb)
• {{convert|62|kg|lb|sigfig=1}} → 62 kilograms (100 lb)
• {{convert|62|kg|lb|sigfig=2}} → 62 kilograms (140 lb)
• {{convert|62|kg|lb|sigfig=3}} → 62 kilograms (137 lb)
• {{convert|62|kg|lb|sigfig=4}} → 62 kilograms (136.7 lb)
• {{convert|62|kg|lb|sigfig=5}} → 62 kilograms (136.69 lb)  Stepho  talk  04:25, 27 May 2013 (UTC)

• The under-precision of kg/lb conversions was to be fixed years ago with m/ft: Sorry, this is another drop-the-ball lack of fixing a massive problem noted years ago. It is related to the fix for m/ft as in: 32 metres (105 ft). Please understand, with all the other problems and troublemakers who distract from important changes, then these major problems sometimes (often) get unresolved for years. Some similar cases:

• {{convert|59|kg|lb}}   → 59 kilograms (130 lb)
• {{convert|60.5|kg|lb}} → 60.5 kilograms (133 lb)
• {{convert|61|kg|lb}}   → 61 kilograms (134 lb)
• {{convert|61.5|kg|lb}} → 61.5 kilograms (136 lb)
• {{convert|62|kg|lb}}   → 62 kilograms (137 lb)
• {{convert|62.5|kg|lb}} → 62.5 kilograms (138 lb)
• {{convert|63|kg|lb}}   → 63 kilograms (139 lb)
• {{convert|63.5|kg|lb}} → 63.5 kilograms (140 lb)
• {{convert|64|kg|lb}}   → 64 kilograms (141 lb)

In general, the default precision of the output amount should be sufficient to differ in amount so that the amount (n - 0.5) does not convert higher than the higher amount n, such as 60.5 kg as "133 lb" but 61 kg as "130 lb" (oops!). It was a major problem with m-to-ft conversions having a conversion factor of ~3.28, and also a problem with kg-to-lb as the conversion factor of ~2.2 gives some numbers which are particularly prone to folding into the same output amount, for 2 different input amounts, or else the higher amount yields a lower result (oops!). It should have been fixed 4-5 years ago, so thank you for noting the severe problem still exists. A fix similar to the default-precision fix for "ft" (fixed in Template:Convert/ft) would correct the kg-to-lb problem.
So then, update Template:Convert/lb to reset precision parameter "j" as:

• Bad: |j=-0.343334259-{{{j|0}}}
• Fix:  |j={{#ifexpr: floor({{{1|9}}}) = ({{{1|9}}}) |-0-{{{j|0}}}|-0.343334259-{{{j|0}}} }}

As shown in the Template:Convert/lb/sandbox version:

• {convert|60.5|kg|lb/sandbox} → 60.5 kilograms ()
• {convert|61|kg|lb/sandbox}   → 61 kilograms ()
• {convert|61.5|kg|lb/sandbox} → 61.5 kilograms ()
• {convert|62|kg|lb/sandbox}   → 62 kilograms ()
• {convert|62.5|kg|lb/sandbox} → 62.5 kilograms ()
• {convert|63|kg|lb/sandbox}   → 63 kilograms ()
• {convert|63.5|kg|lb/sandbox} → 63.5 kilograms ()

That was intended to be the fix 4-5 years ago. -Wikid77 (talk) 23:24/23:40, 27 May, 03:56, 29 May 2013 (UTC)

Interesting—thanks for the explanation. I knew about the extra precision with ft and integer input, but I was not aware of the background. However, there may not be a convenient procedure that always works. Consider:

• {{convert|699.2|kg|lb/sandbox}} → 699.2 kilograms ()
• {{convert|699.6|kg|lb/sandbox}} → 699.6 kilograms ()
• {{convert|699.8|kg|lb/sandbox}} → 699.8 kilograms ()
• {{convert|700  |kg|lb/sandbox}} → 700 kilograms ()
• {{convert|700.2|kg|lb/sandbox}} → 700.2 kilograms ()

The difference between the exact and rounded outputs is generally under 0.4 in that region, but the difference jumps to 43.2 when the input is 700. However, that's a reasonably small error of 43.2/1543 = 2.8%, although it looks dramatic. I used a script hacked from Module:Convert to find that number, which is the biggest difference for inputs from 0 to 1000 with kg/lb.

In the same range, the worst case for m/ft is at 900 where the output jumps up by 48:

• {{convert|899.6|m|ft}} → 899.6 metres (2,951 ft)
• {{convert|899.8|m|ft}} → 899.8 metres (2,952 ft)
• {{convert|900  |m|ft}} → 900 metres (3,000 ft)
• {{convert|900.2|m|ft}} → 900.2 metres (2,953 ft)

Module:Convert has the same problem; I'll think about whether anything can be done, but it looks tricky. Johnuniq (talk) 10:24, 29 May 2013 (UTC)

• Treating one zero as significant digit per number sense: Yes, now I am remembering years ago, as some solved the major cases by treating one trailing zero as significant for some units of measurement, depending on "number sense" in cultural usage. For example, if someone in the U.S. says, "We got a speeding ticket for going 40 mph in a 35 zone" then that 40 miles per hour (64 km/h) was clocked between 39.5-40.5, rather than 1 significant digit rounded between 35-45. So, the "900" would be treated as "900" with sigfig=2 (rather than 1 digit):

• {{convert|900  |kg|lb|sigfig=2}} → 900 metres (3,000 ft)
• {{convert|900.2|m|ft}} → 900.2 metres (2,953 ft)

Hence, "900 m" is properly "(3,000 ft)" because a survey of usage in articles will confirm how "700" or "900" is used to indicate "roughly 900" and the rough result "3,000 ft" is entirely sensible in actual usage. It works well because almost no hill is exactly 900 m high (2,953 ft) and almost no road is exactly 700 mi long (1,127 km). However, having "62 kg (140 lb)" then 62.5 kg (138 lb) as lower, is not reasonable per number sense of people's weights, and the /sandbox fix is needed, as: 62 kg (). I even had to prove "reasonable" by ranges of the rounded input data, around the number 62±0.5:

• {{convert|61.50|-|62.49|kg|lb}} → 61.50–62.49 kilograms (135.6–137.8 lb)

In this proof of reasonable results, the rounding as "140 lb" lies outside the extremes of the rounded interval, 135.6–137.8 lb, while the /sandbox fix as "137 lb" is inside the rounded range. However, there were some rare cases where that proof did not always work, and so the broader validation is to round the rounded interval down+up as "135-138" and that method gave a solid sanity check for the expected results, with "137" inside and "140" as failing the check. The concept is to replace the notion that precision is set by a "mathematical formula" with precision now set by a "logical formula" which gives better results, when compared to similar numbers, such as 62 versus 62.5. And so, {Convert} is not merely a "conversion calculator" and "abbreviation clerk" but also a "precision wizard" and "measurement typesetter". -Wikid77 (talk) 06:27, 30 May 2013 (UTC)