Template talk:Val/Archive 2

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

Val nested over 20 deep yet Gaps nested 2

9-Dec-2010: The Template:Val is performing too many nested if-else-if-else, and is nested over 20 deep (of the tiny 40-level "Expansion depth limit" in MediaWiki 1.6), before Val processes all decimal digits, nesting 1 level deeper for each digit. This nesting can be reduced by checking each validation of parameters as non-nested simple if-then logic (not if-else logic). By contrast, Template:Gaps nests only 2 levels deep (for {gaps|0.123|456|789|u=m} → 0.123456789 m or such). Currently, the MediaWiki 1.6 software has been using a 40-nest limit to stop "runaway" formatting of pages, when 60 (or 200) levels would be more practical (and stop any looping templates soon enough).

Meawhile, by changing the if-else validation checks to non-nested if-then logic, all error conditions will be reported as a sequence of messages, and then the output will still be attempted. However, that is a good tactic because if 2 parameters are wrong, then getting a message for each of them is better (at one time), and then seeing a partial result can help to spot which instance of {Val} has those invalid parameters. Currently, {Val} reports 1 error and stops:

• For {val|0.1234S6|0.L} using 5=S, 1=L gives:

Once the nesting is reduced, then Val would also report "0.L" as an invalid number. I will create a sandbox variation of Val to show the proposed changes. -Wikid77 (talk) 14:51, 9 December 2010 (UTC)

I will create a sandbox variation of Val to show the proposed changes. -Wikid77 (talk) 14:51, 9 December 2010 (UTC)

Good, because I have no idea what you just talked about, :P. Headbomb {talk / contribs / physics / books} 15:13, 9 December 2010 (UTC)

• I have created the Template:Val/sandbox variation, with non-nested validation of parameters. It will continue to show messages for each invalid parameter, then attempt the output.

For {val/sandbox|0.1234S6|0.L} using "S" as 5, "L" as 1, gives:

With the nesting reduced, then Val/sandbox also reports "0.L" as an invalid number, rather than showing only 1 message and stopping. The problem with nesting beyond 40 levels of nested templates and if-else logic is shown in the following examples.

: Nest 27 deep & try Val/sandbox: <!--
-->{{1x|{{1x|{{1x|{{1x|{{1x|{{1x|{{1x|{{1x|{{1x|{{1x
|{{1x|{{1x|{{1x|{{1x|{{1x|{{1x|{{1x|{{1x|{{1x|{{1x
|{{1x|{{1x|{{1x|{{1x|{{1x|{{1x|{{1x
|{Val/sandbox{{!}}12345.12345} → {{Val/sandbox|12345.12345}}
}}}} }}}} }}}} }}}} }}}}  }}}} }}}} }}}} }}}} }}}}
}}}} }}}} }}}} }}

Nest 27 deep & try Val/sandbox: {Val/sandbox|12345.12345} → 12345.12345

Nest 20 deep & try Val: [ simulated ]
{Val|12345.12345} → 12,345.1234

Because {Val} had been coded with nested if-else-if-else-if-else, to check for 8 error conditions, it cannot run within other templates nested to 20 deep, but the /sandbox version can run even when nested 27 deep. -Wikid77 (talk) 17:08, 10 December 2010 (UTC)

• I suppose there is no harm to having enhanced error-handling as long as it doesn’t break pre-existing, proper uses of {val}. Still, I don’t quite understand why is there so much effort being devoted to such fine nuances on error handling. If there is too much precision being asked of {val}, then an error alert about precision seems warranted since {val} has limitations and can’t keep up with a seemingly reasonable expectation. But for everything arising from operator error, a generic alert that amounts to {Val} does't work that way. Instructions are (HERE) would seem to suffice. Using a catch-all, generic error alert might serve as another approach to error handling when {val} is buried 20 to 40 nested levels deep within {Lx} and its family of templates. Greg L (talk) 20:37, 20 December 2010 (UTC)

Thanks Wikid77, I understand what you mean and agree that we should keep the template as simple as possible and allow it to be nested in other complicated templates without going over the maximum nesting level. However, I'd like to keep the error messages as informative as possible, so I don't like Greg's suggestion: it may not be clear to somebody using the template why s/he's getting an error and they would end up wasting time trying to find out. Everybody who's had an application give you one of those frustratingly useless "Error 0x80070054"-like messages will know what i mean.

Here's an idea: would it be possible to output "<!--" at the end of every error and "<!-- -->" at the end of the template? That should hide any output after the first error or, if there is no error, effictively do nothing.     — {{{1}}} (talk) 09:55, 22 December 2010 (UTC)

uncertainty combined with an exponent

{{val|1.234|0.056|e=7}} expands to 1.234±0.056×10⁷. Shouldn't it expand to (1.234±0.056)×10⁷?

I cannot find a reference mentioning this specific case, but the NIST guide says you should write

63.2 m ± 0.1 m or (63.2 ± 0.1) m

but not:

63.2 ± 0.1 m or 63.2 m ± 0.1 

and considering the same multiplicative properties for units and exponents, I think the same rule should apply to both. Musiphil (talk) 06:56, 1 April 2011 (UTC)

(1.234±0.056)×10⁷ m is understood to mean (1.234±0.056)×10⁷ m because reading it as 1.234±(0.056×10⁷) m would be silly. (An uncertainty of 560 kilometers with a measurement reported to the nearest millimeter... nine orders of magnitude apart.) Likewise, if we're speaking of (1.234±0.056)×10⁻⁷ m, reading it as 1.234±(0.056×10⁻⁷) m would equally be silly. Your decimals would be unbalanced (if you insist on reading it that way, you would need to write 1.234000000 ± 0.056×10⁻⁷ m, and then you have an inconsistency in notation, plain for the value, with some power of 10 for the uncertainty. So you'd need to write the long form on both sides (aka 1.234000000±0.0000000056 m).

So basically you have two ways of writing uncertainty. (1.234±0.056)×10⁷, and 0.0000001234(56), both of which are understood to mean (1.234±0.056)×10⁷. Headbomb {talk / contribs / physics / books} 07:49, 1 April 2011 (UTC)

Introduction Q&A

(This is a trimmed version of answers from previous discussions, reduced in size for clarity)

• Q: Why should I use the template?

A: This template has the following benefits:

1. The results will automatically adhere to the Wikipedia Manual of Style from numbers.
2. Updates to the Wikipedia Manual of Style from numbers need only be applied to this template to modify all values that use it.
3. It makes sure the value does not wrap at the end of a line, so that it can always be read as a single value on one line in the text.
4. It's easier to use if you do not have a ± key.
5. It automatically replaces "-" (dash) with a "−" (minus sign).
6. It automatically formats numbers by inserting comma's into large numbers and spaces between decimal digits.
7. It automatically puts spaces between the various parts of the value where they should be.
8. You can easily add exponents of 10 and units
9. All this makes sure all values on all pages have the same look and feel because they will all use the same spacing, font size, positioning, etc...
10. Makes updating, checking, etc... by bots easier because they can recognize a value for what it is.

• Q: When should I use this template?

A: The template has been in use on many pages for quite some time without mayor problems. I don't expect any breaking changes, so there is no reason not to use it. Given the benefits of using this template mentioned above, I'd suggest that you use this template as much as possible.

• Q: Why not use <math>?

A1: Because the font in math tags differs both in face and size from the rest of the page, which messes up the layout of the page.

A2: You cannot copy+paste the data from an image.

A3: Images are slower to load and use more bandwidth, which is especially bad for the mobile version of Wikipedia.

A4: <math> does not automatically adhere to the Wikipedia Manual of Style from numbers.

• Q: Are there any known issues?

A: Because numbers can only be stored with a limited precision by Wikipedia servers, {{val}} cannot handle very large numbers, such as 123456789123456789. This is reported using a {{FormattingError}}, so it should be easy to spot. Since there is very limit use for such large numbers, there is no fix planned for this.

    — {{{1}}} (talk) 23:39, 30 September 2011 (UTC)

Money?

Does anyone know if there is a template that formats money amounts. I have problem with a table that sums up monetary amounts i.e. "{{formatnum:{{#expr:82000000+0}}}}" renders as "82E+7" instead of "82,000,000". This sort of thing must have been addressed somewhere right, but I can't find a template anywhere? Betty Logan (talk) 10:19, 28 September 2011 (UTC)

I think you've stumbled upon a larger issue that applies to any value, not just sums of money. {{val|82000000}} renders as 82000000, at the moment this is "8.2E+7" instead of "82,000,000". I'm not sure where the problem is; but I expect {{val/delimitnum}} may be involved. I also believe we've seen such issues before, but I can't see any previous discussion about it.     — {{{1}}} (talk) 16:43, 28 September 2011 (UTC)

Actually, I was wrong: while editing and using "show preview", {{val|82000000}} rendered as 8.2E+7. However, after submitting my comment above, it rendered as 82,000,000. It seems to change between one or the other randomly. This means that the result is not deterministic and probably outside of the control of the template. The only reason for this that I can think of is that WikiPedia different servers use different configurations (or software versions) and the results depends on which server renders the page. Here's some tests - try refreshing this page to see if the results vary and/or editing this and use "show preview" again and again:

{{val|82000000}} = 82000000

{{val|{{#expr:82000000+0}}}} = 82000000

    — {{{1}}} (talk) 20:00, 28 September 2011 (UTC)

A little testing seems to confirm my suspicion: if a page is rendered by a server which' name starts with "wm"; the number gets rendered correctly as 82,000,000 and if the server's name starts with "srv", it gets rendered as 8.2E+7. I've created a Google Chrome extension that extracts the server name from the comment in the HTML of a page and shows it at the bottom of the page. In case you want to help me confirm this, please install this plug-in from here. After installing the plugin, you should see "Served by ..." at the bottom of the page after it is fully loaded.     — {{{1}}} (talk) 20:36, 28 September 2011 (UTC)

I've asked others about this server side issue here     — {{{1}}} (talk) 22:11, 28 September 2011 (UTC)

Thanks for looking ino it. Unfortunately I don't have Chrome installed on my computer so I can't try the extension, but the server seems the most likely cause. The number format is only changed once it is changed into a numerical expression, so it seems likely it is due to what form the server stores the number in. I think consistency is an issue, since there will be plenty of cases where you specifically want the number in one form or another depending on the context of the article. If it can't be addressed at a coding/server level I guess it shouldn't be too difficult to code up an option for the output format in the template. I'll wait and see what the outcome at the village pump is first. Anyway thanks again for taking this up. Betty Logan (talk) 12:37, 29 September 2011 (UTC)

I've put this in the updated Q&A above. I'll leave this discussion here for a bit until the problem has been resolved.     — {{{1}}} (talk) 23:46, 30 September 2011 (UTC)

 Done This issue should now be resolved.     — {{{1}}} (talk) 19:49, 26 October 2011 (UTC)

Use by {{rndgaps}}

Moved from Template talk:val/delimitnum/fraction

 – * Pppery * _{it has begun...} 15:53, 11 October 2021 (UTC)

I've just created a new rounding template, {{rndgaps}}. It is similar to {{rnd}} but differs in that it formats numbers with thin spaces (like {{val}}). To do this it uses this subtemplate. Its two subtemplates, {{rndgaps/e+}} and {{rndgaps/e−}}, also use this subtemplate. If this subtemplate is to be moved or significantly changed, please make sure {{rndgaps}} is adjusted. JIMp _talk·cont 03:10, 22 February 2012 (UTC)

Year numbers

I moved this discussion to Template talk:Val/delimitnum#Year numbers, as this is where the change should be implemented. — {{{1}}} (talk) 08:51, 24 September 2012 (UTC)

units kyr, myr, byr

I'm trying to add the units kyr, myr, and byr. The unlinked version, the "u=" parameter for

• kyr was displaying "ka"
• myr showed "Ma", and
• byr showed "Ga".

I find nothing in units or unitswithlink or unitswithlink to make that association. This is contrary to the current documentation. Please either fix the documentation or discuss how the above association might have been being made so that I can fix the documentation. Thanks.

Here is the test data I used in a sandbox.

{{val|33|u=kyr}}:::::::::::{{val|33|ul=kyr}}

{{val|33|u=kya}}:::::::::::{{val|33|ul=kya}}

{{val|33|u=myr}}:::::::::::{{val|33|ul=myr}}

{{val|33|u=mya}}:::::::::::{{val|33|ul=mya}}

{{val|33|u=byr}}:::::::::::{{val|33|ul=byr}}

{{val|33|u=bya}}:::::::::::{{val|33|ul=bya}}

and the results were:

33 ka:::::::::::33 kyr

33 kya:::::::::::33 kya

33 Ma:::::::::::33 myr

33 mya:::::::::::33 mya

33 Ga:::::::::::33 byr

33 bya:::::::::::33 bya

It's working now, since I added kyr, myr, and byr to val/units so it would then display "u=" correctly. But if you'll remove kyr, myr, and byr from val/units, you might see what I mean when I say it shows "Ga", "Ma", and "ka". I have not looked at the template code. — CpiralCpiral 09:49, 15 October 2012 (UTC)

There is fallback code in case a unit is not specifically mentioned:

|#default={{#ifexist:Template:Convert/{{{1}}}|{{convert/{{{1}}}|d=ScientificValue/LoffAonSoff}}|{{{1|}}}}}

This is probably where the values come from. I'm not sure how {{Convert}} works or who added that fallback code.

I think {{val/units}} and {{val/unitswithlink}} could use a bit of cleaning, but I'm pretty sure at least some of these "odd" cases are actually in use by pages by now. Making sweeping changes to the template could result in pages using the older version showing incorrect information or errors. I would advise that you tread carefully and deprecate rather than delete. I have used {{FormattingError}} in the past to detect if any pages were using certain features of a template to make sure non where before I deleted the feature.

— {{{1}}} (talk) 14:25, 16 October 2012 (UTC)

Announce synchronization and documentation

I need to announce that

• The user data in Val/unitwithlink, Val/unitswithlink/test, and Val/units have been synchronized.
• {{Val/unitswithlink/test}} has a new interface, and it's talk page has been returned to normal.
• A version of the talk page "Q&A Intro" was moved into the documentation.
• Another stable reference has been made to val in the MoS at MOS:ERA.
• Documentation on "how to add units" is completed.

I would like to point out that step four of How to add units implies that there are minor technical problems with Val easily overcome by an edit to a (Val/units) data file. This is an acceptable burden. Automating from a single, val-user data-file will one day eliminate synchronization needs, simplify documentation and provide test, link, and rendering functions.

— CpiralCpiral 23:14, 25 October 2012 (UTC)

Year numbers

Moved from Template talk:Val/delimitnum

 – * Pppery * _{it has begun...} 15:52, 11 October 2021 (UTC)

I see that val is compliant with U.S. Government Printing Office Style Manual, which puts the comma on four digit numerals.

But units are needed sometimes, not only in the numbers of math and science, but in the general prose too. And years have units too. The MOS offers a choice of saying "2012" or "2,012" in any context, except for year figures of course.

Perhaps I'm going to var wanting to add BC, BCE, AD, and CE to unitswithlinks, asking someone to edit the template so that val was changed towards the "five or more" style and away from the "four" style when it comes to the commas mentioned in the MOS. — CpiralCpiral 02:11, 20 September 2012 (UTC)

I support your change: the current implementation goes against the MoS when used in mailing and shipping addresses, page numbers, or years. The change you propose would fix this without introducing a new conflict with the MoS. I can make this change for you if you can't do so yourself. — SkyLined (talk) 07:42, 20 September 2012 (UTC)

Part of my total one hour of template coder experience was looking at the val code and the code it called, but I could not do it. The 1000 page book, yea it happens in a three volume series sometimes. The four-digit street address, all the time; the botched zip-code someone forgot to preview and learn not to use val for it? Well, it's still worth all the goodness WP gets. Please do the honors. Thank you kindly SkyLined. — CpiralCpiral 08:23, 20 September 2012 (UTC)

Looking at the code, it seems that all numbers are formatted using the "magic word" {{formatnum:}}, which displays "2000" as 2,000. Obviously, it would make sense to modify its behavior, but I have no idea where to do that or if that would cause issues elsewhere. Alternatively, I could make an exception for 0 >= n > 10,000 and output them as-is. That is less elegant and clutters the template, and I'd like to avoid that. Does anybody know how I might find out if modifying the behavior of {{formatnum:}} is possible and desired? — SkyLined (talk) 08:49, 24 September 2012 (UTC)

CoreParserFunctions and Manual. If we find out how, we'll probably find more responsive audience. (Being ignored is no fun.) You meant 0 <= n < 10,000? — CpiralCpiral 06:34, 25 September 2012 (UTC)

Sandbox got the new line:

-->{{#ifexpr:{{{1|0}}}>9999|<!-- If the integer is more than four digits

whose closing logic modifies the next line (appends the |{{{1|0}}}}}):

-->{{formatnum:{{#expr:abs({{{1|0}}})}}}}|{{{1|0}}}}}<!-- Format the integer... else output the number as is

so now it works like we wanted it to, like this: sandbox<-->val

*{{Val/delimitnum/sandbox|2012}}<-->{{Val/delimitnum|2012}}
*{{Val/delimitnum/sandbox|2000}}<-->{{Val/delimitnum|2000}}
*{{Val/delimitnum/sandbox|1987}}<-->{{Val/delimitnum|1987}}
*{{Val/delimitnum/sandbox|10000}}<-->{{Val/delimitnum|10000}}

See Template:Val/delimitnum/testcases where I've highlighted the altered behavior in yellow. 174.24.222.12 (talk) 10:07, 6 November 2012 (UTC)

the first highlight shows a new, questionable twist on the case where the "value" is only a "dot" (the decimal point), which behaves differently now.

• {{Val/delimitnum|.}}<-->{{{Val/delimitnum/sandbox|.}}<-->{{Val|.}}

• {{Val/delimitnum|.}}<-->{{Val/delimitnum/sandbox|.}}<-->{{Val|.|nocategory=true}}

  [big red error messages removed to remove this page from error tracking category Johnuniq (talk) 04:43, 30 June 2016 (UTC)]

Now because {[Val|.}} (the last case) is an error, and because the user will not ever type Val/delimitnum (the first case) to cause it, val and val/delimitnum are equally rejecting the dot. Why is "the dot" even a test case? Is it a concern? If we do invalidate "the dot" testcase for the reason "the user will never type {{val|.}} or {{val/delimitnum/.}}", then the fix proposed in the above line is fully testcase-validated. If my reasoning is right and the test case is questionable (that the value "." should render as "0"), and if Skyline has supported this change (four digits are output directly), then how do we proceed forward with this work I have done?

174.24.208.111 (talk) 05:10, 8 November 2012 (UTC)

— CpiralCpiral 21:02, 26 November 2012 (UTC)
— CpiralCpiral 20:21, 30 November 2012 (UTC)

Sorry, I'm a bit busy at the moment. I'll get back to you when I have more time. — SkyLined (talk) 21:23, 2 December 2012 (UTC)

— CpiralCpiral 04:20, 7 December 2012 (UTC)

Resolved

 – I coded, sandboxed, testcased, and swapped in the change.— CpiralCpiral 00:32, 13 December 2012 (UTC)

Cool - I still haven't had time to read all the above and make sense of it. WRT the "4 digit numbers" changes you made: there was a small error in handling negative numbers; you forgot to make them positive to remove the hyphen. The code already outputs a minus sign, so your change made it output "−-1" rather than "−1" - I was able to fix that with a small edit. This was visible on {{val/test}}, albeit not very clearly, so I added a few test to {{val/test}} to make sure such errors can be caught sooner in the future. — SkyLined (talk) 23:04, 13 December 2012 (UTC)

I take that back - I reverted your edits, as they broke the grouping in negative numbers completely. From what I can tell, your if...else... logic was incorrect, causing this issue. These templates are quite complex, so please make absolutely sure your changes are correct. This is also why I haven't had time to help you - it takes quite a bit of time to make sure even the smallest change doesn't break some feature of this template :( — SkyLined (talk) 23:20, 13 December 2012 (UTC)

I made it work with {{formatnum|#|R}}. Please check both val and deliminum sandboxes with this delimitnum version. Thanks. — CpiralCpiral 07:44, 8 April 2013 (UTC)

But when I ran "delimitnum/sandbox" in place of "delimitnum", in the val/sandbox, those val testcases showed that now decimals don't work. Val has such a nesting problem, it's a prime candidate for a Lua fix for both nesting and year numbers, probably all in one sandbox too. — CpiralCpiral 08:34, 8 April 2013 (UTC)

I've made a stab at fixing this. See Template_talk:Val#Formatting_for_numbers_between_.C2.B1103_and_.C2.B1104_especially_years. Jimp 11:12, 27 February 2014 (UTC)

Minus signs

It says "replaces "-" (dash) with a "−" (minus sign)". The hyphen is mislabeled as a dash. To correct it I needed to know, does it work correctly with a hyphen (like this: - ) or with a dash (longer, like this for an en dash: – and like this for an em dash: — )? The answer is neither. {{val|-1}} shows as −1 (note there is both a minus sign and a hyphen, combining into a crooked line). {{val|–1}} shows as And {{val|—1}} also shows as Art LaPella (talk) 02:34, 13 December 2012 (UTC)

Given that the entire point is making these easy for editors to type on a keyboard, it should clearly be a hyphen, as that's the only key available without entering special codes. "-2" (hyphen 2) ought to correctly generate a mathematical minus and a numeral 2. (Unless you can make it convert all hyphens, dashes, and minus signs to render as minus signs, and then editors can enter whatever they want. But in any case, it should absolutely work with hyphens IMO.) Bigpeteb (talk) 16:45, 13 December 2012 (UTC)

I wrote that documentation and the code that does the replacing. I used the common name for the ASCII character to refer to "-" (which you refer to as the hyphen). This is the character you normally expect to get when you press the "-" key on your keyboard.

I added code to replace it with a minus sign to make it easier to create "correct" negative values. I see no reason to add code to replace any other Unicode dashes or similar characters. You may want to update the documentation if you feel it is confusing as is. — {{{1}}} (talk) 19:36, 13 December 2012 (UTC)

This Google search shows that the rest of the world calls "-" a hyphen, "–" an en dash, and "—" an em dash. So does the Wikipedia Manual of Style: see the beginnings of WP:HYPHEN and WP:DASH. Furthermore, even your special characters article's first reference says it considers - to be a dash, <hyphen>, or <minus>, where the <> signs denote a more official name. It appears to be a list emphasizing silly names rather than common names like "greater than sign".

Apart from the naming issue, I agree that it is reasonable not to code Val for someone using – or — which would be unusual. As for "code to replace [-] with a minus sign", my point was that it isn't replacing the hyphen. It adds the minus sign while keeping the hyphen, resulting in −1. I consider that to be a bug. Art LaPella (talk) 20:36, 13 December 2012 (UTC)

W.R.T. naming: I'm not arguing against changing the doc to use "hyphen" - feel free to do so if you want.

W.R.T. the bug: that is new - this must have been recently introduced. IIRC I saw somebody make some changes recently, which I haven't had time to check. I'll see if reverting those changes fixes this issue. — {{{1}}} (talk) 22:47, 13 December 2012 (UTC)

I think I fixed this: a recent change introduced the issue as I expected. I was able to keep the change and fix the "minus+dash" issue with a small edit. Thanks for letting us know about it. — {{{1}}} (talk) 22:57, 13 December 2012 (UTC)

Document fixed. Thank you. Art LaPella (talk) 23:18, 13 December 2012 (UTC)

Bug in large uncertainty values

One of the following numbers does not have a comma, unlike the others:

{{val|12345|12345|-12345|e=12345}} = 12345+12345
−12345×10¹²³⁴⁵

This is a bug. I do not know when it was introduced, or if it has been around since the template was created. Somebody should fix this. I may do so myself at some point in the future if notbody has time to beat me to it. — {{{1}}} (talk) 23:09, 13 December 2012 (UTC)

I think I found the problem is in {{val/delimitnum}}: it does not handle negative numbers (as evidenced on {{val/test}}).

Example {{val/delimitnum|-1234567890}} = {{val/delimitnum|-1234567890}}

Maybe this was introduced in the recent changes to {{val/delimitnum}}? I'll have a look and move the discussion there — {{{1}}} (talk) 23:14, 13 December 2012 (UTC)

Fixed by reverting the recent edit to {{delimitnum}}. — {{{1}}} (talk) 23:21, 13 December 2012 (UTC)

I wish I would have looked at Val/test. I only looked at Val/delimitnum/test. These things are unfortunate, but it was a good faith effort by a patient volunteer who got no help. Now I have to renounce several key plays related to this 4-digit integer display for year numbers. Bye for now. — CpiralCpiral 20:42, 14 December 2012 (UTC)

Delimiting

Commas to the left of the decimal point and spaces to the right: is there anyone who writes numbers like this? Of course, this is an old discussion. It was brought up a number of times between 2008 an 2010.

The 2008 discussion concluded that the MOS recommended formats like "12,345.67890". This may have been the case then, I don't recall, but it's not recommended now.

The second part of the discussion ended up focusing on different versions of the template for European and South Asian numbering systems. This isn't really an issue for the en-WP version template. Each incarnation of the template on a wiki of a given language can be adjusted to fit.

One year later the issue was again brought up, this time in light of changes to the MOS. Here SkyLined suggested adjusting the template to place gaps on either side of the decimal point with a possible option to have commas to the left and no separator to the right. This suggestion was made in order to conform with the new version of the MOS. From this discussion, though, it would seem that the change was reverted.

The discussion continued but didn't really get anywhere after this. It seemed that there was a consensus that if only the MOS would recommend normal formatting the template should be adjusted (as per SkyLined's suggestions) but the MOS is recommending something crazy and we attempted to fix the MOS but this was overturned.

Now, I'm not sure whether there was a change back in 2009 and I'm not sure whether it was reverted. In fact I don't recall the MOS's ever recommending commas to the left and gaps to the right. Here's a version from January 2009 which makes no mention of the said recommendation.

We need not really go picking through the 2008–2010 MOSNUM history, though, to determine what was said when: what's important is what MOSNUM says now. The current guidelines state that either commas to the left with no delimiting to the right or thin spaces both sides is acceptable. It does not permit a mongrel hybrid (I don't believe it ever did).

Currently {{val|12345.67890}} will give you such a mongrel. This is at odds with the MOS. What I do recall is the claim (somewhere along the line) that this was okay because you'll never have such input. No, never say "never". You might have such input and if you do, the template will give an output which doesn't conform with the MOS.

I'm proposing what was suggested all those years ago. Have the template give gaps both sides of the decimal point with the option to make it commas left and no delimiting right using a parameter. This will not only get rid of the MOS-defiant mongrel misformatting but it will make the template easier to use where there are a mix of numbers in an article (e.g. "23456" and "2.56756").

Jimp 14:42, 13 January 2014 (UTC)

Done. I've added the parameter fmt to allow formatting with commas. Jimp 23:18, 15 January 2014 (UTC)

template error?

see pluto. the problem should be glaringly obvious. -- Aunva6^{talk - contribs} 09:40, 2 February 2014 (UTC)

I've reverted the changes a minute before you reported this. Should be good now. Headbomb {talk / contribs / physics / books} 09:59, 2 February 2014 (UTC)

What was the problem? I've checked w the pre-revert version, and Pluto looks fine. — kwami (talk) 12:06, 2 February 2014 (UTC)

well, it had a mess of {{{{2}}43984}} and such. there were extra brackets , and extra 2's... i'm just not familiar enough with the template to have fixed it myself. -- Aunva6^{talk - contribs} 16:53, 2 February 2014 (UTC)

That was a temporary error that was fixed within a few minutes. — kwami (talk) 19:25, 4 February 2014 (UTC)

Errors

I'm trying to use this template, but sometimes can't because it displays improperly:

1. When both error and exponent are used, the exponent applies only to the error. The number + error need to be in parentheses. [Mentioned above.] [Fixed, though we might want an opt-out when + ≠ −.]
2. When positive and negative errors are used, they are formatted differently than simple errors. On my browser, they are twice the size of other numbers. Combined with them being super- & sub-scripted, this looks really bad. {{±}} has proper formatting. [fixed. forced fixed width messed up display.]
3. When the unit is °, ′, or ″, there is a preceding space though there shouldn't be. [never mind. just set as "suffix" s]

Also, the ± is made smaller than normal font. This raises accessibility concerns, but also looks bad if not all numbers are templated. [fixed. it was templated as Unicode, which is unnecessary.]

— kwami (talk) 20:58, 1 February 2014 (UTC)

4. A side effect of the parentheses is that 1.604(48)×10⁻⁴ J now displays with double parentheses. Will fix later if no-one else gets around to it. — kwami (talk) 09:10, 2 February 2014 (UTC)

Template protected, can't fix. — kwami (talk) 12:34, 2 February 2014 (UTC)

5. {{val|0.00}} returns 0.00. It shouldn't do that: the number of zeroes indicates the precision of the measurement, so they shouldn't be truncated. — kwami (talk) 12:47, 2 February 2014 (UTC)

This is fixed. The problem was the integer check which was comparing the absolute value of the number with adding a non-zero digit on the end to the absolute value of the number multiplied by ten. Iff adding the non-zero digit gave a greater number than the multiplication, the template concluded that it was an integer. This works for most numbers but not for those between −1 and 0 nor for those between 0 and +1. The error was fixed using the truncation function. Jimp 11:29, 11 February 2014 (UTC)

degrees sign

Currently, {{val|142|3|u=°}} gives out 142°±3°, but it should give out 142±3°, without the space before the degree sign. Can somebody fix this? --JorisvS (talk) 09:53, 3 February 2014 (UTC)

In fact, it should be 142° ± 3°. — Mikhail Ryazanov (talk) 20:32, 3 February 2014 (UTC)

I've been using 's' for 'suffix' rather than 'u' to avoid the extraneous space, but that doesn't address the problem of it being in both places. The same is true of ′ and ″. We'll need an exception for those three values.

Another solution would be to add parentheses: {{val|p=(|142|3|s=)°}} → (142±3)°. — kwami (talk) 19:09, 4 February 2014 (UTC)

This problem has been fixed. Jimp 08:05, 12 February 2014 (UTC)

Uncertainty with exponential notation and units

If uncertainty is used with exponential notation or units, there must be parentheses:

"(1.234 ± 0.056) × 10⁷ psi", not "1.234 ± 0.056 × 10⁷ psi",

because in the latter "10⁷" and "psi" belong to "0.056" only (× has higher precedence than ±; see also NIST rules). — Mikhail Ryazanov (talk) 00:52, 13 July 2013 (UTC)

It's not just NIST, it's maths. Jimp 23:16, 15 January 2014 (UTC)

What do you mean by "maths"? — Mikhail Ryazanov (talk) 02:44, 22 January 2014 (UTC)

The multiply applies to each value in the parentheses, so the parentheses are needed due to standard rules of precedence. Johnuniq (talk) 05:06, 22 January 2014 (UTC)

This is exactly what I am saying. :–) And the problem is that currently these parentheses are missing. — Mikhail Ryazanov (talk) 23:30, 23 January 2014 (UTC)

That's what I was saying too (i.e. what I mean by "maths"). You multiple first then add/subtract, e.g. 1+2×3=7 but (1+2)×3=9. It's maths. Jimp 09:26, 13 February 2014 (UTC)

Done. However, there are parentheses even when the + and - errors differ. Are they necessary then? Should we have "(1.234 ^+0.056
_−0.044) × 10⁷ psi" or "1.234 ^+0.056
_−0.044 × 10⁷ psi"? — kwami (talk) 05:29, 2 February 2014 (UTC)

Thank you! I did not find explicit rules for asymmetric uncertainties, but I suspect that they also need parentheses. I would suggest, however, to make them larger, like $\left(1.234\,{}_{-0.044}^{+0.056}\right)\times 10^{7}~{\text{psi}}$, if possible.

Now it's time to change WP:MOSNUM#Uncertainty accordingly. :–)

Mikhail Ryazanov (talk) 08:43, 2 February 2014 (UTC)

With %age errors, does the %age come after the units? — kwami (talk) 09:06, 2 February 2014 (UTC)

Probably, yes. The notation should mean "quantity with relative error x%", so the units are included in the quantity, and the x% comes afterwards. By the way, ISO/NIST apparently have a strong opinion against using "percent errors" and thus do not recommend any reasonable format (I think, their notation "1.23 × (1 ± 5 %) m" is more confusing than helpful). I'll try to find what other manuals say. — Mikhail Ryazanov (talk) 05:02, 3 February 2014 (UTC)

I did not find anything about percent errors, but here is what The Chicago Manual of Style says in general:

12.59 Uncertainties

Uncertainties in quantities are usually written with a plus or minus sign (±): 2.501 ± 0.002 or, if there is an exponent, (6.157 ± 0.07) × 10⁵ or 10^4.3±0.3. However, there are cases in which the bounds rather than the range are given, and these may be unequal; hence,

${\text{...where }}D/H=1.65_{-0.08}^{+0.11}\times 10^{-5}....$

Uncertainties may also be specified as se for standard error, 1 σ (or a larger multiple) or sd for standard deviation. Finally, separation into random and systematic uncertainties is written as

71.0 ± 5.0 (random) ± 2.5 (sys)

or $71.0_{-4.8}^{+5.0}$ (random) $_{-1.8}^{+2.1}$ (sys) for asymmetric bounds. When such expressions occur in an exponent, it is preferable to write a separate expression for the exponent (see 12.49).

(I don't mean that they are a good source, but the are official — this is regarding the previous situation, where WP:MOS had its strange rules without any reasoning at all.)

Mikhail Ryazanov (talk) 22:01, 3 February 2014 (UTC)

Needed fixes

A summary of the problems listed above:

1. {{val|142|3|u=°}} produces ⟨142 ± 3 °⟩, with an extraneous space and a single degree sign, when it should be ⟨142° ± 3°⟩. Same problem with u = ′ and ″, though u = °C displays correctly with a space.
2. {{val|1.604|(48)|e=-4}} produces ⟨(1.604(48)) × 10⁻⁴⟩, with an extraneous pair of parentheses, when it should be ⟨1.604(48) × 10⁻⁴⟩.
3. {{val|0.00}} produces ⟨0⟩ when it should be ⟨0.00⟩. (The number of zeroes is significant as a measure of precision). But inputs like -1.00 display properly.
4. 1234.0 has a thousands space, but 0.1234 does not. The latter is ISO standard, but it looks odd together with a space in 1234.0.

— kwami (talk) 19:23, 4 February 2014 (UTC)

So, what do you want done? If you can tell us what the corrections are, that would be a big help. Kevin Rutherford (talk) 21:59, 4 February 2014 (UTC)

Headbomb reverted the recent changes to the template with edit summary "revert to stable version, use the sandbox to test stuff and make it work before rolling it out". That is very desirable, and I think all changes should be in Template:Val/sandbox. If there is something missing there (such as subtemplates that also need to be sandboxed), let's fix that so the template can be changed in the future in a more systematic manner. I saw a suggestion that this template should be rewritten in a module, and that is probably a good idea, but I haven't got the energy for that at the moment so unless someone else wants to do it, working on the template code in the sandbox seems best. What I could help with is setting up a decent testcases page because I have a module that makes that easy for a template like this. An example of such a test page is Template:Val/units/test, and the table of results is at Template talk:Val/units/test. The convert module has recently been upgraded, and a new feature should be used in {{val/units}} and {{val/unitswithlink}}—see "In {{val/units}}" at the bottom of this section. Johnuniq (talk) 22:57, 4 February 2014 (UTC)

Done! Kevin Rutherford (talk) 01:58, 5 February 2014 (UTC)

The recent edit introduced {{val/delimitnum/sandbox}} into {{val}}. I believe the recommended procedure would be for all changes to occur in {{val/sandbox}}, with updates made here only after there is agreement that testcases show there are no further outstanding issues. The following shows the current output.

• {{val|142|3|u=°}} → 142°±3°
• {{val|142|3|u=′}} → 142′±3′
• {{val|142|3|u=″}} → 142″±3″
• {{val|1.604|(48)|e=-4}} → 1.604(48)×10⁻⁴
• {{val|0.00}} → 0.00
• {{val|1234.0}}, {{val|0.1234}} → 1234.0, 0.1234
• {{val/sandbox|142|3|u=°}} → 142°±3°
• {{val/sandbox|142|3|u=′}} → 142′±3′
• {{val/sandbox|142|3|u=″}} → 142″±3″
• {{val/sandbox|1.604|(48)|e=-4}} → 1.604(48)×10⁻⁴
• {{val/sandbox|1.604|48|e=-4}} → (1.604±48)×10⁻⁴
• {{val/sandbox|1.604|48|-56|e=-4}} → 1.604+48
  −56×10⁻⁴
• {{val/sandbox|0.00}} → 0.00
• {{val/sandbox|1234.0}}, {{val/sandbox|0.1234}} → 1234.0, 0.1234

Johnuniq (talk) 03:39, 5 February 2014 (UTC)

Sandbox

I'll try to set up the sandbox for proper testing, and create some proper testcases. Here is a neat list showing the templates (may need to to update the comparisons):

{{#invoke:convert/tester|compare|Template:Val|Template:Val/angle|Template:Val/delimitnum|Template:Val/delimitnum/fraction|Template:Val/delimitnum/whole|Template:Val/units|Template:Val/unitswithlink}}

Johnuniq (talk) 09:03, 5 February 2014 (UTC)

I have finished setting up the sandbox templates and have started on the testcases.

The first two (Template:Val and Template:Val/delimitnum) call val subtemplates, and the sandbox versions call the sandbox subtemplates. If wikitext is copied from a sandbox template to the main template, the "/sandbox" occurrences will need to be manually removed.

The testcases pages are Template:Val/testcases and Template:Val/units/test. The talk page of each shows the results by comparing live template output with the fixed expected wikitext on the test page. More tests, including the cases mentioned above, need to be added, but I won't be able to do that for a day or two. Johnuniq (talk) 10:27, 5 February 2014 (UTC)

Yes, test this in the sandbox first. I've reverted all the recent edits to restore the stable version while the kinks are being worked out.Headbomb {talk / contribs / physics / books} 18:49, 5 February 2014 (UTC)

You've just restored a bunch of errors. The only one you've fixed is #2, which is hardly ever seen. — kwami (talk) 05:48, 6 February 2014 (UTC)

Let's forget about the main templates and get the sandbox templates correct. Are you aware of anything more needed in the sandboxes? It would be good to see testcases showing the errors you mention (that is, the wikitext that reveals the problem, and a very brief note of what the problem is). Johnuniq (talk) 06:55, 6 February 2014 (UTC)

The four problems I listed above and that we have all the test cases for. (Unless people decide they aren't problems.) Now, in addition to those, we have three old problems that we had fixed:

• 1±2 (poor formatting)
• 1+2
  −3 (poor formatting)
• (1±2)×10³ (incorrect bracketing)

— kwami (talk) 07:42, 6 February 2014 (UTC)

I have put the val examples from this section on the testcases page, using the output from Special:ExpandTemplates from the current {{val}} (because those outputs are not what is wanted, the tests are not much use at the moment). I haven't had an opportunity to think about what is going on, and am unsure what the correct output should be. At any rate, the next step would be to update the sandbox template with the recent fixes—I'm hoping you will do that. Then I can clean up the testcases and see if there is anything I can do to improve the template. Johnuniq (talk) 10:03, 6 February 2014 (UTC)

Other than the links to the units sandbox which you put in, the sandbox template is updated. — kwami (talk) 18:07, 6 February 2014 (UTC)

Aight, I've played with things a bit, and the only problem remaining is the bracketing in cases like (1±2)×10⁻³ [which isn't an issue at all, since if you meant 1±0.001, you would have to write 1.000±0.001, otherwise the sig figs wouldn't match, the bracketing is implicit in these cases], the degrees issue, and 0.00 --> 0. Headbomb {talk / contribs / physics / books} 23:30, 6 February 2014 (UTC)

It looks like essentially all the problems are still there. The only thing that's fixed now is the different font for the "±". And the one you say "isn't a problem at all", based on an argument that has nothing to do with the question, is actually the main problem, and the reason we can't use this template in our astronomy articles.

You also undid one of the fixes, saying the uncertainty "must be fixed width". Why is that? By making it fixed with, the uncertainty is 3× the size of the main number, which screws up the line spacing and generally looks terrible. — kwami (talk) 07:07, 7 February 2014 (UTC)

Asymmetrical uncertainties need to be in fixed with, otherwise they aren't correctly aligned (vertically), e.g. 1.23456+0.11111
−0.99999. And they were not 3 times bigger than the other numbers, they were exactly the same fontsize as regular superscripts and subscripts. Headbomb {talk / contribs / physics / books} 13:42, 7 February 2014 (UTC)

Alright, I took care of most things, and this code is tested and ready to roll out [it correctly takes care of the bracketing, and doesn't introduce new issues]. Unless someone finds a case where the new code is worse than the old code, I'm going to deploy it tonight.

Remaining issues are the 0.00 --> 0 issue, and the degrees issues which cannot be solved until we decide between (142 ± 2)° vs. 142° ± 2°. Headbomb {talk / contribs / physics / books} 16:01, 7 February 2014 (UTC)

Thanks, that helps with the brackets. Normal math formulation would use brackets for 3 args as well, but large enough to span the two uncertainties, so I added large brackets for that case, like we'd get w MATH coding. You might want to play with the size; I just used 'big'.

As for fixed with, asymmetrical uncertainties aren't a problem. At least, I've never come across a real case where that's a problem, but have seen plenty where the fixed width is a problem. However, changing the font looks really bad, like using {{unicode}} for individual letters within a word. On my browser, the digits are all caps and are larger than the 1st arg, though they're supposed to be smaller; combined with them being stacked atop each other, they look horrible. If fixed width were imporant, we'd use it w the {{+-}} template, but we don't. Compare:

1.012 ^+0.001
_−0.002×10⁻²²   (mixed fonts)

with

1.012 ^+0.001
_−0.002×10⁻²²   (single font).

The a=r causes problems without the w=f, so both should be removed, as in the much more common (and thus much more vetted) {{+-}} template. As for those few cases where the diff in width is a problem, perhaps we could add an option for fixed with that would affect the entire number?

Also, {{su}} has the warning, "monospaced : currently not printable to PDF". — kwami (talk) 19:23, 7 February 2014 (UTC)

The bracket in the 3 arg version entirely unnecessary and unsupported by standard MOS such as Chicago (see above). As for {{+-}}, it does make use of monospaced fonts, because it invokes {{su}} which itself uses monospace fonts. For a case where this is important, compare the ouput of the +/- template for 1.123456789^+0.111111111
_{−0.999999999} with the same html, only this time using a non-monospace font (like Candara, which you used above): 1.123456789+0.111111111
−0.999999999. Headbomb {talk / contribs / physics / books} 20:55, 7 February 2014 (UTC)

No, {{+-}} does not use monospace, as it does not call that option in {{su}}.

I'm not sure what your 2nd point is. You have two cases where the uncertainties are of different widths, one left-aligned and one right-aligned. But again, I've never seen an actual case where the alignment is that far off. I would support an option to make the val output monowidth, but it should affect the entire number, not just the uncertainty. It's bad form to mixed fonts within a number. — kwami (talk) 22:21, 7 February 2014 (UTC)

According to the NIST SI rules,[1] (#16), The digits of numerical values having more than four digits on either side of the decimal marker are separated into groups of three using a thin, fixed space counting from both the left and right of the decimal marker. Commas are not used to separate digits into groups of three.

Val currently separates 1 234 but not 0.1234, as noted above. However, while it always groups a 4th digit into a group of 4, the SI rules aren't clear about this. Taken literally, they would mean having a single digit after the 4th. Indeed, the National Physical Laboratory of the UK[2] says the space may be omitted in 4-digit numbers, suggesting just that. — kwami (talk) 23:06, 7 February 2014 (UTC)

In the Q&A, one of the questions is why we should use Val rather than MATH, and part of the answer is "because the font in math tags differs both in face and size from the prose, which can disturb the layout of a page when used inline with the prose." However, the uncertainties in Val are displayed in a font that also differs in face and size from the prose; our own description thus suggests the recent revert is not appropriate. — kwami (talk) 01:04, 9 February 2014 (UTC)

1. Angles are fixed.
2. I don't see the problem (maybe it was fixed).
3. The problem of zero point something has been fixed.
4. The omission of the space before a single final digit after the decimal is in accordance with MOSNUM which states "According to ISO convention ... it is customary to not leave a single digit at the end, so the last group after a decimal point comprises two, three, or four digits".

Jimp 13:31, 11 February 2014 (UTC)

Great!

Could you fix seconds of arc the way you did degrees and minutes?

As for the spacing, my point was that we do leave a space separating a leading single digit, but not a trailing single digit. Also, AFAICT from the ISO rules, they apply equally in both directions, and only apply to the 4th digit before and after the decimal point, not to the 7th or 10th. But that means the MOS has it wrong, and that would require some discussion, since we don't have to follow ISO.

Those people who've replied said they prefer parentheses with e.g. 1+2
−3 m, but don't feel strongly about it. ({{val2}} has it.)

We still need to fix the formatting of the uncertainties, since alignment is not an issue (as noted elsewhere, uncertainties are normally only one or two digits), but mixing fonts is. Once that's done, we can merge {{val2}} back into this template.

— kwami (talk) 14:26, 11 February 2014 (UTC)

@Headbomb: Thanks for addressing arc-seconds, but there's still a bug: it's doubled at the end. (See {{val|142|3|u=″}} → 142″±3″ ″ above.) — kwami (talk) 01:22, 12 February 2014 (UTC)

Strange, it doesn't do that for degrees or arcmins... Headbomb {talk / contribs / physics / books} 06:45, 12 February 2014 (UTC)

Alright, should be good now. Headbomb {talk / contribs / physics / books} 06:56, 12 February 2014 (UTC)

@Headbomb: Nope. No change. — kwami (talk) 07:26, 12 February 2014 (UTC)

1″±2″ looks good to me... Headbomb {talk / contribs / physics / books} 07:31, 12 February 2014 (UTC)

Got it. Headbomb {talk / contribs / physics / books} 07:36, 12 February 2014 (UTC)

@Headbomb: Should we do the same thing for 64%+13%
−15%, meaning 64% give-or-take? Also, when I come across things like 10+3
−3, should I convert to 10±3, or would that result in a loss of information? — kwami (talk) 02:59, 13 February 2014 (UTC)

We certainly have to do something about percentages. {{val|12|3|u=%}} currently gives 12±3 % which is a completely different thing to the 12%±3% we might expect. Likewise, if we're using {{val|12|3|-2|u=%}} we should expect 12%+3%
−2% not 12+3
−2 %. This can be done without too much trouble by treating percentages the same as angles. Jimp 12:20, 14 February 2014 (UTC)

Percent and permil added (1%±2%, 1%+2%
−3%, 1‰±2‰, 1‰+2‰
−3‰). Headbomb {talk / contribs / physics / books} 14:50, 14 February 2014 (UTC)

Perfect, at least for %, in the articles. — kwami (talk) 22:00, 14 February 2014 (UTC)

Edit and merge

We should remove the "w=f|" from the line

-->w=f|a=r|<!-- Fixed width, right aligned

It is not needed and it mucks up the formatting of uncertainties. Once those display properly, we can merge {{val2}} back into this template. — kwami (talk) 14:42, 11 February 2014 (UTC)

• Question: Can you offer some examples or more context. Is there consensus to merge {{val2}} into this template? — {{U|Technical 13}} ^{(t • e • c)} 15:59, 11 February 2014 (UTC)

Not merge, just this one feature. Merger would also mean adding more parentheses, and while we might have consensus to do that, it's not a big problem, and if we bother I'd make a separate request so we don't get conflict between them. AFAICT we do appear to have consensus to fix the formatting, except for Headbomb who keep objecting with strawman arguments. — kwami (talk) 23:36, 11 February 2014 (UTC)

The fixed width of asymmetrical errors has been in {{val}} since pretty much its inception [3]. It is needed to prevent problems such as 1.123456789+0.111111111
−0.999999999 on the wide variety of browser and fonts people use. Unless you show that consensus has changed and that people now want badly-aligned fonts, this won't be implemented. Headbomb {talk / contribs / physics / books} 19:28, 11 February 2014 (UTC)

That's a straw man: As has already been explained to you,[4] there are no such cases, because uncertainties are given to one or two sig figs. The relevant example would be

1.123456789 ^+0.000000011
_{−0.000000099}

vs.

1.123456789+0.000000011
−0.000000099

and that would be an extreme case (an "11" would occur 1% of the time). We also don't use fixed width in the far more common template {{±}}, which the val2-formatted data was converted from. As an editor active in the astronomy wikiproject said,[5] "I don't think mixing fonts is visually attractive or solving any problems". If we on rare occasion do need to fix the width, it should be done to the entire number, not just part of it, so we don't mix fonts, but can you show me a single instance where alignment is actually a problem? If this is truly an issue, we could add a fixed-width option to the template. — kwami (talk) 23:36, 11 February 2014 (UTC)

{{val}} is way more prevalent than {{+-}}, and that {{+-}} is lacking here only means that {{+-}} should be updated. Headbomb {talk / contribs / physics / books} 23:54, 11 February 2014 (UTC)

In astronomy articles it's the other way around. Regardless, we shouldn't screw up another template just because this one is screwed up. I take it you have no real-world example of why we need to mess w the formatting. — kwami (talk) 01:42, 12 February 2014 (UTC)

You've had several examples by now, but if you want more,

Candara

123.0+11.1
−9.9 vs 123.0^+11.1
_−9.9

123.0+1.11
−0.99 vs 123.0^+1.11
_−0.99

0.12345+0.00111
−0.00099 vs 0.12345^+0.00111
_−0.00099

0.1234567+0.0000111
−0.0000099 vs 0.1234567^+0.0000111
_−0.0000099

etc. Headbomb {talk / contribs / physics / books} 07:30, 12 February 2014 (UTC)

Where did you give "several" examples? I haven't seen any. And these aren't more, you just made them up. Where are the numerous examples that would justify messing up all our data, rather than fixing up just the few cases that need it? Where are *any* real examples? — kwami (talk) 07:48, 12 February 2014 (UTC)

There are only 33 articles which have this, and alignment isn't a problem in any of them. I listed them at the MOS discussion. — kwami (talk) 03:05, 13 February 2014 (UTC)

I see cases for both ways. Ideally, we should find a way to solve this without changing the font, if possible. If not, I'd like this to be an option, myself. —PC-XT+ 03:47, 13 February 2014 (UTC)

An option would be simple to add. As for fixing the width, that really does require monowidth characters, which means changing the font. At least, I suspect it would require a lot of coding to do it any other way. We can't just set the two numbers to the same width, as they do not always have the same number of digits. — kwami (talk) 06:08, 13 February 2014 (UTC)

Potential per-parameter problems

Please ponder these potentially problematic possibilities pertaining to the per parameter which have probably previously been passed over by people.

Potential per-parameter problem 1

If up or upl is specified without u or ul also being specified, you get an error message. Why should you get an error message? {{val|12345|u=/km2}} would be perfectly valid if you were talking about population density. up or upl should not depend on u or ul.

Potential per-parameter problem 2

If the u or ul unit contains a slash, specifying up or upl will give you another. For example, suppose we want to encode an acceleration rate of 12 kilometres per hour per second as {{val|12|u=km/h|up=s}} what we'll end up with would be "12 km/h/s". Double slashes like this we don't want (they lead to ambiguity ∵ ⁠(⁠a/b⁠)/c⁠ ≠ ⁠a/(⁠b/c⁠)⁠ ∀c∉{−1, 0, 1}, see Wikipedia:MOSNUM#Unit_symbols which says "Follow a slash in a compound unit symbol with exactly one symbol or parenthesis ..."). The simple solution, let's call it "Solution 1", would be to put brackets around the "km/h" so we'd have "12 (km/h)/s". A more tricky solution (tricky in terms of coding), call it "Solution 2", would be to combine the denominators like this "12 km/(h⋅s)".

Potential per-parameter problem 3

If the up or upl unit contains a dot, we end up with another problem. For example, suppose we have {{val|12|u=W|up=N.m}} what we'll end up with would be "12 W/N·m". We don't want dots after slashes (they again lead to ambiguity ∵ ⁠a/b×c⁠ ≠ ⁠a/b⁠×c ∀c∉{−1, 0, 1} and again get frowns from MOSNUM). We need brackets around the denominator like this "12 W/(N⋅m)".

Potential per-parameter problem 4

If the up or upl unit contains a slash, again we'll have more than one. For example, suppose the friction on some object is proportional to its speed, we might want something like this {{val|12|u=N|up=m/s}} what we'll end up with would be "12 N/m/s", i.e. double slashes again. The simple solution, let's call it "Solution A", would be to put brackets around the unit with the slash again so we'd have "12 N/(m/s)". The more tricky solution this time (even trickier than before), call it "Solution B", would be to flip the per unit like this "12 N⋅s/m".

Potential per-parameter problem 5

Potential per-parameter problem 2 plus 3, it's the combination of problems 2 and 3. For example, {{val|12|u=g/ml|up=N.m}} gives "12 g/ml/N⋅m". Again the solutions are use brackets and get "12 (g/ml)/(N⋅m)" (Solution 1) or combine the denominators and get "12 g/(ml⋅N⋅m)" (Solution 2).

Potential per-parameter problem 6

Potential per-parameter problem 2 plus 4, e.g. {{val|12|u=g/ml|up=m/s}} gives "12 g/ml/m/s". The solutions for this combination of problems 2 & 4 are combinations of their solutions. Solution 1A is the simple one: "12 (g/ml)/(m/s)". Solution 2A is trickier: "12 (g/(ml⋅(m/s))". Solution 1B is even trickier: "12 (g/ml)⋅(s/m)". Solution 2B is the trickiest: "12 g⋅s/(ml⋅m)".

It seems to me that the trickiest set of solutions (2, B & 2B) are the prettiest but I'd suggest we go with the simple solutions (1, A & 1A) not just for the sake of making the coding easier but because these would be less surprising to the users of the template and probably be a better reflexion of the user's intention (you don't expect things to be messed around) and because if you're linking the units, it becomes confusing if they've been flipped, split and/or otherwise rearranged. Jimp 11:13, 13 February 2014 (UTC)

At some point, people are responsible for how they use val. I don't think it's viable to anticipate every corner case and code defensively around it. For instance, 'Problem 1' isn't really a problem because writing 12 /s is just awful and shouldn't be done in the first place. Writing |u=1 |up=s [12 1/s] might be better, but it is still pretty awful. Which is why we force people into writing 12 Hz, or 12 s⁻¹. Problem 2 likewise isn't a problem as there is nothing ambiguous about 12 m/s/s [or 12 m/s² in better notation], as the order of operation still apply. A more likely/real problem would be the use of |u=W |up=m·°C [12 W/m·°C] to mean 12 W/(m·°C) instead of the current output of 12 W/m·°C, [Problem 3 and similar], but that is easily circumvented by putting |u=W |up=(m·°C) in the template (and likewise for |u=(g/mL) |up=(m/s) to give the awful 12 ((g/mL))/((m/s)) instead of the saner |u=g·s |up=(mL·m) [12 g·s/(mL·m)] or |u=g·s·mL⁻¹·m⁻¹ [12 g·s·mL⁻¹·m⁻¹]), as they are WYSIWYG when they don't recognize what's in there. Headbomb {talk / contribs / physics / books} 12:02, 13 February 2014 (UTC)

That being said, if a slash could be detected in the up= parameter (e.g. |u=foo |up=bar/baz), I'm certainly not against implementing brackets [foo/(bar/baz)] as a safeguard. I'm just not sure it's worth the effort to develop, test, and roll out. Headbomb {talk / contribs / physics / books} 14:38, 13 February 2014 (UTC)

• Don't let the name fool you, that is exactly what #titleparts: does. {{#titleparts:{{{up|bar/baz}}}||2}} → baz

You're right, the easiest approach would be to leave it and let users work around the problems. True, "12 /s" is just awful but "123/km²" is perfectly normal for population density. "12 m/s/s" doesn't seem ambiguous because writing this when you mean "12 m/(s/s)" i.e. "12 m" looks akin to insanity but what about "12 g/m/s"? Are we increasing linear density by 12 g/m every second or are we increasing mass by 12 g for every metre per second extra speed we have? 12 (g/m)/s = 12 g/(s·m) ≠ 12 g/(m/s) = 12 g·s/m. Well, there may be a correct way of deciding what something like that should mean but MOSNUM suggests we avoid it to begin with. Circumventing "12 W/m·°C" by using |u=W |up=(m·°C) is all well and good if the user realises there is a problem to begin with (but he/she may not) ... unless he/she wants to link the "m·°C"; |u=W |upl=(m·°C) is going to link to the non-article (m·°C). Anyhow, I'm glad you're not against the idea. As for it's being worth the effort, I've got an idea that might not be too difficult to implement. By the way, thanks for the #titleparts suggestion, that'll help. However, it's in the output not the input that we have to look for the slash e.g. {{val|12|u=mi/h|up=s}} gives "12 mph/s" which is what we want (on the other hand, if an input of bps were converted to the MOSNUM approved "bit/s", we'll have the opposite problem). It's a shame we can't detect a middot but you can't win 'em all. Jimp 07:34, 14 February 2014 (UTC)

Done. Jimp 12:25, 14 February 2014 (UTC)

There may be a way to do that with one of the various string-related templates (Template:Navbox_string_handling_templates). Headbomb {talk / contribs / physics / books} 13:12, 14 February 2014 (UTC)

Good point. I'll have to check it out. Jimp 02:59, 17 February 2014 (UTC)

I think I've found a way using {{str find}}. Jimp 08:50, 17 February 2014 (UTC)

• Avoid auto-brackets as creeping featurism: The tactic of auto-generating extra parenthesis brackets is just too much auto-rewriting of text, as a case of creeping featurism, and instead, just keep it simple. The added brackets can quickly lead to frustrating limits for template {val}, such as the common '32 ft/sec/sec' with nonsense brackets:
       • {{val |32|ul=ft|up=sec/sec}} gives: 32 ft/(s/s)
       • {{val2|32|ul=ft|up=sec/sec}} gives:
  As noted above, the expression "(sec/sec)" is equivalent to 1, and so the auto-generated "ft/(sec/sec)" is a nonsense method of writing "ft". As a computer scientist, I have learned over the years when to draw the line at creeping featurism; otherwise the overall results become featured creepyism of unexpected, nonsense results such as "ft/(sec/sec)". There was a related problem in Template:Convert, where the featured auto-rounding of results generated a nonsense range of 2 amounts showing the same result: {convert|105|-|106|F|C} gave "105–106 °F (41–41 °C)" rather than 40.6–41.1 °C. An easy solution is to turn-off the auto-rounding feature in such cases of close numbers, and just use simple precision+1 rounding, as a simpler template would have done. Another auto-feature was added to {{cite_web}}, to validate date ranges such as a conference booklet published for a 3-day meeting, date=7–9 May 2011; however if the conference begins at the end of May, then the date is rejected (for "date=31 May – 2 June 2011"), and the page is logged with thousands of invalid pages after reformatting 2.3 million(!) pages to check dates, because of featured creepyism to reject conferences which begin at the end of a month. In general, automatic features often have exceptions, as edge cases, where the automatic features should be avoided to deter bizarre consequences, such as "ft/(sec/sec)" or similar. Instead, just keep it simple. -Wikid77 00:53, 18 February 2014 (UTC)

I beg to differ. I don't agree that it's too much rewriting of text. I'd call it just the right amount of rewriting of text. The brackets make it clear to the reader what the writer intended by avoiding potentially ambiguous forms like "a/b/c" or "a/b·c" (which have been recommended against by MOSNUM). The limits we're talking about are simply these.

As for "ft/sec/sec", there are a couple of things to say about this.

• First of all, if you're encoding it as {{val|32|ul=ft|up=sec/sec}}, you probably should go back to the documentation which tells you that up is the denominator. If "sec/sec" is the denominator you specified, who are you to complain that "sec/sec" is the denominator the template gives you? Garbage in, garbage out. As with any template, you've got to read the documentation. Do so and you'll easily realise that the nonsense was {{val|32|ul=ft|up=sec/sec}} to begin with and that it's actually {{val|32|ul=ft/sec|up=sec}} that you mean.
• Next you'll note that {{val|32|ul=ft/sec|up=sec}} will give you "32 (ft/sec)/sec". Now the autogenerated brackets are giving you something sensible but you don't like it because that's just not the way it's done. You want the "common" "32 ft/sec/sec" and feel frustrated that you can't seem to get it.
• You could try {{val|12|u=ft/sec/sec}} (or, if you want it linked, {{val|12|u=[[foot per second squared|ft/sec/sec]]}}) thus circumventing these pesky autogenerated brackets. Of course, though, this would be to ignore the reason for putting them there in the first place.
• Common "32 ft/sec/sec" may be but it's not recommended on WP (for good reason); instead you should be writing "32 ft/s²" which you can simply get from {{val|32|u=ft/s2}}.

The few exceptions that there may exist (and "ft/sec/sec" isn't one of them) can be dealt with easily enough if ever they come up. In the general case, however, the brackets belong there and the template is simply putting them where they belong. We could leave it up to the editor to put them in but perhaps the editor doesn't realise that they should be there, perhaps the editor couldn't be bothered to put them there or perhaps the editor wants to link the unit(s) in brackets. Linking a bracketed unit becomes completely straightforward if the brackets are automatically inserted (e.g. {{val|12|ul=g|upl=kW.h}} vs. the {{val|12|ul=g|up=([[kilowatt hour|kW·h]])}} that would have been necessary before).

Thus the feature is not creepy, it's helpful; it makes coding simpler. It only puts brackets in if they should be there: the brackets it puts in are necessary firstly for avoidance of ambiguity and secondly for MOSNUM compliance. I cannot think of a case off the top of my head where the template would be coded sensibly but produce nonsense because of the autobrackets ("ft/sec/sec" doesn't count, it is nonsense to start with). Perhaps a case may exist but that could be worked around. This would involve less working around than that involved in putting the brackets in manually. Jimp 09:52, 18 February 2014 (UTC)

Trailing zeroes bug

Found another error, one not resolved in the sandbox. I thought we'd fixed trailing zeroes earlier, but I just came across this:

0.2257+0.0009
−0.0010 (current)

(sandbox)

at CKM matrix. Now that's an alignment problem. — kwami (talk) 22:05, 25 February 2014 (UTC)

Is this what it is supposed to look like? — Edokter (talk) — 22:11, 25 February 2014 (UTC)

Oh, I see it is stripping the last zero. Not so much an alignment problem. — Edokter (talk) — 22:12, 25 February 2014 (UTC)

I was being a bit facetious. — kwami (talk) 22:15, 25 February 2014 (UTC)

Fixed Jimp 10:03, 26 February 2014 (UTC)

Formatting for numbers between ±10³ and ±10⁴ especially years

A while back the fmt parameter was added to better adhere to MOSNUM but there was something missing. Firstly, years between 10000 BC and 10000 AD should never be formatted. Secondly, MOSNUM actually allows for four types delimiting styles.

1. group in threes with thin spaces left & right ({{val}}'s default)
2. group in threes with commas left (fmt=commas gives this)
3. group in threes with commas left iff there are four or more digits to the left
4. group in fives with thin spaces left & right

We might not need to worry about the fourth one since it's so that long decimal expressions of maths constants (e.g. π) can be read easily and the template can't cope with heaps of significant figures anyway. Number three, though, is worth considering.

To address this the template now checks whether the parameter u or ul is AD, BC, CE or BCE and, if so, the first parameter will only be formatted if the absolute value of the number is greater than or equal to 10000 (it only works for integers, years have no decimal points so there's no need to worry). Also, parameter fmt now accepts commas4 which formats the number with commas to the left but only if the number is greater than or equal to 10000 (style three mentioned above). Jimp 11:11, 27 February 2014 (UTC)