Last modified: 2012-01-23 20:09:49 UTC
{{#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)
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.
This bug will probably be fixed if Bug 6068 is fixed, but this one can also be fixed independently.
Created attachment 1985 [details] Fixes bug by using bcmod(). Performance impact unknown.
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.
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.
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.
With the latest SVN version of both MediaWiki and ParserFunctions, I can say that my installation consistently gives negative numbers.
Created attachment 1989 [details] Conditionally calls bcmath to fix bug if bcmath is installed
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.
If anybody can decipher the gibberish I've typed above, sorry. I'd need a textarea with 45 or less characters.
32 vs 64-bit.
re #11, ACK, I just wanted to add the same info found in an online PHP manual
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!
(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?
(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
All our web servers are 64 bits now, so assuming this was fixed for 64bits php and/or new releases... Closing.
