Template talk:Convert/Archive February 2014

disp=table

Resolved

 – in the recent code update. -DePiep (talk) 13:07, 1 February 2014 (UTC)

I'm not sure what but there seems to be something broken here.

Table of volume units

Unit	Imperial ounce	Imperial pint	Millilitres	Cubic inches	US ounces	US pints
fluid ounce (fl oz)	1	1/20	28.4130625	1.7339	0.96076	0.060047
gill (gi)	5	1/4	142.0653125	8.6694	4.8038	0.30024
pint (pt)	20	1	568.26125	34.677	19.215	1.2009
quart (qt)	40	2	1,136.5225	69.355	38.430	2.4019
gallon (gal)	160	8	4,546.09	277.42	153.72	9.6076
[ {convert/sandbox} used on row 5]
Note: The millilitre equivalences are exact, but cubic-inch and US measures are correct to 5 significant figures.

{convert/sandbox |28.4130625|ml|cuin USoz USpt|disp=table|sigfig=5}}

This is from Imperial units . disp=table should be putting |align=right| between each output (not just the first). Jimp 09:58, 20 January 2014 (UTC)

I've used {convert/sandbox} on row 5 above. -Wikid77 23:26, 22 January 2014 (UTC)

Groan, sorry but I've put off deploying module v2 due to minor irritation regarding the fact that the modules are locked due to convert being on the main page. The disp=table bug was reported a month ago and was quickly fixed (I had not realized that an output combination unit was supposed to output into separate cells). But, there were a lot of other changes and it took some time to sort it all out. If you want to try the fix, change "convert" to "convert/sandbox" in a couple of the table entries to see that it works in a preview. Then, have a look at #Module v2 soon above, and feel free to copy the module sandbox code to the main module (that's four massive edits). After some server grinding, that should fix several articles that have the problem. Johnuniq (talk) 10:10, 20 January 2014 (UTC)

I've edited the table, now using {{convert/sandbox}} in all rows. Bug looks fixed in /sandbox, waiting to be deployed. -DePiep (talk) 16:12, 24 January 2014 (UTC)

• Fixed page "Imperial units" by {convert/old}: I have fixed the column alignment of the gill/pint/quart table in article "Imperial units (edit | talk | history | protect | delete | links | watch | logs | views)" by using {{convert/old}} to generate exactly the same digits but with precise column-alignment as "|align=right|" for each column (the remainder of the tables look fine). The priority of concerns should be: encyclopedic typesetting first, then Convert deployment later, because people have viciously scolded the level of Convert glitches in the "world's greatest encyclopedia" and {convert/old} still works extremely well, but just one-39th second slower than Lua Convert. Focus on the live typesetting first. Overall, together, we have pinpointed and corrected over 500 pages for unit-mismatch or other problems (+grammar!), but beware how the high-pageview articles are likely to trigger complaints if left uncorrected. Remember, Step 1: use {convert/old}, and then we can discuss other options later. -Wikid77 (talk) 23:26, 22 January 2014 (UTC)

Kg/ha <=> lb/ac

This conversion would be helpful for discussing agricultural chemicals. Thanks for listening. Lfstevens (talk) 03:38, 5 February 2014 (UTC)

The convert module prevents conversions between units of different types, and to provide greatest flexibility, all "mass per area" units are now defined as being "pressure". Any of the unit codes shown here can be used. That includes kg/m2, lb/sqft, LT/acre, and MT/ha.

Please confirm what extra units would be useful in articles: kg/ha and lb/acre (I guess "acre" rather than "ac" is ok?). Johnuniq (talk) 03:55, 5 February 2014 (UTC)

Here's a good example of the problem with muddling mass and weight. Body mass index and area density are a couple more. However, I see what you're getting at with flexibility: mass per area can still be converted to mass per area even though the template internally treats it as pressure. It's a decent solution. Jimp 10:47, 6 February 2014 (UTC)

Yikes, I'm glad I did not ponder those when I was last confused about pressure vs. mass-per-unit-area (see archive).

@Lfstevens: When you get an opportunity to work out what is needed, please reply here. Johnuniq (talk) 22:56, 6 February 2014 (UTC)

I wouldn't have thought it would be a good idea to mix force and mass like that. Are there any use cases that force you to do that?GliderMaven (talk) 03:12, 9 February 2014 (UTC)

I have forgotten the details. At first I thought it would be easy—just point out to people that they are wrong, and from now on they will have to distinguish between force/area and mass/area. However, there were some commonly used units that did not fit that grand plan. Also, for historical reasons, there were some very conflicting units (example: kg/cm2 was pressure but kg/m2 was mass/area, and converting between the two before the module was introduced gave incorrect values). There is more at this archive, and this trains archive. Those discussions are confusing to read now—at the time, {{convert}} called the old template (not the module), but now it calls the module so the examples are not what would have been displayed in the original discussion. I am fairly confident that the results now shown in articles are ok. Johnuniq (talk) 03:43, 9 February 2014 (UTC)

Acre is fine. I have no other units for you at this time. Lfstevens (talk) 02:32, 7 February 2014 (UTC)

@Lfstevens:: I have implemented the new units in the sandbox; following are some examples:

• {{convert|1|kg/ha|abbr=on}} → 1 kg/ha (0.89 lb/acre)
• {{convert|1|kg/ha|abbr=off}} → 1 kilogram per hectare (0.89 pounds per acre)
• {{convert|1|lb/acre|abbr=on}} → 1 lb/acre (1.1 kg/ha)
• {{convert|1|lb/acre|abbr=off}} → 1 pound per acre (1.1 kilograms per hectare)

This change required editing Module:Convert/extra, and that revealed an interesting blunder in my recent update of the convert module: if an article on the main page has a convert using a range, the "extra" module is edit-protected because of some clever code which looks up the range word (such as "to") as a unit on the basis that over 90% of converts have the simple form {{convert|number|unit|options}}, so it saves time to check for that form before looking for complex cases such as ranges. In the next release of the module I will fix that so the "extra" module is not invoked when a range occurs. Johnuniq (talk) 00:21, 8 February 2014 (UTC)

Thanks for the quick response. I'll put them to use when you roll them out. Lfstevens (talk) 02:32, 8 February 2014 (UTC)

They are live now and can be used straight away. Johnuniq (talk) 02:39, 8 February 2014 (UTC)

Successfully applied at Pesticide research#Fragment- and Target-Based Design, Pesticide#Sulfonylurea herbicides and Macrotyloma geocarpum. Lfstevens (talk) 03:23, 8 February 2014 (UTC)

Default rounding

There is currently an error in the default rounding: {{convert|30|K|C}} gives 30 K (−243.2 °C), but it should round the Celsius values to whole numbers. --JorisvS (talk) 17:10, 13 February 2014 (UTC)

The work done by the old templates is now performed by a module, so the first question is whether the module does what the old templates did. The following shows the answer is "yes", and the result is intentional:

• {{convert|30|K|C}} → 30 K (−243.2 °C)
• {{convert/old|30|K|C}} →

I'm not sure of the reasoning, but I think the idea is that at very low temperatures, a tenth of a degree is a big deal, and by default, extra precision is applied. At any rate, the documentation (Template:Convert/doc#Rounding) says:

An exception to this is temperature, wherein the conversion will be rounded either to precision comparable to that of the input value or to that which would give three significant figures when expressed in kelvins, whichever is more precise.

So 30 K is interpreted as 30.0 K, and that requires the precision in −243.2 °C.

I don't know if that background is satisfying, but any set of rules for specifying a default for how rounding is performed will produce unexpected results in some situations. Johnuniq (talk) 20:39, 13 February 2014 (UTC)

km2 to sqmi

I'm probably doing something stupid here, but

• {{convert|1|km2|sqmi}} gives 1 square kilometre (0.39 sq mi)
• {{convert|1|sqmi|km2}} gives 1 square mile (2.6 km²)
• {{convert|300000|km2|sqmi}} gives 300,000 square kilometres (120,000 sq mi)

http://calculator-converter.com/converter_square_kilometers_to_square_miles_calculator.php says that

• one km2 equals 0386 sqmi
• one sqmi equals 2.59 km2

OK, but it says that

• 300,000 km2 equals 115,830.648 square miles.

I observe that 300,000 * 0.39 = 117,800
and that 300,000 / 120,000 = 2.50

????? Wtmitchell (talk) (earlier Boracay Bill) 14:39, 10 February 2014 (UTC)

this template is rounding the output in an attempt to match the precision of the input,

• {{convert|1.00000000000|km2|sqmi}} gives 1.00000000000 square kilometre (0.38610215854 sq mi)
• {{convert|1.00000000000|sqmi|km2}} gives 1.00000000000 square mile (2.5899881103 km²)
• {{convert|300000|km2|sqmi|sigfig=9}} gives 300,000 square kilometres (115,830.648 sq mi)

Frietjes (talk) 15:00, 10 February 2014 (UTC)

It does not seem reasonable to me that

• {{convert|299999|km2|sqmi}} gives 299,999 square kilometres (115,830 sq mi)
• {{convert|300000|km2|sqmi}} gives 300,000 square kilometres (120,000 sq mi)
• {{convert|300001|km2|sqmi}} gives 300,001 square kilometres (115,831 sq mi)

I would have thought that 299999, 300000, and 300001 were all expressed to the same precision.

It seems to me that this template violates the principle of least astonishment in some cases. Wtmitchell (talk) (earlier Boracay Bill) 23:21, 10 February 2014 (UTC)

300000 has an implied precision of only one digit, while the others have an implied precision of 6 digits. If you wanted 300000 to be treated as the same degree of precision one can write:

• {{convert|300000.|km2|sqmi}} gives 300,000 square kilometres (115,831 sq mi)

The treatment of 300,000 is much less astonishing (in my opinion) than converting 300,000 as if it had 6 digit precision, since most of the time when someone writes a lot of zeros they are not intended to be precise digits. Dragons flight (talk) 23:35, 10 February 2014 (UTC)

See also: significant figures. Dragons flight (talk) 23:38, 10 February 2014 (UTC)

Scary.

This, by the way, grew out of a real-world case here on Wikipedia. The List of sovereign states and dependent territories by population density article used (still uses, though that may change soon) the total area figure for the Philippines taken from the geography section of this CIA World Factbook page (total area is given there as 300,000 sq km, vs. 298,170 sq km for land area). I was updating the {{Popdens}} template used by that article to convert from km2 to sqmi directly instead of using template:convert, and was astonished when the sqmi figure changed from 120,000 to 115,831. Wtmitchell (talk) (earlier Boracay Bill) 02:00, 11 February 2014 (UTC)

The behavior described above is standard in an academic context. The rules of significant figures are a standard high school-level science class concept. Under those rules, 300,000 only has one sig fig (the 3) unless its trailed by a decimal point to indicate all of the zeroes are significant. The implication is that the measurement is rounded off to the nearest hundred thousand of precision, but 299,999 means the measurement has been rounded to the nearest single unit. 300,000.0 implies a measurement rounded to the nearest tenth as all trailing zeroes after the decimal are significant (or else they'd be dropped). The template is just applying these rules as a default. Imzadi 1979 → 02:51, 11 February 2014 (UTC)

If I were writing, I might say "300,000 sq km is approximately equal to 120,000 sq mi", or "roughly equal to", or "~120,000". I would certainly give some indication that the conversion was approximate. I would not give an inaccurate approximation with no indication that accuracy had been sacrificed. Perhaps this template needs a parameter like |approx=on, defaulted to off. Wtmitchell (talk) (earlier Boracay Bill) 13:06, 11 February 2014 (UTC)

Per Imzadi1979, the number of zeroes indicates the precision. Hawkeye7 (talk) 21:15, 11 February 2014 (UTC)

In technical and scientific fields, when you write "300,000 sq km", it is assumed that you mean "approximately 300,000 sq km" unless you specify otherwise. "Approximately 300,000 sq km is equal to approximately 120,000 sq mi". As convert shows, and MOSNUM requires, the precision of a number should remain similar when converting between different units. Dragons flight (talk) 17:19, 13 February 2014 (UTC)

• Engineering versus math/computer science: Many people have been shocked during the past 6 years at {convert}'s level of auto-rounding of amounts, which is a typical engineering viewpoint, where a math viewpoint tends to retain all digits. Hence, Wtmitchell is not alone in being astonished by the "over-rounding" and each year, we have reduced the auto-rounding done by {convert} to have better "number sense" and higher default precision. A scan of live pages has confirmed when users put trailing zeroes "0,000" then they almost always mean "approximate". However, {convert} ranges now use smart-rounding of both numbers, considered together, as with:

• {{convert|300,000|and|298,170|km2|sqmi}} of land → 300,000 and 298,170 square kilometres (115,830 and 115,120 sq mi) of land

Notice how the inclusion of the more-precise "298,170" causes the {convert} range to re-think the rounding of the first number. Ideally, in text, {convert} would compare nearby numbers and use the more-precise rounding; however, Wikipedia currently has primitive software which has hindered passing data between templates for 4 years, so today one usage of {convert} cannot "talk" to the other {convert}, and each sets precision separately. Instead with {convert} ranges, then both numbers are compared, and the smart-rounding is applied to treat "300,000" as 5 significant digits (same as "298,170"). Perhaps 20 years from now, WP will have sophisticated software where templates could talk to each other, read the surrounding text (or type of article), and the text could be judged for logical coherence. Anyway, thank you for returning from the future, to remind us how smart conversions will look 20 years from now! Meanwhile, we will keep trying to improve the auto-rounding of amounts. -Wikid77 (talk) 06:08, 20 February 2014 (UTC)