Template talk:Val/Archive 4

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

Archive 6

Archive 7

Alignment is screwed.

See 1+0.11111
−0.99999 (at least in the latest version of Firefox). The 1s and the 9s should be lined up per last's years clusterfuck concerning this. Headbomb {talk / contribs / physics / books} 00:38, 30 May 2015 (UTC)

It looks fine to me (using Chrome). Jimp 14:36, 30 May 2015 (UTC)

Well it doesn't in firefox. Someone undid the changes from Edokter that fixed this. Apparently something involving

in the digits class [1] (ignore the TNR font thing).

Headbomb {talk / contribs / physics / books} 14:57, 30 May 2015 (UTC)

It looks like |w=f should give fixed widths. How's this look: 1+0.111111
−0.999999? Jimp 15:20, 30 May 2015 (UTC)

Aligned in Firefox. Yeah! But the font is needlessly different. The alignment should align at the start, so width should not matter. — CpiralCpiral 23:24, 30 May 2015 (UTC)

The change in font is not good. Alignment should be at left and font should remain unchanged. If you want to align by digit, fine, but this is secondary to the left & font. —Quondum 01:45, 31 May 2015 (UTC)

|w=f was the old solution. There was a big stink last year about how this was ugly, and the other solution was implemented. Search for the "14:27, 23 February 2014 (UTC)" post by Edokter in here, and you will see (in firefox) a bunch of unaligned digits. Search for "12:47, 24 February 2014 (UTC)" by Edokter, and you will see correctly-aligned digits. Whatever removed this should be re-implemented. Headbomb {talk / contribs / physics / books} 21:18, 31 May 2015 (UTC)

Looks like someone removed the digits class for whatever reason. I've reimplemented it. Headbomb {talk / contribs / physics / books} 02:46, 2 June 2015 (UTC)

Hmmm... looks like the .digits class is screwed up too... Let's ping @Edokter: for some help here. Headbomb {talk / contribs / physics / books} 02:52, 2 June 2015 (UTC)

I stepped away from this because no one wanted a real solution. It was Kwamikagami who removed the digits class back in April 2014, because he saw "inconsistencies" (which you would only see when using a font nobody else ever uses), and hasn't been put back since. That means Firefox users have always seen unaligned digits. Solution: Just put the digits class back in. -- [[User:Edokter]] {{talk}} 15:47, 2 June 2015 (UTC)

It seems browser behaviour has changed: it has the opposite effect in Chrome, and no in Firefox. Or perhaps my font (Arial) does not want to cooporate. Anyway, it's in the sandbox. -- [[User:Edokter]] {{talk}} 16:09, 2 June 2015 (UTC)

The solution should work for any font, not just for your preferred fonts, even if you think everyone should follow your preferences by default. They don't -- and we're supposed to be accessible to everyone. — kwami (talk) 16:19, 2 June 2015 (UTC)

It did work for any font, you just didn't like how it looked as lining numerals. -- [[User:Edokter]] {{talk}} 16:24, 2 June 2015 (UTC)

Fixed the digit class to disable kerning as well. That seems to have fixed it. So you can put it back in if you want. -- [[User:Edokter]] {{talk}} 16:24, 2 June 2015 (UTC)

Thanks for fixing things once again! Headbomb {talk / contribs / physics / books} 18:33, 2 June 2015 (UTC)

Integrate, simplify

Integrate and simplify to one, visible configuration file.

1. Integrate unitswithlink and unitswithlink/test.  Done
2. Integrate val/unitswithlink and val/units. Virtually done, now working in the sandbox. We want users to be able to add there own units in a single place and have it work with minimal testing already completed. The MoS requires the linked and non-linked versions look the same. Getting them from the same place does this. The next issue is blocking this one.  Done
3. Integrate /unitswithlink and /angle. We want the code to be clean. Why three switch statements to get functionality for arcseconds? Why not integrate them into the one that is unitswithlink? I must be missing something. N ... ?
4. Remove the parameters from unitswithlink. The MoS says nothing about having brackets around units, as in "45 (m/s)", as it seems the config file has implemented in it, all these {{{3}}}, {{{4}}}, {{{6}}}, {{{7}}} markings. I would remove them or document them. Discuss?  Done

To implement the sandbox, and achieve only only one config file instead of two (plus their own tests and their side-by-side test now done at {{val/unitswithlink/test}}), and to bring test eyes back to testcases, I need this discussion. — CpiralCpiral 05:26, 23 May 2015 (UTC)

Integrating the three unit subtemplates might be good if it can be done without too much processing but merge {{val/unitswithlink}} and/or {{val/angle}} to {{val/units}}.

• Integrating {{val/unitswithlink}} and {{val/units}} seems a good idea.
• Integrating {{val/angle}} also may work as long as we can get the spacing & errors working correctly. For example,

{{val|12|2|u=deg}}	→ 6999209439510239320♠12°±2°
{{val|12|2|3|u=deg}}	→ 6999209439510239320♠12°+2° −3°

Note, though, that the current sandbox cannot handle {{val|1|u=deg}}.

• The brackets only appear where there would otherwise be ambiguity; {{val|1|u=m/s}} and {{val|1|u=m|up=s}} give "45 m/s" not "45 (m/s)". For example, is 1 A/m/s 1 A/(m/s) or 1 (A/m)/s and is 1 A/m·s 1 (A/m)·s or 1 A/(m·s)?

{{val|1|u=g/m|up=s}}	→ 7000100000000000000♠1 (g/m)/s	not 7000100000000000000♠1 g/m/s which could be mistaken to be 1 g/(m/s)
{{val|1|u=g|up=m/s}}	→ 6997100000000000000♠1 g/(m/s)	not 6997100000000000000♠1 g/m/s which could be mistaken to be 1 (g/m)/s
{{val|1|u=g|up=m·s}}	→ 6997100000000000000♠1 g/(m·s)	not 6997100000000000000♠1 g/m·s which could be mistaken to be 1 (g/m)·s

See the Ratios, Rates, Densities row in the General guidelines on unit names and symbols table in the Unit names and symbols section of MOSNUM.

Jimp 13:20, 24 May 2015 (UTC)

Thank you for your assurances and a link to a new MoS section, JimP. And now I see how the ambiguity can arise in certain cases. — CpiralCpiral 01:34, 25 May 2015 (UTC)

There seems still to be a problem with angles, percentages, etc. using the version you've got in the sandbox. See Template:Val/testcases#Non-spaced_units. ... Never mind; it's fixed. Extra ° signs, % signs, etc. were being added but these are already added by {{val/angle}} (which is necessary because they are added to both the main number & the ± error, also they are added before the × 10^e). That is, e.g. {{val|12|2|3|e=4|u=deg}} → 7003209439510239320♠12°+2°
−3°×10⁴; note that the degree sign comes before the "×10⁴" & that the errors also have degree signs. It's the same with percentages, e.g. "12 ± 3%" would mean 12 plus or minus 3% of twelve whereas if % is treated as a unit, it should apply to both, i.e. "12% ± 3%".

I've moved {{val/unitswithlinks/sandbox}} to {{val/units/sandbox}}. If we're going to use just one, we might as well give it the simpler name. Jimp 17:44, 29 May 2015 (UTC)

Also I was considering integrating the Val/angle config file into the Val/units config file, and replacing the dozens of calls to Val/angle done outside the START UNITS section val code with calls to Val/units instead. But if your recent fixes work, then for now (when configuring non-spaced units) users will need to edit several locations. Even so it's readily a vast improvement. Except now that bug has just returned

• Units per is failing for non-spaced units: {{Val/sandbox|1|u=m/s|up=deg}} → 1 (m/s)/°— CpiralCpiral 18:14, 29 May 2015 (UTC)

OK, when you fixed Units to achieve 12°+2°
−3°×10⁴ without the trailing-double non-spaced-unit bug, it reintroduced the {val|1|deg} bug you mentioned earlier. I'm happy about this.

I noticed about a dozen calls from Val to Val/angle to accomplish effects like 12°+2°
−3°×10⁴. I'm not sure if turning those dozen val/angle calls to val/units calls can fix both bugs. I'm not sure if reintroducing the old Unit's wrapper switch, with its call to val/angle, will fix both bugs.

Care to advise me? I don't mind if you want to take-on any or all of this, but at some point I'm going to want to know about what it would take to integrate val/angle, now that its obstacle has been uncovered as those two bugs trading off. — CpiralCpiral 00:01, 30 May 2015 (UTC)

What exactly is the issue with {{val/angle}} and what would integrating it with {{val/units}} achieve exactly? Headbomb {talk / contribs / physics / books} 00:26, 30 May 2015 (UTC)

The reason {{val/sandbox|1|u=m/s|up=deg}} isn't working properly is that the {{#ifeq:{{{2}}}|#47|/{{val/angle|{{{1}}}}}}} is missing from {{val/units/sandbox}}. You couldn't simply add it back in since there is no longer a {{{2}}}. In the current version, this parameter tells {{val/units}} whether it's a {{{u}}} unit or a {{{up}}} unit (nbsp vs #47). In the sandbox version this info isn't being passed to {{val/units/sandbox}}. Jimp 00:49, 30 May 2015 (UTC)

[This] and [this] should fix it up. Jimp 01:12, 30 May 2015 (UTC)

Thank you, Jimp. I understand about {{{2}}}. (I did documented parameters 2-6 at Template:Val/unitswithlink#Arguments while attempting to surgically remove them.) I'll take a look at what we've got, and decide whether or not to implement it (major changes #2 and #4). Change #3, integrating val/angle into val/units, can wait. — CpiralCpiral 08:01, 30 May 2015 (UTC)

@Headbomb, I want to integrate Val/angle precisely because it has units in it, and 1) I am the one who documents how to add units. 2) I am the one who maintains the synchronization of all these units files because no one reads the documents or because the process is too cumbersome. And 3) SkyLined said he'd love to see units integration done if I had the template skills, and Quondum said it would be nice to automate synchronization.

Val has a lot more units to add if people would only add them. After this upcoming integration and simplification, simplified documentation will guide the integrated additions; maintenance needs for them will be minimal, and more pages will use Val. Secretly also, I don't want to always have to default to Template:Convert to get units.

But really, as long as val/angle stays mostly stagnant, and its units are at least advertized in the config file, perhaps I'll be done with it and just document its separation of units and unitswithlink and its unique showing in the config file. — CpiralCpiral 08:01, 30 May 2015 (UTC)

Note that I'm not opposed to integrating it, it just seemed to be that integration for the sake of integration to be not worth the effort. I remember coding {{val/angle}} and it was a bitch to get it to handle all the cases properly. I made it as simple/efficient/well-coded as I could, but that's hardly an argument against doing things more efficiently. Right now, it's a bit of a misnomer at /angle, since it's real function is to handle unspaced units. (To my knowledge, these are limited to degrees, arcminutes, arcseconds, percents, and permils). If it simplifies things for the documentation, it could easily be moved to {{val/unspaced units}} or similar. But I could also quite easily write documentation for /angle if that's all it took to move on to more productive issues.

I'm also a bit unsure what you mean by the 'config file'. Headbomb {talk / contribs / physics / books} 13:39, 30 May 2015 (UTC)

In 2012 before you hacked through Val to discover the spots where the one, START UNITS, section of code had to reach out its functionality and situate itself, and before all the calls to val/unitswithlink and val/units had to be modified in a way that necessarily offloaded coding burdens to them, they were already barely tolerable from a Val-user perspective. Afterwords they also got ugly marks and nested switch statements, after the style of its parent. Val offloads code, and its dumping grounds look to me like code creep, especially val/angle. I had to find out if it was possible to put it back into Val.

With the new String module I could finally move the complication and ugliness back into Val by turning the 10 lines of template code in the START UNITS section into 200 lines. My needs also demanded two additional uses for switch statements: the config-file switch and the filter-switch.

A config file is a #switch structured with partial transclusion tags in such a way that displays only the case-result lines and thus enables an editor unfamiliar with any template coding to view and edit a configurable template element, such as the colors of a sports team. (A config file also documents outside of /doc.) A filter is a #switch all of whose elements do nothing, but whose default applies to all elements not in the switch, such as adding an nbsp.

The new version of the config file, units/sandbox (before it was recently reverted back to using nested switches and val/angle again), uses an inline (not nested) filter to tailor spacing to any unit in a config file. Now after all that worked beautifully, I then discovered your units work deep in Val. My first thought was "why not modify those calls to use the new config file too, (exactly like the new, Lua-based START UNITS does)?" I had just started looking at diverting calls {{val/angle|{{{u|{{{ul}}}}}}}} and {{val/angle|{{{u|}}}|{{{ul}}}}} to val/sandbox/units when this sharing started. I had just started to worry that perhaps val/angle was required, after all that work, that splitting between units and unitswithlink was the only way. Besides, val/angle was also, perhaps, somehow, doing something else: avoiding adding the unit again when Val got to START UNITS. This was causing all manner of frustration for me because as a new template coder I was tiring of looking at code. Yet it seems val/angle is 1) a loss of config file units, 2) a loss of the filter innovation (to control spacing), and 3) an extra processing and nesting burden. — CpiralCpiral 20:26, 30 May 2015 (UTC)

There are advantages of using {{convert}} for units.

• {{Convert}} handles quite a few units (easily numbering in the hundreds, possibly the thousands). Writing a {{#switch}} to replace it would be cumbersome or even impossible. Also the bigger the {{#switch}}, the greater the post expansion template size and therefore the slower the page loads and the few calls can be made.
• Any unit added to {{convert}} automatically is added here.
• Using {{convert}} also helps keep a standard format for units.

Jimp 14:49, 30 May 2015 (UTC)

But there's nothing a #switch style can do to change post expansion size. We'll still add units irregardless of the expansion size increase or page load rate it causes. Perhaps Val will have to dump the #switch-config file angle and go another route, like Convert does. I doubt it, our units template already expands to over 400 units because of all the SI prefixes.

What is the actual number of case-result elements of a simple text switch that is perceivable when loading pages on the average internet connection? Or when does such a switch-caused delay get to an additional, one second if I'm running MediaWiki on my own computer? 500? 2000?

I'd hope the lack of a unit prompted its addition here, (while continuing to default to Convert of course), especially now that here is so close to being simple, efficient, and scary fun.— CpiralCpiral 20:26, 30 May 2015 (UTC)

So as it turns out, val/angle is the way to go, and one bug was caused by using Convert for the default, so I had to rewrite that default with Convert and val/brackets and all that. Headbomb has promised to rename val/angle, and probably delete val/brackets? Documentation and testcases are all prepared. I'm swapping them in now. — CpiralCpiral 09:02, 2 June 2015 (UTC)

I didn't promise to do anything. I just said if the name of the template was the source of contention/confusion, moving {{val/angle}} to a more accurate name is a trivial thing to do. Anyone can do that. Also I notice the current version of {{val}} invokes {{val/units/sandbox}}. Headbomb {talk / contribs / physics / books} 12:33, 2 June 2015 (UTC)

Thank you for the corrections, Headbomb! — CpiralCpiral 19:50, 2 June 2015 (UTC)

I just realized there's more work to do with unitswithlink and units subpages, preservations, moves, deletes, renames and test configs for me to do to finish my unitswithlink-to-units merge project here. Jimp, please give me some days to get these cleaned up before deleting anything besides val/brackets. Thanks. — CpiralCpiral 19:50, 2 June 2015 (UTC)

What should MoS say on unit "au"

Moved from Template talk:Val/units

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

See [2]. How "au" is interpreted as is a MoS issue, since it is sometimes used for atomic units and sometimes for astronomical units. I seem to remember a discussion in which we should standardize on "AU" for the latter, but cannot find it in the MoS. How should we deal with this? Raise it at WT:MoS? —Quondum 20:13, 3 June 2015 (UTC)

AU/au for 'Atomic units' of some unspecific type? That must be very old and very deprecated use. This has to be so marginal a thing as to be completely insignificant. The only thing au/AU is used for are Astronomical Unit / Arbitrary Unit. Headbomb {talk / contribs / physics / books} 20:53, 3 June 2015 (UTC)

Okay, assume for MoS purposes the others are not in contention. Should the MoS not indicate a preferred version for astronomical units (i.e. AU or au)? Though perhaps I should be asking this there. —Quondum 22:31, 3 June 2015 (UTC)

Not really sure that the MOS needs to explicitly legislate on this. E.g. F stands for Farad, a unit of capacitance. But could also stand for Faraday a unit of charge. MOS doesn't address this either. Headbomb {talk / contribs / physics / books} 23:49, 3 June 2015 (UTC)

WP:UNITS is pretty firm:

* In most articles, including all scientific articles, the primary units chosen will be SI units, non-SI units officially accepted for use with the SI, or such other units as are conventional in reliable-source discussions of the article topic (such as revolutions per minute (rpm) for angular speed, hands for heights of horses, et cetera).

It is clear from this (if you follow the link) that the MoS already indicates that the symbol with capital letters (AU) is to be used. —Quondum 00:58, 4 June 2015 (UTC)

The wp:Manual of Style/Mathematics people and wp:Manual of Style/Computing people each have there own MoS for such issues, as do Iranian and Syrian articles, Photography, and Psychology. Chemists, but not physicists or astronomers. — CpiralCpiral 06:37, 12 June 2015 (UTC)

What are you saying? If there is a contradiction with the main MoS, the main MoS should at least point to the more specific MoS. And is there a MoS/whatever (apparently not explicit) that overrides the main MoS on this? You seem to be insinuating that this might be the case. Unless it is, the MoS may be appealed to, as I have done. Or are you simply agreeing with me that the MoS applies in the absence of a more specific MoS? —Quondum 13:52, 12 June 2015 (UTC)

First of all, au is an unknown unit to Convert, so they just link it, and leave the problem to the user. Now au goes to a dab page, and Midas02 is currently a dab gnome working feverishly on a wiki-wide cleanup of content, so when they took a minute to edit Val/units to fix their dab problem, that was commendable for all parties concerned, but they picked the wrong unit code, as you so rightly point out, and that indeed it is a MoS ruling. When Midas02 started edit warring with "fix it yourself", he meant the dab page problem. I did a search to the effect of "insource:/=au/i" and quickly found the page Midas02 must have been trying to fix, and there was AU used all over the place for astronomical unit, so I made it consistently use AU, and thus fixed the dab problem that Convert has. Next I will inform Template talk:Convert

Is it really Convert's problem? Now I was just sharing a remark, but you've alerted me into something important here Quondum: with a wikified template, does that mean the template has its own MoS crew? In other words, where do we bring up these issues, here, or on the article talk page, or at the MoS, or on their wikignome user page?

Where is the line users can't cross, and who decides when they can? WP:3RR? It remains to be seen if we have to edit protect Val/units from all but template admins. Another example of this is the point you brought up about "premade links" (at Val talk). The user who skirts Val's intent to carry out the MoS mandates, is correct too. They can now make there own units there instead of letting us do it for them, even though we can win any adjudication concerning our own units here, and we might easily lose on the MoS talk page, but don't have to do what the MoS says if it seems to diminish Val's image. So we say "MoS compliant" as a great selling point (to those who read) and a motivation (to we Val maintainers), but surely we must prioritize that Val works widely and well. We twice made "premade links", (an undocumented feature) to work because hundreds of people are wanting to doing so because they don't read Val and MoS documentation. The real purpose of Val, then, is not just the oft stated "to carry the MoS banner"; but the real purpose of val is more to "make things easier" for the ignorant. Many things: easily typeable unit code (?) easily avoid reading the MoS (!), and now easily avoid reading Val (!!). But instead hundreds of articles are premaking there own unit (there instead of here), and we facilitate it by abandoning the enforcement of our hard won "easily typable unit codes" and hard won parameter designations. A wikified system is also a setup for friction.

MoS is written in a painstakingly authoritative style by necessity, but overall there are no rules because although standards are extremely useful because efficient, an irrational wiki exuberance is, miraculously and evolutionarily, more productive, which is what we really want when pursuing productivity via efficiency. (Its counter to the intuition of the ethics you and I certainly seek.)

The bad news is that similar up and coming Val/units friction is sure to materialize; the good news is that we can easily win every "units conflict" with wikignomes and article editors, and this serves to keep the ignorant not so free from spreading chaos. Please keep up the good work, Quondum. — CpiralCpiral 21:35, 12 June 2015 (UTC)

You describe it pretty well. I think a permissive approach (let people do much as they like, and allow gnomes to follow) is appropriate. In articles, the usual rules are fine. In val, similarly, except that care must be taken to avoid disrupting any articles using val. So val should support, when not a defined easily typeable string, any literal (though premade links should work for only for well-defined cases). It would be permissible to remove a unit string from val/units once there are no occurrences of its use. I think that this all fits with "easier for the ignorant". As to process and crossing lines, I think that we should just feel our way for a while; we do not seem to be in imminent danger of a war. But a tool for the gnomes would be nice: something that reliably picks up a specific string's use in val; a wikitext search is not quite it, even though it gives a good hit rate.

I've struck my earlier comment above, because the AU/au/ua/a.u. issue is truly confused, and the article that the MoS references on AU has no basis for preferring AU (SI does not seem to use this particular symbol). So I feel like I've only muddied the waters on this one. —Quondum 05:03, 13 June 2015 (UTC)

The wary sentiment about "looooong" negotiations at the MoS, has long been echoed here. Yes, it's usually much more clear what will fix itself in a local machine, as compared to the hearts and minds. But the whole FOSS movement seems to challenge techies to face this kind of mess. This mightn't have happened two months ago. Midas02 might easily have looked at how to add a unit, and left. So there can be many more instances of this kind of event.

I'm sure there's a tool somewhere at Wikipedia:Tools#Browsing_and_editing that'll load instances of a Cyrrus search and modify some hundreds of Val articles. (There's only 1239 articles that use Val.) Imagine not having to be backwards compatible. I've started using hastemplate:val insource:/regexp/. — CpiralCpiral 01:00, 15 June 2015 (UTC)

There are 9352 of {{val}} in 1040 articles in the 3 April 2015 dump. I could put a list of them in a sandbox if needed. April 2015 is a bit old now, but I won't feel like downloading a more recent dump for quite a while. There is a tool which presumably shows almost current results, allbeit not in a very helpful way. I don't know if it accepts parameters to do something more useful. Johnuniq (talk) 07:15, 15 June 2015 (UTC)

Will wait for it at User:Cpiral/sandbox/D. — CpiralCpiral 20:22, 24 June 2015 (UTC)

Error on random unit

Using non standard unit the {val} template creates a '[[' before showing the units with the '|u='.

An example can be shown on

http://wiki.riteme.site/wiki/List_of_device_bit_rates#Conventions — Preceding unsigned comment added by Marcnadrelm (talk • contribs) 11:43, 5 June 2015 (UTC)

This problem is quite pervasive, and might start people removing the use of {{val}}. Perhaps Cpiral or Jimp might have some idea of how to fix this? —Quondum 15:40, 5 June 2015 (UTC)

This particular fix was to add the unit to Val/units. The general culprit is {{Convert}}, where Val defaults to when it doesn't have the unit. It is a newly documented requirement for the new {{Val/units}} that it is supplied with both the markup and the link. We need to address this further, but for now, anyone add the unit to Val, and it just works. — CpiralCpiral 23:44, 5 June 2015 (UTC)

I found a fix. [[title|markup]] is no longer required. It will properly give "title" if no "markup is given [[title]]. It will go in ASAP. Thanks Quondum. — CpiralCpiral 00:25, 6 June 2015 (UTC)

Are you saying there is a problem in convert? I don't think the extra [[ is coming from convert (in the following, xbit/s is arbitrary text unknown to both val and convert):

• {{val|1000|u=xbit/s}} → 1000 xbit/s
• {{convert|1|xbit/s|disp=unit or text}} → xbit/s
• {{convert|1|xbit/s|disp=unit or text|abbr=on|lk=on}} → xbit/s

Johnuniq (talk) 00:28, 6 June 2015 (UTC)

No. Currently [[Title|Markup]] is required at Val/units so the new Val works. Convert will send [[Title]] for some units (I've just learned). I'm working on it, but am scheduled to go somewhere now for a few hours. If you want to swap in the old Val, I think the old units and old unitswithlink are still there waiting for it. — CpiralCpiral 01:22, 6 June 2015 (UTC)

Oh, and that fix I found? It was too easy. Now I remember why I had to enforce that syntax requirement where the title and markup have to be there. It has to do with unit spacing... The sandbox has five newly nested conditionals to address this, but may just need an additional regexp component %1. I should be able to conclude in about four hours from now. — CpiralCpiral 01:22, 6 June 2015 (UTC)

Should work fine with {{Convert}} now, and I'll update the documentation so there is no more requirement to include markup if it matches the title (or redirect). — CpiralCpiral 10:35, 6 June 2015 (UTC)

Error

{{val|150|u=g|up=cm³}} gets displayed as "150 g/(cm³)", instead of simply 150 g/cm³. --JorisvS (talk) 12:59, 9 June 2015 (UTC)

Please use the easily typeable name in Val, something like

• With unit per: {{val|150|u=g|up=cm3}} → 150 g/cm³
• With two links: {{val|150|ul=g/cm3}} → 150 g/cm³
• With one link: {{val|150|ul=gcm-3}} → 150 gcm-3
• Just markup: {{val|150|u=gcm-3}} → 150 gcm-3

If you like those three latter "easily typeable names", you can use the new configuration file, {{val/units}}:

gcm-3 = [[Density|g/(cm<sup>3</sup>]]

gcm/3 = [[Density|g/(cm<sup>3</sup>]]

Thanks for all the feedback. — CpiralCpiral 17:28, 9 June 2015 (UTC)

I don't know why {{val|150|u=g|up=cm3}} works now, because that was one of the things I tried. Anyway, everything is fine now, that's the important thing. --JorisvS (talk) 19:32, 9 June 2015 (UTC)

As you can see, operations have changed and could even be a bit flaky. It has to do with getting units from Convert, which is mostly a blessing, but I'm having to learning Convert units now, because relying on it has produced more and more Val code challenges. Meanwhile we have Val/units for configuring our own units to override Convert. Happy editing!— CpiralCpiral 23:18, 9 June 2015 (UTC)

List articles, List of nuclides

I patrol Category:Pages where template include size is exceeded, and in looking at List of nuclides, I found that it was transcluding {{val}} 745 times, and upon looking at the subst: diff for just one of those, I immediately saw why this page had exceeded template limits. Text like "END OPENING OF ERROR CHECKING, START OUTPUT" is being transcluded 745 times on this page! Quondum is correct. Please do insert <noinclude> tags around these comments. Wbm1058 (talk) 14:52, 2 June 2015 (UTC)

Doing... — CpiralCpiral 15:33, 2 June 2015 (UTC)

But a quick check shows comments don't substitute unless they are in onlyinclude. But Val is wrapped in an includeonly, and there are no onlyincludes. So although I was in a hurry because I believe you, its val/sandbox time first. — CpiralCpiral 16:04, 2 June 2015 (UTC)

 Done — CpiralCpiral 17:00, 2 June 2015 (UTC)

I appreciate that you believed me, but now I'm not sure that no-including the comments is helpful. Perhaps although we can see the comments substituted, they still don't count towards that magic limit of 2,097,152 bytes. If in sandbox testing of a page that fits within the limits, the post-expand include size doesn't budge a single byte after no-including the comments, then we can conclude that comments don't matter, and probably remove the noincludes, for improved readability. Wbm1058 (talk) 18:45, 2 June 2015 (UTC)

We still have an oversize problem, whatever the reason, one which will have to be solved. We need to substantially reduce the template expansion size. —Quondum 20:34, 2 June 2015 (UTC)

Quondum, agreed. However, I just ran a simple test in my user-space, and confirmed that while comments are substituted, and add to the size of the page they are substituted on, they are not transcluded, and do not add to the all-important post-expand include size at all. So, sorry I led y'all off the path. The noincludes around the comments may be removed to improve readability, and the solution will have to be found elsewhere. Wbm1058 (talk) 21:53, 2 June 2015 (UTC)

Understood. I noticed that there seems to be no effect of the noinclude tags on List of nuclides. I was simply pointing out that there is still a significant problem with this template, which must be solved, albeit "elsewhere" as you say. —Quondum 22:58, 2 June 2015 (UTC)

I'm currently removing all units from Val/units that Module:Convert/data can handle for us. That should reduce our excessive, include-size footprint by around 600%, fix List of nuclides, and enable Val for the many future articles like it. — CpiralCpiral 18:42, 6 June 2015 (UTC)

Along the same lines, it may make sense to try to remove little-used compound unit strings for which there is already an equivalent in template:convert. Can the articles that use the units associations in val/units be identified easily, so that we can make the use of strings more uniform between articles? Perhaps just a hidden category that flags articles with units not handled by convert. —Quondum 19:28, 6 June 2015 (UTC)

That hidden category would seem to be a permanently useful addition to Val/units. We need one to weed out little-used symbols. Val maintainers eventually have to go on special missions to kill symbols in articles to address resource issues. — CpiralCpiral 00:01, 7 June 2015 (UTC)

Hmm. That last change made exactly no difference to List of nuclides. —Quondum 21:25, 6 June 2015 (UTC)

The problem with List of Nuclides was, apparently, 745 Val |e= renditions. I've replaced most of them in order to make the article legible.

But yes we need some numbers and some explanations in order to, if nothing else, document Val's limitations (ala m:Help:Expansion depth/demo). What will determine whether it's refactoring the template code, or rewriting it in Lua, will be numbers and explanations. — CpiralCpiral 00:01, 7 June 2015 (UTC)

That you had to remove the use of val just to get the page to render is not really showing that val is a well-behaved template, whatever you might feel about the triviality of its benefit on that page. I notice that the feature where units that are linked and not linked are added simultaneously uses a lot of string processing, which presumably adds a lot to the expansion of the template. The feature is great, but there must be a more efficient way of implementing this feature. For example, in val/data instead of {{#switch:{{{1}}}|muA=[[Ampere|µA]]..., we might have {{#switch:{{{1}}}|muA_disp=µA|muA_link=Ampere..., and invoke it with {{Val/units|{{{u}}}}} or with [[{{Val/units|{{{ul}}}_link}}|{{Val/units|{{{ul}}}_disp}}]] according to whether |u= or |ul= has been set. I may have messed up the syntax, but hopefully I've given the idea. —Quondum 01:40, 7 June 2015 (UTC)

Granted I did say the new feature had a massive substitution footprint. But that statement might be like Wbm1058's "noinclude experiment". Wbm1058 is an expert at template limits: we too, like Wbm1058, need reports on experiments to produce the numbers concerning template limits to then compare older and newer versions, and we need to to then decide about moving forward or backward in code version trees. It is serious, and as soon as we get the numbers we can get serious about making the changes that will allow Val as a choice for list articles who could grow to 700 numeric items. Until then using a "find and replace" regexp makes Val → HTML is as trivial as installing Val as "the template" in long list articles that are unreadable because of <certain coding techniques?>. The numbers may show that no template can do it, or that Val needs to lose the switch feature. Whatever. Let's find out ASAP. — CpiralCpiral

Edit a page transcluding {{val}}, then see "Parser profiling data: (help)" almost at the bottom of the page in Show preview mode. The only thing below it is the category links and the fine-print privacy policy and disclaimers, etc. links. You may need to click on the drop-down arrow to show the table. Post-expand include size is the key metric to keep an eye on there. Now change {{val}} to {{val/sandbox}} or {{val/sandbox2}} to see whether the sandbox version reduces the post-expand include size. Maybe we can apropriate sandbox2 for testing the Lua module? – Wbm1058 (talk) 22:33, 7 June 2015 (UTC)

Lua candidate

I'm thinking that this template is an excellent candidate for conversion to Lua. Requested at Wikipedia:Lua/Requests. – Wbm1058 (talk) 15:13, 2 June 2015 (UTC)

Headcomb said above that it was overly difficult for him to add recent functionality (val/angle to add units to internal parts of numeric expressions). Val/angle is buried in a dozen places deep in the "functional programming language" that template coding is. I thought the Lua conversion would have already been done because of the oft-mentioned expansion depth problem.

While recently trying to analylze val/angle interaction, I thought Val/angle et al are a logical tangle that new template coders like myself will find impossible to contribute to. I could not do things I otherwise normally could do with a stateful approach like Lua. The major changes I just made were made possible because of Lua regex. And now this: the Lua String module calls take up a huge amount of transclusion space when I subst Val! Piecemeal is not the way to go because of that. — CpiralCpiral 17:42, 2 June 2015 (UTC)

The difficulty with {{val/angle}} was mostly that the exact logic was hard to figure out to take care of all the corner cases. It would very likely have been just as hard to code in any language. That being said, a LUA module is very likely the natural evolution of this template, given LUA modules tend to have vastly improved performance. Headbomb {talk / contribs / physics / books} 18:40, 2 June 2015 (UTC)

This template would be better in Lua, but it should be done by the people who maintain it. If wanted, I can help with the initial development and debugging, but I would only do that if those who work here want to start using Lua. Johnuniq (talk) 23:45, 2 June 2015 (UTC)

In relevant Val news:

• Workers' patterns appear to be in a second wave. The units code just got replaced with 200 loc, mostly Module:String, to simplify and integrate Val's reliance on subtemplates as it concerns units maintenance.
• List of nuclides uses Val 671 times, and that article no longer functions to display {{Reflist}}. Expansion-size problems related to this performance were unable to be fixed (by noincluding comments).
• Lua is widely used besides just at Module:Convert, which Val relies on for its defaults functionality (heavily) for units data.
• Johnuniq is offering to get Module:Val started in Lua. Thank you Johnuniq, but behind the scenes The Mol Man has been working on it all year. Looks about done? — CpiralCpiral 23:09, 4 June 2015 (UTC)

  Oh, yes, I should have checked Wikipedia:Lua/To do. "Warning, people are very attached to this template! You should take extra care to ensure it's a one-to-one conversion." (chuckle) Looks like a dropped ball waiting for someone to pick up. Wbm1058 (talk) 21:49, 7 June 2015 (UTC)

  As long as the template remains in active development, it's going to be harder for a Lua coder to sync behavior with the existing template. There should be a consensus on the current template's specifications, then freeze work on that to allow a Lua coder to catch up. Wbm1058 (talk) 22:01, 7 June 2015 (UTC)

I'm still developing units. I need to put some of the Val/units back I took out. First I'll generate all Convert units in "Val style", then we can do performance tests to determine how to balance string processing and switch size. String processing will increase if we accept all strings that Convert offers. Switch size will increase if we don't. — CpiralCpiral 20:40, 10 June 2015 (UTC)

Is it possible to leave the generated list of all strings that {{convert}} supports as a doc subpage, including a date and time of generation? It will be handy as reference to people who would like to add units to {{val}}. —Quondum 21:08, 10 June 2015 (UTC)

My thoughts exactly. Yes, and I think all of Convert's available units should be displayed at Val/units (but not transcluded to Val). I am imagining a multi-column list divided into sections the way /doc#conversions is divided. — CpiralCpiral 00:13, 11 June 2015 (UTC)

Woo-hoo. That is one long list of units. Seems like a daunting challenge. I'll leave the decisions to you ... —Quondum 03:11, 11 June 2015 (UTC)

When counting existing features, template Val, which should be the premiere template, the general "go to" for expressing numeral systems, actually has surprisingly few features. Just as Val/units can link to any article and have any markup, so Val should offer general features to represent all numeral systems. For example, module Val could soon start to offer template {{Gap}}'s base notation, and {{Base 36}}'s base conversions, and start to do complex numbers. — CpiralCpiral 20:40, 10 June 2015 (UTC)

Val can't handle square brackets in units (premade links)

See this edit made as a workaround for a {{val}} bug. The parsing is still problematic. —Quondum 04:41, 11 June 2015 (UTC)

It was undocumented, but the old Val/units would #default= to whatever was in {{{2}}}. Val was supposed to offer "an easily typable name", but currently 100s of articles don't seem to care about having to type extra. Try these searches to find the above two types of errors users are making

1. insource:val insource:/\{val/ insource:/u=\[/       to find u=[[ errors
   
2. insource:val insource:/\{val/ insource:/u=[^}]+su/       to find u= errors

What to do? Give them what they want. We must #default= to {{{2}}} and move calls to {{convert}} into {{Val}}.

That would solve two other problems we have:
1. In the #default= position where it is now, Convert always calls with lk=on, requiring unnecessary string processing. If it was moved to Val, we could just call it with lk=off when we needed.

2. Here's what Convert sends us, and what we do with, what is not a unit. Even if it was a unit, and it was blue, the problem is those surprise brackets.

{{convert|1|[[notAU]]|disp=unit|lk=off}} → notAU

{{convert|1|[[notAU]]|disp=unit|lk=on}} → [[notAU]]

{{val|1|u=[[notAU]]}} → 1 notAU

{{val|1|ul=[[notAU]]}} → 1 [[notAU]] — CpiralCpiral 19:38, 11 June 2015 (UTC)

Is disp=unit being used? Val is supposed to use code like this:

• {{convert|1|[[notAU]]|disp=unit or text|lk=off}} → notAU
• {{convert|1|[[notAU]]|disp=unit or text|lk=on}} → [[notAU]]

I guess you are saying you would like convert to remove any square brackets if lk=on is used? Or perhaps val could remove lk=on if a square bracket is found. Johnuniq (talk) 00:23, 12 June 2015 (UTC)

In Val/units: {{convert|1|{{{1}}}|disp=unit or text|abbr=on|lk=on}}, but why the "or text"? — CpiralCpiral 04:37, 12 June 2015 (UTC)

The above four "surprise brackets" → results have just changed, now that Val accepts markup for |u=. Now Val behaves like Convert. See how they are the same now. Convert's good.

Neither removing nor finding square brackets. Val/units just needs{{convert|1|{{{1}}}|disp=unit or text|abbr=on|lk={{#if:{{{u}}}|off|on}}. But again, why the "or text"? It's not documented at Convert, is it?

Gory details: Val's challenge is that Val/units always calls Convert with lk=on. Here's the scenario, and where it works and doesn't:

• Val calls convert lk=on: {{convert|disp=unit|lk=on|abbr=on|1|km/parsec}} and gets km/pc
• Val then tries to get the markup from [[km]]/[[pc]], but can't: →1 km/pc.
• OTOH, when Convert sends one link (the slash is blue): {{convert|disp=unit|lk=on|abbr=on|1|ft/mi}}→ft/mi, then it works: {{val|1|u=ft/mi}}→1 ft/mi

Val is not designed to remove brackets except in its own config file, where there is always one link, never two, so we simply must call with lk=off at times. — CpiralCpiral 04:37, 12 June 2015 (UTC)

Val can now handle square brackets in units.  Done — CpiralCpiral 04:37, 12 June 2015 (UTC)

Units from convert

Val can now make the internal call Convert|lk=off...  Done. It should be done (internally) for |u= because many cases in val/units were defaulting to Convert with lk=on. Now use {{Val/units|u=unit|lk=off}}. I'll document |lk= at {{Val/units}}. — CpiralCpiral 06:11, 12 June 2015 (UTC)

That fixed problems nobody's complained about yet, where Convert sends multiple links, and we extract only one, as we will ever do with the current format of Val/units. We won't know of more problems until we run a test suite on a complete set of units. I'm still working on part of that complete set by generating Convert's units in a Val style. Converts units are at Module:Convert/data in native Lua tables. — CpiralCpiral 06:11, 12 June 2015 (UTC)

If you want a bunch of val calls for every unit code defined in convert, please provide an example of what is needed using unit code ft, and I can readily prepare the list using tools I have for convert. It won't be complete because convert generates units with SI prefixes automatically, and can also handle what it calls engineering notation, and automatic per units. Examples of these are kg, e6cuft, nmi/h.

Re disp=unit or unit above, the difference is that disp=unit displays an error if the unit is not known to convert (mouseover the message for details):

• {{convert|1|xyz|disp=unit}} → xyz
• {{convert|1|xyz|disp=unit or text}} → xyz

Johnuniq (talk) 07:03, 12 June 2015 (UTC)

Thank you. [[Foot|ft]] is Val style. Also, group them by "utype", and also include each alias, please. ([[target's "link"|alias' "symbol"]]). Many thanks. For delivery, apparently Val has an unused Template:Val/unitsfromconvert page ready and waiting. (I've notified its creator.)— CpiralCpiral 17:29, 12 June 2015 (UTC)

I had assumed you wanted a page to test what val generates, so each line would be like these:

{{val|1|ul=sqft}}

{{val|1|ul=ft2}}

These would be used in a table or whatever to show what val generates for each unit known to convert (except for the automatically generated units: SI prefixes, engineering notation, x/y).

Instead, you are saying you want the linked unit displayed by convert. For example, for sqft and ft2 the result would be:

[[square foot|sq ft]]

That is the output from {{convert|1|sqft|lk=on|abbr=on|disp=unit}} and {{convert|1|ft2|lk=on|abbr=on|disp=unit}} (same for both because ft2 is just another way of saying sqft). The input unit code is not displayed.

The "square foot" title starts with a lowercase letter because of an optimization convert uses (it does not store the article title if it can be deduced from the unit name).

Please clarify exactly what is wanted. If it is the output, I guess you would also want the input unit code. Johnuniq (talk) 23:33, 12 June 2015 (UTC)

It is the output, and yes, plus the unit code, like you said. Like this: unit code = [[link|symbol]]. Like at Val/units. I can generate test suites from that.

Sorry for the confusion, but then maybe there are some unit codes that when combined with _ or / trigger a single link to a unique article. The links in the Automatic per table are not always interesting, (since the unit codes that generate those links are simply all possible unit type-combinations), but I believe there are some unit codes that, when they combine, generate such single links, no matter if they are in the Automatic per table or not. I think people would be interested in those combinations too just because they would know that using that combination would go to that article. Johnuniq, thanks. — CpiralCpiral 01:16, 13 June 2015 (UTC)

I put some results at Template:Val/unitsfromconvert. Re per units: In case you are not aware, some per units are defined in convert. To see them search for "==" in the full list of units. See "==g/m3" for a case where a link is defined for such a per unit. Johnuniq (talk) 07:54, 13 June 2015 (UTC)

Beautiful. Thank you very much Johnuniq. — CpiralCpiral 17:49, 13 June 2015 (UTC)

Units only in unitswithlink don't link properly

From my work disambiguating links, it appears that units that are only on {{val/unitswithlink}} (and not {{val/units}}) don't link properly when in the ul parameter. For example, {{val|2.2|ul=kG}}, which is supposed to say 2.2 kG (linking to Kilogauss), says 2.2 kG (linking to KG).

I've noticed a few of these - ppm and ppb are two I saw yesterday, and added to {{val/units}} because I couldn't figure out what was wrong with {{val/unitswithlink}}. Does anyone have any ideas? -Niceguyedc ^{Go Huskies!} 09:24, 13 June 2015 (UTC)

We reworked Val's interactions with its subtemplates and its calls to Convert. Val/unitswithlink was renamed Val/units, and the old Val/units is gone. Now we use the String module to do what the old Val/units used to do. That way there is only one place to add a unit, instead of two places to configure one unit. Thanks for reminding me this could happen, and to such a nice guy like you. Sorry, I'll make sure it doesn't happen to anyone else. — CpiralCpiral 04:50, 16 June 2015 (UTC)

Using a linked unit is broken

I think a recent edit to this template must have broken something. The code "{{val|3.846|e=33|u=[[erg]]/s}}" currently displays the text "3.846×10³³ erg/s" (somehow the opening double-brackets for the link has been stripped away and the closing double-brackets are showing up as plain text). - dcljr (talk) 06:31, 9 June 2015 (UTC)

Please use the |ul= parameter instead of the square brackets, and use the |up= parameter for "unit per", so it'd be {{val|3.846|e=33|ul=erg|up=s}}. (Yes we're making changes, and you've pointed out something else important, thanks.) You can also just add your own unit to Val, and call it whatever you want, probably ergs/s = [[power|ergs/s]] or something like that. See the new {{Val/units}}. — CpiralCpiral 08:30, 9 June 2015 (UTC)

Actually, no. Although you should use ul and up, I now would not ask anyone to use ul and up. Anyone can just use u and forget about ul and up and upl. But in that case, the page is on its own. Changes to val/units will not show up there. — CpiralCpiral 22:26, 17 June 2015 (UTC)

It seems to be fixed. As far as {{val}} is concerned, the [[erg]]/s is just an unrecognized string, which it should use unmodified, and should be supported. It seems to work fine now. —Quondum 22:48, 17 June 2015 (UTC)

Untitled discussion

Moved from Template talk:Val/unitsfromconvert

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

I added the onlyinclude tags not to mess up the spacing, but only temporarily so we can run load tests to see how defaulting to Convert effects Val with and without string processing versions.

Aspect one: No call to Lua module Convert from Val/units. At {{Val/units/sandbox}} remove the |#default = {{Convert... (#switch works without it), and then add unitsfromconvert: <onlyinlude>{{Val/unitsfromconvert}}</onlyinclude>.

Aspect two: No Lua string processing in Val. At {{Val/sandbox}} install a version of val with the old, pre string processing, START UNITS section, with "unitswithlink" replaced with "units".

Then edit {{val/units/loadtest}} and, {{val/loadtest}} and per Val talk:

... see "Parser profiling data: (help)" almost at the bottom of the page in Show preview mode. [...] Post-expand include size is the key metric to keep an eye on there. Now change {{val}} to {{val/sandbox}} or {{val/sandbox2}} to see whether the sandbox version reduces the post-expand include size. [...] – Wbm1058 (talk) 22:33, 7 June 2015 (UTC)

Rather than making sandbox versions permanent pages, we should agree to use some outstanding edit summaries: such as for val VAL WITHOUT LUA STRING PROCESSING and for val/units VAL/UNITS WITHOUT DEFAULTING TO CONVERT, so others of us can swap them in to see for themselves, or modify. I guess we'll need four tests, all combinations of the two version of Val and Val/units?

Val/units has both /testcases and /test, so I thought we'd combine them and then rename /test to /loadtest and fill it with about 700 calls to val/units. See how switch size effects post-expansion. (It's supposed to be costly.)

Val would need a new loadtest subpage, filled with, say the recent version of List of nuclides. — CpiralCpiral 20:45, 13 June 2015 (UTC)

Load test results

At issue are three challenges Val now faces. List of Nuclides was reduced from 750 {{Val|4-digit|e= calls to just 30 because Val breached the Post-expansion include size limit. Simple HTML reduced CPU time from ten to one second, and reduced the expansion size almost entirely. And two, Val recently changed (got ten calls to the String module) and Val/units recently changed (offloaded 352 units #switch cases to Convert.) And three, we're being asked to consider a Lua version of Val. (See recent discussions.) This data should help us decide.

The load test was about 900 calls to Val using 450 different units, each called two ways: one with u and one with ul. The {{Val/units/loadtest}} page will render about 8400 characters of output. The raw data is at Template talk:Val/units/loadtest. The various setups used the two sandboxes:

• {{Val/units/sandbox}} either included {{Convert}} by calling Convert indirectly through a 1-case #switch, or used its own 450-cases #switch instead.
• {{Val/sandbox}} either included module String or not, or included the ten 450-cases switches (representing the number of calls to Val/units) itself.

Setup	Expansion	Nodes	Lua Time	Lua Mem	CPU Time	REAL Time
Val and Val/units currently	2,008,660	500,040	3.260	4.39	10-19	10-19
Val with no String module	2,063,543	490,611	3.025	4.19	11.5	12
Val/units without Convert	1,973,055	680,089	3.396	1.44	10-16	11-17
No Convert and no String module	1,986,427	671,109	2.187	1.36	13-14	15
No Val/units and no Convert	1,909,114	702,988	3.28	1.43	15.6	16.4
Val without nested #iferror	1068831	597925	5-8	4.5	13-20	14-20
Template Limits in general	2,097,152	1,000,000	10	50	--	--

— CpiralCpiral 07:51, 15 June 2015 (UTC)

Comments

Please offer feedback Wbm1058, Quondum, Jimp, Headbomb, DePiep, and Johnuniq, or recommend a setup to add.

The expansion size problem is unlikely to be fixed because it is unlikely Val has enough sub-templates to integrate to reduce the multiplier effect bug. (Val calls Val/units calls Convert. {{Val/delimitnum}} calls Gapnum. There maybe others.) Not sure. — CpiralCpiral 18:57, 16 June 2015 (UTC)

The new String modules in Val added only 0.2 seconds under those extreme conditions. No problem. — CpiralCpiral 18:57, 16 June 2015 (UTC)

The Lua version of Val should get up to speed now. I think it will fix the List of nuclides issue, because a page with 1000 calls to Lua module {{convert|9|mm|lk=on|abbr=on}} loads in two seconds and is less than half way to the expansion limit. Besides, Val just got remodeled, and its generous, current list features are all it needs for the next several months. — CpiralCpiral 18:57, 16 June 2015 (UTC)

If Val, by itself, approaches limits (size, time) on a table-like page (even with thousands of invocations, this seems to me to be a problem. This, to me, is a solution that has become a problem. I cannot constructively comment, though, since I am not familiar enough with the template/Lua system to be able to offer an alternative. —Quondum 16:11, 16 June 2015 (UTC)

Yes, Val is the solution to the number-formatting and units-linking problem, and Lua is the solution to feature-additions and server-load problems. Lua can be learned in a day at http://lua-users.org/wiki, and, because Val is not near as big and complex as Convert or Citation modules, I think there's nothing here to learn about the MediaWiki version of Lua (Scribunto) except that "frame" is a name for "#invoke and the args". The way module Val will have to continue to share Val/delimitnum to other templates will be a slight challenge, but only for the Scribuntu meisters. — CpiralCpiral 18:57, 16 June 2015 (UTC)

Correct me if I'm wrong: It seems to me that a page with 900 uses of Val is marginal (in size, not so bad in time). Which is to say, it should still mostly work for the previous problem page, but it's kinda close? —Quondum 21:25, 16 June 2015 (UTC)

From the sometimes-near 20 second CPU time, plus more for the network, page-loading time (an unknown), I'd say Val is not advised for List of nuclides.

Your question made me realize that templates are for editor ease. For me, it is just as easy to remove 750 calls to Val on a single page, and thus also relieve the burden on the CPU and the page-delay burden on the reader, by replacing them all, with one quick application of a regexp. As a rule of thumb, when page-delay doubles because the CPU time is around half the the the page delivery time, which will include the network time (not measured here), its time. It's true that few should concern themselves over server CPU loads, but equally true that everyone cares about unnecessarily excessive wait times. (CPU overload could cause queue size of pages to deliver...) So a good rule of thumb on the use of templates might be that when the processor time approaches (some theoretical average) network time, everyone wants them gone, for the same reason they would want queues gone (speed), and it is time to take them out with a regexp. If the replacement was HTML, that would cement the style, but in some cases, that's well worth the price for speed. If it was a small, fast template instead of a large (because more general) template, then the style problem would be solved, and there would be no problem anywhere except for the valour of Val "services". — CpiralCpiral 21:36, 17 June 2015 (UTC)

The post-expansion include size problem is caused by the way error checking is done. Error checking nests the entire template eight times, and increases the expansion depth by eight. When I removed the error checking, the expansion size is halved. See WP:TLIMIT#Post-expand include size for why. Even so, the loadtest page takes too long to load, so we may not be helped by refactoring error-checking. — CpiralCpiral 00:50, 19 June 2015 (UTC)

4-digit spacing borked?

• 123
• 1234 --> 1 and 2 spaced. This should be unspaced.
• 12345 --> 2 and 3 spaced. This is correct behaviour.

Compare with

• 0.123
• 0.1234 --> 3 and 4 unspaced. This is correct behaviour.
• 0.12345--> 3 and 4 spaced. This is correct behaviour.

Please fix the 1234 case. Headbomb {talk / contribs / physics / books} 19:06, 2 June 2015 (UTC)

Is this incorrect behaviour? I consider it correct behaviour: only a trailing single digit is not spaced. A column of integers of any length should align; the thousands separator is used even when there are four digits. Does the MoS say otherwise? —Quondum 20:28, 2 June 2015 (UTC)

Hmmm I think it may be optional behaviour. I'll need to check. Headbomb {talk / contribs / physics / books} 23:13, 2 June 2015 (UTC)

This issue was raised for {{convert}} recently (here although that will be a bit hard to follow) because there is a comma=gaps option for convert. It was decided that 1234 should always have a gap after the 1, but 0.1234 should not have a gap before the 4 unless an option specifically requests that. Johnuniq (talk) 23:41, 2 June 2015 (UTC)

The current wording of WP:DIGITS, read strictly, says that if a comma is used it is optional for four digits to the left of the decimal point, but that if a space is used it is not optional (it simply says "Digits are grouped both sides of the decimal point"). But the distinction seems strange, and insisting on this, I guess, would be very wikilawyerish. —Quondum 02:22, 3 June 2015 (UTC)

It's important that four digits be left unspaced for dates, so we can link the half-dozen units for dates. — CpiralCpiral 23:43, 4 June 2015 (UTC)

 Done I'm going to swap in a modified (and tested) {{val/delimitnum}} because:

• There seems to be agreement amongst us on that we want that 4-digits pure option from the MoS.
• WP:DIGITS says four-digit page numbers or four-digit calendar years should never be grouped, and we now never have to force users to say "fmt=commas4" to comply.
• The {{e}} and {{10^}} templates use Val's very useful {{val/delimitnum}}, but don't need BC and AD unit handling or commas4 formatting.

Now it just works without having to say commas4, or being concerned with any units. If they they want commas, they will have to start saying so there:

{{val|1234|fmt=commas}} → 1,234

{{val|1234|fmt=gapsoranyotherfmt}} → 1234

{{val|1234}} → 1234

{{e|1234}} → ×10¹²³⁴

{{10^|1234}} → 10¹²³⁴

{{val|1234|1234|1234}} → 1234+1234
−1234

— CpiralCpiral 21:46, 18 June 2015 (UTC)

Signed four-digits should probably not be spaced, eh?

{{val|-1234}} → −1234

{{val|+1234}} → +1234

 Done — CpiralCpiral 00:14, 19 June 2015 (UTC)

This improved readability on a 107 articles:
insource:/\{val\|-?[0-9][0-9][0-9][0-9]}/}}
They are consistent unless they've used |fmt= with a 4-digit number somewhere else on their page.
Forty pages use "commas", (but less than half need to):
insource:/\{val\|[^}]*fmt=commas/}}
Eight of these intersect:
insource:/\{val\|[^}]*fmt=commas/ insource:/\{val\|-?[0-9][0-9][0-9][0-9][|}]/
They have inconsistencies because they use "commas", but not always. When they don't it defaults to gaps. None of this is Val's fault. Val was intended for scientific numbers. Gaps are them, per the MoS. So non-scientific articles have more difficulty with Val, having to say "commas", and when doing, contaminating our prefered 4-digit pure number. But "fmt=commas" is pretty self explanatory in the wikitext for users, so all is well. — CpiralCpiral 19:19, 19 June 2015 (UTC)

Enable cuteness

Per the load-test results, we now allow five of seven errors. Here they are:

1±2

Nutty, eh? But allowing them makes a dramatic difference. Besides, Gapnum will pick up the slack. Gapnum will elicit user error notifications for real errors, and it must accept all letters so it can gap numerals above base 10, all the way to base 36.

I've kept the mutual exclusion of

• |u= and |ul=
• |up= and |upl=

Val logic depends on preventing those last two errors. — CpiralCpiral 18:19, 19 June 2015 (UTC)

I haven't taken the time to learn the details of Lua module coding yet, but I think this is an area where Lua really shines vs. traditional templates. Maybe these five error-checks can be done within a Lua sub-module which is called by this template. Wbm1058 (talk) 22:04, 20 June 2015 (UTC)

It would not be a sub-module, it would be a couple of lines of readily understandable and fast code. The current activity in editing the template should be directed towards finding out how to do it in Lua. I indicated earlier that I would help in that. Johnuniq (talk) 00:34, 21 June 2015 (UTC)

Very nutty! Actually it's mostly an improvement; only the first is unwelcome. I wonder whether it would be worth just ignoring the hyphen/minus here. Jimp 16:40, 3 July 2015 (UTC)

4-digit grouping

I modified the template per Val talk "4-digit spacing borked?".

• output 4-digits pure, with no grouping, whether signed or not
• forgo units processing of BC and AD
• forgo commas4 formatting
• make self-documenting

I use three or four more calls to module String, but remove lots of switch cases. — CpiralCpiral 02:52, 19 June 2015 (UTC)

Broken example

Moved from Template talk:Val/units

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

Our doc page uses the example 9.8 m/s², which does not display or link sensibly. This suggests that we should explicitly support a unit of second squared. Or should we change the example? —Quondum 13:54, 20 June 2015 (UTC)

Convert is sneakily undercuts val

Moved from Template talk:Val/units

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

See this workaround. Clearly there will be many more examples like this, where convert interprets a symbol differently and val didn't catch it (here, J/C is taken as J/°C instead of J/C). Must this be overridden here for every unit incorporating the coulomb? I'd say no, if this template is to live up to its potential. Of course, I think convert should be changed, but it won't (some seem to feel strongly that it is better to fix this in val than to inconvenience editors by making them type degC or °C whenever convert is used. (Whatever would these lazy – or must we infer that they are supposed to be too stupid? – editors have done if they were merely entering a temperature without the need for converting it? Horrors!) I'll leave it to others to consider how to approach this. —Quondum 21:16, 23 June 2015 (UTC)

At Template talk:Val#Load_test_results "Val/units without Convert" shows that when we took Convert out and used only a fully loaded Val/units, that Nodes went up and Expansion went down. Nothing compelling about that. Before that when we removed all the units that convert could link for us, it seemed like a good attack on the performance problem we had. Then it seemed like a good idea to keep them gone even though the loadtest was not a compelling reason to do so. You've reminded me about putting all the ones back we took out. (Those were a lot of work to put in.) I've been working on sandbox experiments related to WP:TLIMIT on behalf of Val, and I've been working on {{Template usage}} on behalf of Val.

Everything after the = is one "unit code" to Val, but unlike Val, Convert, without being told specifically, often treats the numerator and denominator separately. There are workarounds to limit this at Convert, but not to eliminate it. So a better workaround is just to add "J/C" to Val/units. And in general to add all "per" units involving C, (and even more generally, others like C) to Val/units. So please take a look at this searchlink and make some improvements for Coloumbs on Val/units. It finds any C that is directly preceded or followed by a slash char: hastemplate:"Val" insource:/\{\{ *[Vv]al *\|[^}]*(\/C|C\/)/ prefix::

C definitely follows under the purview of MOS:CONVERSIONS, which says in effect that every °C ever written has to be converted to its °F except in scientific articles or articles about units, our favorites. So its no wonder Convert does C that way.

Val will only live up to its potential if units are maintained. That begs decent documentation and tools, and talk page attention. Now it's easier than ever (but comprehensive units maintenance is only possible with regex and *nix OS). Even so Val will only live up to its potential if it becomes Lua-based, so it can easily run long list articles like List of nuclides. But Val will always need units maintenance, and probably still default to Convert, and have overrides, but configuring units will altering Lua tables, instead of a switch statement, although much much simpler than the units tables at Convert. — CpiralCpiral 06:42, 24 June 2015 (UTC)

If Lua were used, it would be easy to have a single if statement that decides whether or not to pass a unit to convert. For example, a unit of the form C/anything might not be passed, while anything else would be. On a different but related topic, currently the only way to access convert's units is via the template which is inefficient from another module and I have noted that some helper functions should be added to convert to allow another module to lookup units. Johnuniq (talk) 09:14, 24 June 2015 (UTC)

The use by val of convert at its "user" interface convert is going to keep the maintenance levels at val high, because irregularities will keep behaving in unanticipated ways. To expect users of val to paste in new units in val/units every time they see that it is doing something unexpected is in my mind simply unacceptable. It must be possible to document the template behaviour in a way that does not involve "and then check to see what it does, and go and edit the template units if it misbehaves". If val is to use convert, there should be a regular form of units database that both val and convert can use, that gives a regular behaviour for all units. Convert can then, on top of this, substitute °C for C before using the database if it chooses. The current reliance on convert is just too ugly for me. —Quondum 12:34, 24 June 2015 (UTC)

Practically what needs to happen based on your observation is, we add add back most of the units we took out, at least all the per/units, and C and F. I'd want to check "Parser profiling data" on a load test again after adding them to be sure it doesn't make a noticeable performance impact. Hopefully then users will add most of what is needed after that, as their need arises, its so easy.

Module:Val/units has 318 units. And now we can look fwd, per Johnuniq, to a new units interface coming from Convert that may enable us to better automate the choice of which units to farm out. At the other extreme, how about removing Convert and adding a link to Val/units if the unit is missing? Just kidding.

At one possible extreme is the something unexpected wiki way, hand to mouth: edit, preview, edit, preview... edit, preview, save, talk. At the other possible extreme there are the long-term planner engineering types like us who first read the book and insert std naming databases, then proceed to just edit, save. The reality of situations is that they're in the middle, requiring patience and prodding, eh? — CpiralCpiral 18:07, 24 June 2015 (UTC)

I know better than to think that my way of thinking will prevail. And I should not criticize, since I'm not doing the work, and not in a position to even understand what is involved. The quick fix is, of course, just to add J/C to val/units, or just remove use of val where coulombs are in a compound unit. There is nothing fundamentally wrong, just re-architecting needed. Maybe the future convert will help. —Quondum 18:23, 24 June 2015 (UTC)

Your discussions are helpful. Always. — CpiralCpiral 02:08, 25 June 2015 (UTC)

I put all the units back in unsorted, so at least they are functioning. But lets not sort them just yet. While taking a closer look at Convert's handling of the 354 units we recently gave to it, I noticed too many units linking to different pages than we were. (e.g. Convert's A and V were going to the letters of the alphabet, and EV, EK, EG, EA, GA, GK, GV, were going to dab pages.) See {{Val/units/test}} for a comparison between Val/units and Convert. — CpiralCpiral 02:08, 25 June 2015 (UTC)

To get a perspective on the situation, here's a search link showing that only Power supply unit (computer) was effected, out of 6,917,366 articles. hastemplate:"Val" insource:/\{\{ *[Vv]al *\|[^}]*ul=(A|V)[}\|]/ prefix:: — CpiralCpiral 02:29, 25 June 2015 (UTC)

Now everything is caught back up

• Val/units are spiffy and restored
• Val/units/sandbox is duplicate of Val/units
• {{val/units/testcases}} has a fresh set of comparisons.

Please see {{Val/units/testcases#Commentary}}.

— CpiralCpiral 19:29, 26 June 2015 (UTC)

New feature

Taking {{val|1.2|ul=A}} as an example, here is my understanding of how val/convert work. The unit "A" might have been defined in val to have whatever properties are required. If that has not happened, val has no knowledge of what "A" means and cannot do anything clever with it. The final steps in deciding what to do would then be:

1. Val asks convert to display the linked symbol for "A".
2. If, like val, convert has no knowledge of "A", there is nothing clever convert can do.
3. As a final resort, what the editor typed is used verbatim, so the result would be "A".

The final resort step is performed by convert because it has to output something—it has no way to report a "unit undefined" error in a way that val could reasonably use, and there is no reason to do that because there is nothing val could do either. Therefore, {{convert|1.2|A|lk=on|disp=unit or text}} outputs "A". I don't see what else could be done.

Some of the above comments seem to suggest that "unit or text" should be abandoned in favor of some other scheme—perhaps convert could output the symbol if the unit is known, or output "?" as a signal to val that the request did not work. Johnuniq (talk) 11:25, 25 June 2015 (UTC)

Surely the appropriate action if no link is known is to remove the link, but to still display the input string, i.e. A rather than [[A]]? —Quondum 15:28, 25 June 2015 (UTC)

More generally now, the appropriate action if no unit code is known is to display the unit code (interpreted and rendered as plain wikitext markup). But what if it wants a link? A redlink in a preview is not confusing because it obviously needs further editing before saving, as usual. But what if it goes to a disambiguation page and looks good because blue? What can we do besides tweaking the dab-finding bot to look inside templates and message that requestor? We can tweak Val or Convert to indicate a problem if a linked unit code is unknown; we can't not do that, or else it confusing to give the request a black, marked up unit with that obvious link request sitting there in the template parameter "forever" displaying that confusion. But yes, giving a blue link does not promote our image. There's no need for us to continue doing those two things. We must give an error message or red, but not black or blue. — CpiralCpiral 18:15, 25 June 2015 (UTC)

Since Convert holds the units cards, and a units API is in the works, how about {{?}} for requests of Val, or something like {{Convert}} (talk) for requests of Convert? It'd be brutal to have to add another expansion level by wrapping the call to Convert in {{#ifeq:"link not found"}} — CpiralCpiral 18:15, 25 June 2015 (UTC)

Whitespace and numbers

Normally leading and trailing spaces in unnamed parameters are passed in. But we ignore leading and trailing spaces in our unnamed parameter: our number one parameter. That's good because we don't have to document how "ya can't have any space between the leading pipe and the number". It just works without saying 1=.

Normally inner spaces in any parameter values are passed in. So if a long string of digits has a space character somewhere in it, we pass it in, and gapnum fails. (See below and see {{val/delimitnum/testcases}}.) That's bad because its quite clear that its a number.

Take for example {{val|  123456789.1234567890  }} → '123456789.1234567890'

Should we allow spaces inside numbers, like

• {{val| 123 456 789 . 123 456 7890}} →

Oh the hypocrisy! We don't take what appears here to be properly formatted :-0

But if we allowed spaces for some reason, we'd be allowing

{{val|
123 
345 
789
.
123
456
7890
}}

→

See? It's the same error.

By the way, currently 4-digits pure works with outer spaces: {{val| 1234 }} → '1234'

but not with outer newlines:

{{val|1234
}}

→ 1234

{{val|
1234}}

→ 1234

— CpiralCpiral 06:36, 16 July 2015 (UTC)

I don't think spaces should be accepted because that would invite garbage in garbage out—obvious errors would be accepted as valid numbers. There may be a couple of editors who would want to enter a number with embedded spaces, but there would be many more who would puzzle over the weirdness in the wikitext. In particular, I would not recommend making val accept spaces in numbers while all other templates reject them. Johnuniq (talk) 10:12, 16 July 2015 (UTC)

I've added tic marks in my example data to stress the disappearance of the outer spaces. The newly added tic marks hilite the fact that Val seems to ignore spaces on the outside, seemingly violating standard template behavior for unnamed parameters. But, like all other templates, Val does not ignore spaces on the outside of an unnamed parameter. In fact Val passes the outer spaces to Val/delimitnum, and Val/delimitnum also does not ignore them, but passes them to Gapnum. It is module Gapnum that receives the spaces on the outside of numbers, but of course takes them off.

Should Gapnum have the internal option to accept inner spaces in the fashion that some web sites accept dashes and parenthesis and spaces in phone numbers in a single data field? Or is that why most of the surviving website-inputs of a telephone number have evolved three data fields that reject non-numeric characters? (-;;; I think the matter is closed. Thank you very much, Johnuniq.  Not done — CpiralCpiral 16:04, 16 July 2015 (UTC)

bug / inconsistency

There is either a bug, or an inconsistent default in this template: 3333, but 3333.3 and 33333. --JorisvS (talk) 08:03, 25 July 2015 (UTC)

It's intentional, see #4-digit spacing borked? above. The template code explicitly regards four digits with no decimal point as an exception, and does not insert a gap, although it will insert a comma if specified.

• {{val|1234}} → 1234
• {{val|1234.0}} → 1234.0
• {{val|1234|fmt=commas}} → 1,234

I'm not sure why this is done. Johnuniq (talk) 08:25, 25 July 2015 (UTC)

I thought as much. Because of this, in List of Solar System objects by size Titan is the only one without the space (until you get down to Pluto), which looks really weird. For such lists, it is rather inconvenient to required editors to format val specifically when the value happens to be four figures. --JorisvS (talk) 09:33, 25 July 2015 (UTC)

Assuming there is a good reason for wanting four digits to not show a gap by default (they seem pretty confident in the above discussion), perhaps the syntax fmt=gaps could be accepted to force a gap? The Titan example is at List of Solar System objects by size#Larger than 750 km. Johnuniq (talk) 10:12, 25 July 2015 (UTC)

The documentation was wrong. It already works.{{val|1234|fmt=gaps}} → 1186±2 — CpiralCpiral 21:51, 25 July 2015 (UTC)

endashes

This template should accept endashes every time, so that things such as {{val|30–50|u=km}} like it accepts {{val|30-50|u=km}} to produce instead of "". — Preceding unsigned comment added by JorisvS (talk • contribs) 08:09, 29 July 2015

I don't think a range is part of val's syntax, and the fact that "30-50" appeared to produce something useful was only an accident. Consider the following:

• {{val|12-34}} →
• {{val|1-2}} →

The dash in the above vals is a hyphen, and the dash in the first output is a minus sign (U+2212), not an en dash (U+2013). You can kludge a range like this:

• {{convert|30-50|km|km|disp=out}} → 30–50 km
• {{convert|30–50|km|km|disp=out}} → 30–50 km

Convert accepts a hyphen (first line) or an en dash (second line), and always uses an en dash for the output. Johnuniq (talk) 10:58, 29 July 2015 (UTC)

Thanks for catching that. In that case, Val should, like Convert, accept those to produce the correct output (so 30–50 km, not the visually nearly identical 30−50 km). To use Convert for this use is weird, because nothing is being converted. --JorisvS (talk) 15:09, 29 July 2015 (UTC)

Thank you JorisvS, you found a dash loophole, and together we've found a great example for the documentation as a way to use |end=.

Use {{val|30|end={{ndash}}50|ul=km}} → 30–50 km

Or {{val|30|end={{ndash}}{{gaps|1|234|567}}|ul=km}} → 30–1234567 km

Or {{val|1234567|fmt=commas|end={{ndash}}1,234,567|ul=km}} → 1,234,567–1,234,567 km

The Val page explains how the first parameter is a number. Now, Val sends that number to its /delimitnum, which sometimes sends it to module Gapnum, and sometimes to parser-function Formatnum. But... if the current Delimitnum counts four digits after temporarily removing any signs, it outputs "four-digit pure" directly, converting any dashes to minus signs.

Delimitnum code needs to remove only leading signs. Val code needs to explicitly check |end= for dashNumber, an important and common usage, because only then it can Val do its job and format that particular |end=. (Currently it just renders wikitext.) Users' manual workarounds for the longer numbers are shown in the examples. — CpiralCpiral 19:06, 29 July 2015 (UTC)

Testing. Using an endash directly instead of the template works, too, as well as nesting Vals: {{val|1234567|fmt=commas|end=–{{val|1234567|fmt=commas}}|ul=km}} → 1,234,567–1,234,567 km. Seems clumsy, though. It is often easier to just write it out without Val. --JorisvS (talk) 09:41, 30 July 2015 (UTC)

Ranges

There are suggestions under #Feature requests and #endashes above that a Lua version of val should support ranges. I have been wondering about that because it would help List of device bit rates if a slash could be used as a range (so a bit rate could be specified as 8/16 kB/s). However, using a slash in the input should be reserved for a possible implementation of fractions (where input 8/16 would give 8⁄16).

It appears there has only ever been one request for a range like "1-2", so I'm reluctant to add a bunch of complex code that may be used only a couple of times. One problem with interpreting "1-2" as a range is that it is easy to accidentally put a junk character in wikitext and it might be better for val to require a valid number—perhaps "-12" was intended rather than "1-2".

Another problem with ranges concerns what to do with the uncertainty and e parameters when a range is used. The following uses fixed wikitext to simulate the appearance of some vals to illustrate the issue:

• {{val|78.9|(3)|u=cm}} → 78.9(3) cm
• {{val|78.9|1.23|u=cm}} → 78.9±1.23 cm
• {{val|78.9|1.23|4.56|u=cm}} → 78.9+1.23
  −4.56 cm
• {{val|78.9|e=12|u=cm}} → 78.9×10¹² cm
• {{val|78.9|87.6|u=cm|range=-}} → 78.9–87.6 cm
• {{val|78.9|87.6|u=cm|range=/}} → 78.9/87.6 cm

The last two use show a possible way of specifying a range. Note that the second parameter is interpreted as the second value in the range, so it would not be possible to specify uncertainties.

• What is wanted?
• What should be the output for {{val|78.9|87.6|e=12|u=cm|range=-}}?
• Should uncertainties be handled? I don't see how because the second value might have different uncertainties.

Johnuniq (talk) 04:08, 31 July 2015 (UTC)

OK, I'll throw out an answer. Per Template:convert#Ranges of values, but sans the +/-, and the "by" and the "x":

1. {{val|78.9|(3)|u=cm}} → 78.9(3) cm
2. {{val|78.9|1.23|u=cm}} → 78.9±1.23 cm
3. {{val|78.9|1.23|4.56|u=cm}} → 78.9+1.23
   −4.56 cm
4. {{val|78.9|e=12|u=cm}} → 78.9×10¹² cm
5. {{val|78.9|-|(3)}} → Error
6. {{val|1/2|and|2//3|u=cm}} → 1⁄2 and ⁠2/3⁠ cm
7. {{val|78.9|or|1.23|4.56|u=cm}} → (78.9 or 1.23) ± 4.5 cm
8. {{val|78.9|or|1.23|4.56|7.89}} → Error
9. {{val|78.9|to|87.6|e=12|u=cm}} → (7.89 to 87.6) ×10¹² cm
10. {{val|78.9|-|1.23|e=8|4.56|u=cm}} → ((78.9–1.23)± 4.56)×10⁸ cm
11. {{val|78.9|/|87.6|e=12|u=cm}} → (7.89/87.6) ×10¹² cm

5-11 are simulations: 7 and 10 are Errors too, but shown for conviction. Otherwise, IF {{{1}}} is a number AND {{{3}}} is a number AND {{{2}}} is "/and|or|to/ OR /a dash or a slash/" THEN <output> <plus parentheses if |e=>, but then Error is emitted if {{{3}}} has parentheses or {{{4}}} or {{{5}}} is a number. Just a thought. — CpiralCpiral 08:32, 31 July 2015 (UTC)

By requiring writing {{val|1|-|2}} or {{val|1|–|2}} or somethings similar, such as Template:Convert does, we can avoid typos. The output should always show an endash, not a hyphen, of course, no matter what is written. As for uncertainties, they often don't make much sense with ranges, writing 500–700 and 600±100 often mean the same thing. When they are meaningful it is probably best to rewrite to not have a range. Hence, I think uncertainties combined with a range should not be allowed. --JorisvS (talk) 08:53, 31 July 2015 (UTC)

Thanks all, I'll chew those examples over and see what's involved in implementing them. Sounds doable. Johnuniq (talk) 10:47, 31 July 2015 (UTC)

The module now implements ranges. I can't think of why it would be wanted, but it handles up to 10 numbers with 9 range separators. Examples:

• {{val/sandboxlua|19|to|29|u=percent}} → 19% to 29%
• {{val/sandboxlua|1|or|2|u=cm}} → 1 or 2 cm
• {{val/sandboxlua|1|-|2|-|3|u=cm}} → 1–2–3 cm
• {{val/sandboxlua|1|-|2|-|3|e=12|u=cm}} → (1–2–3)×10¹² cm
• {{val/sandboxlua|1|-|2|3}} →

List of device bit rates has many examples like the first of the following, which could be replaced with the second:

• {{val|56.0|us=kbit/s}}/{{ntsgaps|33.6|u=kbit/s}} → {{val|56.0|us=kbit/s|nocategory=true}}/{{ntsgaps|33.6|u=kbit/s}}
• {{val/sandboxlua|56.0|/|33.6|u=kbit/s}} → 56.0/33.6 kbit/s

In the above is a suggestion that a range could include an uncertainty that applied to all values in the range. I have not implemented that because it's too easy for a mistake in the wikitext to be interpreted as an uncertainty, and also because it seems very unlikely that the same uncertainty would be wanted for multiple values.

The ranges are defined in the range_types table in Module:Val. The following are accepted:

,   by   -   –   and   or   to   x   ×   /

The module is now very near completion. The extra features requested above will probably have to wait, and I would now like to focus on cleaning up a few details and testing, prior to implementation. Johnuniq (talk) 04:02, 3 August 2015 (UTC)

Wrong white space

"{{val|340|55|u=°}}." creates a space between the unit and the period: "340°±55°.". --JorisvS (talk) 10:36, 4 August 2015 (UTC)

Yes, I noticed that while testing the module (it's "&nbsp;"). The module is finished and the final polishing and testing will be over soon so it could be used to implement the template and it might not be worth fixing.

• {{val/sandboxlua|340|55|u=°}}. → 340°±55°.

Johnuniq (talk) 11:20, 4 August 2015 (UTC)

Nowrap wikitext

I'm wondering what wikitext Module:Val should output for nowrap. The following shows the output, rearranged for legibility, from Special:ExpandTemplates for a simple val.

{{val|123}}
<span class="nowrap">
  <span style="display:none" class="sortkey">7002123000000000000♠</span>
  <span style="white-space:nowrap">123</span>
</span>

That includes two nowrap spans, using different techniques:

• <span class="nowrap">...</span>
• <span style="white-space:nowrap">...</span>

Is the second nowrap needed? I'm thinking the module should omit it.

Is the technique of the first nowrap sufficient? Or should it use the style of the second? My guess is that the first is best because it is what {{nowrap}} outputs. Johnuniq (talk) 01:17, 3 August 2015 (UTC)

After some testing, I decided to remove the inner nowrap. Johnuniq (talk) 11:22, 4 August 2015 (UTC)