Template talk:Rounddown

• {{rounddown|123.456|-2}} gives 100
• {{rounddown|153.456|-2}} gives 100

Automated unit test

(Only errors should appear. To see test code, use the edit button.)

I am satisfied that the current version of this template gives correct results. --Uncle Ed 13:38, 7 May 2006 (UTC)

Except that it is inconsistent with the built-in rounding used by #expr:.

• {{#expr: 0.5 round 0}} = 1
• {{#expr: -0.5 round 0}} = -1
• {{rounddown|0.5|0}} = 0
• {{rounddown|-0.5|0}} = -1

With 'round' if we ignore the +/- sign a given value always rounds to the same result. With the new rounddown positive and negative values round differently. The 'round' template works consistently with the 'round' ParserFunction expression. The 'rounddown' and 'roundup' templates also used to be consistent with that. Now they aren't. A 'round' consistent with the way 'rounddown' works now would evaluate {{#expr: -0.5 round 0}} as 0, rather than -1. Pull up Excel, C++, or any other method you have of computing rounded numbers... chances are that NONE of them work that way. They compute {{rounddown|-0.5|0}} as 0 rather than -1 as this template now does.

The code is also just alot longer than it needs to be. The exact same results could be achieved with something like;

{{#expr:{{Floor|{{{1}}}{{#if: {{{2|0}}} < 0|*|/}}{{pow|10|{{{2|0}}}}}}}{{#if: {{{2|0}}} < 0|/|*}}{{pow|10|{{{2|0}}}}}}}.

There may be a point to the inconsistent rounding... it isn't needed for the templates which call it currently, but it could be for some future situation. However, if so then I think it should be the exception rather than the default. I've looked and can't find rounding functions which work that way in any tool or programming language I've got. --CBDunkerson 14:32, 7 May 2006 (UTC)

I made an update which uses a shorter and, I believe, more consistent formula. It 'fails' three of the conditions above, but I believe the conditions are themselves using an invalid assumption;

1. {{Rounddown|-3.14159|3}} evaluates to -3.141 rather than -3.142. This matches normal 'rounddown' calculations in every tool I have tested. Note that the page says this template is equivalent to "truncation"... which means cutting off the decimals after those specified. Thus, -3.141 is truncation and normal rounddown logic. The -3.142 is a specialized 'mathematical' rounddown which I can't find actually used anywhere.
2. {{Rounddown|-0.314159|0}} evaluates to 0 rather than -1. Same issue as above... 0.<whatever> truncated to 0 decimal places is 0.
3. {{Rounddown|-314159|-3}} evaluates to -314000 rather than -315000. Again, this is the same issue... truncating at '-3' decimal places gets rid of the '159' rather than 'rounding up' to -315000.

If someone can make a case for needing the 'negative values round decimals up to the next negative integer' rather than 'truncating / rounding down to the previous negative integer' then I'd suggest separate templates for that. But I cannot see any logical reason to use non-standard rounding in the default rounding templates. --CBDunkerson 13:51, 8 May 2006 (UTC)

Simpler code

The code:

{{#expr: ( (({{{1}}}) - {{sgn|{{{1}}}}} * 0.5 * {{pow|10|-{{{2|0}}}}}) round {{{2|0}}} ) + 0 }}

would duplicate the current behavior, and would be less of a server strain than the current code. --Eliyak T·C 22:38, 11 July 2007 (UTC)

This doesn't exactly duplicate the current behavior. This version rounds towards zero, rather than rounding down. --- RockMFR 01:01, 13 June 2008 (UTC)