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 <[email protected]>:
> 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
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
