Is it possible to incorporate a new parameter in this template to round the result to a certain decimal point? For example, precision=0 would round to the nearest whole number, precision=1 to the nearest tenth, precision=2 to the nearest hundredth, etc. Cheers, Hwy43 ( talk) 06:32, 6 June 2013 (UTC)
I have been working on a version in the sandbox which uses module:convert. the output is nearly identical (see Template:Pop density/testcases), with the following exceptions (1) space between the slash and the number, (2) some slight differences in precision in some cases. any input or suggestions or changes which improve things are more than welcome. 108.73.25.49 ( talk) 15:52, 28 December 2013 (UTC)
- nice work! I created a lua version, which is output-identical in all the documented cases. it only supports sqmi and km2 density at the moment, and "falls back" to the old version for other area units with a tracking category. I saved the old version in the sandbox for the moment for comparison. a simple module:convert frontend would be better, but until we can support the issues you identified (or discuss if they are actually problems), this seems to be the least-controversial option. let me know if you spot any problems, or have any suggestions for improving the module. Frietjes ( talk) 17:04, 30 December 2013 (UTC)
Is there a template that can display the data in table format? For example, if you input "{{<template>|10|5}}" it would output "10||5||2". Doesn't even need units since they can be stated in the column headers. -- Lasunncty ( talk) 22:19, 29 January 2017 (UTC)
One more request: Can we make the cells be right-aligned? -- Lasunncty ( talk) 07:47, 13 April 2019 (UTC)
I've noticed a strange problem with the rounding in this template. If you look at my table below, for some reason it sorts opposite if the densities are very close. Is there any solution to this? Thanks! Mattximus ( talk) 14:12, 17 November 2018 (UTC)
| Name | Type | Government type | County | Population (2010) |
Population (2000) |
Change (%) | Land area (2010) |
Population density | |
|---|---|---|---|---|---|---|---|---|---|
| sq mi | km2 | ||||||||
| Kline | Town | Mayor-council | Barnwell | 197 | 238 | −17.2% | 3.11 | 8.1 | 63.3/sq mi (24.5/km2) |
| Lane | Town | Mayor-council | Williamsburg | 508 | 585 | −13.2% | 3.95 | 10.2 | 128.6/sq mi (49.7/km2) |
| Lodge | Town | Mayor-council | Colleton | 120 | 114 | +5.3% | 3.14 | 8.1 | 38.2/sq mi (14.8/km2) |
| Lowrys | Town | Mayor-council | Chester | 200 | 207 | −3.4% | 3.16 | 8.2 | 63.3/sq mi (24.4/km2) |
- Mattximus, I have added a "sort key" with 2 digits higher precision than the main output unit. Frietjes ( talk) 14:47, 17 November 2018 (UTC)
@ Frietjes: As I understand it, the recent edit means that all instances of {{ Pop density}} will output a hidden sort key where none was present before. That is breaking the infobox at India because it has
- | population_density_km2 = {{Pop density|{{Indian population clock}}|3287263|km2|disp=num|prec=1}}
which (I assume) is being passed to {{
convert}} by {{
Infobox country}}. Convert chokes on the span of the sort key. I don't know why
Category:Convert errors is only showing one error (India). Perhaps others will occur when pages are purged, or perhaps
India is using the template in a non-standard way? By the way, if you edit the module, you might delete = nil, nil, nil because standard usage is to assume an undefined variable contains nil.
Johnuniq (
talk) 00:54, 18 November 2018 (UTC)
- Johnuniq, I think only Hilldale, Lancashire and India were the only ones. I moved to sortkey prefix inside the various if statements and will work on cleaning up the code a bit next. thank you. Frietjes ( talk) 14:23, 18 November 2018 (UTC)
Not sure what to do about this now that this module is protected only to template editors, so commenting here: the use of rnd() inside the generation of the sortkey breaks sorting, since it puts a formatted number (with commas) inside the sortkey. This means that, for example, in
a table I'm working on, the sort by density is broken because it's just sorting alphabetically. It seems like the solution is not to use rnd() when generating the sortkey so that it just generates a number, but I can't try this myself.
David Baron (
talk) 22:35, 26 April 2019 (UTC)
OK, now that's been fixed (thanks!), but it's still sorting wrong. I think it's likely because of the problem that the unit conversion generates two sortkeys. (I was hoping the table sorting would just pick the first one, but that doesn't seem to be the case.) Perhaps the converted value needs to not insert a second sortkey. David Baron ( talk) 18:23, 27 April 2019 (UTC)
- David Baron, yes, I noticed that the change didn't fix the problem, but didn't have a chance to fix it yesterday. I have switched the module to use Module:Sortkey to generate the sortkey, which should be more consistent with other templates/modules. Frietjes ( talk) 13:34, 28 April 2019 (UTC)