Text and/or other creative content from this version of template:Sigfig/rnd was copied or moved into template:Rnd with this edit. The former page's history now serves to provide attribution for that content in the latter page, and it must not be deleted so long as the latter page exists. |
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)
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)
Template:Rnd: (former version)
Template:Rnd/a: (formerly used)
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)
((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)
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)
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)
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)
((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)
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)
Regarding the problem with #ifexpr:
((rnd|1200000.002|2))
→ 1,200,000.00 (should be 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)
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)
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)
I've created three new rounding templates.
JIMp talk·cont 17:08, 21 February 2012 (UTC)
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)
•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/-}:
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)
This edit request to Template:Rnd has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
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)
This edit request to Template:Rnd has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
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)
@Pppery: See the auto-rounded version of DnuCs in the table at Template:Physical constants/doc: Δν(133Cs)hfs ≈ Error in ((val)): parameter 1 is not a valid number.. 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×109) 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)
Can Category:Pages with bad rounding precision show only article-space? Jonesey95, another one. Thanks. MB 02:56, 19 November 2019 (UTC)
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)
local formatted_num = lang:formatNum(math.abs(value))
) gives the string "0
". Johnuniq (talk) 03:57, 25 April 2021 (UTC)
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)
-- 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
((round|0|-3))
(0) doesn't add any.Why is it not mentioned anywhere in the documentation that ((Round))
supports mathematical expressions?
((Round|5+7))
→ 12((Round|1/(1+2)|5))
→ 0.33333I have learned about the existence of this functionality from the source code of ((Fb cl3 team))
. — UnladenSwallow (talk) 23:13, 11 July 2021 (UTC)