On Mon, Feb 2, 2009 at 10:55 AM, greg_l_at_wikipedia greg_l_at_wikipedia@comcast.net wrote:
I have a sandbox with hundreds of test numbers to exercise the {delimitnum} template. This template uses the same math-based functions as {val}. For anyone who has produced improved math functions, you can examine values on this sandbox that currently produce rounding errors and test your new math functions. The sandbox is at the following:
http://en.wikipedia.org/wiki/User:Greg_L/Delimitnum_sandbox
At the very bottom of the page (which loads slowly), is a concise list of values that all have errors.
It would still be much better if a character-counting parser function can be made. Then, numbers like {{val|1.4500}} won't have its two trailing zeros truncated.
Based on feedback, principally from Aryeh, I modified a previous effort to add an explicit fractional tolerance test of 1e-10 to #expr when performing comparisons and integer conversion (e.g. floor, ceil, mod, etc.)
That would have the effect that the comparison functions and integer conversion would generally operate correctly up to 10 significant figures (e.g. A == B if A/B - 1 < 1e-10). This would eliminate many of the problems associated with comparison functions and modular arithmetic, but with the tradeoff that those same operations may give unexpected results if the significand is intended to have more than 10 base-10 digits.
This doesn't apply to basic math operations (+, -, *, ^, etc.) except where they are coupled to either comparisons or integer conversions. So if someone simply wanted to do computations, such as 47.3 * 10.23^7.8, then they will still get all ~15 digits that PHP is capable of displaying.
I see this principally as a step to make the basic math functions more reliable and consistent with user expectation by reducing the impact of floating point rounding effects. An indirect effect is that I believe those number formatting templates would generally work as intended for significands with no more than 10 digits. (Greg, how often do you worry about more than 10 digits?) Though, we may still want to consider building number formatting options into Mediawiki directly since I'm not sure putting all of that formatting effort into template space is really a good idea.
Aryeh and I seem to have a difference of opinion about whether sacrificing precision for some operations involving more than 10 significant digits is an acceptable trade-off for quashing round-off problems most of the rest of the time. The code is in r46683, and I would appreciate some additional viewpoints on this.
Thanks.
-Robert Rohde