Artur Fijałkowski, Does that mean a template author could selectively apply the round() function on {val} when it is manipulating numbers and doing so would solve its periodic rounding errors? Or would using the round() function possibly introduce errors of its own?
If the latter, I would again suggest that what the template authoring community could really use are just two character-string-manipulating functions:
1) The first would be a function that you could tell to go fetch the string fragment to the right of a specified character, like a decimal point (and the same to the left of the decimal point). 2) The second function would could count how many characters are in the returned strings.
With those two, simple parser functions, template authors could have a field day. With {val}, it could now be told, “there are 10 characters to the right of the decimal point” and the template could calculate that it must delimit in two groups of three and a final group of four digits (e.g. 0.123 456 7890). Then, as I understand it, there is already a “character cannon” of sorts {{#sub:mystring|0|3}} that can feed out the characters.
The virtue of this approach is a character-based version of val could handle numbers bigger than ten digits (an increasingly necessary feature since physics is now more frequently establishing physical and universal constants at precisions of 11 or more significant digits). Also, {val} would be able to handle numbers that end with zeros, such as 2.4500.
Greg
On Feb 8, 2009, at 2:17 AM, Artur Fijałkowski wrote:
2009/2/2 Greg L greg_l_at_wikipedia@comcast.net:
Let me try that again since I mangled the last response:
Sure. And my expectation that 5 divided by 3 times 3 ought to equal 5 and not 4.9999998 is due to my relative understanding of math and relative lack of understanding regarding the inner workings of common calculators. Is there some downside to fixing rounding errors in math functions? If so, then we might as well throw up our hands that trying to delimit numbers via math functions is a lost cause.
It's not a rounding error, but effect of finite-length binary representation. If you 'fix' floating point arithmetic in way that 4.9999998 will be 5 you will fuck all other computations in which it will be precise result.
If you really want to see such thing always use round() function ;)
You should remember that probably many compilers will simplyfy expression '5/3*3' into '5' :)
AJF/WarX
_______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l