| • bzimport | |
| Jun 18 2006, 9:58 AM |
| F2997: ExprModulus2.patch | |
| Nov 21 2014, 9:19 PM |
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
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | Feature | None | T19468 Support decimal math (bc extension) in #expr ParserFunction to avoid floating-point surprises | ||
| Resolved | None | T8356 ParserFunctions MOD result sometimes wrong |
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.
ezyang wrote:
This bug will probably be fixed if Bug 6068 is fixed, but this one can also be
fixed independently.
ezyang wrote:
Fixes bug by using bcmod(). Performance impact unknown.
attachment ExprModulus.patch ignored as obsolete
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.
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.
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.
ezyang wrote:
With the latest SVN version of both MediaWiki and ParserFunctions, I can say
that my installation consistently gives negative numbers.
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.
omniplex wrote:
If anybody can decipher the gibberish I've typed above,
sorry. I'd need a textarea with 45 or less characters.
omniplex wrote:
re #11, ACK, I just wanted to add the same info found in an online PHP manual
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!
(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.