Template talk:Round

Rnd uses too many subtemplates for Convert

04-April-2010: The standard Template:Convert has been hitting template-nesting limits, when used inside nested infoboxes or nested doc subpages. For some conversions, Convert has been using over 23 nested subtemplates. A major part of the too-many subtemplates is the use of the unneeded middle-man subtemplate {{Rnd/a}} for rounding almost every conversion result. Hence, see topic below: #Condensing Rnd by combining Rnd/a. Every subtemplate which can be bypassed is another less for worry. -Wikid77 (talk) 15:56, 4 April 2010 (UTC)

Condensing Rnd by combining Rnd/a

04-April-2010: The rounding Template:Rnd can be condensed by merging the short contents of subtemplate {{Rnd/a}} and avoid an extra level of nested subtemplates. Removing 1 more nest-level can help avoid hitting Wikipedia's template-nesting limit. Rnd can be changed to directly invoke {{Rnd/b0}}, {{Rnd/b1}} or {{Rnd/b-1}} without using the "middle-man" Template:Rnd/a. The condensed template would be identical to Rnd invoking Rnd/a, but avoids the 2-step transclusion by combining expressions formerly split between the 2 templates. As shown by the template contents, below, the proposed version of {Rnd} would be similar in size to combining the text of the former {Rnd} with {Rnd/a}.

The proposed Template:Rnd replaces former Template:Rnd & Template:Rnd/a combined, as just one level of nesting to perform the same steps.

---

Template:Rnd:      (proposed version)

{{formatnum:{{rnd/b{{#expr:( ({{{1|9.4}}})round({{{2|3}}}) >0 )-( ({{{1|9.4}}})round({{{2|3}}}) <0 )}}|{{#expr: ({{{1|9.4}}})round({{{2|3}}}) }}|{{{2|3}}}|{{#expr:{{{2|3}}}>0}} }} }}<noinclude>

{{doc}}

</noinclude>

---

Template:Rnd:      (former version)

<includeonly>{{formatnum:{{rnd/a|{{#expr:({{{1}}})round({{{2}}})}}|{{{2}}}|{{#expr:{{{2}}}>0}}}}}}</includeonly><noinclude>

{{pp-template}}

{{doc}}

</noinclude>

---

Template:Rnd/a:      (formerly used)

<includeonly>{{rnd/b{{#expr:({{{1}}}>0)-({{{1}}}<0)}}|{{{1}}}|{{{2}}}|{{{3}}}}}</includeonly><noinclude>

{{pp-template}}

{{doc}}

</noinclude>

As shown above, the proposed contents of Template:Rnd would be similar in size to combining the text of the two templates, since the joining of the 2 allows combining the 3 {#expr} expressions, which, formerly, had been split between the 2 templates. The supposed efficiency of passing common parameters, into Rnd/a, had been offset by the inefficiency of comparing those parameters in multiple expressions, which had been split between the 2 templates. By re-combining the 2 templates, the split expressions can be re-combined, and hence the reduced template is also efficient. There had been no real improvement by splitting into {Rnd/a}, but fortunately, recombining {Rnd/a} into {Rnd} is a simple change. -Wikid77 (talk) 15:56, 4 April 2010 (UTC)

Change Rnd to bypass Rnd/a

{{editprotected}} 05-April-2010: The rounding Template:Rnd needs to be replaced from the Template:Rnd/sandbox to combine the contents of {{Rnd/a}} and allow that subtemplate to be bypassed, as 1 less nesting level against the Wikipedia template-nesting limit. IMPACT: nearly 307,000 pages will be reformatted, with over 286,000 using {Convert}, while the other pages use rounding in other calculations.

The condensed template contents are shown below:

Template:Rnd/sandbox:      (proposed version)

{{formatnum:{{rnd/b{{#expr:( ({{{1|9.4}}})round({{{2|3}}}) >0 )-( ({{{1|9.4}}})round({{{2|3}}}) <0 )}}|{{#expr: ({{{1|9.4}}})round({{{2|3}}}) }}|{{{2|3}}}|{{#expr:{{{2|3}}}>0}} }} }}<noinclude>

{{doc}}

</noinclude>

After update, then Template:Rnd/a should become almost totally unused, as in what-links-here for {Rnd/a}. The table below shows the before-and-after results as identical, with every digit exactly the same after the update, but just rounded using 1 template to begin rounding, rather than 2 nested templates:

Example	Current Rnd	Proposed Rnd/sandbox
{{rnd|1|4}}	1.0000	{{rnd/sandbox|1|4}}
{{rnd|9.27455|4}}	9.2746	{{rnd/sandbox|9.27455|4}}
{{rnd|9.27455|3}}	9.275	{{rnd/sandbox|9.27455|3}}
{{rnd|9.27455|1}}	9.3	{{rnd/sandbox|9.27455|1}}
{{rnd|0|4}}	0.0000	{{rnd/sandbox|0|4}}
{{rnd|0|0}}	0	{{rnd/sandbox|0|0}}
{{rnd|7628.37|4}}	7,628.3700	{{rnd/sandbox|7628.37|4}}
{{rnd|7628.37|1}}	7,628.4	{{rnd/sandbox|7628.37|1}}
{{rnd|7628.37|0}}	7,628	{{rnd/sandbox|7628.37|0}}
{{rnd|7628.37|-1}}	7,630	{{rnd/sandbox|7628.37|-1}}
{{rnd|7628.37|-2}}	7,600	{{rnd/sandbox|7628.37|-2}}
{{rnd|7628.37|-3}}	8,000	{{rnd/sandbox|7628.37|-3}}
{{rnd|-707628.37|-1}}	−707,630	{{rnd/sandbox|-707628.37|-1}}
{{rnd|-707628.37|0}}	−707,628	{{rnd/sandbox|-707628.37|0}}
{{rnd|707628.37|-1}}	707,630	{{rnd/sandbox|707628.37|-1}}
{{rnd|707628.37|-3}}	708,000	{{rnd/sandbox|707628.37|-3}}
{{rnd|707628.37|-4}}	710,000	{{rnd/sandbox|707628.37|-4}}
{{rnd|707628.37|-5}}	700,000	{{rnd/sandbox|707628.37|-5}}
{{rnd|123456789|-2}}	123,456,800	{{rnd/sandbox|123456789|-2}}
{{rnd|123456789|-4}}	123,460,000	{{rnd/sandbox|123456789|-4}}
{{rnd|123456789|-7}}	120,000,000	{{rnd/sandbox|123456789|-7}}
{{rnd|1234567890|-3}}	1.234568×109	{{rnd/sandbox|1234567890|-3}}
{{rnd|1234567890|-8}}	1.2×109	{{rnd/sandbox|1234567890|-8}}
{{rnd|1234567890|-9}}	1×109	{{rnd/sandbox|1234567890|-9}}
{{rnd|9.35|4}}	9.3500	{{rnd/sandbox|9.35|4}}

Once Template:Rnd has been updated, the table above should appear unchanged, because all of the rounded amounts will be rounded in exactly the same manner as before, with every digit exactly the same, but rounded using 1 less subtemplate, in over 307,000 calculations. -Wikid77 00:31, 5 April 2010 (UTC)

 Done Looks like the change has not produced any errors  Ronhjones  ^(Talk) 00:50, 5 April 2010 (UTC)

• Thanks. Most of those 307,000 page reformats were finished before 5am UTC, but a suspicious 1,196 pages still claimed links to {Rnd/a}. Upon editing some of those 1,196, during edit-preview they still claimed {Rnd/a}, but after removing {Convert} & re-adding {Convert}, then they finally de-linked {Rnd/a}: I guess the database "got tired" of unlinking 306,000 {Rnd/a} and went on "de-linking strike". Hence, some articles still insist they use {Rnd/a}, when they really don't. Not a problem, with 99.97% of prior pages de-linked, we can handle the rebellious pages later. -Wikid77 Wikid77 (talk) 14:46, 5 April 2010 (UTC)

On the one hand we've cut out one layer. On the other hand we're doing the same calculation three times instead of once. Have we condensed the template or expanded it? I'm not actually sure. It's worth checking out. JIMp _talk·cont 09:28, 12 November 2010 (UTC)

• Compare contents above in: "#Condensing Rnd by combining Rnd/a". I spent some hours analyzing the general issues. The new April-2010 {Rnd} uses 3 expressions, just as the prior {Rnd} with {Rnd/a}, together, had used 3 expressions of #expr. The use of "round" 3 times (to round parameter 1) is trivial, in terms of internal computing, just like trying to avoid adding "2+2" three times by invoking another template. For template-expansion space, the comparison is about equal, rather than 1 being 3x times the other 2. For editors, they no longer see "Rnd/a" in the template list during article-edits. As for overhead, Wikipedia dropped 308,000 transclusions of {Rnd/a}, allowing another template to enter the list of the top 50 most-used templates. If we could avoid nesting another subtemplate, it would have similar benefits. Meanwhile, people are using "57" varieties of "{{ft_to_m}}" because they noted that Convert was exceeding the template-nest limits. -Wikid77 (talk) 13:57, 15 November 2010 (UTC)

Bypassing the b & c (& d) subtemplates too

When the template was created we had to deal with pre-expand limits. This (in part) explains the design. Nesting several levels of small templates allowed us to achieve a very low pre-expand size whereas a tree of nested ifs might have caused strife. Improvements have since been made and we no longer have to worry about the size of stuff which doesn't get included. This has shifted the focus towards another limit we (still) have to deal with: template nesting. This is what Wikid is talking about above.

I've written a version in the sandbox which uses an elaborate if tree to bypass the level c subtemplates ({{rnd/c0dec0}}, {{rnd/c2dec1}}, etc.). We could bypass the b level too, this would involve repeating the round function several times but according to the above discussion it would seem to be worth it. JIMp _talk·cont 06:31, 16 February 2012 (UTC)

I've revised the sandbox version. It cuts levels b, c & d (d is only for scientific notation though). JIMp _talk·cont 14:33, 16 February 2012 (UTC)

I've just copied the new version from the sandbox. JIMp _talk·cont 03:24, 20 February 2012 (UTC)

Ifexpr error causing strife

{{edit protected}} As noted on the convert talk page {{#ifexpr: }} is broken. These should both give "6".

{{#ifexpr:4.1E+6/10^5round0=4.1E+6*10^-5|6|4}} {{#ifexpr:4.1E+6/10^5round0=4.1E+6/10^5|6|4}}

The first (used by {{rnd/b1}}) is not working properly (giving "4"). Luckily the second is working.

Here's the new code for {{rnd/b1}} (it goes beyond the page).

<includeonly>{{rnd/c{{#ifexpr:{{{1}}}<10^5|{{#ifexpr:{{{1}}}<0.0001|2|4}}|{{#ifexpr:{{{1}}}<10^9|{{#ifexpr:{{{1}}}/10^5round0={{{1}}}*10^-5|6|4}}|8}}}}dec{{{3}}}|{{{1}}}|{{{2}}}}}</includeonly><noinclude>{{doc}}</noinclude>

Let's fix {{rnd/b-1}} whilst were're at it (just change the /10^5 to a *10^-5).

JIMp _talk·cont 09:21, 12 November 2010 (UTC)

rnd/b1 done, for rnd/b-1, do both /10^5 need to become *10^-5, or just the last one ? —TheDJ (talk • contribs) 14:26, 12 November 2010 (UTC)

It seems only the last one is causing the problem ... but who knows ...

12,344 cubic metres (435,900 cu ft)

12,344 cubic metres (435,900 cu ft)

12,344 cubic metres (435,900 cu ft) ← put round "-2" to stop depth error

Another thing: The template is (still) misbehaving in infoboxes; this was actually the problem that lead me here in the first place. I'm hoping to try some things out which will involve a rewrite of the main page and of {{rnd/a}}. JIMp _talk·cont 14:46, 12 November 2010 (UTC)

I'd like to try the following on {{rnd/a}}

<includeonly>{{rnd/b{{#ifeq:{{{1}}}|0|0|{{#ifeq:{{#expr:{{{1}}}<0}}|1|-1|1}}}}|{{{1}}}|{{{2}}}|{{{3}}}}}</includeonly><noinclude>
{{documentation}}
</noinclude>

and undo the most recent change. If it doesn't fix the problem you see on the right, just revert (though it might not be immediate). If it does fix it, it'll be time to try work the said edit back in ... or perhaps not (I'm not quite convinced about it anyway). JIMp _talk·cont 15:01, 12 November 2010 (UTC)

Could you carry out tests on Template:Rnd/sandbox rather than the live template? — Martin (MSGJ · talk) 16:55, 12 November 2010 (UTC)

Yes and no. We can test the code in the sandbox and see how this template goes but we won't know whether it fixes the convert-infobox clash until it's running. JIMp _talk·cont 17:00, 12 November 2010 (UTC)

... It's now in the sandbox & everything looks fine (see the table above). JIMp _talk·cont 17:07, 12 November 2010 (UTC)

Okay, I made the change, but it didn't fix the transclusion depth issue, so I reverted it for now. If this wasn't supposed to fix this issue, let me know and I can re-implement it. Thanks! Plastikspork _―Œ^(talk) 16:54, 13 November 2010 (UTC)

Whilst it was running did you see anything happen to the horrible red mess over there? JIMp _talk·cont 10:40, 14 November 2010 (UTC)

No, there was no change in the red mess in the infobox there floating on the right. It also didn't appear to break anything, so I can reimplement it if you want. By the way, I just added another example, to expose the nature of the infobox problem. Basically, each call to {{infobox}} adds two to the transclusion depth. When the infobox is within another template, that adds one as well. So, at level 2 and 4, everything is fine, but when we jump to over 4, it breaks. Plastikspork _―Œ^(talk) 17:58, 14 November 2010 (UTC)

Regarding the problem with #ifexpr:

• {{rnd|1200000.002|2}} → 1,200,000.00 (should be 1200000.00 1,200,000.00; at the time of writing, this gives the wrong 1.2E+6.00).

The expression (1200000.002)round(2) should be passed on as parameter, instead of its result 1.2E+6, or the result should be rounded again, because 1.2E+6 is treated as 1.2, rounded to a representable number, multiplied by 1,000,000, and in some of such cases the result is not the round number. Also, to check whether it is a multiple of 100,000, divide by 100,000, round to an integer, multiply by 100,000, and compare with the original: {{#ifexpr:((((1200000.002)round(2))/100000)round0)*100000=(1200000.002)round(2)|yes|no}} → yes. This works correctly for numbers below 2.8e17 and non-negative second argument of round, because the multiplication is exact in these cases, in combination with the fact that the equality in #ifexpr is exact.--Patrick (talk) 00:13, 14 November 2010 (UTC)

Thanks. This will be useful info in trying to get this working. JIMp _talk·cont 10:40, 14 November 2010 (UTC)

I made the change.--Patrick (talk) 00:45, 16 November 2010 (UTC)

Avoid errors by setting precision

Reminder: The template-nesting can be reduced by specifying precision in Convert, rather than the default which invokes the nested templates to determine precision. Notice, in the examples, below, how the errors were avoided when precision was specified as round "0" or "sigfig=5" and such.

{{Infobox power station
|name           = Use {convert{{!}}12344{{!}}m3}
| installed_capacity = {{convert|12344|m3}}
}}
{{Infobox power station
|name           = Use {convert{{!}}12344{{!}}m3{{!}}0}
| installed_capacity = {{convert|12344|m3|0}}
}}
{{Infobox power station
|name           = Use {convert{{!}}12344{{!}}m3{{!}}sigfig=5}
| installed_capacity = {{convert|12344|m3|sigfig=5}}
}}

Sometimes, it is faster to hard-code the precision for certain cases, rather than try to redesign and modify the {Precision} or {Rnd} templates and risk upsetting 310,000 other articles. If people, in general, always put "0" or "sigfig=3" (or similar), then those conversions will be faster and bypass the {Precision} templates completely.

I initiated the prior update to {Rnd} to bypass {Rnd/a} and directly invoke {Rnd/b*} because that uses 1 fewer template in the 40-deep limit. The usage figures revealed that {Rnd/a}, no longer transcluded, was dropped from 308,000 articles (after a few days). However, we need to get the developers to raise the template-nesting limit to 100 (or 60 or such). Convert is complex, but this is "not Rocket Science" and we need at least 50-deep nesting to expand Convert and other templates for validation and error-message subtemplates. You might know the 40 limit is pathetic, similar to a "call stack" limited to only 40 procedures (subroutines) nested. In modern times, call-stack depth is almost unlimited, so 100 (or 200 or 500) would be more reasonable. However, there might be some issues of "efficiency" which would limit depth to 60 as less of a resource drain. The MediaWiki software has been so peculiar, and concepts of modern software might not apply, except beware that many software developers have fragile egos caused by the strain of all the details being juggled in a nightmare of total software they didn't all write. -Wikid77 (talk) 13:23, 15 November 2010 (UTC)

A hack

I'm cheating, I know, but I think I've got rid of those error messages. Getting garbage in the second parameter was the cause. Now I tweeked the template to round to two significant figures in this case. Of course, the real solution is fixing {{convert}} but before we can get {{convert}} in order we have to get this one working smoothly. JIMp _talk·cont 07:07, 21 February 2012 (UTC)

New templates

I've created three new rounding templates.

• {{rndfrac}} for rounding to a fraction
• {{rndnear}} for rounding to a multiple
• {{rndgaps}} for formatting using gaps

JIMp _talk·cont 17:08, 21 February 2012 (UTC)

Lua implementation

I created {{rnd/sandbox}} which invokes Lua to make this template much faster. The output at template:rnd/testcases seems to be identical to the current {{rnd}}, except for very long numbers where the truncation is slightly different, but I would appreciate another set of eyes to make sure. Dragons flight (talk) 21:20, 21 February 2013 (UTC)

Is is possible this change is the cause of the widespread errors I'm seeing with automatic population density in {{Infobox settlement}}? (See Template talk:Infobox settlement#Problem_with_auto_density). If so, perhaps a revert is in order. —Stepheng3 (talk) 23:14, 22 February 2013 (UTC)

I rolled back the change, can you provide information about what case is actually breaking? Dragons flight (talk) 23:18, 22 February 2013 (UTC)

The relevant invocations of {{Rnd}} are buried down in the population density calculations of {{Infobox settlement}} which I believe are performed in {{Infobox settlement/densdisp}}. Articles affected included Calistoga, California. The revert seems to have cleared up the problem, btw. —Stepheng3 (talk) 23:25, 22 February 2013 (UTC)

{{Infobox settlement/densdisp}} This page showed errors in all "Result" columns of the first two tables before the changes were reverted. --hydrox (talk) 23:30, 22 February 2013 (UTC)

I've setup a testbed using User:Stepheng3/sandbox, Template:Infobox settlement/sandbox, Template:Infobox settlement/densdisp/sandbox, and Template:Rnd/sandbox in order to recreate the problem. —Stepheng3 (talk) 23:43, 22 February 2013 (UTC)

{{Infobox settlement/densdisp}} needs expert attention before it will work with the new version of {{Rnd}}. Please stand by... —Stepheng3 (talk) 02:46, 23 February 2013 (UTC)

Should not be "round" not "rnd"; "rnd" is redundant duplication

•This template never should have been named "rnd", but "round". (Too terse - I have never rnded a number in my life.) ("rnd()" is the random number generator function in some older programming languages.) Trying to find an excuse for {rnd}: Compactness at the expense of unclarity? Fetish/prfrnce for cprtc tmplt names?

•Template:Round existed since 2006-04-16. Template:Decimals existed since 2006-12-07. Despite this, Jimp created Template:Rnd on 2007-09-21. Trying to find an excuse for this addition: Didn't know and didn't look? Chose to skip the sandbox and red tape, to get the alternate implementation out there?

Both templates refer other templates for retaining trailing zeros. The names derived differently. {{rnd/-|123|2}} → −123.00; {{decimals|123|2}} → 123.00

{rnd} is "beating" (round} (not that that proves anything), but {decimals} is beating {rnd/-}:

• Template:Rnd has 245,834 transclusions (and is "protected") and Template:Rnd/- has 440 (and is not "protected" at all).
• Template:Round has only 7,022 (and is only semi-protected) and Template:Decimals has 12,804 transclusions (and is "protected").

A way out is a little harsh, but might go smoothly: 0) Compare codes, in case improvement to {rnd} is possible. 1) Replace {round} with this [compatible] code. 2) Redirct {rnd} to {round}. (Because I prefer {round}, I urge to NOT redirect the minority {round} to (rnd}.) -A876 (talk) 17:02, 20 November 2017 (UTC)

Nominated for merging: Wikipedia:Templates for discussion/Log/2018 December 14#Template:Rnd

Please add

{{Tfm/dated|page=Decimals|otherpage=Round|link=Wikipedia:Templates for discussion/Log/2018 December 14#Template:Rnd|type=disabled|bigbox={{#invoke:Noinclude|noinclude|text=yes}}|help=off}}

inside <noinclude>...</noinclude>. — JJMC89 (T·C) 07:17, 15 December 2018 (UTC)

 Done ~ Amory (u • t • c) 10:40, 15 December 2018 (UTC)

Protected edit request on 15 December 2018

Please replace the contents of this template with the contents of the sandbox in order to remove an undesirable line break that is causing Linter missing end tag / stripped tag errors. See User:Jonesey95/sandbox3 for an example. Thanks. – Jonesey95 (talk) 14:23, 15 December 2018 (UTC)

Pinging Amorymeltzer, if you are around. Thanks. – Jonesey95 (talk) 14:24, 15 December 2018 (UTC)

 Done Yeah, that's on me, window size hid the newline. Thanks. ~ Amory (u • t • c) 15:15, 15 December 2018 (UTC)

Merge with Template:decimals broke Template:Physical constants

@Pppery: See the auto-rounded version of DnuCs in the table at Template:Physical constants/doc: Δν(¹³³Cs)_hfs ≈ . Basically, the output of {{decimals}} was being fed to {{val}}, and for that constant, the value is 10 digits long (9192631770), and the resultant exponential notation (9.192631770×10⁹) was not valid input to {{val}}.

I fixed it by changing {{Physical constants}} to use {{#expr:{{{value}} round {{{digits}}}}} rather than use a more complex pretty-printer like {{decimals}} at all. But since you're doing the conversion and are familiar with the whole thing, you might want to take a look. 167.88.12.231 (talk) 02:54, 2 June 2019 (UTC)

I could have sworn I had looked at all of the templates calling Template:Decimals and checked for any cases like this before doing the redirection after the merge was reverted two months ago because Template:Inflation broke in exactly the same way. I probably missed this one because of the large amount of markup between the decimals and the rounding template. Note to self: Merging templates is harder than you think ... * Pppery * _{it has begun...} 03:08, 2 June 2019 (UTC)

Error cat

Can Category:Pages with bad rounding precision show only article-space? Jonesey95, another one. Thanks. MB 02:56, 19 November 2019 (UTC)

 Done. – Jonesey95 (talk) 17:49, 19 November 2019 (UTC)

Bug in rounding 0.000020004?

In Examples:

{{Round|0.000020004|7}} gives 000 for some reason (template: 000)

Shouldn't this be at least 0.00002, or exactly 0.0000200?

Tests:

{{Round|0.000020004|6}} -> 0

{{Round|0.000020004|5}} -> 0

{{Round|0.000020004|4}} -> 0.0000

{{Round|0.00020004|4}} -> 0.0002

{{Round|0.00020004|7}} -> 0.0002000 MarMi wiki (talk) 17:21, 24 April 2021 (UTC)

The code at precision_format in Module:Math would need serious time to investigate. I don't know why lang:formatNum is used there (for localization of digits? in only that function?) but it is the cause. When the value is 0.000020004, line 478 (local formatted_num = lang:formatNum(math.abs(value))) gives the string "0". Johnuniq (talk) 03:57, 25 April 2021 (UTC)

It seems that something is wrong with the lang:formatNum in some languages (en, de, ...).

From debug console at Module:Math:

mw.log(mw.language.new( 'en' ):formatNum( 0.000020004))

0

mw.log(mw.language.new( 'en' ):formatNum( 0.000020004, { noCommafy = true } ))

2.0004E−5 MarMi wiki (talk) 22:22, 25 April 2021 (UTC)

@Jonesey95, Pppery, and Primefac: You have edited Template:Round or Module:Math and are active. You might not have been involved with the code for {{round}} (which uses {{#invoke:Math|precision_format|(VALUE)|(PRECISION)}}) but you might have knowledge of how this template is used? I'm too irritated by "what links here" to work out the significant usages of {{round}}. Surely it cannot be cases like that reported here ({{Round|0.000020004|7}}) where fixed text is entered into the template because it would be easier to simply write the rounded value. Instead, presumably the value to be rounded comes from another template or a calculation. At any rate, lang:formatNum is incompatible with round because formatNum requires a number as input and converting what round is doing to a number will lose round's work. Also, formatNum will format the output text according to its own rules. I guess it's intended use was to insert commas but the vagaries of floating point representations mean that working with a number (as opposed to a string) will always fail occassionally. Any thoughts? @MarMi wiki: Where did you notice the problem or were you just experimenting? Johnuniq (talk) 11:05, 26 April 2021 (UTC)

My guess is that the problem happens in the code starting at line 462:

    -- Due to round-off effects it is neccesary to limit the returned precision under
	-- some circumstances because the terminal digits will be inaccurately reported.
	if order + precision >= 14 then
		if order + p._precision(value_string) >= 14 then
			precision = 13 - order;
		end
	end

These test cases appear to have order+precision greater than 14, so they trigger this apparently buggy workaround. Just guessing. I would bring it up at Module talk:Math. – Jonesey95 (talk) 16:16, 26 April 2021 (UTC)

@Johnuniq:

I've noticed this looking at the template documentation - it's one of the examples (second one). I've added it also as a testcase in the template test page.

Lang:formatNum in some languages (en included, pl excluded) will return 0 at any small number starting with 4 zeroes (ex. 0.00001), so I think that's this function problem (or it's a locale problem).

I've reported this on Mediawiki Extension talk:Scribunto: "lang:formatNum returns 0 in some languages for small numbers (starting with 4 zeroes)". MarMi wiki (talk) 18:31, 26 April 2021 (UTC)

Added 0.00001 & 0.0001 in Template:Round/testcases. Template should prevent returning multiple zeroes (00+), since {{round|0|-3}} (0) doesn't add any. - I forgot that the template invokes Module:Math.

Reported on the Module:Math talk page, with possible solution: lang:formatNum_fix_for_small_numbers_of_order -5 and_smaller. MarMi wiki (talk) 18:45, 26 April 2021 (UTC)

Math expressions

Why is it not mentioned anywhere in the documentation that {{Round}} supports mathematical expressions?

{{Round|5+7}} → 12

{{Round|1/(1+2)|5}} → 0.33333

I have learned about the existence of this functionality from the source code of {{Fb cl3 team}}. — UnladenSwallow (talk) 23:13, 11 July 2021 (UTC)

Please don't croak on comma

Round fails when passed numbers that take comma dividers:

• {{Round|6207189|2}} ⟶ 6,207,189.00
• {{Round|6,207,189|2}} ⟶

Not sure if this should be handled via formatnum in the template to strip commas, or directly in Module:Math. Thanks, Mathglot (talk) 23:11, 22 July 2024 (UTC)