Jump to content

Template talk:Val/Archive 1

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1Archive 2Archive 3→Archive 5

New units feature

I added a feature that automatically translates easy to type unit names to proper HTML display of the unit, optionally with a link. See the documentation for the u argument and the examples for details. See the {{ScientificValue/units}} template for a list of supported units. Feel free to add more when needed.

I've added all units supported by {{convert}}. JЇѦρ 17:33, 8 April 2008 (UTC)

That doesn't seem to work correctly: See Scientific_Notation#Significant figures for an example:

{{val|1.602176487|(40)|e=−19|u=C}} (Coulomb) -> 1.602176487(40)×10−19 C
-- SkyLined (talk) 10:04, 9 April 2008 (UTC)
Thanks for the heads-up. I've fixed it also adding the farad which would have given us the same problem. {{Convert}} uses plain C and F for Celsius & Fahrenheit but we were getting a red link because ... it's complicated ... JЇѦρ 15:13, 9 April 2008 (UTC) ... and the rayleigh (same again). JЇѦρ 15:31, 9 April 2008 (UTC)

Deprecating redirects

I think {{val}} is the shortest, easiest to remember name for this template. Having the other two names complicates things without added benefit:

I've tagged {{ScientificValue/Units}} for deletion. JЇѦρ 17:20, 9 April 2008 (UTC)

I personally don't think it's a problem to have multiple redirects to a template. It lets the users choose whichever name is either easiest to type or easiest to remember (or some combination of the two). Plus, it sometimes helps users find the template if they don't a priori know the name of the template (e.g. you guess scientificvalue will be a template for displaying a scientific value). I wouldn't go about creating new redirects, but if they exist already then it's probably not expending the effort to delete them. Mike Peel (talk) 21:16, 9 April 2008 (UTC)

Having multiple names for one thing adds confusion and may have people think that there is a difference. I would much rather see an error message when you use the wrong template that explains which template should be used instead.


Look and feel

Parenthesis

Just to let you know that when you write things like (1234±35)×10−23 or 1234+12
−12×1010, it is very uncommon to have the parenthesis. I don't think they should be there by default. Headbomb (talk) 21:48, 9 April 2008 (UTC)

I agree, I've removed them, Maybe Mike wants to explain why he added them? -- SkyLined (talk) local time:14:53, 13 April 2008 (CET), server time: 13:53, 13 April 2008 (UTC)
Because unless they are there, I read it as 1234 with an error of 35 × 10, which is ridiculous. By putting both numbers in brackets, it makes it obvious that the × 10 applies to both numbers. Mike Peel (talk) 16:58, 13 April 2008 (UTC)
With all due respect, if you do not know how to interpret a certain notation, it is not the notation that is at fault. Let's try to follow commonly used convensions as much as possible and try to keep personal preferences out. (It is very unlikely we'll ever find a notation that everybody likes). I would suggest that we try to find some trustworthy references on the use of these notations, so we can implement the most commonly used one. -- SkyLined (talk) local time:09:30, 14 April 2008 (CET), server time: 08:30, 14 April 2008 (UTC)

minus vs dash

The template now automatically represents negative numbers using the minus sign (−) instead of a dash (-) but you will need to write the number using a dash to make it a negative number! (Eg. {{val|-1}} instead of {{val|−1}} or {{val|−1}}). This applies to exponent and uncertainty as well. -- SkyLined (talk) local time:12:53, 14 April 2008 (CET), server time: 11:53, 14 April 2008 (UTC)

Space between value and (uncertainty)

This has been removed; NIST uses no space.

Bugs in template

If you find a bug in this template, please let us know exactly what the problem is and try to avoid using {{val}} itself in examples: if you see something odd because your browser is odd, then others may not see what you see because they use a different browser. If possible, make a screengrab and dump it on the web somewhere, so we can see what you see. And please also let us know what type and version of browser and operating system you are using.

NOWRAP

...doesn't work. Go to the {{val/test}} page and shrink it's size so you can see the values wrap... Has anybody got a clue how to fix this? -- SkyLined (talk) 08:27, 17 April 2008 (UTC)

Trailing zeros missing

Can someone fix the bugs in: {{val|1.2340|0.0050}} → 1.234±0.5

so that it displays 1.2340±0.0050? Mjamja (talk) 18:28, 18 April 2008 (UTC)

This is a known issue, there is a theorethical fix, which I will try to implement soon.-- SkyLined (talk) 19:02, 22 April 2008 (UTC)

IE6

Exponents of 10 do not appear. For example, {{val|5|e=6|u=m}} appears as 5×106 m and this has made many articles unreadable. Q43 (talk) 02:55, 1 May 2008 (UTC)

What's wrong with how 5×106 m appears? Looks like 5 x 106 m to me.Headbomb (talk · contribs) 03:05, 1 May 2008 (UTC)

Over here it appears 5 x 10   m  !!! Q43 (talk) 03:14, 1 May 2008 (UTC)

Browser problem?Headbomb (talk · contribs) 04:38, 1 May 2008 (UTC)

Yeah, this problem happens with IE6 and is a problem in the way {{su}} creates sub/sup script, which is really complex because FireFox sucks. I may look into it at some point but don't hold your breath. Feel free to try and solve it yourself :). Btw. If you have IE6, can you let me know if this: 1+2
−3×104 contains the numbers 1, 2, 3 and 4? The 4 (exponent) should be missing, as reported, but I'm interested to hear if the 2 and 3 are visible at all? Thanks    — SkyLined {talkcontribs 01:59, 4 May 2008 (UTC)
I've created a temporary, partial fix by modifying {{su}} to use <sup> and <sub> when only sub- or sup-script is needed. When both are needed it still uses the original code, which does not wok for IE6. This means that uncertainty with two numbers, one over the other, does not work.     — SkyLined {talkcontribs 22:10, 4 May 2008 (UTC)

Precision bug

{{val|2.6033|0.0005|e=-8}} doesn't look like it's supposed to. Right now, it looks like ((2.6033±0.0005)×10−8), but should look like 2.603 3 x 10-8. - Unknown (please SIGN your posts!)

Seems to me like a precision problem; {{val}} uses math to calculate where to put spaces. This math is limited by the precision of the math module of wikipedia, which undoubtedly uses double or float. Apparently the precision is not sufficient to prevent rounding errors from modifying the value :(. The best way to solve this is to move away from math and use string functions. Unfortunately, they are not installed on wikipedia. Possible solutions:
  • Drop the formatting - this would violate the MOS.
  • Attempt to work around the rounding error - really complex, if at all possible.
  • Get wikipedia to install the string ParserFunctions modules - no clue if that's going to happen or how to request that.
  • Get some server side script in php do this - no clue if that's going to happen or how to request that.
    — SkyLined {talkcontribs 22:16, 4 May 2008 (UTC)

linking

It needs to be possible to _not_ link to the unit - i had to fix a few self-links in Kilogram. --Random832 (contribs) 21:18, 19 April 2008 (UTC)

Fixed with new arguments:

  • u = units
  • ul = units with link
  • up = units per
  • upl = units per with link

This means that effective immediately, all links have been removed from existing use of {{val}}. I assumed that this was not a mayor problem, you can add the link back in any instance of {{val}} by replacing u= and up= with ul= and upl= respectively. -- SkyLined (talk) 20:05, 22 April 2008 (UTC)

New {{val}} convention

I've taken the liberty to prune some of the old chat and summarized the main points of discussion. Please supply references where appropriate, especially if you make claims about guidance provided by third parties. Please refrain from putting your personal opions here, unles you are (somewhat of) an autority on the matter or if we really cannot find any proper guidance to follow. (To prove that personal opinion is bunk; I'd like to see all numbers printed backwards, in pink Wingdings, so let's not go there) -- SkyLined (talk) 10:20, 23 April 2008 (UTC)

Problem:

The problem is that there is some debate over automatic separation of groups of digits in long numbers into 123,123,123 and 0.123 123 123 (instead of 123123123 and 0.123123123). It has been suggested that this should be a feature that can be switched on and off.

Arguments:

  • The Manual of Style on large numbers and the results of the {{delimitnum}} discussions say that all wikipedia pages should use comma seperators for the digits before the decimal dot and thin spaces for the digits after it.
  • The main Manual of Style suggests that all pages across wikipedia should have the same look and feel as much as possible and individual pages should use the same style throughout, unles there is a good reason for discrepancy.
  • SI usage specifications clearly define against the use of comma's in large numbers, due to the possible confusion that may arise in different countries. SI suggests either spaces (123 123 123.123 123) or nothing at all (123123123.123123). commas should never be used. [1]
  • Commas actually make the number harder to read [1].
  • Commas are frowned upon by scientific organizations, they follow the SI guidelines, and so will not use commas for grouping digits.
  • Using {{val}} should be as easy as possible and not become a lot harder than typing the number as is. (Otherwise, no one will use it, which defeats its purpose.)

Options:

  • Possible options for the digit group seperator are: comma, thin space and nothing.
  • We can choose one seperator for all values or we can have one for "normal" values and another for scientific values.

{{val}} can be updated to allow you to choose between the two, should we choose the second option. Creating another template for this is also an option.

I'd support the user-specified seperation. By default it should follow the MoS for "normal" numbers ({{val|sd|123456789.987654321}} giving 123,456,789.987 654 321 and {{val|sd|123456789.987654321}} giving 123 456 789.987 654 32 for (sd=scientific delimitation). Headbomb (talk · contribs) 13:58, 28 April 2008 (UTC)
I concur; this is blatantly the correct solution. Further, I shall be removing uses of the val template until this is done to comply with WP:MOS. 87.254.68.31 (talk) 00:50, 11 November 2008 (UTC)


Discussion:

Please add anything you'd like to add here, or under one of the sub-sections above.

References

  1. ^ a b http://physics.nist.gov/Pubs/SP811/sec10.html#10.5.3 NIST-Grouping Digits
  • In case we end up choosing different seperators for "normal" numbers and scientific values, I am against creating a second template and would rather see an extra argument to {{val}}. The reason for this is maintenance: there is a good chance that somebody will change one template and forget to change the other as well, causing differences between the two and thus differences between pages that use them, which is what this template is meant to prevent. Should a second template make things easier to the user, I suggest we make it a wrapper for {{val}} that adds the argument I suggested, so that we also won't have the maintenance issue. -- SkyLined (talk) 10:20, 23 April 2008 (UTC)

val template has a serious flaw

This one is a deal-breaker, folks.

Over on the light-year article, {{val|3.086|e=13|u=kilometers}} displays as 3.86 (current testcase results in: 3.086×1013 kilometers), when it should display as 3.086. I'm not good enough at the scripting to see why it drops that zero, but it does. Rhialto (talk) 05:34, 23 May 2008 (UTC)

I was the one who put {{val}} onto Light-year not realising that there was a problem ... yeah, and not checking. The fact that {{val|3.860|e=13|u=kilometers}} gives "3.86×1013 kilometers" is bad enough but {{val|3.086|e=13|u=kilometers}}'s giving the same is, as Rhialto says, a deal-breaker. Both problems have got to be fixed if this template is to be of any use. JIMp talk·cont 06:56, 27 May 2008 (UTC)
Status: I checked a value that is present in the Kilogram article that uses a workaround because of this problem with Val
  • (≈6.02214098 × 1023) atoms.
I tried the Val template on it, just in case someone fixed it without mentioning it on the talk page. Here is the result:
  • 6.02214098×1023
I see that the last digit has been changed from 8 to 79, indicating the problem still exists. --Gerry Ashton (talk) 00:35, 10 October 2008 (UTC)

Two more bugs

  • {{val|1.00794|0.00007}} gives 1.00794±0.00007.
  • {{val|9|2|e=-4}} gives (9±2)×10−4. If it's technically possible, there ought to be parentheses around the 9 ± 2, otherwise it looks like it means 9.0000(2).
  • (I noticed this while writing this post.) {{val|9.0000|(2)}} gives 9.0000(2).

— Preceding unsigned comment added by Army1987 (talk • contribs) 21:01, 18 October 2008 (UTC)

The template is limited in what it can do as it reads what you input as numbers rather than text. Bullet #1 and #3 can't be fixed as of now, and bullet #2 isn't a bug/error. This is how values are reported. (1.3±0.3)×10−10 always means (1.3 ± 0.3) × 10−10 and never 1.3 ± (0.3 × 10−10) Headbomb {ταλκκοντριβς – WP Physics} 22:23, 19 November 2008 (UTC)

Proposal: constant values by name/symbol

I've thought of a new feature: allow constant values to be represented by a name or their symbol, as in:

{{val|c}} → 299792458 m/s (speed of light) and
{{val|h}} → 6.62606896(33)×10−34 Js (Planck's constant).
etc...

I think it would be good to have this because:

  • This makes it impossible to make a mistake and type or copy+paste the wrong number in an article
  • This makes it easy to update these values on all pages (eg. should a new measurement of the value provide more accuracy)
  • This prevents different pages from using different values or representations of the value. (I've seen that for Planck's constant)

And finally:

  • This makes it easier to write and edit pages - no need to look up or copy+paste the correct value.

I think this feature can be added to this template, but we could also consider making another template as a wrapper for {{val}}. Adding it to {{val}} has the benefit that people do not need to remember two template names. A drawback would be adding more complexity to {{val}}. I'm not sure which one would be faster/less of a load on the server. Let me know what you think about this. Don't expect anything from me in the near future, as I am very short on time. I'll get around to this eventually though. Also, I will need somebody to modify {{val}} for me or give me access as I lost the ability to edit it when it got locked. I can create the new code somewhere else first, it would only need to be copy+pasted over the current code once it's done.

    — SkyLined {talkcontribs 19:00, 19 November 2008 (UTC)

I don't think this is necessary or useful.

  • Cut and paste should be a trivial operation for anyone who claims competence to write entries in an encyclopaedia (admittedly, this is a weak point, considering the amount of trollery on WP).
  • Articles that discuss these units rarely give their value in just a single set of units, so someone would still need to do the funky conversion stuff.
  • The number of articles in which each specific value would be used is quite limited. Programming in these values is a lot of work for little gain.
  • Some letters are used for more than one constant (can't think of any offhand, but I'd be astounded if there was no such multiple usage).
  • Newer, more accurate, values for these constants aren't normally generated by their respective scientific bodies more than once every few years at most. There is no need that is being fulfilled by the automation of being able to rapidly update a single entry.

Rhialto (talk) 20:14, 19 November 2008 (UTC)

I think this is rather outside the scope of {{val}}. However a template such as {{constant}} would be pretty useful.Headbomb {ταλκκοντριβς – WP Physics} 22:22, 19 November 2008 (UTC)
@Headbomb:
{{constant}} does make more sense.
@Rhialto:
To copy+paste a value, you would need to find a page with the correct value, make sure the value has not been vandalized and make sure you copy all of it. Trivial or not, with the number of pages being edited and created, I'm sure it will go wrong at some point. Using one template for all values makes it easier to find the value you need, easier to protect the value from vandalism and you cannot accidentally mess up your copy+paste (Automatic error checking can report incorrect use in Category:Pages with incorrect formatting templates use). All in all, it would increase the reliability of Wikipedia and make it easier for editors.
Humans are more error prone than machines, so let them do the calculating where possible. We can add an option to convert constants, eg. {{constant| constant name [|units] }} (similar to what {{val}} has) With a lookup table for conversion factors that are automatically applied.
What number of pages do you think is sufficient to warrant this? The number of pages on the english wikipedia that contain the speed of light as text is ~144. Replacing existing values can be automated.
"Name collisions" is an inconvenience that can easily be solved by using something a bit more descriptive, eg the name of the constant. It so happens that "c" is used for both the speed of light as well as the speed of sound. One could use {{constant|lightspeed}} instead of {{constant|c}}, which would make it better readable to editors as well. The template would of course have a table in which you can look up any value for your convenience, similar to {{SubatomicParticle/list}}.
I'm not sure how much time you have, but I'd rather spend it creating new content than updating old content.
    — SkyLined {talkcontribs 17:09, 26 November 2008 (UTC)

War on rounding errors

If have left code changes at Template talk:Val/delimitnum/real and Template talk:Val/delimitnum/firstgroup that should eliminate all rounding errors for significands having 10 or fewer digits. I applied the changes directly to Template:Val/delimitnum/group which is unprotected for some reason. Significands having 11 or more digits e.g. 1.23456789123×1024 will have roughly a 50% chance of being wrong in the last digit. That is "bad", but at least it is "bad" in a predictable way and people can be encouraged to write out very precise numbers by hand. Dragons flight (talk) 21:07, 8 February 2009 (UTC)

PS. This does not solve, or in anyway affect, the problem of dropped trailing zeros. So 0.05600 will still be 0.056. Dragons flight (talk) 21:09, 8 February 2009 (UTC)
I applied the changes to the two protected templates. — Carl (CBM · talk) 21:37, 8 February 2009 (UTC)

Trailing zeros

I've created {{trailingzeros}} that can count the number of trailing zeros on the end of a number. Using that and similar logic, one should be able to patch the problem of dropped zeros. I do not plan to do so myself during the foreseeable future. Dragons flight (talk) 04:38, 9 February 2009 (UTC)

The final solution

I hope so anyway.

I have fundamentally reimplemented {{val}}.

Please replace Template:val/delimitnum with 

<noinclude>{{documentation|Template:val/doc}}</noinclude><!--
-->{{#ifexpr:{{{1|0}}}<0|&minus;}}<!-- Output minus if negative
-->{{val/delimitnum/logic|{{{1|0}}}|{{{1|0}}}1}}<!-- Output value (always positive)
--><includeonly>

and protect the new auxiliary templates Template:val/delimitnum/logic and Template:val/delimitnum/fraction.

Previous templates Template:val/delimitnum/real, Template:val/delimitnum/group, and Template:val/delimitnum/firstgroup are no longer used, and references to them in the documentation can presumably be removed.

This should:

  • Put an end to the trailing zeros problem (YAY!!)
  • Eliminate bugs associated with leading zeros after the decimal point (less common, but also annoying).
  • Allow val to correctly format all numbers with less than 13 digits.
  • Allow val to sometimes format numbers up to 15 digits.
  • Force val to generate an error message if the operand is longer than 15 digits. (It also sometimes generates an error on 14-15 digit cases if it can tell it will fail.)
  • Decrease the preprocessor load associated with val by about an order of magnitude.

I've tested a wide range of cases but please send me error reports if there are problems after this goes live. Dragons flight (talk) 19:56, 10 February 2009 (UTC)

  • Testing: {{val|5.1234567890100|(32)|e=-23|u=kg}} → 5.1234567890100(32)×10−23 kg
    <pouted_lower_lip>Dragon flight’s new version not “live” as of this post.</pouted_lower_lip>
    Thanks a million Dragon. Greg L (talk) 20:12, 10 February 2009 (UTC)
  • Real life calls. A quick check of Kilogram shows nothing that looks out of the ordinary. I did some quick screen captures and I can’t see any difference at the pixel level (although) I might have grabbed my first set after the changeover). Back later. Thanks. Greg L (talk) 20:29, 10 February 2009 (UTC)

I posted a correction at Template talk:Val/delimitnum/fraction that closes some dangling <spans> which led to formatting issues in some cases. Dragons flight (talk) 23:11, 10 February 2009 (UTC)

  • Yup. Saw it. That happened more often than I care to admit when I started messing with span-based gaps. When I got back from a meeting, I spent more time looking over Kilogram and figured out on my own that there must be some unclosed spans. I alerted MBisanz of the waiting update to Ver. 2.0.1. Greg L (talk) 00:00, 11 February 2009 (UTC)
Yeah, it is easy to miss bugs that principally only affect material that comes after the material you are interested in. Dragons flight (talk) 00:22, 11 February 2009 (UTC)
So, any remaining problem now? Will error messages ALWAYS show up whenever there would be an error in the output? Headbomb {ταλκκοντριβς – WP Physics} 03:46, 11 February 2009 (UTC)
  • See below. Also, I’ve notified Dragon flight on his talk page about the sandbox so he can help certify that {val} is formally ready for prime time. As far as I can tell from working on my new sandbox, it works flawlessly within its stated limitations. Greg L (talk) 04:09, 11 February 2009 (UTC)

It appears that some of the WMF servers have PHP's precision set to 12 digits. The logic in {val} ought to work correctly 100% of the time through 13 digits, but on the servers that are (mis)configured to only allow 12 digits, that imposes a hard upper limit of 12. I'm not sure how many servers that is. Certainly more than 1 but also much less than half. I think this is the source of the occassional error that Greg mentions below. This is an annoying problem because it is intermittant, so it may render correctly one moment and incorrectly the next. Given this, I think the advice needs to be not to use this with more than 12 digits. I have put a request in to try and track this down. I am hoping it will be possible to at least get all of the servers to render the same way, though whether that will be 12, 13, or 14 digits, I don't know.

To answer Headbomb's question, I am not aware of any scenario where the current logic will allow a wrong answer to be displayed (i.e. an error message may always shows up when there is a problem). However, I am not 100% confident that no such situation could exist, so there might be some uncommon circumstance where the last digit is wrong on very high precision input and no error message is available. Dragons flight (talk) 05:27, 11 February 2009 (UTC)

Correction

Moved from Template talk:val/delimitnum/fraction
 – * Pppery * it has begun... 15:53, 11 October 2021 (UTC)

Closes dangling spans. Dragons flight (talk) 23:11, 10 February 2009 (UTC) 

<includeonly>{{#ifexpr:{{{2}}}>14|{{FormattingError|Too Many Digits}}|<!--
-->{{#ifexpr:{{{2}}} >= 1|{{#expr:{{{1}}}*10 mod 10}}<!--
-->{{#ifexpr:{{{2}}} >= 2|{{#expr:{{{1}}}*100 mod 10}}<!--
-->{{#ifexpr:{{{2}}} >= 3|{{#expr:{{{1}}}*1000 mod 10}}<!--
-->{{#ifexpr:{{{2}}} > 4|<span style="margin-left:0.25em">}}<!--
-->{{#ifexpr:{{{2}}} >= 4|{{#expr:{{{1}}}*10000 mod 10}}<!--
-->{{#ifexpr:{{{2}}} >= 5|</span>{{#expr:{{{1}}}*100000 mod 10}}<!--
-->{{#ifexpr:{{{2}}} >= 6|{{#expr:{{{1}}}*1000000 mod 10}}<!--
-->{{#ifexpr:{{{2}}} > 7|<span style="margin-left:0.25em">}}<!--
-->{{#ifexpr:{{{2}}} >= 7|{{#expr:{{{1}}}*10000000 mod 10}}<!--
-->{{#ifexpr:{{{2}}} >= 8|</span>{{#expr:{{{1}}}*100000000 mod 10}}<!--
-->{{#ifexpr:{{{2}}} >= 9|{{#expr:{{{1}}}*1000000000 mod 10}}<!--
-->{{#ifexpr:{{{2}}} > 10|<span style="margin-left:0.25em">}}<!--
-->{{#ifexpr:{{{2}}} >= 10|{{#expr:{{{1}}}*10000000000 mod 10}}<!--
-->{{#ifexpr:{{{2}}} >= 11|</span>{{#expr:{{{1}}}*100000000000 mod 10}}<!--
-->{{#ifexpr:{{{2}}} >= 12|{{#expr:{{{1}}}*1000000000000 mod 10}}<!--
-->{{#ifexpr:{{{2}}} > 13|<span style="margin-left:0.25em">}}<!--
-->{{#ifexpr:{{{2}}} >= 13|{{#expr:{{{1}}}*10000000000000 mod 10}}<!--
-->{{#ifexpr:{{{2}}} >= 14|</span>{{#expr:{{{1}}}*100000000000000 mod 10}}<!--
-->}}<!--
-->}}<!--
-->}}<!--
-->}}<!--
-->}}<!--
-->}}<!--
-->}}<!--
-->}}<!--
-->}}<!--
-->}}<!--
-->}}<!--
-->}}<!--
-->}}<!--
-->}}<!--
-->}}</includeonly>
Done, Vsmith (talk) 01:10, 11 February 2009 (UTC)

Val sandbox

I’ve got a sandbox here: User:Greg L/Val sandbox where I have exercised the tar  out of {{val}}. So far, I see that {val} performs exactly as Dragon flight described it would here. I think {val} is now bug free. From what I can see, Headbomb, it always generates a red error flag when there is a problem, and that only occurs when it is fed too many digits. The {val} template always handles 12-digit numbers perfectly and sometimes will generate errors with 13 and 14-digit values. It will almost never handle 15-digit numbers, but might handle them properly on occasion (I haven’t seen it). So far, there is only one value on Kilogram that {val} can’t digest: 1,579,800.298728 (because it has 13 digits, and sometimes—not often—generates an error). Greg L (talk) 04:07, 11 February 2009 (UTC)

See above. Also {{val|120.120340560780}} = 120.120340560780 from your sandbox is 15 digits and renders correctly when the server is in a compliant mood. Dragons flight (talk) 05:30, 11 February 2009 (UTC)
  • Yes, I see what you wrote above regarding different settings on different servers and I saw your e-mail. I think you have a sound theory. And if it helps any, I added a “15-digit progression section. It appears that if you luck out and get a 14-digit-capable server, 15-digit numbers that end with zero will also render. But 15-digit numbers that end with 1–9 won’t. Greg L (talk) 06:35, 11 February 2009 (UTC)
Actually, the error checker is being conservative. If you call {{val/delimitnum}} directly, rather than {{val}}, it will render many cases correctly (plus a few wrongly) that it otherwise gives up on. At some point I may think about improving it so it discards fewer workable cases, but not right now. Dragons flight (talk) 06:52, 11 February 2009 (UTC)

Uncertainties alignment (in the + x - y case).

2.00+13
−2 should have the 3 and the 2 aligned together for readability. Headbomb {ταλκκοντριβς – WP Physics} 11:45, 15 February 2009 (UTC)

That should be doable using the "a=r" argument of {{su}}     — SkyLined {talkcontribs 17:28, 18 February 2009 (UTC)

{{editprotected}} Here's the modification that's needed (view-source to see what I mean): 

                    --><span style="white-space:nowrap;margin-left:0.3em;">{{su|<!-- Uncertainty = +X -Y (3 arguments)
                      -->w=f|a=r|<!-- Fixed width, right aligned
                      -->p=+{{val/delimitnum|{{{2}}}}}|<!-- Output +arg2, formatted.
                      -->b={{val/delimitnum|{{{3}}}}}<!-- Output -arg3, formatted.
                    -->}}</span><!--

(I moved the w=f to the next line as well for clarity). I'll find somebody to do the edit as I am still not able to edit it myself because of the protection.

    — SkyLined {talkcontribs 19:00, 18 February 2009 (UTC)
I noticed this and hoped it'd be fixed. However, I can't find how to do this, so I've temporarily unprotected the template (per your request on my talk page) so you can make the adjustments. Let me know when you're done. Best, PeterSymonds (talk) 10:30, 21 February 2009 (UTC)

Changes made and seem to work fine. Also a note to Skylined, <pre></pre> is a better choice than <code></code>.Headbomb {ταλκκοντριβς – WP Physics} 10:45, 21 February 2009 (UTC)

I'd ask for reprotection, but maybe Skylined has additional changes he wants to bring to this, so I'll let him ask for reprotection.Headbomb {ταλκκοντριβς – WP Physics} 10:48, 21 February 2009 (UTC)

Double uncertainties

Many times it would be usefull to use {{val}} to report values such as 25.4 ± 1.2 ± 3.5. We should expand val to cover these cases as well.Headbomb {ταλκκοντριβς – WP Physics} 10:04, 22 March 2009 (UTC)

That was fairly easy to do: We use {{val|25.4|1.2|-3.5}} for 25.4+1.2
−3.5, we can use a positive third argument for this new format. Here's an example: {{User:SkyLined/val|25.4|1.2|3.5}} → User:SkyLined/val.
    — SkyLined {talkcontribs 19:55, 22 March 2009 (UTC)
The template is not yet fully protected, if you could check my code doesn't break anything I didn't consider, I can add this feature now.
    — SkyLined {talkcontribs 19:57, 22 March 2009 (UTC)
I'm thinking that we may want to reserve {{val|25.4|1.2|3.5}} for a double-positive tolerance (i.e. 25.4 +1.2/+3.5). Although strictly speaking, that would conventionally be represented as 25.4 +3.5/+1.2 (or conversely, 25.4 -1.2/-3.5 if the tolerance band was in the negative direction). Theoretically, we might implement nesting {{val}}s (e.g. {{val|{{val|25.4|1.2|1.2}}|3.5|3.5}}), but I can't imagine that working very well in practice. In any case, I've never seen 25.4 ± 1.2 ± 3.5 used: what's the reason behind giving a second tolerance/uncertainty band? (Is that conventional in some scientific applications?) TheFeds 01:03, 6 April 2009 (UTC)
It's used to distinguish what is "systematic" uncertainty with "data-related" uncertainty. See [1] for an example of this use. Headbomb {ταλκκοντριβς – WP Physics} 18:57, 8 April 2009 (UTC)

We can always fork {{val}} into multiple smaller templates, eg. create {{val ±±|X|Y|Z}} for X ± Y ± Z and {{val /|X|Y|Z}} X +Y/+Z. That would keep the code in each template simpler than putting everything in one template. The documentation can explain which template to use for what format, similar to how it now tells you which arguments to use (see discussion below about a similar split). If that works well, we could even decide to split the currently supported formats into separate templates as well (it should be relatively easy to replace existing use of {{val}} with the correct sub-template for each use case automatically).

    — SkyLined { talkcontribs 08:45, 9 April 2009 (UTC)

Digit grouping

I see that there was a proposal about a year ago (c. April 2008) to harmonize the digit grouping, which is currently different depending on which side of the decimal point you're reading (non-breaking space versus comma). Given that {{val}} is most useful in scientific and engineering contexts, and the fact that the MOS suggests its use in these situations, it probably ought to follow ISO 80000-1 (former ISO 31-0) and NIST SP 811 10.5.3 which are the accepted international and American standards for this purpose. (Note that old versions of the MOS did not account for the scientific/engineering case, and suggested commas only; nowadays, the MOS suggests non-breaking spaces as well.)

As justification, consider the article on ISO 31-0 (which draws from section 3.3 of ISO 31-0):

Numbers consisting of long sequences of digits can be made more readable by separating them into groups, preferably groups of three, separated by a small space. For this reason, ISO 31-0 specifies that such groups of digits should never be separated by a comma or point, as these are reserved for use as the decimal sign.

Further, from NIST SP 811 10.5.3:

Because the comma is widely used as the decimal marker outside the United States, it should not be used to separate digits into groups of three. Instead, digits should be separated into groups of three, counting from the decimal marker towards the left and right, by the use of a thin, fixed space. However, this practice is not usually followed for numbers having only four digits on either side of the decimal marker except when uniformity in a table is desired.

So, I suggest that we modify the default behaviour of {{val}} to incorporate a small CSS gap (as in {{gaps}}) as the digit grouping symbol (or, if necessary for technical reasons, the thin space character), within {{nowrap}} elements. If desired, and as proposed by SkyLined, we could implement alternate symbols for digit grouping and decimal indication as parameters: {{val|29923.393434|dg=.|dp=,}}, which would return a number formatted with the old-style western European convention, 29.923,393.434. Either way, the current commas-on-the-left, spaces-on-the-right convention is non-standard, messy, potentially confusing, and rarely encountered in practice. TheFeds 00:49, 6 April 2009 (UTC)

I developed the template to allow easy modifications to the standardization of number formatting so if the current formatting is non-standard, I am all for changing it. Unfortunately, I have no experience or authority in this area, so I'll leave the decision making to people who do. However, this template talk page is not the right place for discussions about Wikipedia styles. This discussion should be taken to the relevant MOS pages. Only when consensus is reached should we modify the template. (But feel free to create a copy with the required modifications if you have the time, so we can replace the current code with whatever you come up with if we do decide to change it).
Because this template is likely to get ported to other Wikipedia languages (there already is an Italian version), it would indeed be useful to support different digit grouping/decimal indicators. However, this template is designed to create scientific notation of numbers, so adding a feature to allow non-scientific numbers as well may "overload" the template with features, making it require more CPU to process and cause pages to load slower. Because there are not that many variations on digit grouping/decimal indicators, it might be better to create multiple copies of the template with such differences hard-coded into them, eg. {{val-eu}} to support "european" format. The drawback of creating multiple copies is that some changes to the template would have to be made in multiple copies of the template, but since there are not that many variations on the theme, I think it's preferable to adding more complexity to an already complex template.
    — SkyLined { talkcontribs 09:06, 6 April 2009 (UTC)
Given that the current version of WP:MOSNUM#Large Numbers says "In scientific and mathematical contexts, {{gaps}} may be used to insert thin spaces, e.g. use {{gaps|8|274|527}} to produce '8274527'", isn't that pretty explicit support of that output format (in those contexts)? Even though it calls out {{gaps}} and not {{val}}, isn't it recommending the format provided by {{gaps}} rather than mandating that {{val}} can't be used for this purpose? Right now, the MOS allows either digit grouping format and either template, but they result in different output: 8274527 = 8274527.
Basically, I think that discussion on the MOSNUM page has already resulted in consensus and an MOS change, and that we can therefore proceed accordingly at the template level.
Regarding expanding the template: isn't it preferable to make the template itself more complex, in order to make it easier for editors to pick the right template, and keep the MOS simple? (If we went to {{val-eu}}, etc., wouldn't that tend to require a paragraph in the MOS describing the several variations and their purposes? Contrast this with a feature that is part of {{val}}—the MOS already recommends the template, so there's no need for a change.) TheFeds 16:32, 6 April 2009 (UTC)
Regarding template complexity: I am proposing we introduce a new template eg. {{val-eu|...}} rather than provide the functionality through an argument {{val|eu|...}}. When done in this fashion, this does not make using the template more complex. Have a look at Category:Nuclide templates, which is a good example of a set of templates that perform very similar tasks rather than have one template (that would be very complex). Let me know if a similar solution for {{val}} (with one doc page describing all the templates, so far only two) sounds like an acceptable solution to you.
    — SkyLined { talkcontribs 21:04, 6 April 2009 (UTC)
I see what you're suggesting there; that's better than I expected. I was concerned about a situation like {{cite x}}, where the templates are each documented separately, behave differently (in terms of output formatting), and aren't called out in the MOS together.
In terms of digit grouping, I can think of the western European convention, the British convention, the Indian convention and the ISO/NIST convention—but those aren't widely recognized terms, and they have a bias toward certain places (e.g. Indian convention also used in Pakistan and Bangladesh). We'd have to settle upon some appropriate identifier for the new {{val-?}} variants. I suppose we could instead do it so that we identify the variants by their ISO 3166 country codes, and then apply whatever format is recommended by that country's standards body. (But maybe doing it that way would be easier to implement as an argument to val: {{val|13234234|c=IN}} returns 1,32,34,234, formatted according to the Indian convention.)
Actually, despite that, I'm thinking now that we might want to avoid encoding nationalities of any type into the template—that could provoke the same sorts of edit wars that occur around American vs. British spellings. It's probably less controversial to set {{val}} up to use the scientifc convention by default, and encode a {{val-alternate}} that lets the user specify a formatting convention by themselves (choose grouping character, decimal character and grouping scheme) without the excess baggage of national origin.
There's also an argument for keeping it within {{val}}, and using extra parameters: it means that once a new user knows {{val}}, they don't have to discover {{val-eu}}, {{val-gb}}, {{val-in}}, etc..
Finally, autoformatting may eventually be implemented so that users can set their preferences, and always view in one particular format. This is getting tossed around for dates, over in MOS-land. One of the obstacles there is that there isn't already a de facto standard template for dates—but {{val}} is sort of standard based on MOSNUM. If such autoformatting were implemented, it would be simple to override the behaviour of {{val}} easily, rather than have to be applied over top of a whole family of templates. TheFeds 05:05, 7 April 2009 (UTC)
Regardless of how you want to identify the various formatting schemes, they can be implemented as arguments or separate templates: {{val|c=X|...}} vs. {{val X|...}} (or {{val-X|...}}).
I think adding this to the (already very complex) code would make the template code near impossible to understand and maintain for anybody who is not familiar with them. Also, we've had issues with high server load because of very complexity templates in the past, let's try and avoid that by not adding even more if statements.
The current code is only reasonably readable because I added a large amount of HTML comments to format it a bit (all of which ends up in the final page that is sent to the user without adding anything useful). I originally developed this as a set of templates ({{val±|...}}, etc...) but later merged them into one because I thought it would make things easier. I wish I had not: Category:Nuclide templates shows that using multiple templates can be just as easy to document/understand as using an argument. As you can see from the code in those templates, they are a lot simpler to understand and take less time to process on the server. The documentation is also straight forward and easy to understand because of the use of a Category.
If at some point Wikipedia develops the possibility to allow custom formatting schemes, we can always merge the templates into one "master template" and use a regular expression to replace all uses of {{val X|...}} with {{val|c=X|...}} to remove references to the old templates. Until that time, the above arguments stand; it's easier to maintain multiple very similar and simple templates than one very complex one and it causes less server load.
    — SkyLined { talkcontribs 20:30, 7 April 2009 (UTC)

The discussion at WT:MOSNUM seems to have concluded, and the WP:MOSNUM has been revised to accept traditional US grouping with commas to the left, or the BIPM style, with the option of omitting the thin space if there are exactly 4 digits to the left or right of the decimal point. Is it time to revise this template to conform to the revised MOSNUM? --Jc3s5h (talk) 16:21, 7 July 2009 (UTC)

Header/footer vs. prefix/suffix

Wouldn't it be more correct to call the header and footer fields prefix and suffix instead? (Header and footer imply above and below, and could be confused with "text to be displayed over or under the value".) If changed to p and s (for example), I suppose the deprecated h and f parameters would need to be retained for backward compatibility. TheFeds 18:47, 7 April 2009 (UTC)

From a purist point of view: yes it makes more sense to call them that. From a practical point of view: I have better things to do :). If you want to find out how much work this is, you could add a Category to the template so every page that uses the argument in the template is added to this category, in order to determine how many (and which) pages would need the change.
    — SkyLined { talkcontribs 19:57, 7 April 2009 (UTC)
Are you thinking of something like this at the bottom of {{val}}:
...
<!--
EXAMINING USAGE OF H AND F PARAMETERS:
-->{{#if: {{{h|}}}|[[Category:Pages using val header or footer parameters]]}}<!-- If h is defined, add to category.
-->{{#if: {{{f|}}}|[[Category:Pages using val header or footer parameters]]}}<!-- If f is defined, add to category.
--></includeonly>
And then, doing this to use the new parameters while retaining backward compatibility:
{{{p|{{{h|}}}}}}<!-- If p is defined, display p; if p is not defined, but (the deprecated parameter) h is defined, display h; if h is not defined, do nothing.
-->
And so on for f and s. (That throws away h if p is defined, which I believe is the desirable behaviour.)
I think this change would be valuable, and relatively simple. Obviously we could make a bot request once the category listing was populated, to update any deprecated usage. TheFeds 16:46, 8 April 2009 (UTC)
Does anyone have any comments on the changes that SkyLined and I suggested, or the rationale behind them? I've done a bit of userspace testing on it, and it appears to have no effect upon the output of {{val}}, except as described (throwing out h if p, and f if s). If nobody has objections, I'll make the changes. TheFeds 16:43, 13 April 2009 (UTC)
I don't care either way, just make sure you have a bot ready and have the old parameters produce a cleanup category to facilitate bot work.Headbomb {ταλκκοντριβς – WP Physics} 19:11, 13 April 2009 (UTC)
I'm fine with the change as long as the deprecated h/f arguments will continue to output a warning/error for at least half a year: people may continue to use them without knowing they have been deprecated which could lead to confusion if they do not output anything.     — SkyLined { talkcontribs 07:43, 14 April 2009 (UTC)

Can someone point me to a page where they've used {{val}}.h or .f? I'm wondering whether we're the only ones who know about it, given there's exactly one article using header or footer in Category:Pages using val header or footer parameters. I've tried making dummy edits to the category page, adding a test page to the category to update it, purging and refreshing, and waiting for a day. The job queue is low, and has been since at least yesterday: apparently, there's nothing wrong with the category itself. So I'm wondering: is it just that nobody uses these parameters? (If that's true, then I don't think the half-year idea matters too much.) TheFeds 22:06, 14 April 2009 (UTC)

That could well be true - which is a lucky break :). I say go ahead and remove it altogether if the category is empty after you modified CNO cycle - no need to keep stuff that nobody uses around :).
It's all done. Interesting how that turned out.... TheFeds 06:32, 21 April 2009 (UTC)

Horizontal lineup problems when placed in <small> tags

  • The regular 104+36
    −24     looks fine. (Could be a weeeeeeeeeeeee bit higher if you ask me, but thats a rather minor complaint)
  • The errors in 104+36
    −24     don't line up properly for me. They are slightly lower than they should be. This is more of a problem. Headbomb {ταλκκοντριβς – WP Physics} 14:52, 31 May 2009 (UTC)
Same here using Chrome 2.0. This is a problem in {{su}}. I've copied this discussion there.
    — SkyLined (talk) 21:54, 4 June 2009 (UTC)


Pending changes to match the MoS

WP:Manual of Style (dates and numbers) has recently been changed. The current digit grouping used in this template does not follow the MoS (unfortunately, it never did). I suggest we change {{val}} to use thin spaces on either side of the decimal separator. If there is a need, we could consider adding an option to use comma's on the left and no separators on the right (which is another accepted format). Please let me know if you have objections to this. Of course, if you object to the MoS, you should complain there. But do let me know if you expect the changes to the MoS to get undone - it would safe me time not having to change stuff and then revert it later.

    — SkyLined (talk) 21:48, 4 June 2009 (UTC)
After being unchallenged for about a week, the change was reverted. Please participate in the RfC: WT:MOSNUM#RfC: Is 4,046.8564224 an acceptable number format? --Jc3s5h (talk) 02:13, 13 June 2009 (UTC)

I'm not going to: I don't care either way and can't be bothered with these looooong discussions. I'm just here to make {{val}} output numbers in a format supported by the MoS.     — SkyLined (talk) 22:24, 13 June 2009 (UTC)

WP:MOSNUM appears to have settled down and I believe it is now appropriate to make the template use the appearance of thin spaces on both sides of the decimal point. --Jc3s5h (talk) 17:07, 18 August 2009 (UTC)
I spoke too soon; discussion of this matter has resumed at WP:MOSNUM. --Jc3s5h (talk) 12:34, 19 August 2009 (UTC)

val-template values needed to be sortable

I converted my data into this WP-appreciated form using {{val|MANTISSA|e=EXPONENT}} . But how can I use it in class="wikitable sortable"? On default, only the mantissa values are sorted. :-( Regards, Achim1999 (talk) 15:50, 25 June 2009 (UTC)

I read Help:Sorting and it does not seem to explain how to sort numbers in scientific notation. So, how did you sort numbers in scientific notation before you started using Val? --Jc3s5h (talk) 16:07, 25 June 2009 (UTC)

I did not do it automatically here. I must sort all the data externally (on UNIX with sort -g) and then copy them into the edit window. The problem is: new data or to-be corrected data must also sorted in manually by hand. If I could use "wikitable-sortable", then this data can simply be added at the end of the whole table. It would be a real pity generally, if sorting of this notation is not possible on WP, IMHO. Regards, Achim1999 (talk) 16:30, 25 June 2009 (UTC)

Well there might be a way of implementing at least a partial sortability using the {{hs}} template (or a similar template). I'll investigate.Headbomb {ταλκκοντριβς – WP Physics} 17:18, 25 June 2009 (UTC)

Yes, thank you for your {{hs}}-trick, I was not aware. One could indeed duplicate all the values and transform the original values into its logarithmic value as a hiden key (in my case all values are positive), but ugly because one needs all sortable data doubled. My table data is already blown up a bit artifically due to the fact that I don't know how else to align the cells vertically. (Still no expert on wikitables has responded to my further problems with wikitables). Regards, Achim1999 (talk) 18:09, 25 June 2009 (UTC)

I'm working on a solution right now. I'm making good progress, and should have something ready for full deployment by monday. See Help:Table for your alignment issues.Headbomb {ταλκκοντριβς – WP Physics} 14:00, 26 June 2009 (UTC)

Thanks once more. I am curious what you will surprise me with :). Now I think writing a special template which internally transform stuff should be a reasonable solution. BTW: I'm fully aware of this decimal-point-centering example in [[Help:Table], if you mean this by 'alignment issues'. Regards, Achim1999 (talk) 15:07, 26 June 2009 (UTC)

I've hit a noose, but not impossible to resolve. I'm rather busy right now, but I'll get back to it sometimes this month when I have more time hopefully.Headbomb {ταλκκοντριβς – WP Physics} 04:54, 13 July 2009 (UTC)

Bug in this template

In the article titled Sun, I found this:

Its orbital speed was thought to be 220±20 km/s,

That obviously violates WP:MOSMATH, so I decided to edit it to say this:

Its orbital speed was thought to be 220 ± 20 km/s,

That's when I learned of the existence of this template. What I found was this:

Its [[orbital speed]] was thought to be {{val|220|20|ul=km/s}},

Can someone fix this? I don't know how to edit things like this. Michael Hardy (talk) 16:59, 26 July 2009 (UTC)

It works for me; what is wrong with the output of the val template? --Jc3s5h (talk) 17:33, 26 July 2009 (UTC)

What is wrong with it is what I explained above. Did you read that? Are you saying that particular problem doesn't happen for you? Michael Hardy (talk) 18:05, 26 July 2009 (UTC)

All right, let's try it with the template and then both the incorrect and correct forms without the template:

The orbital speed was thought to be 220±20 km/s.

The orbital speed was thought to be 220±20 km/s.

The orbital speed was thought to be 220 ± 20 km/s.

Viewed from this browser window, the template form (the first one) looks OK; the second one looks incorrect (as intended) and the third one is the standard format and looks correct.

Now I am again looking at this version and now it looks OK, although when I looked at it before my recent edits it looked like the second form above. Could this be dependent on the geometry of the browser window? If so, it's still a bug, but a subtler one. Michael Hardy (talk) 18:22, 26 July 2009 (UTC)

I'm using Internet Explorer 8 and no matter how I manipulate the window size, I always see spaces on either side of the ± sign in the first example in Mr. Hardy's post of 18:22, 26 July 2009 (UTC). --Jc3s5h (talk) 18:55, 26 July 2009 (UTC)

I can't find any reference to uncertainty in WP:MOSMATH. AFAIK, the only documentation is in WP:MOSNUM#Uncertainty, but it does not describe when or where to use spaces (it actually seems to use two different conventions in the examples). I suggest you take this discussion to WP:MOSNUM and suggest changes to the manual that describe when and where to use spaces. Once the discussion is settled and changes are made, {{val}} can be updated if needed. I have a couple of machines with various browsers installed, so I can check if any browsers are not rendering the values as expected. However, since there does not seem to be consensus as to what the correct format is, I'll hold off until the MoS is updated.     — SkyLined (talk) 19:52, 22 August 2009 (UTC)

Documenting variability of MoS

user:Greg L recently reverted some of my edits to the documentation page with good reasons. To prevent going back and forth on the doc page, I'd like to suggest and discuss some additions here that I feel are needed to make sure {{val}} is used correctly by editors.

My suggested addition:

"{{val}} should be used for all values that are to be displayed in the most up-to-date style as described in WP:MOSNUM. Editors should be able to rely on the output of {{val}} to comply with WP:MOSNUM at any point in time. However, they should not rely on the output of {{val}} to be static: any future changes to WP:MOSNUM that affect the way values are to be formatted will result in changes to {{val}} to make its output comply with WP:MOSNUM. If an editor requires a value to be displayed in a certain format regardless of what WP:MOSNUM suggests, the value should be formatted manually. This will prevent changes to {{val}} resulting in changes to the way the value is formatted.
(Changes to WP:MOSNUM are not expected to happen frequently. Whenever changes are made, {{val}} will be updated as soon as possible. Pages that use {{val}} require no editing for these changes to be applied: this happens automatically the next time the page is rendered.)"

I believe this addition would work best in the first section ("Purpose"). Let me know if you think this will help explain to editors when to use {{val}} and when not to use it or if this complicates matters too much. If the latter, I still feel we need this documentation, but we might move it towards the end of the page in a separate section, so as not to frighten off editors while still providing the information to those that want it.

    — SkyLined (talk) 19:43, 22 August 2009 (UTC)

How do I use a pure power of 10?

Consider 600 GeV/c2 which uses 'val' to good effect, vs. 1017 {{val/units|GeV/c2}} which cannot. I should be able to leave off the first argument somehow, or make full use of a portion of the machinary inside val. At least I can use val/units directly, but must code the superscript and non-breaking space directly. And doing that won't apply any special style rules to the whole thing. Długosz (talk) 21:53, 11 December 2009 (UTC)

I've removed code that checks for the first unnamed argument, allowing use without any unnamed arguments. You can now use {{val|e=17|ul=GeV/c2}} like so: 1017 GeV/c2.     — SkyLined (talk) 10:01, 21 December 2009 (UTC)

Imperial Gallons - have I broken it?

Hi there. Just doing some clean-up editing, during the course of which I changed some template entries of the form {{Val|0.125|u=gal}} to {{Val|0.125|u=impgal}}. This came up with a redlinked template Template:Convert/ScientificValue/LoffAonSoffImp. I've created this template by copying Template:Convert/ScientificValue/LoffAonSoff so that the page on which I changed the {{Val}} template now works (it displays "gal" rather than "USgal"), but I suspect that my solution is not the most ideal. If I've broken something, any hints as to how to fix it would be much appreciated. Tevildo (talk) 12:16, 24 December 2009 (UTC)

Allow number format like 123,456.789 12 ?

{{rfctag}} Discussion moved to WT:Manual of Style (dates and numbers).

Should numbers in the format 123,456.789 12, which use thin spaces to group digits to the right of the decimal point, but commas to group them to the left, be accepted? 14:52, 18 May 2009 (UTC)

Alternatively, should the Val template be modified to use thin spaces to group digits, both to the left and right of the decimal point? --Jc3s5h (talk) 14:55, 18 May 2009 (UTC)

Well that's the Wikipedia house style. I don't like it myself, but apparently that's what was decided after some long discussion. Skylined might have some insight here.Headbomb {ταλκκοντριβς – WP Physics} 03:20, 19 May 2009 (UTC)
It is not clear to me that the long discussion made it clear that numbers like the above would occur; certainly that possibility was not in the template documentation until I put it there a few days ago. The Manual of Style (dates and numbers) says it's OK to use Val, but does not fully endorse or explain the behavior of Val. --Jc3s5h (talk) 03:47, 19 May 2009 (UTC)
Having a disclaimer in the {{val}} page that the MOS does not follow international standards is like shooting the messenger: I created {{val}} to allow everybody to easily create numbers in Wikipedia MOS format, whatever that may be. When using this template, there is no need to remember how to format the number (No complex HTML, unicode chars, MOS guidelines, etc..). You just need to know how to use the template, something which should never change.
I see people reporting style issues in the MOS as style issues in {{val}} way too often. We should come up with a solution to this:
→ ONLY if the style of {{val}} does not follow the MOS, should {{val}} be updated. (Changes to the way an editor uses {{val}} should be avoided: only the output style should be changed. Additional uses can be added when they do not interfere with existing ones.)
Whenever the MOS is updated, {{val}} should be updated accordingly.
→ if you do not like the output format of {{val}}, you should get the MOS updated.
→ if the MOS does not define certain behavior well enough, you should get the MOS updated.
→ if you MOS does not follow the internationally accepted style, you should get the MOS updated.
Jc3s5h brings up a good point for discussion: we should get the MOS to mention/endorse/enforce (in order of increasing personal preference) the use of {{val}} and to be clear about digit grouping (I've not followed the discussion, but iirc the style has already been changed a few times since I created it only a year ago). I still see a lot of pages with hard-coded numbers that do not conform to the MOS. We should mention at the top of this talk page that discussions about style do not belong here, but on the MOS pages.
Luckely, modifying {{val}} allows you to easily apply changes in the MOS to all numbers that are generated using it. If you don't like the digit grouping, get the MOS updated and I'll happily apply the changes to {{val}} for you.
    — SkyLined (talk) 14:23, 19 May 2009 (UTC)
Btw. should both types of digit grouping be acceptable, but in different situations (for example, the MOS could say use thin spaces for scientific notation and commas for financial amounts or whatever), it is not impossible to create two versions of {{val}} or add an extra argument to describe what type of value you're entering, so the right part of the MOS gets applied.    — SkyLined (talk) 14:30, 19 May 2009 (UTC)
I already appreciated the advantage of being able to change the format of all articles that use Val in the event the MOS changes. I believe the Val documentation should always describe, in detail, the behavior of the template, and should highlight any behavior that is likely to suprise a novice. I believe using different digit grouping methods to the left and right of the decimal is indeed suprising to anyone who did not follow the debates at MOSNUM and elsewhere, so highlighting this behavior is essential.
My idea of the best solution is not technically feasible, so far as I know. It would be nice to have a default behavior of using commas to the left and not grouping digits to the right of the decimal. But, if a flag were present once in an article, all digit grouping would be done with thin spaces (or the visual appearance of them). I don't think there is any way for a template to pick up the presence of a flag that is not contained within the template.
It's a pity, because if such a method were available, when an article is edited to contain a number with many important digits to the right of the decimal, the format of the whole article could be changed. --Jc3s5h (talk) 15:10, 19 May 2009 (UTC)
SkyLined is talking complete sense. You are agreeing with all he say's. Additionally you want the Template:Val to be able to over-ride the MoS. Which I think rather goes against SkyLined's original intent, of course that doesn't mean his intent was to prevent non-Mos style! The question then becomes, should Val be able to subvert MoS at the users behest? I think not, but... HarryAlffa (talk) 19:20, 21 May 2009 (UTC)
A template cannot enforce the MOS. If need be, an editor who didn't like what Val was doing could just strip it out of the article completely. --Jc3s5h (talk) 19:41, 21 May 2009 (UTC)
No one said anyting about enforcement, I just said the "intent" of the designer! HarryAlffa (talk) 16:17, 22 May 2009 (UTC)
The point is that there is one widespread style: commas to the left and no separator to the right of the decimal. When a pubisher needs to publish many documents with many numbers to the right of the decimal, this is not satisfactory. The usual solution, as far as I can tell, is to use the thin space as the separator in all cases. There are two methods around. If Wikipedia wants to imitate the practices of other publishers, both options need to be available. --Jc3s5h (talk) 19:41, 21 May 2009 (UTC)
About the digit grouping itself: I seriously do not care either way - I'm only here to implement the MOS through {{val}}. So, again, please take this discussion to the MOS. We can start to think about how to implement what you are suggesting when it's in the MOS. Until that time, I see no reason to talk about circumventing the MOS through {{val}} when it is designed to aid in implementing it.
About explaining what the template does: the documentation of {{val}} is there to do that. If sufficient people would be surprised by the output format to warrant a disclaimer and/or explanation, we should have one. I'd create it myself if I knew what people might expect the output to be and how it differs in reality and why. Unfortunately, I don't know because I'm just a dump programmer: I'll need to leave that up to you. One request: please also add links to the MOS, specifically to pages that contain the reasoning behind the current format. Hopefully, people will stop asking questions about it here, which would save me a lot of time.
    — SkyLined (talk) 08:48, 22 May 2009 (UTC)
Templates take technical knowledge and skills, SkyLined has chosen to use his skill-set to create the Val template. He took the MoS as his style guide. Very sensible. His design goals were clear - follow the MoS. If someone doesn't like the Val template they can try to persuade him to change his design goals, or re-write the thing themselves. If you don't have the skills, seek for change in the MoS. Then SkyLined will more than likely change the template. End. HarryAlffa (talk) 16:17, 22 May 2009 (UTC)
Who are they? -lysdexia 21:19, 6 January 2010 (UTC) —Preceding unsigned comment added by 69.108.162.62 (talk)

Includeonly

Moved from Template talk:Val/delimitnum
 – * Pppery * it has begun... 15:52, 11 October 2021 (UTC)

{{editprotected}}

Remove the last <includeonly> at the bottom of the page. Headbomb {ταλκκοντριβς – WP Physics} 20:12, 12 September 2009 (UTC)

 Done. PeterSymonds (talk) 20:23, 12 September 2009 (UTC)

Ellipsis

Is it possible to put an ellipsis after a number but before power of 10? For example, the magnetic constant is (exactly by definition) 4π×10−7 N / A2. Is it possible to use val to display its actual value, i.e. 1.2566370614... ×10−6 N / A2? (Possibly I'm missing something obvious!) Djr32 (talk) 22:58, 31 October 2009 (UTC)

No: this currently not supported by the template but it could always be implemented through yet another argument. But, I have not seen that notation for approximations before; I do seem to recall people using something similar to ~1.2566370614×10−6 N/A2 instead - maybe you should check the MoS to make sure that your use of ellipsis makes sense?     — SkyLined (talk) 17:22, 2 November 2009 (UTC)
The only use of ellipsis I've seen is a way of indicating repeating decimals, such as 1.234234... to indicate the digits 234 repeat forever. --Jc3s5h (talk) 18:02, 2 November 2009 (UTC)
An ellipsis is often used to indicate that we could keep writing more digits forever, but aren't going to. It's currently used in that sense in the articles on both π and e (mathematical constant), for example. This is different to an experimentally-measured value that's only known to a certain degree of precision. (I can't find anything relevant in MOSNUM.) But it's probably a sufficiently rare requirement that it's not worth over-complicating val to accommodate it. Djr32 (talk) 20:29, 2 November 2009 (UTC)
Actually the modification would be rather trivial if we introduced something like |end=. {{val|123.234|end=...|e=-4}} → 123.234...×10−4. Headbomb {ταλκκοντριβς – WP Physics} 04:13, 3 November 2009 (UTC)
I object to the end parameter being added to the code without being documented. --Jc3s5h (talk) 04:38, 3 November 2009 (UTC)
 DoneHeadbomb {ταλκκοντριβς – WP Physics} 04:43, 3 November 2009 (UTC)
Good patch, but "errend"? (Knowing where the name comes from makes it easier to remember.)     — SkyLined (talk) 08:39, 3 November 2009 (UTC)
"error end". Uncertainty would be more accurate, but I didn't find any nice ways to shorten it to something less unwieldy. Headbomb {ταλκκοντριβς – WP Physics} 13:45, 3 November 2009 (UTC)
Why would you want nescient ways to end et? -lysdexia 21:33, 6 January 2010 (UTC) —Preceding unsigned comment added by 69.108.162.62 (talk)

semi-protected

Moved from Template talk:Val/delimitnum
 – * Pppery * it has begun... 15:52, 11 October 2021 (UTC)

I can't edit, which is annoying. However, I can edit {{val}}, which makes the protection useless. Can we have all val related templates be semi-protected? I am asking because this page needs a Wikipedia:null edit to solve a categorization issue.     — SkyLined (talk) 09:35, 5 November 2009 (UTC)

Currently 1 eV/c2 has two separate links to electron volt and speed of light; wouldn't it be more useful to have a single link to Electron volt#As a unit of mass? (Also, shouldn't the c be italicized?) ― A._di_M.2nd Dramaout (formerly Army1987) 16:48, 28 December 2009 (UTC)

I agree. We should also update the eV/c to link to "As a unit of momentum" or something, if it's not already done. Headbomb {ταλκκοντριβς – WP Physics} 21:22, 2 January 2010 (UTC)
 Done. The eV/c is not supported yet, though. ― A._di_M.2nd Dramaout (formerly Army1987) 14:48, 10 January 2010 (UTC)

Option for percent uncertainty

I am missing an option for a number with a percentual uncertainty like 1.23±4% × 105. Trying {{val|1.23|4%|e=5}} results in an error message. −Woodstone (talk) 21:09, 27 May 2008 (UTC)

This type of uncertainty is not supported at this point.     — SkyLined {talkcontribs 15:22, 11 June 2008 (UTC)

I would appreciate this functionality; further, it would be quite nice if the calculated range could be displayed for purposes of ease of understanding for those not familiar with scientific notation (see Electrical wiring (UK)). 217.28.2.84 (talk) 04:13, 23 January 2009 (UTC)
Clearly this is an incorrect notation. Percentages must appear after the base-10 exponent, because they are relative to the whole value, so this should be simply, and much more clearly like: 1.23 × 105 ± 4% (preferably with non-breaking half-spaces instead of plain spaces here around the ± additive operator, and possibly as well between the percentage value and the % unit). verdy_p (talk) 02:31, 27 November 2010 (UTC)

Breaking four-digits numbers

I think that numbers with fewer than five digits before the decimal point look better without a thousand separator, e.g. 2008 rather than 2,008. Does anyone agree with me? --Army1987 (talk) 12:00, 9 June 2008 (UTC)

I think we should follow whatever the standard says or, in absence of a standard to follow, whatever is used most commonly among major organizations. If you can provide us with a reference to a standard or a few papers that the formatting you suggest, I am willing to support it.     — SkyLined {talkcontribs 09:53, 28 June 2008 (UTC)
For example, http://physics.nist.gov/cuu/Constants/ does so in the PDF tables (see e.g. the proton-electron mass ratio). See http://www.bipm.org/en/si/si_brochure/chapter5/5-3-2.html#5-3-4 . --Army1987 (talk) 12:47, 1 July 2008 (UTC)
Don't confuse year numberings in dates (that are ordinal numbers) with quantitative values. The common agreement is that we don't grouping in date elements and notably not in absolute calendar year numbers. Such use for date does not preclude the need for the notations of quantities. Year numbers are not quantities. verdy_p (talk) 02:34, 27 November 2010 (UTC)

That's WP:MOSNUM stuff. IMO, commas as decimal seperators should be purged from the wiki. But then you'll have to deal with the millions of Americans who can't ever modernize themselves ever as far as standard goes. Headbomb {ταλκκοντριβς – WP Physics} 02:01, 11 November 2008 (UTC)

separators. It's English, not American, and it's grammatic and loghic; Continental SI's separators are wrong: Gaps mean multiples and dots mean stops. Moreover, the best decimal separator is mid-dot: 13,200·2. Strike Napoleonic dýsmaths from the wiki. -lysdexia 20:41, 6 January 2010 (UTC) —Preceding unsigned comment added by 69.108.162.62 (talk)

Copy/paste behavior change?

I was told that this template used to have the property that if you copied the formatted text from an article, it would not include commas. For example {{val|123123}} would output "123,123" but when you copied that you would get "123123". This is not the case right now. Has the template changed? — Carl (CBM · talk) 02:24, 25 January 2010 (UTC)

It's impossible to display the commas AND avoid them to be copied. All what it does is to avoid copying the thin spaces that are generated between operators (like plus/minus and times), because they are built using 0.15em horizontal margins (instead of thin spaces) between groups of digits (in the fraction decimals only) and between operators. So the non-fractional part of numbers, either in the absolute numeric value, or in the precision values, will be formatted using {{formatnum: ...}} which inserts those commas in the English locale used on this wiki (on other wikis, it will generate the appropriate separators). Really, it has never worked the way you describe it (but may be in the past, groups of digits in the non-fractional part of numbers where formatted using thin spaces generated by margins, like in the fractional parts now, instead of using {{formatnum: ...}}).
I must admit that the commas generated by {{formatnum: ...}} in the US English locale for grouping digits is causing lots of confusion, and that thin spaces (generated by small margins, just like today for fractional decimals) would be much more neutral internationally (and in fact recommended in scientific books, for articles where this template is typically used). We won't change however the decimal separator (that this template forces as a dot for all English readers, because it's impossible to predict the format that users will read, without forcing an alternate new layout for their locale, that would fill up the server caches). It looks that it was changed from spaces to comma based an an argument for legal prints, but not applicable to scientific publications. verdy_p (talk) 18:53, 8 October 2010 (UTC)

Val is now screwed up

The look of Val was heavily voted upon on WT:MOSNUM and it was decided to use the grouping convention observed by the BIPM, ISO and NIST, which has the last group of digits always be either 2, 3, or 4 digits in order that there is never a single hanging digit. I see that {val} no longer does this. That is entirely incorrect. Also, this edit, which has this edit summary: some chars saved in parameter space (memory). Balanced (left-right) thin-space margins on operators. Needs more in /doc, messed with the spacing of the times (×) symbol. That spacing was the product of a great deal of effort by editors using a variety of operating systems and browsers (including iPhones), who shared screen shots, e-mailed them to each other, and posted many of them on talk pages. That effort resulted in the best compromise. It will look a little too far one way or the other depending upon the editor. Please restore {val} to the way it was in both these regards. Greg L (talk) 16:53, 25 November 2010 (UTC)

I have undone the spacing changes. Please discuss this with Verdy p. — Martin (MSGJ · talk) 17:08, 25 November 2010 (UTC)

I will alert him to come here. This needs to be discussed in only one venue.

I see that the {val} template is still messed up since it leaves a single hanging digit as evidence by this expression: 6.6260693×10−34 J·s.

All here should know that I am not a template author. I coordinated the consensus and production of templates that performed the role of {val}. This template first started out as the Template:Delimitnum, which used math-only methods and produced rounding errors. The operation of {delimitnum} (and later, the {val} template that User:Skylined created based precisely on the {delimitnum} functionality) was first discussed here on WT:MOSNUM and then here on my talk page in December 2007 and was later voted upon and final consensus here on WT:MOSNUM in March 2008.
Now, I shouldn’t have to go look up every single link, like the ISO, but poring over the past discussions, I quickly located this one: BIPM: SI brochure, ¶ 5.3.4 Formatting numbers, and the decimal marker, which states that the thinspace is inserted between groups of three. However, when there are only four digits before or after the decimal marker, it is customary not to use a space to isolate a single digit. The NIST, in their database of fundamental physical constants uses this convention. And why? Because Pub. SP811, “NIST Guide to the SI,” ¶ 10 More on Printing and Using Symbols and Numbers in Scientific and Technical Documents mirrors the BIPM and clearly follows their own advise. The proper delimiting of numbers to the right of the decimal point is as follows:
2.123
2.1234
2.12345
2.123456
2.1234567
2.12345678
2.123456789

You're wrong ! You did not read it carefully ! NIST clearly states that:
  • "0.491 722 3" is highly preferred to: "0.4917223"
  • "8012.5947" or "8 012.594 7" are correct groupings, but not: "8 012.5947" or "8012.594 7"
  • It clearly states then that grouping is preferable on both sides, and states that the customary grouping by 4 on the last group is not used if you present consistant tables (it may only happen for numbers in isolation).
In other words, use grouping by 3 digits on both sides of the decimal separator, using commas in the integer part, and spacing in the fractional part, but do that consistantly, or don't use any groupings at all ! There's no such reference stating that grouping by 4 digits can occur in the last segment.
You read it incorrectly. Given that the template will unconditionally use groupings, your 2nd and 5th examples are wrong, and this discussion is non-sense. verdy_p (talk) 22:01, 26 November 2010 (UTC)
And if you really wanted to adopt international standards, the comma should not be used to group digits in the integer part (this is an old customary US English convention, that is not used universally in all English speaking countries, all other countries use the non-breaking half-space on both sides of the decimal separator which may be either a dot or a comma without causing any ambiguity with the non-breaking half-space for standard grouping separators) verdy_p (talk) 22:40, 26 November 2010 (UTC)
Besides, all the BIPM and the NIST (and the ISO and IEEEE, I believe also) are doing is merely endorsing good typestyle practices; a single hanging digit looks awkward, most-authoritative professional publications for decades made the last group be four digits to avoid a single hanging digit, and this best-practice is merely being recognized and formally endorsed by international standard bodies; they seldom just *invent* writing practices out of the blue.. It should suffice to say that this issue was thoroughly discussed and there was an overwhelming consensus to abide by the practice of the BIPM and the NIST.
Note that I have restored this "custom grouping by 4" on the last group, but my opinion is that this is wrong and has never been recommended by NIST of the BIPM (and certainly not ISO or IEEE as what you « suppose »), even if a few books were edited displaying numbers like this. Most books in fact still use normal and consistant grouping by 3 digits everywhere', or no grouping at all (and collections of numbers with very precisions (spanning many lines of printed texts) sometimes use grouping by 5 digits (as it allows counting decimals more easily). verdy_p (talk) 22:24, 26 November 2010 (UTC)
A sandbox that was used long ago to evaluate {val} is here: User:Greg L/Val sandbox. Note the broken instance, ninth down in the list. And note also the many improper instances in Section II.
Another reason for the sandbox is Wikipedia had a number of servers that used to run Fedora but most were upgraded to Ubuntu. There was a bug in the math of the remaining Fedora servers that would limit the precision of {val} to only 12 digits a certain percentage of the time. That was Bugzilla 17452 - Complete migration of all application servers from Fedora to Ubuntu. All servers have been fixed by June of this year and {val} now consistently works to 14 digits of precision.
This is NOT a problem/bug of Ubuntu. This is just a problem of portability between 32-bit vs. 64-bit native integers. The 32-bit version of Ubuntu uses 32-bit integers and the PHP mod operator operates on the native int datatype of the C platform, which is 32-bit on 32-bit installations of Ubuntu (or any other 32-bit architecture, including on Windows, BSD, Solaris, and all versions of Linux). This has the effect that mod 10 cannot compute the correct digits for more than 9 decimals.
To fix it, this is simple: don't use the mod 10 operator in #expr's, because it is computed using the PHP builtin mod operator that first truncates (and not rounds) its two parameters to a default int, before computing the integer modulo. Use floor() instead (available in PHP and in MediWikit #expr parser functions) to compute the remainder as: the difference between (the first number) and (the floored floatting-point division by 10, then multiplied by 10), and then truncate again (here you can safely use mod 1) this difference to keep only the integer part for the resulting digit...
But be warned about the rounding effect that may occu on the last significant digit (and be warned about the effect of multiplying a floatting point value multiple times by 1000 : multiple rounding occurs that cause errors that I have fixed by multiplying only once by a power of 10 (like "value*1E9" and not "value*1000*1000*1000" which incorrectly returns the last digit (because mod is very sentitive to very small rounding downs that may occur as it truncates its parameters towards zero).
In fact, there is still no warranty that the last figure will be correct: the last decimal should really be rounded and not truncated, for correct results. That's something that I had fixed in {{Val}} to eliminate 3 bugs that were listed in the testcases. verdy_p (talk) 22:17, 26 November 2010 (UTC)
Someone please fix the grouping. We shouldn’t have such a limited number of template authors reversing a wide consensus from earlier to follow international practices for digit grouping. Greg L (talk) 18:29, 25 November 2010 (UTC)
Are you saying that the recent edit which was reverted did not affect this issue? Was the template ever performing as you wish? If so, can you specify a version (or date) when the template performed correctly? — Martin (MSGJ · talk) 10:09, 26 November 2010 (UTC)
Indeed, I did not notice which edit broke it. Unlike looking at an old version of an article, I have no way of testing an old version of a template. By the luck of the draw, in those articles on which I am the shepherding author, there are few instances containing numbers that showed this problem. Expressions with 4, 7, 10, or 13 digits to the right are supposed to have four digits in the last group (Ubuntu doesn’t work beyond 14 digits of total precision). So I only recently noticed the problem. Skylined wrote this thing in the first place but is very busy lately. I am quite sure that Skyline’s 20:28, 22 April 2008 version had the proper code for grouping digits.

Below is a sandbox with a *live* expressions of {val} so you can do a quick test of Val’s operation. If there are hanging digits, then {val} is still broken.

Sandbox

1.1234×10−34 J·s
1.1234567×10−34 J·s
1.1234567890×10−34 J·s
1.1234567890123×10−34 J·s

Greg L (talk) 17:17, 26 November 2010 (UTC)
  • Here is another, complete version of a quicky sandbox:

Sandbox

1×10−34 J·s
1.1×10−34 J·s
1.12×10−34 J·s
1.123×10−34 J·s
1.1234×10−34 J·s
1.12345×10−34 J·s
1.123456×10−34 J·s
1.1234567×10−34 J·s
1.12345678×10−34 J·s
1.123456789×10−34 J·s
1.1234567890×10−34 J·s
1.12345678901×10−34 J·s
1.123456789012×10−34 J·s
1.1234567890123×10−34 J·s

Greg L (talk) 17:30, 26 November 2010 (UTC)
And your comment in Bugzilla has nothing to do there, it is unrelated to the bug spoken there. A separate bug should be filed to make sure that the MediaWiki #expr parser function will implement its mod operator using floatting point and not the architecture-sensiteve implementation of the PHP's mod operator (which cannot be fixed for compatibility reasons with lots of other PHP installations not used by MediaWiki).
Note that all Wikimedia servers are now running on 64-bit systems, and running a 64-bit version of Ubuntu or some other Linux installation, and were installed with 64-bit versions of PHP.
We should avoid using mod in #expr parser functions for the 10th to 14th decimals... verdy_p (talk) 22:34, 26 November 2010 (UTC)
Thanks for restoring the grouping.

It isn’t “custom grouping by 4” and I can’t fathom why you write has never been recommended by the NIST of the [sic] BIPM.

Why the "sic" ? I have NEVER stated that NIST was a part of BIPM. I know that NIST is a US-only organization, and BIPM (abbreviation for Bureau international des poids et mesures in French, i.e. International Bureau of Weights and Measurements) is an international organization headed in Paris (with also subsidiary research/meeting offices in Vienna, London and in US and a few other places in the world from its participating members). I clearly know that they are completely unrelated.
It is an writing style that is a formal recommendation of both organizations, per BIPM: SI brochure, ¶ 5.3.4 Formatting numbers, and the decimal marker, which states that the thinspace is inserted between groups of three. However, when there are only four digits before or after the decimal marker, it is customary not to use a space to isolate a single digit. And the NIST, in their Pub. SP811, “NIST Guide to the SI,” ¶ 10 More on Printing and Using Symbols and Numbers in Scientific and Technical Documents.
And you misread what NIST said, when it admitted that this was just a customary use, and clearly showed that the 4-digits grouping was not recommended by itself in many cases (I quoted in bold characters the important words stating exactly the opposite of what you have clearly misread). It still happens that there are a few usages for the terminal 4-digits grouping in a very old paper where it is used for displaying isolated quantities. But even theNIST contradicts itself, and this is not an international standard (what NIST will say just applies to US, but now US highly prefers international standards and has deprecated many of its historic documents). In addition, NIST is not the only normalization organism in US. More importantly, the BIPM, ISO, IOC and all other organisms have definitely not endorsed this old practice that even NIST does not defend very well.
I also challenge you to find any supporting reference at BIPM about your statement (all seems to indicate that this is an invention or assumption by you only).
Note: I certainly do not contest the fact that spaces used for grouping digits should be non-breaking half-spaces ("thin spaces" in English typographic terminology, something that has been forgotten for too long in US, but that was never forgotten in France where we call them « fines », without even needing to specify that this should be non-breaking because thin spaces have survived the short period of mechanical dactilography and ASCII on computers, all French editors using non-breaking fines in a continuous way). I also know that the French fine is a bit larger (between 1/4 em and 1/5em) than the English thin space (1/5 to 1/6 em). As most fonts on computers are built with US designs (where glyphs in numeric fonts already embed the advance width between inked glyphs, œil in French), this has caused US to simply discard the thin space because the embedde advance between pairs of characters was eating it almost completely (that's why the thinspaces was discarded in dactylography), but this did not happen in France where it was still best to use a visible space if we could not produce the fine.
The common practice that reconciliates French and English typography should be to use 1/5-em thin spaces, but as Wikipedia is most often viewed on screens with limited resolution, it is still best to increase it to 1/4 em (0.25em), which is exactly the French typographic tradition (if we supposed that digits did not already included the extra advance width on both sides). Ideally then, we should better use 0.2em value.
And please reconsider your tests on smartphones : all of them are displaying pages in a very small font just to compensate for the small display width, but pages are also rescaled at random zooming levels, and users still need to adjust the zoom level manually (touch and pinch action with two fingers sliding on the screen) to make the text just decipherable. So the final zoom level is completely unpredictable depending on where the user stops his zoom (younger people will zoom in less than peoples in their 40's (sometimes even before at their 30's) just because presbytie that progressively affects everyone on Earth causing lack of adaptation for looking at displays at small distances in the hand).
So try zooming text like mature adults: you'll immediately see that even the iPhone or Android smartphones are effectively showing unbalanced spacing arond operators. And this is also visible on desktop and notebooks that run more precise rendering engines with more accurate fonts (thanks to better-performing CPU and more complex algorithms and better fonts today).
I criticize the fact that all this discussion occured on your obscure private discussion page, and the fact that you even forgot to reference your discussion in a proper way, and to document the expected behavior. In fact I really doubt that this discussion was a real consensus, because this discussion was invisible (and your page also shows that you have irritated lots of users by your edits in this period, causing you admnistrative penalties on your account). Your discussion page is mixing lots of unrelated subjects. You should have done your homework to properly reference and document what you did (all what I have done was documenting what was missing, and creating testcases, and correcting precision problems when the template was not just fixing minor spaces, but also correcting the much more important displayed figures (that were still wrong in many cases that your did not have solved). verdy_p (talk) 03:21, 27 November 2010 (UTC)
More to the point, this issue of grouping, as I wrote above (and provided links to) was endorsed by a widespread consensus on Wikipedia when {delimitnum} was being considered (which is what {val} was based on).

I also don’t understand why you wrote This is NOT a problem/bug of Ubuntu. Indeed, I agree with you; it is not a problem with Ubuntu. But more to the point, I never suggested it was. I wrote that it was a problem with some servers that still were running Fedora (as they were upgrading to Ubuntu).

I also don’t understand why you wrote And your comment in Bugzilla has nothing to do there. I didn’t say it was. I wrote that the Bugzilla problem was another reason for making the sandbox (that I provided a link to). My point was to explain why my special sandbox for exercising the {val} template contains error messages for all expressions that have 15 decimal places and how that is now normal. I was hip deep in those issues years ago, don’t remember the atomic-level details, nor do I need to care nor do I care now.

Please read what others write more carefully before disputing what others didn’t write.

Finally, per your suggestion on your talk page, where you wrote If you really did not want to have a single digit in the last group you should have included such a case in the documentation, I agree with you. But as I am not a template author, I wouldn’t know the best way to document such a thing. But I will admit to not having foreseen that over two years later, someone would wade into a locked-down template and decide on their own to change a fundamental way the template had worked from the beginning. Had I foreseen such a thing, I would have lead the way towards having someone add a hidden editors’ note right into the relevant section of code say <!-- NOTE TO EDITORS: Four-digit grouping is per BIPM and NIST recommended practices and was adopted for use on Wikipedia by consensus after wide discussion. PLEASE DO NOT CHANGE IT. -->

And this assertion is plain wrong : neither NIST (a US-only organization which does not represents by itself the official US view at ISO, and that has also changed its own practices over time), nor the BIPM (an international standard organization headed in Paris and officially supported by US which is represented there) is recommending this 4-digits grouping (I have restored it because this change was not expected) but really this merits discussion as this is only the result of your own decision and misinterpretation and incorrect argumentation ! I don't know how to explain you that you are misreading your own references. Reread what I have quoted from NIST, it is clear that you are wrong. verdy_p (talk) 03:21, 27 November 2010 (UTC)

So perhaps someone here who knows how best to accomplish documenting this issue might step up to the plate. It might be by a combination of hidden editors note and something in some documentation for template authors. One could, for instance, reference the above-cited links to the BIPM and the NIST and could also reference WT:MOSNUM archive #98 #{{delimitnum}} template. Note also this thread on that same archive, WT:MOSNUM archive #98 # {{val}}. Skylined posted that as a sub-section of the section on {delimitnum} after seeing the shortcomings of its math-based approach. Greg L (talk) 23:58, 26 November 2010 (UTC)

So quote it completely: your referenced NIST page clearly demonstrates (in the examples as well as in its introductory sentence) what it recommends, it is clearly not the green sentence extracted from its context. So read what NIST says, I am not inventing: their words "may" and "customary" do not constitute any recommendation in any standard. verdy_p (talk) 03:58, 27 November 2010 (UTC)

Arbitrary break

For what it's worth, Greg's testcases all display with the proper grouping behaviour to me (IE 8). Headbomb {talk / contribs / physics / books} 23:44, 26 November 2010 (UTC)

Indeed. Thanks, Headbomb for looking in here. It all looks quite good now. Note my above suggestion regarding documenting the issue using four-digit grouping to avoid a single hanging digit. Perhaps the simplest way would be to imbed the above-suggested hidden editors’ note into the code and reference the above thread? I don’t know what is best. But this incident has been instructive that 2+ years is a l-o-n-g time in Wikipedia years and perhaps we should get this stuff memorialized to avoid revisiting this issue in the future. Greg L (talk) 00:03, 27 November 2010 (UTC)
P.S. Oh, and if we are going to be documenting things, I suggest we also document that the spacing on both sides of the × symbol was the product of great effort over many days by different editors e-mailing screen shots taken with different operating systems and different browsers (even an iPhone) and the resultant spacing is a best compromise.
Really, you don't know what you're speaking about. Such best compromise does not exist and fails to render properly in ALL my test browsers ; I can test more then 200 combinations with various fonts), including on my Android smartphone. Even my current iPhone emulator (by Apple itself in its dev'kit), Safari (on Windows) clearly shows the unbalanced spacing. Just blame the poor font designs that have been used in early models or OSes (don't forget that iPhones are very recent technologies, even more recent than Wikipedia itself, and that it is not alone and has still not reached any standard status, and supported lots of corrections in updates ; there are even newer models that don't exhibit the old bugs/quirks/limitations of iPhones v1). Now the unbalanced spacing is very visible and undesirable. I don't know how you tested it, but your tests must have been extremely limited and were probably using early bogous versions of fonts at the time when the times operator was still not so widely present in core fonts of OSes or browsers, years ago.
You can reference this thread: User talk:Greg L, Archive, #Number formatting tempate where some of that effort is memorialized. Greg L (talk) 00:11, 27 November 2010 (UTC)
Note to Headbomb: the Greg's testcases above were depending on a change that I did to make them work as he wanted (before this change, there was still only the 3-digits grouping and nothing else for the decimals, as recommended by NIST, BIPM, ISO and many other international organizations (notably those working in chemistry, astronomy and nuclar physics).
The 4 digits grouping is just the result of an historic custmary use in specific cases that is not universal and not defended by the sources that Greg was citing, that he was misreading, because these sources were recommending exactly the opposite and had not read them correctly or misinterpreted them ! The 4-digits grouping is clearly NOT recommanded for tabular data, and may only be used in isolation. Most softwares do not support it (e.g. Excel) and this may have been customary only within a specific period, in specific domains, and in publicatrions of specific regions.
Anyway this was never documented and unexpected. So next time you take some obscure decision, you should state this clearly on a place where this can found again, because what I did was clearly to create testcases, and document them, and solve the issues that have been there since long (notably in terms of precision of display, something that is still not solved completely).
And your discussion archive in a private discussion page is clearly not the proper place for storing a decision, it cannot be the result of a community decision as it is invisible in most searches with the default search options of Wikipedia, notably for a tempalte that is so widely used (with long lists of uses in lots of pages). verdy_p (talk) 02:10, 27 November 2010 (UTC)
The 3/4 digit grouping has had long-withstanding consensus on Wikipedia and is the MOSNUM recommendation.
If you want to change it, created a thread at WT:MOSNUM, but be warned that it will most likely fail to get any ground because 3/4 grouping is the best way to go. Headbomb {talk / contribs / physics / books} 02:55, 27 November 2010 (UTC)
No ! This has never been discussed there. verdy_p (talk) 04:10, 27 November 2010 (UTC)
I don't want to challenge this myself, that's why I have restored this grouping as requested, because I was asked to do so. But Greg's arguments are just wrong, he does not even want to read correctly the NIST reference that he is giving in green above : the examples shown immediately after his quoted sentence (extracted from their context) are much better demonstrative that NIST does not endorse this old customary practice, that is probably customary only in US and nowhere else (NIST cannot state anything about customary uses in other countries).
All my searches from ISO, BIPM, IOC and other international organizations show that this is just an old US-only practice, that even NIST does not recommend (but it just documents its existence for historical reasons by a few non-standardizing organisms or by US governmental bodies). All recent publications by NIST (including papers submitted by NIST to ISO and international organizations) do not follow this old US practice, which is not even implemented in most softwares (not even in MS Excel 2010 for example, or in Adobe products). You'll find this only in informative papers on the Internet that have not been carefully scrutinized by scientific lecturers.
As what the BIPM write: « For numbers in a table, the format used should not vary within one column. » Given that this template will be used in tables containing results with variable precisions, and you can't expect that the formatted noumber will be used in isolation, this old practice (only allowed by choice in limited areas), should not be followed and should really not be the default. The BIPM page also shows (in the blue column on the right) the recommended formattings, excetly like in the examples given in the NIST page: there's absolutely no 4-digits grouping in those places where you may expect it.
And in fact this discussion has never reached the status of a consensus as it was only discussed in a private user page, referenced nowhere else, and known only by a few users at this epoch. verdy_p (talk) 03:34, 27 November 2010 (UTC)
Well, we’ve flogged this about as much as I am prepared to do. I’ve provided links above to the BIPM’s recommended practice as disclosed in their manual of style for the SI, and to the NIST, which mirrors that advise, and to a database where it can be seen that the NIST practices what it preaches. I’ve misread nothing at all. So you and I are just going to have to agree to disagree on that point, m‘kay? And thanks again for restoring the functioning of {val} so it groups numbers to the right of the decimal point so that there is no single hanging digit and look like this value as stated by the NIST (note the four-digit group at the end?) If you want to assert that not leaving a single hanging digit at the end is some sort of new-fangled house style unique to Wikipedia, it is your right to believe so but you don’t seem to be convincing anyone here otherwise.

As for your truly absurd And in fact this discussion has never reached the status of a consensus as it was only discussed in a private user page: why don’t you actually read the links I provided above? But to save you the effort, see WT:MOSNUM archive #98 #{{delimitnum}} template.

Once again, there's no trace in this archive about a discussion related to 3/4-digit grouping. All this focuses in problems of precision (I can find the reference to the problem of incorrect figures for 13 and 14 digits in decimals for example), or the choice of the separator. I maintain that this was never discussed openly, and at least not there ! verdy_p (talk) 04:28, 27 November 2010 (UTC)
That is an open venue—not a “private user page” and is the governing venue on this issue. Like Headbomb wrote, take it up at WT:MOSNUM if you want to change things. Happy editing and thanks again for restoring the functioning of {val} so it performs as the community wanted it to perform. Greg L (talk) 04:19, 27 November 2010 (UTC)
Note what the US NIST standard 2008 writes: « A comma should not be used in any part of a built-up fraction of four or more digits or in decimals » ; this is not saying « five » (what is currently incorrectly stated in the template documentation). The purpose of this statement is to indicate that only a thin space may be used in the fractional decimals (see also rule 12.27), but definitely not any comma where you could expect or find it in non-recommended customary uses.
Yes I have read all your references, and they all agree that the 3-digits only is the only official recommendation (which will be appropriate everywhere, unlike the 3/4-digits customary use which is severely restricted in the same pages), including in their very explicit examples. Note also that My edit (tested in sandboxes and testcases that I have included or increased) corrected the precision issue that was remaining since long with incorrect figures on the 13th and 14th position. verdy_p (talk) 04:24, 27 November 2010 (UTC)
What part of this value from the NIST shocks and confuses you? Or this value of theirs? No one around here likes a single hanging digit but you. Go to WT:MOSNUM if you don’t like it. Wikipedia is supposed to be a fun hobby and dealing with you makes it un-fun for me. There is no requirement that I further engage you. Goodbye and happy editing. Greg L (talk) 04:31, 27 November 2010 (UTC)
No part at all. I read it completely, and don't forget the examples provided and important words like "highly prefered to" that are explicitly in this page ! NIST and BIPM agree on this, they recommend the 3-digits grouping only (with a "should"). You should be more aware of the important definitions of words like "must" (requirement), "should" (strong recommandation), and "may" (not a recommendation, used here with "customary" to even lower its value explicitly) within texts of standards (the same applies to ISO, and to IETF RFC's) ! For me it's just enough that NIST displays "highly preferred to" in its example. verdy_p (talk) 04:52, 27 November 2010 (UTC)
Nothing wrong from this US-only standard body, because this is not tabular data, each figure is read in isolation and falls within the permitted cases where the customary use may be accepted. NIST (or the IEEE, or ITU) does not follow this customary practice in its tabular datas, and other national bodies (such as BS, DIN, AFNOR, KSC, GB) do not use or even reference this non-recommanded convention, even though they have endorsed the BIPM standard (simply because this is definitely not a recommendation applicable internationaly by ratifiers). verdy_p (talk) 04:52, 27 November 2010 (UTC)
NIST, and more importantly the BIPM (as well as many national or industry standard bodies) do like it and show their support of the 3-digit only grouping in its official examples (and they do not give any example with the custumary 3/4-grouping, they just describe it and restrict this use). I am definitely not alone. verdy_p (talk) 04:52, 27 November 2010 (UTC)
I don’t care how they do things on fr.Wikipedia, desist with modifying my posts. If you want to respond to a particular statement, quote the passage. Greg L (talk) 05:58, 27 November 2010 (UTC)
I have not modified your posts. I have just commented them. And I have definitely not spoken about fr.wikipedia here, just about the same sources in English that you chose and referenced yourself and that you persist in misinterpreting. Please learn the meaning of MUST, SHOULD, and MAY within standard sources. They are really important and fix clear priorities in their interpretation (there's an RFC only about it for IETF standards, and an ISO standard for international standards and national standard bodies, either of these being referenced as well in the introduction of most industry standards). In those sources, you cannot freely select a "MAY" sentence out of its context (which only describes limited usages which is not recommended but that could optionally be applied in very restricted applications, as long as the MUST and SHOULD rules are observed) just to ignore the "MUST" and "SHOULD" ones. verdy_p (talk) 16:07, 3 December 2010 (UTC)
Learn to respond to others’ posts by adding a post of your own below it and indented to make the posting order of the thread clear; not by doing so in a manner that breaks up others’ posts into a hodgepodge with your 2¢ interleaved throughout. In short: learn proper posting etiquette as everyone else on en.Wikipedia understands that principle. Your insulting style of interacting with others (Please learn the meaning of MUST, SHOULD, and MAY within standard sources) on en.Wikipedia is a big turn off. I already know what those mean. You have a lot to learn about how to get along in with others in the world. I realized further engaging you here would be unproductive and unwise. I hope we don’t cross paths anymore because your style is so annoying. Greg L (talk) 20:23, 20 December 2010 (UTC)
This is getting off topic; please take this discussion it to your personal pages should you want to continue it.     — SkyLined (talk) 09:46, 22 December 2010 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Val/Archive_1&oldid=1123826908"