Template talk:Infobox settlement/areadisp

Infobox settlement
Infobox settlement
Area
• City	10,000 sq mi (30,000 km2)
• Land	1,000 sq mi (3,000 km2)
• Water	100 sq mi (300 km2)
• Urban	10 sq mi (30 km2)
• Rural	1 sq mi (3 km2)
• Metro	0.1 sq mi (0.3 km2)
• blank1	0.01 sq mi (0.03 km2)
• blank2	0.001 sq mi (0.003 km2)

Removal of cases from switch

The 5 templates "mentioned" in the switch statement are actually being "used", I.E. transcluded in every article that has both kn and mi, up to 7 time for a maximum of 35 top level transclusions per page, but up to 3 or more times that as at least the following are called:

Template:Country data USA (edit) (protected)
Template:Country data United Kingdom (edit) (protected)
Template:Country data United States (edit) (protected)
Template:Country flag2 (edit) (protected)
Template:Country flagicon2 (edit) (protected)
Template:CountryAbbr (edit) (protected)
Template:Flag (edit) (protected)
Template:Flagicon (edit) (protected)
Template:UK (edit) (protected)
Template:USA (edit) (protected)

Given an occurrence of items that transclude this page is about 100,000 this is a high cost. The number of "badly formed" articles is about 3000, I porpose to add unit_pref = Imperial to these articles, where they don't already have it (which will be most cases), and remove the template matches. I could fix up the subdivison_name, but it would be swimming through treacle. Rich Farmbrough, 05:48, 1 May 2010 (UTC).[reply]

If you have the time and patience to do it, then go for it. By the way, there was some resistance to the use of the word "Imperial" for feet and square miles, since Imperial units is something else. I believe we have an alternative name? Plastikspork _―Œ^(talk) 15:08, 1 May 2010 (UTC)[reply]

Zero acres returned when ha is 1 or 10 or 100 (may be other instances)

Hard (impossible!) to know where it's going wrong. Could be in the precision.
As a matter of interest, why is #expr used rather than convert - that will do everything in one line - conversion from any to appropriate units, with display, and rounding? Johnmperry (talk) 01:01, 15 November 2012 (UTC)[reply]

the problem is with using template:precision, see Template talk:Precision#Bug?. I have asked for help from someone who knows that template. Frietjes (talk) 01:18, 15 November 2012 (UTC)[reply]

{{convert}} is both expensive and slow - it's easy to take the page beyond the template limits with just one apparently-simple calculation. I have seen the transclusion depth of a page change by about fifteen levels by the simple addition of one parameter to {{convert}}. Where the units to convert from and to are known in advance, and are unlikely to change, the parser function {{#expr:}} is far more efficient. --Redrose64 (talk) 09:57, 15 November 2012 (UTC)[reply]

I don't understand why on line 46 the precision of the input is reduced on output. Why wouldn't we want both the same? (particularly since acres are smaller than hectares). I don't know how to test this (nor want to know). Other cases also invoke Order of magnitude, but that seems to be inferring that an input which is an exact multiple of 10 (100, 1000 ...) has already been rounded by inputter. Kind of second-guessing.

And from an efficiency point of view, isn't division much slower (hungrier) than multiplication? So why is the input divided by a constant rather than multiplied by one? Johnmperry (talk) 00:37, 16 November 2012 (UTC)[reply]

The difference between relative speeds of mathematical operators is negligible compared to the time spent expanding templates and parsing parameters. I'm going to drop a note on Jimp (talk · contribs) who wrote most of this. --Redrose64 (talk) 09:55, 16 November 2012 (UTC)[reply]

yes, the issue is definitely with parsing/expanding the expressions. the cost of a flop is going to be nothing compared the the cost of the text processing. and, we aren't really concerned about "cost" as we are with the limits imposed by MediaWiki on expression depth. we should see how expensive this template is compared to convert though to assess if switching to convert is feasible. Frietjes (talk) 21:16, 16 November 2012 (UTC)[reply]

It was over-rounding the conversion. It's fixed. JIMp_talk·cont 02:36, 17 November 2012 (UTC)[reply]

Edit request: Fix over-rounding in conversion of square miles to km2

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

While updating the documentation for this template, I noticed it is over-rounding the conversion of square miles to square kilometres, such that an area of 10,000 sq mi displays 0 km² as the conversion (see examples to the right). This is similar to the recently fixed problem with conversion of hectares to acres and can be fixed the same way, by removing "-1" in the following portion of Template:Infobox settlement/areadisp:

|{{rnd<!-- convert square miles to square kilometres -->
   |{{#expr:{{formatnum:{{{sqmi}}}|R}}*2.589988110336}}
   |({{precision|{{formatnum:{{{sqmi}}}|R}}}}-1)
 }}<!-- end rnd -->

I have implemented the suggested correction at Template:Infobox settlement/areadisp/sandbox (diff) and provided multiple test cases at Template:Infobox settlement/areadisp/testcases. -- Zyxw (talk) 00:19, 5 February 2013 (UTC)[reply]

Done! Plastikspork _―Œ^(talk) 00:04, 17 February 2013 (UTC)[reply]

Thanks! -- Zyxw (talk) 10:25, 17 February 2013 (UTC)[reply]

Conversion error

I've noticed that when area_total_km2 and area_land_km2 is automatically converted to square miles, something odd is happening. In KM2, area total can be larger than area land. But once converted into sq mi, area land becomes larger than area total.

You can see this in action at Borough of Halton.

I can only think it must be something hard coded in the conversion, perhaps a rounding error. Perhaps someone more knowledgeable than me will know what might be behind it please? Dgp4004 (talk) 23:34, 9 June 2024 (UTC)[reply]