On Wed, Feb 11, 2009 at 7:25 AM, Domas Mituzas <midom.lists(a)gmail.com> wrote: Yes Domas, haha, because no one would ever want to write about math or high precision scientific measurements in an encyclopedia. PHP has its limits. We know that. But the fundamental issue is that there are real applications whose output is changing depending on which server happens to do the parsing. For example, 80% of the time one might see the correct 13 digits expression for the number of atoms in a kilogram (formated via template according to NIST standards for scientific notation) and 20% of the time the page gets a big red error message. If the parser always failed, people would know they have to avoid the formatting templates and format the number by hand. However, when something fails only intermittently depending on which server happened to get the job that is a problem that is a lot harder for average users to diagnose. I would generally think the server admins would want all of the servers to generate identical behavior, if at all practical. Am I wrong in thinking that the server admins should care when different machines produce different output from the same code? In this case, the behavior suggests it may be as simple as ensuring that the servers have the same php.ini precision settings. -Robert Rohde

On Wed, Feb 11, 2009 at 9:58 AM, Gregory Maxwell &lt;gmaxwell(a)gmail.com&gt; wrote: Actually PHP's maxint craps out at 10 digits. That's not currently the issue though. <snip> <snip> Yes there is. Testing with various types of expressions supports the view that PHP is aware of the extra digits (out to the double limit of ~15 digits) and able to consistently perform math with them regardless of which server is processing the request. For example, if you perform operations that reduce the precision by removing the highest most digits, then the lowest digits (that had previously been hidden) will reappear. So it appears the internal representations are the same and it is merely a matter of how the information is being output. Since the number of digits to output is governed by the PHP setting that would seem to be the most likely cause. -Robert Rohde

Ok Domas, you’re just not getting it here. Try going to this example page… http://en.wikipedia.org/wiki/User:Greg_L/val_failure_example Do you see all those numeric equivalencies in high-precision scientific notation? Those types of numbers appear in science articles all over Wikipedia. Do you see the ones that are generating error codes? Suppose they didn’t do that when you wrote the article but it randomly happens to others that view the page. Robert is saying that if there is a software setting to make the servers perform the same way, then we should make them the same. Why? Because, imagine that editors use {val} and check (twice, or thrice) to make sure all looks good. But then 20% of the time—purely randomly based upon the server—a couple of numbers with 13 digits will generate error codes like shown in the article. That’s what’s happening here. Roughly 80% of the time, 13 and 14-digit numbers are rendered properly. But 20% of the time, they don’t. Why not just advise editors that they should limit {val} for 12 digits? The issue is that 12-digits is just barely cutting it. Ten years ago, there were few numbers in physics that were measured to this precision. But the are becoming increasingly common—particularly anything related to time or length. That’s why editors should care. If you don’t that’s fine. But please don’t suggest that others shouldn’t care either. Greg L On Feb 11, 2009, at 1:13 PM, Domas Mituzas wrote: Hello! Since when you need floating point math in presentation language, when you're writing about floating point math? There're plenty of topics that our encyclopedia is about, that don't have tools (like physics/biology simulators) inside wikitext. Damnit, we write about all these people and we don't even have tools that would evaluate their genome and provide probabilistic matching and evaluation of article text based on that. This is exactly my point, you don't give a single valid reason for us to care, except some random "oh no, 12 numbers, oh no 14 numbers". Why should we care? -- Domas Mituzas -- http://dammit.lt/ -- [[user:midom]] _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On Wed, Feb 11, 2009 at 10:47 AM, Brion Vibber &lt;brion(a)wikimedia.org&gt; wrote: <snip> <snip> Thanks Brion. It is nice to know I had the right understanding of the problem. :-) Any thoughts on whether one or the other setting might be applied as a standard across all of the servers? Based on your comment about Fedora, should I understand that those servers may be replaced / upgraded eventually anyway? -Robert Rohde

On Wed, Feb 11, 2009 at 3:45 PM, Brion Vibber &lt;brion(a)wikimedia.org&gt; wrote: That's great, and thanks for your attention. -Robert Rohde

Greg L wrote: You can watch yourself bug 17452 https://bugzilla.wikimedia.org/show_bug.cgi?id=17452

On Wed, Feb 11, 2009 at 2:17 PM, greg_l_at_wikipedia &lt;greg_l_at_wikipedia(a)comcast.net&gt; wrote: [snip] Division is very much math and has significant implications on precision. You might think that by dividing only in powers of 10 you are avoiding precision problems, but you would be wrong because the computer isn't doing math in base 10. There exist plenty of such string functions. Every proper programming language provides them. The parser functions, however, do not.