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(a)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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l