Template talk:Precision

New code

{{editprotected}}

Please replace the current code with the following.

{{precision/a|{{{1}}}|{{#titleparts:{{{1}}}|1|2}}}}

This will have two positive effects.

1. It will fix a recently noticed bug in the template.
2. It will allow for the template to handle fractions.

JIMp _talk·cont 00:03, 10 August 2009 (UTC)

The bug

During a discussion on WT:MOSNUM a bug was discovered in {{convert}}. The bug was tracked down here via further discussion on Template talk:Convert. Here is the bug.

{{precision|4.70000}} 5	{{precision|47.0000}} 4	{{precision|470.0000}} 4	{{precision|4700.0000}} 4
{{precision|4.7000}} 4	{{precision|47.000}} 3	{{precision|470.000}} 3	{{precision|4700.000}} 3
{{precision|4.700}} 3	{{precision|47.00}} 2	{{precision|470.00}} 2	{{precision|4700.00}} 2
{{precision|4.70}} 2	{{precision|47.0}} 1	{{precision|470.0}} 1	{{precision|4700.0}} 1
{{precision|4.7}} 1	{{precision|47}} 0	{{precision|470}} -1	{{precision|4700}} -2

JIMp _talk·cont 00:03, 10 August 2009 (UTC)

Fractions

The automatic rounding function on {{convert}} cannot handle fractions. This new code will be Step 1 of the solution to this problem.

JIMp _talk·cont 00:03, 10 August 2009 (UTC)

Sandbox and test cases

{{precision/sandbox|4.70000}} 5	{{precision/sandbox|47.0000}} 4	{{precision/sandbox|470.0000}} 4	{{precision/sandbox|4700.0000}} 4
{{precision/sandbox|4.7000}} 4	{{precision/sandbox|47.000}} 3	{{precision/sandbox|470.000}} 3	{{precision/sandbox|4700.000}} 3
{{precision/sandbox|4.700}} 3	{{precision/sandbox|47.00}} 2	{{precision/sandbox|470.00}} 2	{{precision/sandbox|4700.00}} 2
{{precision/sandbox|4.70}} 2	{{precision/sandbox|47.0}} 1	{{precision/sandbox|470.0}} 1	{{precision/sandbox|4700.0}} 1
{{precision/sandbox|4.7}} 1	{{precision/sandbox|47}} 0	{{precision/sandbox|470}} -1	{{precision/sandbox|4700}} -2

I created a sandbox and testcases page. Could you check to make sure this is the desired result, and if not, edit the sandbox to get the desired result? Thanks! Plastikspork (talk) 00:42, 10 August 2009 (UTC)

It is the desired result. JIMp _talk·cont 00:58, 10 August 2009 (UTC)

This type of template code is mostly magic to me, but on the test cases page, I notice on lines 6, 7 and 8, that the new code indicates six decimal places, even though the examples are, respectively, 8, 7 and 6 decimal places in length. Not sure what to make of that. — Huntster (t • @ • c) 01:02, 10 August 2009 (UTC)

Both versions have problems when the string is too long it appears. I'm not sure if this is fixable. Plastikspork (talk) 01:04, 10 August 2009 (UTC)

Well, since this appears to solve the immediate problem, I've gone ahead and installed the fix. If Jimp finds a solution to the extended problem later on, it can be installed then. — Huntster (t • @ • c) 01:07, 10 August 2009 (UTC)

Thanks. Now the next step is to transfer all calls of the old {{precision/+}} over to {{precision}} in the {{convert}} subspace but there'll be brackets to move. JIMp _talk·cont 01:54, 10 August 2009 (UTC)

More new code

{{editprotected}}

I've rewritten the code for {{precision/1}}.

The effects are simulated on Template:precision/testcases. There is improved handling of large numbers of sig figs.

New Template:Precision/1 (edit | talk | history | links | watch | logs)

<includeonly>{{precision/1b|{{{1}}}|{{#expr:{{{1}}}3-{{{1}}}}}}}</includeonly><noinclude>calls {{lt|precision/1b}}</noinclude>

JIMp _talk·cont 02:34, 14 August 2009 (UTC)

 Done It does look like an improvement. Let me know if there are any problems. Plastikspork (talk) 05:23, 14 August 2009 (UTC)

I suspect this is what killed all the {{convert}} usage in infoboxes when using decimal numbers. Will revert for now. —TheDJ (talk • contribs) 12:30, 14 August 2009 (UTC)

Those pages are repaired now, so this was responsible in some way. I'm not sure what exactly caused the problem however. It seems rather... obscure. —TheDJ (talk • contribs) 12:45, 14 August 2009 (UTC)

That's strange. JIMp _talk·cont 13:04, 14 August 2009 (UTC)

Strange indeed as it didn't show up in the testcases. Thanks for sorting that out. Plastikspork (talk) 15:34, 14 August 2009 (UTC)

I'm beginning to suspect that old {{precision/+}} had some disagreement with the new {{precision/1}} ... dunno what tho. JIMp _talk·cont 15:42, 14 August 2009 (UTC)

Created

The math utility Template:Getprecision was created by long-term user Wikid77 on 15 August 2010, with testing by User:WOSlinker, to get the decimal precision of negative or positive numbers. The original need was to find the precision of a temperature when converting negative temperature amounts. -Wikid77 (talk) 09:47, 4 September 2010 (UTC)

Handling decimals below 1

{{editprotected|Template:Getprecision}} This template needs to be updated, from Template:Getprecision/sandbox, to handle decimal amounts less than 1 (such as 0.542 having precision 3 not 6). The sandbox version has the corrected calculation, plus new internal comments explaining the algorithms used. IMPACT: Only about 4,070 pages use this template, mostly for converting negative temperature amounts. Once updated, all of the current results should match the expected:

• Expected: {{getprecision/sandbox|0.542}} → 3
• Currently: {{getprecision/sandbox|0.542}} → {{getprecision/sandbox|0.542}}
• Expected: {{getprecision|0.542}} → 3
• Currently: {{getprecision|0.542}} → {{getprecision|0.542}}
• Expected: {{getprecision|0.1234}} → 4
• Currently: {{getprecision|0.1234}} → {{getprecision|0.1234}}
• Expected: {{getprecision|0.88}} → 2
• Currently: {{getprecision|0.88}} → {{getprecision|0.88}}
• Expected: {{getprecision| 65.88}} → 2
• Currently: {{getprecision| 65.88}} → {{getprecision|65.88}}

After updating {getprecision}, all amounts should match. -Wikid77 (talk) 09:47, 4 September 2010 (UTC)

 Done. Thanks for fixing the issue. -- WOSlinker (talk) 15:50, 4 September 2010 (UTC)

Comparison to Template:Precision

Initially, the Template:Getprecision was created to avoid problems with Template:Precision, as used for most numeric conversions in Template:Convert. There were 2 major issues: {Precision} did not handle negative numbers, and {Precision} often invoked 3 subtemplates (hitting the parser limit of 40 nested expressions). However, {Getprecision} uses 4 other templates, as 1 more than {Precision} uses.

Currently, these are comparisons:

n → {{getprecision|n}}	{{precision|n}}
0.00 → {{getprecision|0.00}}	2
5.01 → {{getprecision|5.01}}	2
5.007 → {{getprecision|5.007}}	3
-5.01 → {{getprecision|-5.01}}	2
-5.007 → {{getprecision|-5.007}}	3
0.01 → {{getprecision|0.01}}	2
-0.007 → {{getprecision|-0.007}}	3
5.407 → {{getprecision|5.407}}	3
5.68E+03 → {{getprecision|5.58E+03}}	-1
2.654E+09 → {{getprecision|2.654E+09}}	-6
2.654001E+23 → {{getprecision|2.654001E+23}}	-17
0.1234567 → {{getprecision|0.1234567}}	7
0.1234567890 → {{getprecision|0.1234567890}}	10
0.123456789012 → {{getprecision|0.123456789012}}	12
0.123456789012345 → {{getprecision|0.123456789012345}}	15
4.123456789012345 → {{getprecision|4.123456789012345}}	15

The older, Template:Precision, could not handle negative numbers, and then had trouble when a number had more than 12 decimal digits after the decimal point.

Templates used by Template:Getprecision (often 5):

• Template:Getprecision (protected)
• Template:Order of magnitude (protected)
• Template:Order of magnitude/x (protected)
• Template:Str len (protected)
• Template:Str len/core (protected)

Templates used by Template:Precision (often 4):

• Template:Precision (protected)
• Template:Precision/-11 (protected)
• Template:Precision/1 (protected)
• Template:Precision/a (protected)

• Template:Precision/-10
• Template:Precision/-20
• Template:Precision/-31
• Template:Precision/0 (protected)
• Template:Precision/00 (protected)
• Template:Precision/01 (protected)
• Template:Precision/10 (protected)

The 3 typical subtemplates used by Template:Precision are: {Precision/a}, {Precision/1} and {Precision/-11}, for moderate decimal amounts. The other subtemplates are used, instead, depending on the size of the number, where larger numbers use different subtemplates (such as Template:Precision/-10). Note that {Precision} typically uses 4 templates, whereas {Getprecision} often uses 5. -Wikid77 (talk) 16 November, revised 01:34, 17 November 2010 (UTC)

Consider 1 fewer nest level

There have been more cases where Convert is dying due to hitting the 40-level nesting limit, due to extra nesting in infoboxes or doc-page examples. For the present, the very efficient Template:Precision can be reduced by 1 nest-level (from using 4 templates to 3) by combining the contents of Template:Precision/a, where parameter {2} would be expanded as a #titleparts function:

• OLD: {{#if:{{{2|}}}|{{#expr:(ln{{{2}}})/ln10}}|{{#expr:{{precision/{{#expr:3*{{{1}}}>{{{1}}}0}}|{{{1}}}}}}}}}
• NEW: {{#if:{{{hasfraction|{{#titleparts:{{{1}}}|1|2}}}}}|{{#expr:(ln{{#titleparts:{{{1}}}|1|2}})/ln10}}|{{#expr:{{precision/{{#expr:3*{{{1}}}>{{{1}}}0}}|{{{1}}}}}}}}}

That expanded template coding, replacing the two instances of {2}, would become the new contents of {Precision}, and we could bypass template {Precision/a} as 1 less level of nesting. Unlike parser function {formatnum:27}, the "#titleparts" function must have prefix "#" with the name. Fractions are detected by finding "/":

• EXAMPLE FRACTION: {{#if:{{{hasfraction|{{#titleparts:{{{1|1+3/16}}}|1|2}}}}}|{{#expr:(ln{{#titleparts:{{{1|1+3/16}}}|1|2}})/ln10}}|{{#expr:{{precision/{{#expr:3*{{{1|1+3/16}}}>{{{1|1+3/16}}}0}}|{{{1|1+3/16}}}}}}}}}
• EXAMPLE FRACTION (result above): {{#if:{{#titleparts:1+3/16|1|2}}|{{#expr:(ln{{#titleparts:1+3/16|1|2}})/ln10}}|{{#expr:{{precision/{{#expr:3*1+3/16>1+3/160}}|1+3/16}}}}}}
• EXAMPLE FRACTION {{precision}}: 1.2041199826559

Simple decimals have no "/" slash:

• EXAMPLE DECIMAL: {{#if:{{{hasfraction|{{#titleparts:{{{1|73.456}}}|1|2}}}}}|{{#expr:(ln{{#titleparts:{{{1|73.456}}}|1|2}})/ln10}}|{{#expr:{{precision/{{#expr:3*{{{1|73.456}}}>{{{1|73.456}}}0}}|{{{1|73.456}}}}}}}}}
• EXAMPLE DECIMAL (result above): {{#if:{{#titleparts:73.456|1|2}}|{{#expr:(ln{{#titleparts:73.456|1|2}})/ln10}}|{{#expr:{{precision/{{#expr:3*73.456>73.4560}}|73.456}}}}}}
• EXAMPLE DECIMAL {{precision}}: 3

The speed and efficiency of Template:Precision will be almost unchanged becaused most amounts, in actual use, do not contain fractions and will be processed in #titleparts only one time. In articles, fraction conversions are relatively rare, so running #titleparts twice will only occur for those rare fractions, and no delay will be seen.

I dread that people (especially volunteers) have to penny-pitch resources this way, but it takes time for a bureaucracy to make improvements, even to fix the most crucial of underlying resource limitations, such as the expression-nesting limit as only 40 deep. Also, it is good practice to modify Template:Precision, in preparation for making any future improvements. -Wikid77 (talk) 18:20, 16 November 2010 (UTC)

More test cases

The following are test cases involving negative numbers, and decimal amounts between 0-1, plus scientific notation (if needed). The majority of negative numbers are converted, perhaps, as negative temperatures, handled by Template:Getprecision as an interim solution.

Currently, these are comparisons:

n → {{precision|n}}	{{precision/sandbox}}	Expected
5.01 → 2	2
5.007 → 3	3
-5.01 → 2	2	2
-5.007 → 3	3	3
0.01 → 2	2	2
-0.007 → 3	3	3
5.407 → 3	3	3
5.68E+03 → -1	-1	2
2.654E+09 → -6	-6	3
2.614001E+23 → -17	-17	6
0.1234567 → 7	7	7
0.123456789012 → 12	12	12
0.1234567890123 → 13	13	13
0.123456789012345 → 15	15	15
4.123456789012345 → 15	15	15

During mid 2009, Template:Precision could not handle negative numbers, and then had trouble when a number had more than 12 decimal digits after the decimal point (although no actual use over 13 digits had been reported). -Wikid77 (talk) 01:57, 17 November 2010 (UTC)

Fix Getprecision for negative rounding and fractions

{{editprotected|Template:Getprecision}}
03-Jan-2011: Template:Getprecision needs to be updated from Template:Getprecision/sandbox to also handle negative rounding and fractions (2+1/3). Specifically, 150 should show as "-1" rounding, or 2300 as "-2" or 23,000 as "-3" , etc. Plus, a fraction such as 38+1/125 should show as "3" because the denominator 125 has 3 digits.
A wide variety of test-cases are listed in the table below. This change was developed over 2 months, to allow more time to be sure it works correctly. IMPACT: It is used for negative temperatures in Template:Convert.

n → {{getprecision|n}}	{{getprecision/sandbox|n}}	Notes
0.00 → {{getprecision|0.00}}	{{getprecision/sandbox|0.00}}	no newline here.
5.007 → {{getprecision|5.007}}	{{getprecision/sandbox|5.007}}	most commmon form
150 → {{getprecision|150}}	{{getprecision/sandbox|150}}	fixed in year 2011
2300 → {{getprecision|2300}}	{{getprecision/sandbox|2300}}	fixed in year 2011
23000 → {{getprecision|23000}}	{{getprecision/sandbox|23000}}	fixed in year 2011
46000000 → {{getprecision|46000000}}	{{getprecision/sandbox|46000000}}	fixed in year 2011
4600000000000 → {{getprecision|4600000000000}}	{{getprecision/sandbox|4600000000000}}	astronomical amount, but works
38+1/125 → {{getprecision|38+1/125}}	{{getprecision/sandbox|38+1/125}}	fixed in year 2011
-5.01 → {{getprecision|-5.01}}	{{getprecision/sandbox|-5.01}}
0.01 → {{getprecision|0.01}}	{{getprecision/sandbox|0.01}}
-0.007 → {{getprecision|-0.007}}	{{getprecision/sandbox|-0.007}}
-0.00400 → {{getprecision|-0.00400}}	{{getprecision/sandbox|-0.00400}}	{Precision} did not handle negatives
5.407 → {{getprecision|5.407}}	{{getprecision/sandbox|5.407}}
12+6/100 → {{getprecision|12+6/100}}	{{getprecision/sandbox|12+6/100}}	6/100, fractions only <1% of use
98+1/2 → {{getprecision|98+1/2}}	{{getprecision/sandbox|98+1/2}}	1/2 is common fraction
5.68E+3 → {{getprecision|5.58E+3}}	{{getprecision/sandbox|5.68E+3}}	(not used)
2.654001E+23 → {{getprecision|2.654001E+23}}	{{getprecision/sandbox|2.654001E+23}}	(not used)
0.1234567 → {{getprecision|0.1234567}}	{{getprecision/sandbox|0.1234567}}	rare, but possible
0.1234567890 → {{getprecision|0.1234567890}}	{{getprecision/sandbox|0.1234567890}}
0.123456789012 → {{getprecision|0.123456789012}}	{{getprecision/sandbox|0.123456789012}}
0.123456789012345 → {{getprecision|0.123456789012345}}	{{getprecision/sandbox|0.123456789012345}}
4.123456789012345 → {{getprecision|4.123456789012345}}	{{getprecision/sandbox|4.123456789012345}}

The table lists a wide variety, of numeric types, which ensures that the new sandbox version of {Getprecision} works correctly before being updated. -Wikid77 (talk) 16:38, 20 November 2010 (UTC), revised 14:31, 3 January 2011 (UTC)

Done Dabomb87 (talk) 03:05, 4 January 2011 (UTC)

Fix Getprecision for negative hundreds

{{editprotected|Template:Getprecision}}
06-Feb-2011: Template:Getprecision needs to be updated from Template:Getprecision/sandbox to fix the precision counts for negative hundreds and similar. Specifically, -300 should show as "-2" rounding, -150 should show as "-1" rounding, or -23,000 as "-3" , etc.
A wide variety of test-cases are listed in the table below, to show the expected results. This change was developed over 1 week, to allow more time to be sure it works correctly. IMPACT: It is used for negative temperatures in Template:Convert.

n → {{getprecision|n}}	{{getprecision/sandbox|n}}	Notes
0.00 → {{getprecision|0.00}}	{{getprecision/sandbox|0.00}}	no newline here.
5.007 → {{getprecision|5.007}}	{{getprecision/sandbox|5.007}}	most commmon form
-150 → {{getprecision|-150}}	{{getprecision/sandbox|-150}}	with 1 end-zero
-300 → {{getprecision|-300}}	{{getprecision/sandbox|-300}}	with 2 end-zeroes
-2300 → {{getprecision|-2300}}	{{getprecision/sandbox|-2300}}
-23,000 → {{getprecision|-23000}}	{{getprecision/sandbox|-23000}}	with 3 end-zeroes
-460000000000000 → {{getprecision|-460000000000000}}	{{getprecision/sandbox|-460000000000000}}	has 13 zeroes
38+1/125 → {{getprecision|38+1/125}}	{{getprecision/sandbox|38+1/125}}	fixed in year 2011
-5.01 → {{getprecision|-5.01}}	{{getprecision/sandbox|-5.01}}
0.123456789012345 → {{getprecision|0.123456789012345}}	{{getprecision/sandbox|0.123456789012345}}
4.123456789012345 → {{getprecision|4.123456789012345}}	{{getprecision/sandbox|4.123456789012345}}

The table lists a variety, of numeric types, to ensure that the new sandbox version of {Getprecision} works correctly before the update is made. -Wikid77 (talk) 17:14, 6 February 2011 (UTC)

Would you mind if I moved your "notes" to the template's documentation? A few well-placed notes can aid code readability, but this significantly adds to the length of the template and seems excessive. — Martin (MSGJ · talk) 17:24, 7 February 2011 (UTC)

You didn't reply so I went ahead and removed the notes. (Hope you don't mind!)

 updated. — Martin (MSGJ · talk) 16:56, 8 February 2011 (UTC)

Fix Getprecision to restore explanatory comments

{{editprotected}}
10-Feb-2011: Template:Getprecision needs to be updated from Template:Getprecision/sandbox to restore the internal comments which explain the template's operation, using internal footnotes about the algorithms used. Previously, the internal footnote comments had been moved separately to the /doc page, and as predicted, they no longer matched the actual coding of the template, after only 1 day of being separated. IMPACT: Getprecision is used for temperatures in Template:Convert.

n → {{getprecision|n}}	{{getprecision/sandbox|n}}	Notes
0.00 → {{getprecision|0.00}}	{{getprecision/sandbox|0.00}}	no newline here.
5.007 → {{getprecision|5.007}}	{{getprecision/sandbox|5.007}}	most commmon form
-150 → {{getprecision|-150}}	{{getprecision/sandbox|-150}}	with 1 end-zero
-300 → {{getprecision|-300}}	{{getprecision/sandbox|-300}}	with 2 end-zeroes
400 → {{getprecision|400}}	{{getprecision/sandbox|400}}	also 2 end-zeroes
-2300 → {{getprecision|-2300}}	{{getprecision/sandbox|-2300}}
-23,000 → {{getprecision|-23000}}	{{getprecision/sandbox|-23000}}	with 3 end-zeroes
-460000000000000 → {{getprecision|-460000000000000}}	{{getprecision/sandbox|-460000000000000}}	has 13 zeroes
38+1/125 → {{getprecision|38+1/125}}	{{getprecision/sandbox|38+1/125}}	fixed in year 2011
-5.01 → {{getprecision|-5.01}}	{{getprecision/sandbox|-5.01}}
0.123456789012345 → {{getprecision|0.123456789012345}}	{{getprecision/sandbox|0.123456789012345}}

The table lists a variety, of numeric types, to ensure that the new sandbox version of {Getprecision} still works correctly before the update is made. With the internal comments restored, now the explanation of the template's operation matches the actual template. Also, in the future, the internal comments can be updated to match changes to the markup logic during the same edits, as just 1 update, rather than the current dual maintenance problem, where separate technical notes often become outdated (and overlooked), when split between the template and /doc page. -Wikid77 17:36, 10 February 2011 (UTC)

Done. Plastikspork _―Œ^(talk) 04:31, 12 February 2011 (UTC)

Four precision templates

As of this moment we have four rival precision templates:

1. {{precision}},
2. {{precision/+}},
3. {{getprecision}} and
4. {{precision1}}

... two .. or three too many ... but not for long. It's time for a merge. I've seen enough. My infernal towering template-nesting skyscraper-bottomless-pit structure (#1 & #2 (note that #2 is just an old version of #1 which just got stuck)) is no match for Wikid's go getprecision approach (#3). Some combination of software quirks & nesting limits is playing havoc with the approach I took. It's time for get something better in it's place. I'm merging the first three here. Whether or not Wikid's version is slim enough (wrt template limits) is another question ... probably is. JIMp _talk·cont 05:09, 22 June 2011 (UTC)

One thing that my version did do better was give a true measure of the precision of a fraction (i.e. the base ten logarithm of the denominator) Getprecision was rounding up. When someone says this thing is 2+3⁄4 of an inch long they mean quarter-inch precision not 0.1-inch precision. I have restored this feature. JIMp _talk·cont 15:40, 22 June 2011 (UTC)

I had to revive the old version (it's at {{precision/2010}}) because something was going wrong with the hands conversion ({{convert|11|hand}} etc. was giving error messages). My guess is that between them these two large templates blew the limit. Let's look into trimming things down. One thing that could be causing strife is the {{#switch}}. Order is important in {{#switche}}s, they're like huge nested {{#ifeq}}s. Let's put the lower numbers up the top. (Of course {{convert/hand}} needs a serious look at but that for another day.) JIMp _talk·cont 00:15, 25 June 2011 (UTC)

Bug?

I would expect the following to return a monotonic progression?

• {{precision|8}} --> 0
• {{precision|9}} --> 0
• {{precision|10}} --> -1
• {{precision|11}} --> 0
• {{precision|12}} --> 0

seems like a bug? Frietjes (talk) 17:12, 14 November 2012 (UTC)

never mind, this is not a bug. the problem that I am having is with the areadisp subtemplate of infobox settlement. Frietjes (talk) 01:30, 15 November 2012 (UTC)

No, no bug. The bug was over there. JIMp _talk·cont 12:16, 17 November 2012 (UTC)

Lua Implementation

I've written a Lua module called as {{ #invoke:Math | precision | 0.12345 }} = 5, that I believe is equivalent to this template, but I'd like people to check it to make sure it covers all the cases. Dragons flight (talk) 05:57, 21 February 2013 (UTC)

Just checked on some standard numbers & worked fine. Didn't match with the current version for E numbers. -- WOSlinker (talk) 07:30, 21 February 2013 (UTC)

n	{{precision|n}}	{{#invoke:Math | precision}}
5.68E+03	-1	-1
5680	-1	-1
2.654E+09	-6	-6
2654000000	-6	-6
2.614001E+23	-17	-17
261400100000000000000000	-17	-17
26140010000000	-7	-7
2.61E-09	11	11
0.00000000261	11	11

That should be better. I assume that messing up on the large and small values is not a goal... Dragons flight (talk) 07:59, 21 February 2013 (UTC)

Looks good now. -- WOSlinker (talk) 08:08, 21 February 2013 (UTC)

I've added a table below using some of the test cases mentioned farther up the page. Right now, the behavior if fed fractions is unpredictable for #invoke:Math. Is that actually a case that people are using? There are no examples of it on the main template page. And if it is something people care about, is natural logarithm of the denominator really the functionality that people want to see? That seems a very weird choice to me. Dragons flight (talk) 16:12, 21 February 2013 (UTC)

n → {{precision|n}}	{{precision|n}}	{{precision/sandbox |n}}
0.00 → {{precision|0.00}}	2	2
5.007 → {{precision|5.007}}	3	3
150 → {{precision|150}}	-1	-1
2300 → {{precision|2300}}	-2	-2
23000 → {{precision|23000}}	-3	-3
46000000 → {{precision|46000000}}	-6	-6
4600000000000 → {{precision|4600000000000}}	-11	-11
38+1/125 → {{precision|38+1/125}}	2.0969100130081	2.0969100130081
-5.01 → {{precision|-5.01}}	2	2
0.01 → {{precision|0.01}}	2	2
-0.007 → {{precision|-0.007}}	3	3
-0.00400 → {{precision|-0.00400}}	5	5
5.407 → {{precision|5.407}}	3	3
12+6/100 → {{precision|12+6/100}}	2	2
98+1/2 → {{precision|98+1/2}}	0.30102999566398	0.30102999566398
5.68E+3 → {{precision|5.58E+3}}	-1	-1
2.654001E+23 → {{precision|2.654001E+23}}	-17	-17
0.1234567 → {{precision|0.1234567}}	7	7
0.1234567890 → {{precision|0.1234567890}}	10	10
0.123456789012 → {{precision|0.123456789012}}	12	12
0.123456789012345 → {{precision|0.123456789012345}}	15	15
4.123456789012345 → {{precision|4.123456789012345}}	15	15
0 → {{precision|0}}	0	0

I figured a simple way to handle the fractions case and update the template to use Lua. Much faster now. Dragons flight (talk) 23:03, 22 February 2013 (UTC)

Thanks. The reason for the logarithm (base ten not e) is so that {{convert}} can give sensible readings of precision when fed fractions. You'd expect to be talking the same degree of precision, for example, whether you're talking about feet or thirds of a yard. Take 1⁄10, this is the same as 0.1 with a precision of one. 1⁄100 is 0.01 with a precision of two. 1⁄1000, 0.001, has a precision of three. So, where the denominator is a power of ten the precision is the base ten logarithm of the denominator. What, then do we do when the denominator is not base ten? Why not do the same? If by going from centimetres to millimetres you increase the precision by a factor of 1, what about when you go from yards to feet? We're comparing tenths to thirds. We've only gone a little less than half way (3² ≈ 10) so the precision of a third should be a little less than 0.5 (between 0 and 1). So that the logic behind {{convert}}'s handling of fractional input and why this template was written the way it was. JIMp _talk·cont 08:23, 25 February 2013 (UTC)

Expansion depth of getting precision

The major worry about getting numerical precision, in {Convert}, has been the wp:expansion depth limit, not the speed, because it had waited to get precision until calculations were being performed. Of course, if {Convert} had run the get-precision at the start, and passed the precision value into deeper subtemplates, then the depth of performing get-precision would not have been an issue. Anyway, the use of the #invoke interface runs only 2 levels deep, compared to running a shell template as 3 levels deep to invoke a Lua module. Here:

• {{ #invoke:Math | precision | 0.12345 }} = 5 (only 2 levels deep)

So, when depth is critical, avoid running a shell template (such as "{precision}") and use the #invoke interface directly, to use 2 levels rather than 3 (and the invoke also runs 20%-50% faster).

The reason the trivial nesting has been such a major concern is because the MediaWiki parser has not been improved, despite years of discussions, to allow more than a pitiful 41 levels of nesting, when perhaps 45 would be enough, and modern software for over 20 years has easily allowed a depth of 500 nested-logic levels (or typically an unlimited stack). The logic depth of {Convert} became a critical issue when editors started using double-nested infoboxes to combine related infoboxes within the same box border. Previously, nested infoboxes were not used, and so an infobox template typically became a "one-size-fits-all" monstrosity to replicate other infobox parameters within the one massive infobox, rather than have nested infoboxes to mix-and-match some smaller related infoboxes within the same box border, with fewer parameters processed (faster) by each separate infobox. Hence, the severely restricted 41-level has hindered many areas of Wikipedia, especially Template:Taxobox which uses nested template calls to follow 60-level nested chains of sub-taxons in the taxonomy infoboxes for biology topics. The reason the taxon templates must be nested is because the parser also has not been improved to allow resetting parameter values to store the intermediate results of prior template calls, as for example, {{#set:taxon1|{{parent|taxon1}} }}, to store the next level of taxon-chain name, by iteration along a taxon-chain, rather than nested template calls to process the same chain of sub-taxon names. Instead, the MediaWiki markup language has been artificially limited, as if a grocery store where shopping carts were not allowed and customers must hold all objects in hand until they reach the smaller limit of holding all items, when instead, some shoppers might even use 2 shopping carts to reflect real-world needs. Hence, Wikipedia has been severely crippled by multiple, horrendous design flaws in the underlying MediaWiki software, and Lua can be used to bypass the long-term limitations in nesting of wp:parser functions which, ironically, seem to run 2x-3x faster than Lua which is being used to avoid them. I have elaborated these side issues, about severe depth limits, to emphasize the impact on templates such as {Convert}, and the consequent, follow-on warping impact on infobox designs. -Wikid77 (talk) 12:46, 25 February 2013 (UTC)

Precision of real-world fractions

As noted above, the precision of fractions, also in mixed numbers, has been a need for thousands of cases with Template:Convert, such as "6+3/100" viewed as precision "2" decimal places. Currently:

• {{#invoke:Math|precision|6+3/100}} = 2 (expected 2)
• {{#invoke:Math|precision|6+3/1000}} = 3 (expected 3)
• {{#invoke:Math|precision|6+3/1}} = 0 (expected 0)
• {{#invoke:Math|precision|99+5/8}} = 3 (expected 3)
• {{#invoke:Math|precision|7+1/3}} = 13 (expected many?)
• {{#invoke:Math|precision|4+1/19}} = 13 (expected many?)

Ideally, the precision of fractions could be kept into practical proportions, although transcendental numbers can be a problem of endless precision for trailing digits. The problem of 7+1/3 as "7.33333..." or 4+1/19 as "4.0526315789474..." could be handled by recounting as precision of denominator+2, so 1/3 yields precision 2, or 1/19 yields 3. However, the imposition of practical limits should probably be done by another get-precision function with real-world limitations, since a 1⁄3 fraction cannot realistically represent infinite decimal precision of a measurement, such as 1⁄3 cup of milk, in litres, treated as 0.33 cup with precision 2. More later. -Wikid77 (talk) 12:46, 25 February 2013 (UTC)

I've added an optional flag "check_fraction=true" into the Lua module. If set to true (default is false), it will look for a fraction and return the log10 of the denominator. So:

• {{#invoke:Math|precision|4+1/19}} = 13
• {{#invoke:Math|precision|4+1/19|check_fraction=true}} = 1.2787536009528

By putting it in Lua, I can eliminate the branching here and elsewhere and shave a little off the expansion depth. That should help you a bit. Dragons flight (talk) 17:21, 25 February 2013 (UTC)

• Truncating the repeated digits: I think the "check_fraction=true" is part of the solution, where we want "1/3" to not have infinite precision of repeated digits "0.33333..." so the current result is:

• {{#invoke:Math|precision|1/3|check_fraction=true}} = 0.47712125471966

Now, for the conversion of one-third US gallon to litres, it shows:

• {{convert|1/3|USgal|L}} = 1⁄3 US gallon (1.3 L)
• {{convert|1/3|L|ml}} = 1⁄3 litre (330 ml)
• {{convert|1/8|L|ml}} = 1⁄8 litre (130 ml)
• {{convert|0.125|L|ml}} = 0.125 litres (125 ml)
• {{convert|1/20|L|ml}} = 1⁄20 litre (50 ml)
• {{convert|1/19|L|ml}} = 1⁄19 litre (53 ml)

It seems as though 1/3 litre works as 0.33 litre, so that uses precision as 2 decimal digits. In computer science, such real-world limits (related to "number sense") are noted as a "pragma" which resets performance to practical limits of the specific computer. So perhaps there could be a Lua option as "check_fraction=pragma" to force 1/3 to have precision as exactly "2" while 1/100 also has precision "2". Compare those values with the mathematical option "check_fraction=true":

• {{#invoke:Math|precision|1/3|check_fraction=true}} = 0.47712125471966
• {{#invoke:Math|precision|1/100|check_fraction=true}} = 2

By whatever means, option "check_fraction=pragma" could force 1/3 to have precision as "2" rather than "0.477~" but not interfere with the mathematical accuracy for a true 1/3 as a pure number. -Wikid77 (talk) 05:47, 26 February 2013 (UTC)