Focusing on a key assumption of yours, Gregory: “Adding a number
fudging kludge to produce a less accurate result…”
Is this true? It seems that Robert Rohde is suggesting that his code
turns round-off errors back to their intended values. Is your
assumption true that this tweak MUST necessarily also occasionally
fudge up correct results into incorrect ones?
That said, I agree also with your last paragraph: string functions is
the best solution for {val}, since it will allow it to render output
with trailing zeros, such as 2.4500(15) x 10^16
Greg
On Feb 2, 2009, at 3:25 PM, Gregory Maxwell wrote:
On Mon, Feb 2, 2009 at 5:56 PM, Robert Rohde <rarohde(a)gmail.com> wrote:
I've already written code that converts
4.9999999998 to 5 immediately
before performing operations that explicitly expect integers by
applying an explicit 1 part in 10^10 tolerance. That covers a wide
range of cases that might be affected by round-off errors while adding
little overhead.
I can't wait to see the complaints when some compiler upgrade results
in the code using the 32bit SSE registers rather than the 80bit FPU
and producing inexplicably different results.
The whole reason that the discussion is even being had here is because
Wikipedia is full of pedants. Adding a number fudging kludge to
produce a less accurate result to order to fix some other kludge, just
to satisfy one set of pedants is only going to irritate another set of
pedants later.
Doing math in the parser is the wrong solution for this. Give the
users string manipulation functions and save the math for integer only
calculations and sausage making like table layout. Finite precision
math simply can't be guaranteed to produce reasonable results for
non-integer "content math" purpose.
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l