r46683 MediaWiki - Code Review archive

I'm still not at all sure about this. It seems like it would probably have some kind of scary side effects somehow. More specific concerns:

1. What made you choose a/b - b/a? I can't quite see how this is meant to behave, other than the obvious fact that it handles a few more cases correctly.
2. Is 1e10 the best cutoff to choose? What's PHP's floating-point precision?
3. This still makes strictly fewer things possible. It's possible to emulate this behavior under the current system by checking (a - b) < 1e-10 yourself, but it's *not* possible to emulate higher precision in the new system.

I think it might be better to keep the status quo for now. In particular, with respect to (3), I don't see the problem in just telling template programmers that they shouldn't test floating-point numbers for equality, like all other programmers.

1. First, using a fractional expression rather than something like abs(a-b) < TOL, means the process is agnostic to the size of the variables. In other words, it correctly knows that 1.23e-30 != 4.6e-20, whereas a tolerance by difference would usually consider those the same. Regarding the technical detail, I used a/b - b/a because that is symmetric under interchange of parameters, whereas a definition like a/b - 1 can lead to situations a == b but b != a.
2. PHP's precision is system dependent, but generally it is the same as C's double. A double usually gives 15-16 significant digits base 10. I chose 1e-10 as a compromise between preserving significant figures and wanting to limit the possibility that accumulating round-off error alone would exceed the tolerance. Since we aren't expecting Mediawiki's #expr function to be a tool for advanced computations, I would guess that 10 digits of precision is enough for nearly all comparisons. And as I said before, the alternative that 0.07*100 != 7 and 5/6 != (1/6)*5 is very confusing to everyday users.
3. Forcing template programmers to add emulation everywhere they want to reliably use: floor, mod, ceil, trunc, and any of the comparison functions would require a large amount of extra template code, and in my opinion is very undesirable. By contrast, it IS still possible to emulate higher precision in those cases where people feel having more than ten significant figures is essential. Because the basic operations (e.g. +, -, *) do not round, one can break up a number, v, into high and low portions with constructions like v_low = v - round(v,10) and v_high = v - v_low before doing comparison testing. v_low will never have more than 5 or 6 real digits, and will often have fewer since the lowest ones may already be corrupted by round-off error in floating point operations, so the usability of this for comparison testing may be dodgy though. (The 10 in the round above actually needs to be replaced with a log expression that accounts for the place value of the highest significant digit, since round counts relative to a fixed decimal, but you get the idea.)

I would like to re-emphasize that this does not have any impact on basic mathematics. So someone who just wants to find {{#expr:78.4^1.2 - 67/92.1}} will still see all ~15 digits (or whatever PHP is able to give them). This is just about improving integer operations (floor, mod, etc.) and comparison functions so that everyday template coders don't have to go nuts trying to figure out why 5/6 != (1/6)*5.

Yes, there are some trade-offs associated with adding a specific tolerance, but I think the usability improvement associated with giving users math functions whose behavior is easy to understand, significantly outweighs the losses associated with limiting precision in a few cases.