Robert Rohde wrote “Noticing errors isn't the hard part, but the
common user will have a hard time figuring out how to avoid them.”
I couldn’t agree more. The {val} template takes care of details such
as making a slightly narrower <span> gap preceding the digit 1. It
also substitutes the somewhat longer looking, true mathematical
“minus sign” for the keyboard-typed hyphen when generating a
negative exponent.
Whenever {val} chokes on a big number or does one of its rounding
errors, the only work-around for editors that produces identical
functionality and appearance in an article is to code this:
2.718<span style="margin-left:0.25em">281</span><span style="margin-
left:0.2em">828</span>(30) × 10<sup>−23</sup> kg
This is totally beyond the ability of most editors, who expect {{val|
2.718281828|(30)|e=-23|u=kg}} to work.
So merely flagging rendered output with big red text that the {val}
template generated a rounding error would be minimally helpful. What
would be exceedingly helpful is if the math functions wouldn’t
produce rounding errors. Something tells me that fixing the math
functions would be time consuming. So, the best option of all, and
what the community needs, is one of the following:
1) for StringFunction to be made bullet proof, (as Jason Schulz
wrote), or
2) for a new general-purpose character-counting parser function to be
written (which many templates could use), or
3) for a magic-word-based version of {val} to be written.
It seems that StringFunction (option 1, above) has been buggy for a
long time and there is little interest in the developer community to
wade through it. To my mind, the most useful thing developers could do
is produce a really clean, elegant, bullet proof, tight character-
counting parser function.
One of the intricacies of the {val} template is that it follows the
ISO convention (also observed by the NIST and the BIPM) where numbers
are delimited in groups as follows:
2.1
2.12
2.123
2.1234
2.123 45
2.123 456
So there may be two, three, or four digits in the last group in order
that there is never a single hanging digit. Accordingly, the template
follows this logic:
Q1: Are there five or more undelimited digits remaining after the
decimal marker? No=Stop / Yes=Advance three digits and prepare to add
span gap. Goto Q2.
Q2: Is the span gap to be added following the digit “1”? No=Add a
span gap of 0.25 em and then goto Q1 / Yes=Add a span gap of 0.2 em
and then goto Q1.
Note too that the {val} template also needs to strip off any digits to
the left of the decimal marker and delimit them with commas.
How hard can can it be to make a parser function capable of supporting
this sort of “Q1/Q2” logic? I would think that some parser
functions are already available to use in the above logic that can
report to a template how many characters there are in the string. With
that information, the template could do the math and to know how many
groups of three there will be and whether the final group will have 2,
3, or 4 characters. I would also think that the new parser function
required to fulfill the rest of {val}’s needs would be very useful
for many other templates and would fulfill perhaps 80% of what
StringFunction would have ever been used for anyway.
I’m no programmer, but it seems to me that all this new parser
function needs to do is spit out a requested number of characters from
a string. After the template does the math on the number of characters
it is dealing with, it asks the new parser function “give me three
digits” … “give me three digits” … “and now give me four
digits”. Yes?
Greg L
I should think that there must already be a parser function that a
template could ask “how many characters are in the string”.
On Feb 1, 2009, at 3:13 AM, Robert Rohde wrote:
On Sat, Jan 31, 2009 at 10:21 PM, Daniel Friesen
<dan_the_...@telus.net> wrote:
> Output a big red error when giving numbers that will encounter a
> floating point error?
>
> Perhaps also provide a # of use limited #expr equivalent that will
> use a
> bignum library rather than normal numbers which can be used in cases
> where that big red error shows up.
Noticing errors isn't the hard part, but the common user will have a
hard time figuring out how to avoid them.
For example:
{{#expr:floor(0.00007*100000)}} = 6
{{#expr:0.07*100 = 7}} is False
{{#expr:5/6 = (1/6)*5}} is False
{{#expr:(10^16 + 1) % 10}} = 0
All of these are examples of floating point quirks, but at the same
time none of them is so complicated that analogous expressions
wouldn't come up in practical situations. From the point of view of a
non-programmer Mediawiki user, this behavior is both unexpected and
cryptic.
The first three are fixable, provided one applies some reasonable
tolerance for when two numbers are the same. The fourth would require
big math, or failing that should probably generate an error.
-Robert Rohde
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
