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_man@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