Gerrit change 37368 change did change the behavior of {{#expr: X mod Y }}. The old code,

$stack[] = $left % $right;

is more or less equivalent to

$stack[] = fmod( floor( (float)$left ), floor( (float)$right ) );

rather than to

$stack[] = fmod( (float)$left, (float)$right );

Note that PHP doesn't have different precision floating point types (according to http://php.net/manual/en/language.types.float.php), so (float)$x and (double)$x are equivalent and therefore Gerrit change 38278 was a no-op.

While this change in behavior was requested in bug 6068, it seems that many templates are relying on the rounding behavior of the old implementation.

If we really want to solve bug 6068, it might be best to keep "mod" with the old rounding behavior and to introduce a new "fmod" operator. Change I6114c6e7 will do that.

(In reply to comment #1)

If we really want to solve bug 6068, it might be best to keep "mod" with the
old rounding behavior and to introduce a new "fmod" operator. Change
I6114c6e7
will do that.

I came across https://www.mediawiki.org/wiki/Extension:ParserFunctions/Extended when looking into this (which has an fmod too)

I wonder if we should pull some other functions from it into ParserFunctions itself...
'Further it includes the PHP functions abs, floor, ceil, fmod, and sqrt, and a function idiv which applies conversion to an integer by the PHP function "(int)" (rounding towards zero) to the quotient of the arguments.'

We already have abs, floor, and ceil. sqrt wouldn't hurt, but see bug 6068 for far too much ... "discussion" about idiv.

Merged