Robert: With regard to your Q: “Greg, how often do you worry about more than 10 digits?”, the answer is, ‘not too often.’ The highest- precision set of number sequences on my sandbox is nine significant digits; e.g. 0.298728008
Getting floating-point math to no longer produce rounding errors (like it is a cheap hand-held calculator where 5/3 x 3 = 4.9999998) will likely take away most of the need to have a caveat on WP:MOSNUM about using {val}. Still, it couldn’t properly ever parse a number like 1.2300 and leave the last two zeros in the result.
As for your comment, Robert: “ 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”, I agree; Mediawiki would be the better place for this. There were a number of editors on WT:MOSNUM who were very enthusiastic over the notion of a character-counting parser function that could treat *anything* as a string of mindless characters and could respond to requests like “gimme three” – “gimme three more” – “and gimme the last four”.
If such a character-dolling parser function has a little bit of extra sophistication (perhaps if combined with other existing functions), then template authors could ask a couple of questions like this about the nature of the string:
“How many characters are to the left of a decimal point?” “How many characters are to the right?”
…and then request the following from a character-dolling function:
“Give me the first three to the right of the decimal point”
As I understand it, adding character-dolling functionality to Mediawiki would be very well received indeed.
Greg
On Feb 2, 2009, at 12:33 PM, Robert Rohde wrote:
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
_______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l