ParserFunctions MOD result sometimes wrong
Closed, ResolvedPublic

Description

Author: omniplex

Description:
{{#expr: 20060618093259 mod 10000}} gives mostly 3259 as it should,
but sometimes the result is -6357.

It needs several (about 20) attempts to see it, test it with URL
http://meta.wikimedia.org/wiki/ParserFunctions/MOD10000?action=purge

Not related to [[mediazilla:6068]], tested version 1.7alpha (r14796)


Version: unspecified
Severity: normal
Platform: Other
URL: http://meta.wikimedia.org/wiki/ParserFunctions/MOD10000?action=purge

bzimport added a subscriber: Unknown Object (MLST).
bzimport set Reference to bz6356.
bzimport created this task.Via LegacyJun 18 2006, 9:58 AM
bzimport added a comment.Via ConduitJun 18 2006, 9:33 PM

ezyang wrote:

This has to do with overflows. PHP's modulus overflows very easily. This PHP
bug: http://bugs.php.net/bug.php?id=1335 says that occasionally, PHP will
intercept the operation and use bcmath, but it's better to just use it
unconditionally.

Executing the following code in PHP 5.1.2 will consistently give -6357:

echo (20060618093259 % 10000);

This gives the correct result:

echo bcmod('20060618093259', 10000);

However, using BC math may pose an unacceptable performance degradation.

bzimport added a comment.Via ConduitJun 18 2006, 9:36 PM

ezyang wrote:

This bug will probably be fixed if Bug 6068 is fixed, but this one can also be
fixed independently.

bzimport added a comment.Via ConduitJun 18 2006, 9:40 PM

ezyang wrote:

Fixes bug by using bcmod(). Performance impact unknown.

attachment ExprModulus.patch ignored as obsolete

brion added a comment.Via ConduitJun 18 2006, 9:43 PM

bcmath is not compiled in by default, so I would recommend
against using it unconditionally. It would make the extension
useless to many, perhaps most people.

bzimport added a comment.Via ConduitJun 19 2006, 2:15 PM

ezyang wrote:

I'll look into making it conditional (at another performance hit!)

Could this be sporadic because of configuration differences between servers? The
load-balancer then is causing it to randomly hit servers that serve negative
numbers.

bzimport added a comment.Via ConduitJun 19 2006, 2:21 PM

ezyang wrote:

I did a whole bunch of reloads on the bug page and noted which server had served
it. Here are the results:

error
srv2 x2
srv11
srv14
srv15 x2
srv22 x2
srv25
srv30
srv70

no error
srv35
srv53
srv51
srv58
srv60
srv61
srv62 x2
srv64
srv69
srv73
srv79
srv82
srv90 x2
srv98
srv100
srv113
srv116

I definitely think it's a configuration issue.

bzimport added a comment.Via ConduitJun 19 2006, 2:31 PM

ezyang wrote:

With the latest SVN version of both MediaWiki and ParserFunctions, I can say
that my installation consistently gives negative numbers.

bzimport added a comment.Via ConduitJun 19 2006, 2:36 PM

ezyang wrote:

Conditionally calls bcmath to fix bug if bcmath is installed

Attached: ExprModulus2.patch

bzimport added a comment.Via ConduitJun 22 2006, 8:55 AM

omniplex wrote:

Interesting results, in other words any given either gets it always right or
always wrong. The "intermittent" effect only caused by load balancing. What
is wrong with the serves always getting it wrong, why not fix that? Otherwise
I fear your fix doesn't help generally, Wikis offering arbitrary precision
math probably, that might be rare, who needs it?

Another approach could be to limit the input for MOD in a reliable way, if
the operands need more than 14 decimal digits just throw an error, always,
reliable. I'm not sure if 14 is correct, it could be also 13. Apparently not
15, although 64 bits IEEE can AFAIK represent all integers with 15 digits.

bzimport added a comment.Via ConduitJun 22 2006, 8:59 AM

omniplex wrote:

If anybody can decipher the gibberish I've typed above,
sorry. I'd need a textarea with 45 or less characters.

brion added a comment.Via ConduitJun 22 2006, 9:34 AM

32 vs 64-bit.

bzimport added a comment.Via ConduitJun 29 2006, 4:24 PM

omniplex wrote:

re #11, ACK, I just wanted to add the same info found in an online PHP manual

bzimport added a comment.Via ConduitJan 23 2012, 7:51 PM

sumanah wrote:

Edward, I'm sorry it has taken so very long for us to respond to this patch! Would you kindly check whether it's still necessary and whether it still applies to trunk? Thanks!

Bawolff added a comment.Via ConduitJan 23 2012, 7:58 PM

(In reply to comment #11)

32 vs 64-bit.

Given 6 years have past - is it safe to say that Wikimedia servers are all 64 bit, and hence this is no longer an issue?

Reedy added a comment.Via ConduitJan 23 2012, 8:06 PM

(In reply to comment #14)

(In reply to comment #11)
> 32 vs 64-bit.

Given 6 years have past - is it safe to say that Wikimedia servers are all 64
bit, and hence this is no longer an issue?

I'm fairly sure this is the case yeah, more so for the apaches

Platonides added a comment.Via ConduitJan 23 2012, 8:09 PM

All our web servers are 64 bits now, so assuming this was fixed for 64bits php and/or new releases... Closing.

Add Comment