Template talk:Val/Archive 5

This is an archive of past discussions about Template:Val. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 1

←

Archive 3

Module:Val

I have reworked the following:

Module:Val • Main module (some examples are shown in the documentation).
Module:Val/units • Definitions for units built-in to val.
Template:Val/sandboxlua • Use {{val/sandboxlua}} for testing.

The following parameters have not been implemented (they do not appear to be used in articles):

sortval= • alternative sorting factor
us= • alternative unit code for sorting
ups= • alternative unit code for sorting
~~a=l • align left~~ (now implemented)
w=f • fixed-width font

Everything else should work, although the unit definitions need tweaking, mainly to add scales so, for example, {{val|1|year}} sorts after {{val|99|s}}.

Testing shows that the output from the module closely agrees with {{val}}, except that there are many minor differences in the sort key, and some major sort key differences which need to be investigated. The minor differences are inconsequential as they would have no practical effect on the order in which items are sorted; they are mainly due to rounding errors from the different methods of calculating the sort key.

See my sandbox (permalink) for a copy of List of nuclides using {{val/sandboxlua}} instead of {{val}}.

Please try {{val/sandboxlua}} and report any problems. Johnuniq (talk) 11:25, 21 July 2015 (UTC)

sortval, us and ups are new. They may or may not turn out to be useful but they do have the potential. Are they never used? I'm not sure that they'd have been introduced if there was no use ... but I can't remember exactly why they were added ... it might come to me later. Jimp 17:38, 21 July 2015 (UTC)

all: hastemplate:"val" insource:/\{\{ *[Vv]al *\|[^}]*(ups|us|sortval) *= */ shows "us" is used at Conversion of units and at List of device bit rates— Cpiral Cpiral 18:30, 21 July 2015 (UTC)

Sandboxlua looks fine in {{val/testcases}}. Module:val takes only two seconds to process List of nuclides. (HTML takes one second. Val currently takes eight seconds). Val's as good as back in List of Nuclides with a simple flick of the history page. When do we start, and where do I sign up? (-; — Cpiral Cpiral 18:30, 21 July 2015 (UTC)

Thanks, that is a useful check. I would want to take another week or two fiddling with the code and checking the sort key issue mentioned above. I see that I forgot to pass the default align=right to Module:Su, so the module was showing the uncertainties left-aligned for the {{val|12|+34|-5}} test. I fixed that and implemented a=l and a=c for left/center align. I'll need some quiet time to think about the two articles and how they are making a sort key—that won't happen for a couple of days. Johnuniq (talk) 10:52, 22 July 2015 (UTC)

You're welcome, Johnuniq. Peace be with you always. — Cpiral Cpiral 23:02, 23 July 2015 (UTC)

Units

|u= takes markup just fine, as it should. Module Val seems ready, but it requires a huge change for Val/units. I'd like to see the ol' val/units format. It was actually visited twice recently by super gnomes who added units to solve problems they encountered. Why can't the format be: unit code = [[aricle title|unit symbol]] enforcing the same delimiter and spacing rules as MediaWiki software does for communicating this information. The parser logic is already waiting in Val.

Looking at Module:Val/units

ALIAS. If it's in there twice, the code can deduce that it must be an alias, right? We don't need ALIAS?
SI. If it should be marked as SI or given a sorting scale, these can be post-updated later by maintainers, right?
NOSPACE. We don't need NOSPACE. (I've learned these are all done.)
Templates. It doesn't use templates for markup, but val/sandbox/lua |u= can.

— Cpiral Cpiral 23:02, 23 July 2015 (UTC)

Definitions with markup: The module currently defines units like this (code, symbol, link):

m-1 m−1 Metre

That could be changed to be like this (code, link and symbol):

m-1 [[Metre|m−1]]

That would be fine, but are you sure it would really be helpful? I guess it would make the documentation of units easier. On that point, I was contemplating adding a function to list all the defined units for a doc page, and it could produce the same output regardless of which of these methods was used to define a unit.

Refactoring the code is not a big deal, so we could use one method of defining units then later decide the other was worth a try, and switch to it. I would have to wait until investigating the details to be sure, but I don't think there would be any problem from using the markup style, and am happy to start with that.

Thank you. The fewer changes at a time, the better. But I just noticed there's no Show preview to test that link and markup. A main reason to use the old format was to test the link and markup. That there is a loss. We could rame process Template:Val/units, but then there's the "or just add the unit to convert" remark, so that means adding a unit to module Val would entail sandboxing + makeunits + copy/paste route. I still kinda sorta like the idea of the proposed format. The process would still be foreign and complicated to document, require additional descriptions of testing elsewhere, and then cutting and pasting. All because there's no Show preview?! — Cpiral Cpiral 07:18, 25 July 2015 (UTC)

There's a sort-of preview, see #How to preview a new unit below. Johnuniq (talk) 10:19, 25 July 2015 (UTC)

ALIAS: There are three units defined like this:

degC °C ALIAS

The reason that trick was required was to make degC give the same sort key as °C. Temperatures require an offset as well as a scale, so calculating the sort key is tricky, and ALIAS was an easy way to achieve that—an editor can type "degC" but the module will treat it as if "°C" had been entered.

Are you suggesting that ALIAS could be removed to reduce clutter, and the definition could simply be:

degC °C

The module could deduce that an alias was wanted because no link had been entered. That's possible, but why? Requiring "ALIAS" make the intention clear, whereas omitting a link could simply be a mistake.

I was hoping for the old functionality: the person simply adds a wikilink, and it just works. Then module Val maintainers would do the rest. In other words, hide the implementation. That means a simple entry form with nothing complicated to document. Yes, no clutter. But I'm learning that the simple old way may not be worth it because there's no Show preview. — Cpiral Cpiral 07:18, 25 July 2015 (UTC)

NOSPACE: I started with NOSPACE to declare that there is no space before a unit like percent, but later I found that ANGLE was needed for those units which need to be positioned differently—"%" appears after the value and the uncertainty, if present. That meant NOSPACE was no longer required. I'm happy to remove it because it is now not used, but it is harmless and could conceivably be wanted in the future. It could be left in the module, but removed from Module:Val/units/doc to simplify the documentation.

SI: Yes, any adjustments like adding/removing SI or scales can easily be done at any time. It would be best if such adjustments were done in a sandbox so they can be tested, and to reduce the overhead of frequently editing a template used in over 1000 articles.

That's good to hear. But per {{Val/units/test}} having a problem with an individual unit affects very few pages. — Cpiral Cpiral 07:18, 25 July 2015 (UTC)

Templates: Modules have a problem with templates. It's fine to use a template or parser function in a parameter to a module: for example, {{val/sandboxlua|1|u={{lbf}}}} works due to the fact that {{lbf}} is expanded by MediaWiki before the parameter is passed to the module. However, the output from a module is not expanded so defining a unit as {{lbf}} will not work. It's like that because the main purpose of using a module is to eliminate overheads associated with expanding templates. If we wanted the module to handle {{lbf}} the module would have to recognize that it is a template (easy), then call frame:preprocess to expand it. That would not be hard to do, but it seems an unnecessary overhead. In practice it is very unlikely that putting the wikitext of {{lbf}} in the module would cause a problem. Before {{convert}} was changed to a module, adjustments to the template and its units were frequently made as people made tweaks and worked around quirks. However, only a very small number of changes to the units have occurred since December 2013 when the module started to be used—once things settle down, units are not likely to need adjustments. Johnuniq (talk) 02:02, 24 July 2015 (UTC)

Thanks for the explanation. I'm not sure Val/units will top out very soon; I think there are a lot of missing units. Given that, plus the simple Val/units config process, you can see where the module Val/units aspect of module Val is the hardest part to accept. Certainly I would give the uncertainties (of who would add how many units, and what they would need from module Val/units) for performance, the ability to put Val back in List of nuclides. That much is clear. The rest is just guesswork to me. So I ask for your opinion (you are helping so much with all of this process), given what we've shared so far, and perhaps a quick look at {{val/units}}, just how far should the development go to implement the simple Val/units config process? — Cpiral Cpiral 07:18, 25 July 2015 (UTC)

I think lots of complex code is justified in order to make the procedure to define units as simple as possible. The format I'm proposing was my attempt at doing just that. I won't get a chance to do much for a couple of days, but I'll play around with the alternative of the "code, link and symbol" example above. Johnuniq (talk) 10:19, 25 July 2015 (UTC)

How to preview a new unit

Here is how to preview a new unit—I'm not saying this is easy, but it is possible.

Put the wanted val in a sandbox or any other page. This is the first step, and the edit has to be saved. For example:
{{val/sandboxlua|1.23|ul=wocky}} → 1.23 wocky
Edit Module:Val/units and insert a line like the following (do not save):
wocky wocky Jabberwocky
Under "Preview page with this module" enter the title of the page from step 1 (for example "Template talk:Val" if it is on this page), and click "Show preview".
That shows the whole page including the val under test. The edit can be adjusted and "Show preview" repeated.
If wanted, click "Save page" to save the edit to Module:Val/units.

Johnuniq (talk) 10:04, 25 July 2015 (UTC)

action=list
I have added the ability to list all the built-in units—see the demonstration at Template:Val/list. It shows how to preview changes made while editing the units. It performs some validity checking and the result should be searched for "invalid" to see if any problems are reported. The display format could be prettified, perhaps with tables, if it were really needed. Give it a try—you can preview edits to Module:Val/units without saving. Johnuniq (talk) 07:49, 27 July 2015 (UTC)

Nice! Thank you Johnuniq for making Val/units closer to the way it was. Now if we could only edit that page and have it parse the new values into the new Lua tables it would be just like the old version.

I have a challenging request though: display only the subset of the (many) SI units whose link differed from the base unit link. This would be an improvement over the appearance of the old version, because it would reduce info glut by two thirds. (See Template_talk:Val#Regularization_of_unit_shorthands for previous efforts.)

Because isn't it true that SI units are automatic in module Val, by an internal attribute? If so then they don't need to be "verified", because they're automatic, as indicated by the new SI indicator on the page. (The only relevant information would be when the link differed.)

I mean the old page served two functions: 1) "units Val understands", and 2) "where it links". It was oriented around the idea that "anyone can edit". Having sortkey or other might be acceptable noise, just like the old pipe character was. Sortkey can also teach how sorting works, but the sortkey is much more likely there in order to verify the sorkey value, i.e. there for developers only, see? Sortkey was not a function of the old page.

I'm grateful though, and I'm just doing my job by mentioning these things.

— Cpiral Cpiral 21:02, 4 August 2015 (UTC)

Val lua able field data

I took actual Val field data snippets from each article, and demo'd them with module Val at {{val/sandboxlua/testcases}}. There's bound to be a few nuggets of info in there somewhere. — Cpiral Cpiral 07:05, 26 July 2015 (UTC)

Thanks, I'm looking. I've done something similar and have 2000 val examples including the results from Special:ExpandTemplates to see exactly what the current template outputs. Comparing that with the outputs from the module shows very minor differences, mainly inconsequential changes in sort keys. Some of the sort key issues are due to quirks in {{nts}} which I'll later document somewhere. Johnuniq (talk) 11:38, 27 July 2015 (UTC)

New features

Two new features are demonstrated below. Johnuniq (talk) 03:04, 28 July 2015 (UTC)

E notation

E notation is accepted for the first argument as an alternative to entering an e parameter. Entering both gives an error.

{{val/sandboxlua|1.5|e=+1234}} → 1.5×10⁺¹²³⁴
{{val/sandboxlua|1.5e+1234}} → 1.5×10⁺¹²³⁴
{{val/sandboxlua|1.234e5|e=5}} → Error in {{val}}: exponent parameter (e) cannot be used if the first parameter includes "e".

This is a universal format for numerals. Finally.

Now if someone would only remove |e= from the wiki we could clean up the documentation in order to better serve the many future users. Here's the list of articles to input to AWB: hastemplate:"val" insource:/\{\{ *[Vv]al *\|[^}]*e=/ prefix::

— Cpiral Cpiral 21:17, 4 August 2015 (UTC)

Sortable

For testing, the sort key can be displayed.

{{val/sandboxlua|1.234e5|debug=yes}} → 7005123400000000000♠1.234×10⁵
{{val/sandboxlua|1.234e5|sortable=debug}} → 7005123400000000000♠1.234×10⁵

Feature requests

Numbers

While we're in the business of doing numbers, lets do them all (drawing the line at formulas and variables until the day Val's a POSIX compliant bc programming language calculator/eVALuator). These are only requests to make numerals from each of the main number systems, even if they are simple to make otherwise, just so we have a full feature set.

Four features requested. — Cpiral Cpiral 05:51, 28 July 2015 (UTC)

These look fine, but they may not happen soon. I need to finish the module first, and that means deciding what to do about the sortval, us and ups parameters as mentioned above. The back tick is a bit weird because it looks like noise. If something simpler than base=7 is really needed, I think an alternative would be better, even if it's a letter as in "16v8" (v being the opposite of ^) or "16b8". Is a sort key needed with all this stuff? Johnuniq (talk) 09:59, 28 July 2015 (UTC)

No sortkey needed, just stubs for future, module Val, editors, just code comments. — Cpiral Cpiral 19:21, 28 July 2015 (UTC)

Those four features are the missing mind-share of Val's purview (provision of nowrap and HTML and prefix/suffix, spacing, font, etc.). They are a direction that deserves more thought about their timing: they are superfluous; but they're "loss leaders" to garner editors who associate numerals with Val; they are an editor stepping stone to other templates or to HTML; but they're also a Val stepping stone to Val's other meaning: numeric calculator, converter of bases and fractions and powers. (Something much more complex than its meaning today.)

Q. Do we really need all that? A. What's in a name when you have no processing limitations? Everything. And yes, we have plenty of instances of Val calculators and instances of Val wikitexters already.

We'd have to invent a markup for these four features. Superscript is obviously ^, fractions are obviously / or //, a complex number is obviously a string, but subscript is a problem. It could be "v" but that would preclude evaluating a base 22 or greater number. — Cpiral Cpiral 19:21, 28 July 2015 (UTC)

Base

Feature request, new parameter base:

{{val/sandboxlua|16}} → 16
{{val/sandboxlua|16|base=7}} → 16₇
{{val/sandboxlua|16`8}} → 16₈

The back tick ` is non-std. (Just made it up.)

Comment Subscripts are usually indicated by _, so 16_8 would make a lot more sense, if possible. Headbomb {talk / contribs / physics / books} 16:50, 28 July 2015 (UTC)

Powers

Feature request, new parameter power:

{{val/sandboxlua|16}} → 16
{{val/sandboxlua|16|power=7}} → 16⁷
{{val/sandboxlua|16^8}} → 16⁸

The hat ^ is std for powers.

Complex numbers

Feature request:

{{val/sandboxlua|3-5i}} → 3 − 5 $i$
{{val/sandboxlua|3+5j}} → 3 + 5 $j$

Rational numbers

Feature request, rational numbers, no?

{{val/sandboxlua|3/5}} → ⁠3/5⁠
{{val/sandboxlua|3//5}} → 3⁄5

Double slash for "really slanted"? (Just made it up.)

That should be ok because convert has the code, however, let's swap the slashes because the following shows what convert does:

{{convert|1+2/3|ft|in}} → 1+2⁄3 feet (20 in)
{{convert|1+2//3|ft|in}} → 1+2/3 feet (20 in)

The principle is that a fraction slash is the most common way of showing a fraction in text (per {{frac}}) so it should be a single slash, and two slashes gives an "extra" slant, making the horizontal rule. Johnuniq (talk) 09:51, 28 July 2015 (UTC)

Ranges

Convert has the code for ranges too. For Val's own units, how about its own range syntax, like Converts Template:convert#Ranges of values, but sans the +/-, and the "by" and the "x"?

By the way, {{{2}}} takes a dashNumber that probably should be an error, considering the range options.

{{val/sandbox|160|-180}} → 160±180 (Actual)
{{val/sandboxlua|160|-180}} → 160–180 (Reject?) — Cpiral Cpiral 21:17, 30 July 2015 (UTC)

Sort key quirks

I mentioned that many results from the module disagree with the existing template regarding the sort key. For anyone interested, there appears to be a minor problem in {{nts}} which is shown here. In all of the differences that I have examined, the module appears to be correct. Johnuniq (talk) 03:56, 28 July 2015 (UTC)

Micro symbol

µ = 'MICRO SIGN' (U+00B5) Correct symbol for micro.
μ = 'GREEK SMALL LETTER MU' (U+03BC) Depending on the font, this looks the same but is not the correct symbol.

In Module:Val/units, the only units which use U+03BC are:

μg/dL μg/dL Gram per litre
μg/dl μg/dL Gram per litre

Should that be fixed? Also, should the second use a lowercase "L"? Johnuniq (talk) 04:05, 28 July 2015 (UTC)

See Liter#Symbol for why use "L". You can guess why not use l (El).

My only ~~two~~ mistakes, thanks. :-) — Cpiral Cpiral 05:57, 28 July 2015 (UTC)

Module:Val ready for use

Module:Val is ready to go live. If no one raises a problem, I'll copy Template:Val/sandboxlua to replace Template:Val probably on 7 August 2015—I'll have some time then to watch out for any problems.

I decided to not implement the following parameters because they seem to be workarounds that aren't needed now ranges are supported, and the options don't always work correctly, and it's not clear how they should work if a unit is entered (such as |u=km):

sortval= • alternative sorting factor
us= • alternative unit code for sorting
ups= • alternative unit code for sorting (appears to be not used)

The only articles using sortval and us are Conversion of units and List of device bit rates and I have worked out how to fix them. I plan to do that immediately the module goes live.

The one occurrence of sortval in fact gives the wrong sort key. That may be due to other changes since sortval was introduced because the sortval ends up being multiplied by 1000 due to the unit (kbit/s) with the result that it sorts incorrectly. The occurrences of us can be replaced with a range.

To make sure there are no other places where the unsupported options are used, the module checks for unsupported parameters and gives a warning if found. I'll check the tracking category to see if any warnings occur. Examples (hold the mouse over "warning" to see details):

{{val/sandboxlua|1.23|exp=6|u=m/s}} → 1.23 m/sError in {{val}}: Val parameter "exp=6" is not supported
{{val/sandboxlua|1.23|us=kbit/s}} → 1.23Error in {{val}}: Val parameter "us=kbit/s" is not supported
{{val/sandboxlua|1.23|.05|.04|.03|u=m/s}} → 1.23+0.05
−0.04 m/sError in {{val}}: Val parameter 4 ignored

Johnuniq (talk) 11:25, 5 August 2015 (UTC)

Way to go. I suppose we'll have time to discuss #How to preview a new unit afterwards. (I've made new discussion material there.) — Cpiral Cpiral 22:45, 5 August 2015 (UTC)

Module now live

Template:Val now invokes Module:Val and I fixed the two articles mentioned above (Conversion of units and List of device bit rates). Later I'll look at what needs fixing in the template documentation, and I'll make a sandbox for the modules for safer experimenting, and some testcase pages specifically for the module. So far, so good.

Cpiral put a test section in Module:Val/units and I took the hint and modified the module to accept Foo [[Foo|Hz]] as an alternative to Foo Hz Foo. The "Test" section at Template:Val/list shows the result, although the tricky syntax in Bar is not working for some reason (I don't think that is a val issue). I also included c0 as a unit; please check if that's wanted as it might have been a temporary test for the documentation? Johnuniq (talk) 02:14, 7 August 2015 (UTC)

Thank you very much. Applause... I'll document that new wiki-syntax you just gave us when it starts working. For right now I'm going over and put List of nuclides back together with Val. And yes, c0 is valid, not sure yet if it's needed. Happy editing!

~~About the tricky Bar syntax, module:DemoTemplate was having a lot of trouble with that, saying it was impossible? I wonder if they figured it out yet.~~ — Cpiral Cpiral 03:28, 7 August 2015 (UTC)

Documentation

Moved from Module talk:Val/units

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

I thought I had understood the format of entries. Now I have questions:

1) In the Chemistry section, why are these entries "invalid definition" ?

 uM  [[Molarity|µM]]  SI
 uM    µM    Molarity  SI

2) For these entries in Electromagnetism:

 N.A-2   N⋅A<sup>−2</sup>   Permeability 
 YC      C       Coulomb                            SI

How is it that when the second field is markup, it is displayed,

{{val|1|ul=N.A-2}} → 1 N⋅A⁻²

but when the SI marker is used the first field is displayed, not the second field?

{{val|1|ul=YC}} → 1 YC

— Cpiral Cpiral 01:22, 15 August 2015 (UTC)

I added the extra "SI flag" documentation below to clarify what's going on. The "invalid definition" is because the symbol column is actually the base unit when "SI" is used. I think the following should provide the answers; please ask again if more wanted. The conclusion is that if markup is wanted for the symbol, the SI flag should not be used—instead, the definition must provide the correct symbol and scale. Johnuniq (talk) 03:31, 15 August 2015 (UTC)

Got it. Documented it. Catching up to your way of thinking, but I do have a question about sorting.

What's the easiest way to tell for sure if Convert sorts a Val unit? None. But at Template:Val/Archive 5#Testing a new unit the table functions to "fall into place" out of order. Crude but very effective. As far as I know it's the easiest way to tell about sorting: a "trial and error" technique. Takes under a minute with a slow connection.

Got a better way to tell if Convert handles a unit? Although Template:Convert#Units and Template:Val/unitsfromconvert listings are useful for many other things, they themselves say they are not complete, and this makes them useless for deciding definitively about whether or not to add sorting here. That Convert may handle the sorting for certain units does not seem to help the documentation, although it is necessary in the wikitext above those certain units, in order to keep editors from "helping" in that way.

The alternative to documenting the "cut-and-paste trial-and-error crude-but-effective" way seems to be to go backwards, to get Val/units out of to much or so much user-config-file business. It seems to me that the Val/units page either handles the addition of sorting maintenance and its documentation well, or it goes back to the way it was before, where sorting was not handled by users, but transparently, by Jimp and a few others "in the know". It goes against my grain to think we'd have to revert to Val/sortkey/unit, but then I haven't studied sorting or Module Val very much, and I haven't seen users step up very often and start taking on Val/units tasks for themselves. So maybe I would agree to get out of the sorting business.

— Cpiral Cpiral 00:23, 17 August 2015 (UTC)

When I rewrote Module:Val I did a lot of checking on a local computer, including comparing the exact output produced by the old template from Special:ExpandTemplates with the exact output produced by the module for about 3000 examples. That showed many minor problems with the old system. One example of a significant problem is that the SI prefixes f, a, z, y were not handled so the old system regarded 2 fm as larger than 1 m. In practice, that's unimportant because sorting is not frequently used, and sorting errors would be very rarely noticed, so it doesn't matter. The checks I've done show that the module is sorting correctly. I added a section below (#Sort key) to document how it works.

One way to check whether convert is doing what is wanted would be like this:

{{val|1|debug=yes}} → 7000100000000000000♠1
{{val|1|u=''example''|debug=yes}} → 7000100000000000000♠1 example

The fact that the sort keys are the same shows that the scale for example is 1. If the editor wants something else they should ask at Template talk:Val and you or I will fix it.

If I needed to know whether convert supports a unit, I would preview something like this (mouse over the error message for details):

{{convert|1|''example''}} → 1 example^{[convert: unknown unit]}

The old system was identical in effect. For example, if it weren't already present, an editor might add quadrillion without thinking about sorting. It would sort incorrectly until someone added it to {{Val/sortkey/unit}}. Using the module, exactly the same thing would occur. The editor would add quadrillion, and it would not sort correctly until someone added a scale to the definition. Johnuniq (talk) 01:52, 18 August 2015 (UTC)

SI still a problem

Moved from Module talk:Val/units

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

The recent changes are not working as expected, as shown by the fact that currently the output in the third column of the following table is different from that in the second.

Val	Correct output	Current output
`{{val\|999\|u=uV\|debug=yes}}`	6996998999999999999♠999 µV	6996998999999999999♠999 μV
`{{val\|99\|u=V\|debug=yes}}`	7001990000000000000♠99 V	7001990000000000000♠99 V
`{{val\|1\|u=kV\|debug=yes}}`	7003100000000000000♠1 kV	7003100000000000000♠1 kV

The following examples from the current definitions are not correct:

kV  [[Volt|kV]]  SI
µV  [[Volt|µV]]  SI
uV  [[Volt|uV]]  SI

For example, the following has the sort key "7000100000000000000" which is the value for 1 with no scale, and it does not use a micro symbol in the output. This uses fixed wikitext so the output shows what happens with the above definitions.

{{val|1|u=uV|debug=yes}} → 7000100000000000000♠1 uV

Please examine #SI flag above, in particular, the two equivalent sets of definitions, one with and one without SI. I would try to explain some more, but I think this is one of those cases where more text would just generate more complexity. Johnuniq (talk) 11:19, 16 August 2015 (UTC)

I just saw that it doesn't sort correctly. I'll have it sorting again ASAP, less than 10 min. OK? Thanks.

Two quick things about "invalid definition". It did not say "invalid definition" when the difference between the unit code and unit symbol was made zero (so that it presented well at Val/list), but it should have. Also, it did say "invalid definition" when there was a single space at the end of the entry, a difficult thing to find. Should it have? — Cpiral Cpiral 16:17, 16 August 2015 (UTC)

Done

SI flag

This is a further explanation of the original documentation (I agree, it's obscure!). The following has three unit definitions for illustration—the links shown here are not the same as those in the module.

A unit may be defined as "SI" which means that the unit code begins with an SI prefix which will be interpreted by {{convert}}. For example, the following defines an SI unit with code kV, base symbol V, and link Kilovolt. The symbol V refers to the base unit with the SI prefix removed. A unit defined in this manner will have its sort key scaled by convert according to the SI prefix: for example, {{val|1|u=kV}} would sort after {{val|999|u=V}}. This is useful for units which are not defined in convert, or which are defined but where a link different from that specified in convert is wanted.

kV V Kilovolt SI

µV V Microvolt SI

uV V Microvolt SI

SI specifies that the unit's symbol is for a base unit after removing the SI prefix in the unit code.

The idea is that SI is merely a convenience to simplify the definitions which are identical apart from the unit code and link. The symbol column shows "V" for each, but it is not the symbol—it is the base unit after removing the SI prefix so convert can work out what is intended to be the prefix. The following would give identical results:

kV kV Kilovolt 1e3

µV µV Microvolt 1e-6

uV µV Microvolt 1e-6

Without "SI", it is necessary to define the symbol wanted, and the scale, and it is necessary to use the correct micro character for the symbol for unit code uV. When "SI" is used, convert does the right thing for the symbol and scale.

The following shows how to check the sort key (this uses fixed wikitext output so it will correctly show what would happen with the above definitions):

{{val|999|u=uV|debug=yes}} → 6996998999999999999♠999 µV
{{val|99|u=V|debug=yes}} → 7001990000000000000♠99 V
{{val|1|u=kV|debug=yes}} → 7003100000000000000♠1 kV

Johnuniq (talk) 03:31, 15 August 2015 (UTC) Updated using fixed wikitext. Johnuniq (talk) 10:56, 16 August 2015 (UTC)

Sort key

Moved from Module talk:Val/units

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

By default, a hidden sort key is included in the output. For testing, the key can be displayed:

Val	Output
`{{val\|12.3\|debug=yes}}`	7001123000000000000♠12.3
`{{val\|12.3\|u=bit/s\|debug=yes}}`	7001123000000000000♠12.3 bit/s
`{{val\|12.3\|u=kbit/s\|debug=yes}}`	7004123000000000000♠12.3 kbit/s
`{{val\|12.3\|u=V\|debug=yes}}`	7001123000000000000♠12.3 V
`{{val\|12.3\|u=kV\|debug=yes}}`	7004123000000000000♠12.3 kV

The sort key produced by Module:Val follows these rules:

If a scale is given for a unit, it is used as a factor to multiply the value. For example, the unit kbit/s is defined to have scale = 1e3 = 1000, and that means {{val|12.3|u=kbit/s}} has a sort key calculated from 12.3 × 1000 = 12300. The sort key is calculated by Module:Convert and is the same as that produced by {{ntsh|12300}} (except that ntsh has some quirks).
If a unit is defined with the SI flag, its SI prefix sets the scale, which is then used as if a scale had been given.
Otherwise, Module:Convert uses its knowledge of units to determine the scale. If the unit is unknown, the scale is 1.

Editors won't want to spend time digesting this mumbo-jumbo, but that does not matter. Anyone can add a unit and ignore sorting. If it is found that the unit sorts incorrectly they can either ask to have it fixed (if that hasn't already been done), or ponder the documentation. Adding units is pretty rare so there is not a big problem, and I'm likely to fix any issues from someone unfamiliar with val anyway. Johnuniq (talk) 01:36, 18 August 2015 (UTC)

Documentation planning

Moved from Module talk:Val/units

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

I don't think it's worth optimizing the documentation because very few people will want to add units, and it would be far easier, more reliable, and less stressful for them to post at Template talk:Val and ask for someone to add a unit they have in mind. That would have the benefit of clearing up any disagreements about what would be desirable before starting to edit. Val is used on quite a lot of pages so the modules should not be regarded as a scratchpad where people use trial-and-error to get a unit they want, while others change the definitions because they regard them as undesirable. That's because every edit to the module tells MediaWiki to generate new html output for any page using val, rather than using a page in its cache. We're not supposed to worry about performance, but we shouldn't do obviously bad stuff either. However, I'll leave these notes here to record my thoughts on some points.

I'm aiming at a very few people, I'm thinking "new maintainers" like myself. But I will make the talk page link stand out in the lead section. I have always encouraged units being added to Val because it's natural to imagine all units to just be there.

The docs are far too long with many more words than needed. The whole point of the simple system used to define units is that it is easy to find something similar, then copy it.

You're totally right, but please think of them as babies that need to grow down. I The baby fat is then moved to anemic help files like preview. This blah blah bloat technique has worked elsewhere for me, like {{search link}} and help:search.

One issue that might be mentioned is that people do not need to define a unit—any old stuff can be entered into val and it will use what is given. A definition is only needed if the unit will be used in several places and the markup wanted is a bit cumbersome, so a short unit code would be preferable.

You keep saying that. Hmmm. It sounds too rational. Take a look at the number of zero-usage one-usage units Val now has, for example, take a look at how only List of device bit rates uses bits/s and other of our units. Wild guess? The avg use looks to be about 0.1 uses per unit.

I can make out what "The common reference for a unit on the wiki is the unit code" means, but I don't think it would help someone needing to read the docs.

I can cut that, thanks. Terminology. I pound that term so many ways, it needs no formal definition. You're spot on. Terminology definitions like that are stolid braille. I got the terminology from Convert, then used "unit code" to replace "unit" to clarify many statements.

I don't think "If the same unit code is defined twice on this page, the later one overrides the earlier one" is correct. I would expect val to use the first definition.

For the earlier switch statement, that was true. You're probably right. The draft needs to be questioned like that. Testing... You're right. Updating the doc...

Rather than encouraging people to leave comments at Template_talk:Val/list, I think all discussion should be at Template talk:Val. Even the discussion on this page probably should be at the main template talk so others can see it and at least be aware of what is going on even if they don't want to join in.

OK. Hmmm. Yes. Although that creates less-categorized conversation "clutter", It has the benefit of a newspaper and a city. Back country pages can still pacify trepidation.

The explanation with "Previewing this page with Val/list is different from previewing it with other pages" and "Val/list is a transclusion of this page" is not accurate. When editing a template or a module, the "Preview page with this template/module" feature can be used to show what any other page would look like, if the changes to the template or module were saved. The only thing that is special about Val/list is that its wikitext calls val with an option that generates the list of units.

Well said. When I renamed the transclusion and setup the two module sandboxes (Val and Val/units) with val/list/test, my hunches about the way things inter-work were pleasantly accurate, but trying to put my learning in words... it does need some attention, fixing it now thanks (shorter).

I'm not sure that it is useful to tell people to add definitions they don't intend to use. For example, "We end up with both the slash a/b and inversion ab-1 forms" tells people they should define something that might never be used, and that adds clutter making maintenance more difficult.

If you keep saying things like that, maybe things will change, but that's been the Val mantra since I first saw Val.

It's only clutter when you're having to make some kind of consideration on a unit-by-unit basis (re-categorise, re-association, reconsideration, etc), otherwise for line-oriented record processing it's easily automated, you know. In this regard Template:Val/units/test shows many units usage are shockingly low or zero. If you would see Val/units/test as a decluttering tool, a cleanup project checklist, we would see differently on that. I see it as just the reality that we do support well over two thirds of our units in potentia only, as they lay unused, or used once. Put another way, although we spend way more time on maintaining "that one use" that could have just been done by hand... and the rational thought is to avoid that inefficiency and just forget the template usage... It's not right to keep all these units, but it's not wrong.

How about we just comment out unused units, while keeping them in place for easy restoral?

The statement "Note that the base unit does not need the SI sort-marker" is not always correct. I doubt there would be a real-world usage where the inaccuracy would be visible, but the essence of the SI flag is being missed. If SI is omitted (and assuming no scale is given), convert will be asked to generate a sort key using its knowledge of the unit code. For example, the definition dam [[Decametre|dam]] does not specify a scale. Nevertheless, a correct sort key will be generated because convert knows that 1 dam = 10 m so the sort keys following are the same:

{{val|10|u=m|debug=yes}} → 7001100000000000000♠10 m
{{val|1|u=dam|debug=yes}} → 7001100000000000000♠1 dam

If SI is omitted, the definition m [[Metre|m]] will only do what is expected if m has a scale of 1 in convert. The simplest is to include SI for all the units that belong together, and to not attempt to explain it in the documentation. Johnuniq (talk) 02:27, 17 August 2015 (UTC)

I would defer to help:sorting if it had the word "scale", but neither it nor {{ntsh}} use the term, but then template ntsh isn't documented very well; help sorting is terse for the most part, although very long and they don't use "scale".— Cpiral Cpiral 08:20, 17 August 2015 (UTC)

The help page and ntsh that you mention do not handle units, and that is why they don't have a need to worry about a scale. The templates like ntsh generate a sort key calculated only from the value they are given. By contrast, val may have a unit, and it is useful for the sort value to be calculated from the given value and a scale factor to account for the size of the unit. That allows, for example, kilovolts, volts, and millivolts to be used in one table and still sort correctly. The sort key for 1 kV is 1000 times bigger than that for 1 V, which in turn is 1000 times bigger than that for 1 mV.

Re your comment above concerning unused units, I have a big todo list for convert which includes the fact that I would like to prune many of the unused units there (with stuff like "Cypriot dönüm"), but I may never get around to it. Johnuniq (talk) 03:25, 18 August 2015 (UTC)

Error in Basque Wikipedia

Moved from Module talk:val

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

I have just copied this module and the /units module and I get this error:

Luanda errorea in Modulu:Val at line 267:attempt to call local 'lookup' (a nil value).

You can see live at: eu:Protoi

Well, solved! It called to Module:...." and it should be Modulu:...." as in basque language Wikipedia. -Theklan (talk) 20:17, 13 October 2015 (UTC)

@Theklan: No, that's not it—there must have been some other issue, perhaps the fact that the page was displayed before all the modules existed and you saw a cached copy of the page that had the error. The system software (MediaWiki) understands a generic name for each namespace as well as the local name. That means "Module:" works on all WMF projects. Here are two examples to demonstrate:

eu:Module:Convert and eu:Modulo:Convert are identical
bn:Module:Convert and bn:মডিউল:Convert are identical

Further confirmation is that if you search Module:Convert for "Module:" you will see that it requires eu:Module:Convert/data (and more)—convert is very complex and it is not as easy to see as in eu:Module:Val, but it is there. If you undo your edit to Module:Val you will see that it still works. Johnuniq (talk) 01:55, 14 October 2015 (UTC)

Defining units in the module

Units are now defined in Module:Val/units. Anyone interested may like to review Module talk:Val/units. Johnuniq (talk) 02:30, 17 August 2015 (UTC)

Request for SI units at Val/list

For making the SI units at Val/list more consistent, can we please remove the the wikilink from the base unit in field two, and put it with the unit code, either in field one or field two?

Question.current	`ms [[Millisecond\|s]] SI` `ms s Millisecond SI`	→ ms s · SI unusual wikilink *
A1.good swap fields in rendering only	`[[Millisecond\|ms]] s SI` (swap required) `ms s Millisecond SI` (usual order OK)	→ ms s · SI move wikilink over
A2.better Make the 4th field a variable SI string	`ms2 [[Millisecond\|ms<sup>2</sup>]] s__SI` `ms2 ms<sup>2</sup> Millisecond s__SI`	→ ms2 ms² · s__SI entirely consistent
A3.best When the 4th field not a number, an SI prefix	`ms2 [[Millisecond\|ms<sup>2</sup>]] m` `ms2 ms<sup>2</sup> Millisecond m`	→ ms2 ms² · SI entirely consistent

* Currently when the hover text for "s" says "millisecond" at times, "microsecond" at other times.
This is a mostly hidden inconsistency. — Cpiral Cpiral 02:47, 17 August 2015 (UTC)

This concerns the test page Template:Val/list which shows all the units defined in Module:Val/units.

I changed Module:Val to get something close to #3. Here is an extract showing how it handles micro prefixes:

kg = kg • SI

mcg = µg • SI

mug = µg • SI

µg = µg • SI

Johnuniq (talk) 04:35, 18 August 2015 (UTC)

Space at the end

Must a space at the end of a unit be an invalid entry? That's notoriously difficult to troubleshoot. — Cpiral Cpiral 02:47, 19 August 2015 (UTC)

Please post an example of what you mean and I'll look at it—nothing elaborate, just a line in a pre box would be fine. Johnuniq (talk) 03:18, 19 August 2015 (UTC)

m m m ♦ Invalid definition

There's actually a space at the end.

Edit module:val/units
Add a space onto the end of any unit, or some random five units.
Preview through Template:Val/list
See "invalid unit" message next to any unit with a space at the end.

Some say Invalid scale "SI ", and won't render the page. One may sort of see the space by virtue of the quotation marks.

I don't think the ♦'s position indicates the space or not. I tried to move the diamond in♦, but never in a million years will removing square bracket registers an error. For example, [[mya|million years] shows no error. — Cpiral Cpiral 04:44, 19 August 2015 (UTC)

Hmm, that mess came when I added the code to accept [[link|symbol]]. I'll fix it soon and will post here. Johnuniq (talk) 06:10, 19 August 2015 (UTC)

That's fixed. Johnuniq (talk) 07:38, 19 August 2015 (UTC)

Thank you again Johnuniq. I'll update Val/units/doc. While I'm at it I'll mention that two spaces are not allowed inside a wikilink. There's just no reason two spaces could ever be needed in the inside [[ any article title | or any unit symbol ]]. — Cpiral Cpiral 17:53, 19 August 2015 (UTC)

Invalid unit should say so

This is an invalid unit because it will not sort:

PK  PK  Kelvin  SI

It should say ♦ Invalid unit, bug it doesn't. — Cpiral Cpiral 06:48, 21 August 2015 (UTC)

A module cannot be expected to deduce that "PK" is actually petakelvin so the user should not have provided a conflicting definition. Module talk:Val/units#SI flag explains what adding "SI" does, with why it matters explained in the following Module talk:Val/units#Sort key section.

Using "SI" tells val to not use convert's knowledge of units, but instead to use the SI prefix to scale the value in the val template. As you know, the above definition should be PK K Kelvin SI with K as the base unit in the second column. To detect that as an error, val would have to be given knowledge of all units, and would have to flag any conflicting definitions as invalid. That's difficult and unnecessary. Johnuniq (talk) 07:35, 21 August 2015 (UTC)

I was thinking of comparing the two fields. If 1) they are the same, and 2) the first letter(s) are SI, and 3) the remaining letters are a base unit already defined, then 4) flag it as a common error anyone could make who uses the wikilink model with SI. I don't see existing val/units situations where the algorithm would not work, but I'm not sure about the feasibility or practicality of (3). — Cpiral Cpiral 20:03, 21 August 2015 (UTC)

Similarly, SI might take markup with some string processing. Just remove <anything between matching brackets/>, then do the remaining string processing where the base unit in field two is removed from the ending of the unit code, in order to derive the SI prefix, in order to then translate that into a scaling factor. As it is, units like cs "centisecond" cannot have hovertext created with <abbr>...</abbr> or ... to expand the abbreviation using the title attribute, and instead only the creation of a redirect is an option to expand the abbreviation. — Cpiral Cpiral 20:28, 21 August 2015 (UTC)

The problem is that there are a hundred other ways a unit could be defined incorrectly. Let's wait until there are a couple of real-world examples of errors introduced by people adding units that are going to be used in articles, and where the error is not quickly corrected. You wanted to change the format of how the units are defined, and that's the only reason you encountered some problems. Johnuniq (talk) 01:29, 22 August 2015 (UTC)

Testcases

I have changed Template:Val/testcases to use a test system automated with Module:Convert/tester. The results are at Template talk:Val/testcases. The advantage is that a large number of tests (currently 1431) can be quickly run, and the results are checked in detail—any difference in the generated wikitext gives a "Fail". A difference in the hidden sort key, or any other difference, will be flagged as a fail. The results talk page has some notes at the top showing how the tests are generated.

Example: Edit Module:Val/units/sandbox. Change the symbol for the Foo test unit or anything else. Under "Preview page with this module" enter:

Template talk:Val/testcases

then click Show preview. Search the resulting preview for "Fail" to see any differences.

The preview won't show any new units unless val templates for the new units are added to the testcases page. Johnuniq (talk) 11:48, 23 August 2015 (UTC)

Sorting Val units

Which units, if any, at Template:Val/list that are not marked as configured and ready for sorting, are actually configured and ready for sorting because Convert handles the sorting of those units?

I think we use the mark ALIAS to avoid the temptation to redefine a Convert unit. If Convert does handle any unit's sorting, it needs an indicator at Val/list for a similar reason. — Cpiral Cpiral 20:43, 20 August 2015 (UTC)

The scale only matters if val is being used in a sortable table, and I'm not sure that perfecting val/list would have much practical benefit. However, it might be reasonably straightforward to display the scale generated by convert in square brackets, for example:

km = km • [1000]

The brackets would show that the scale is automatic (from convert) and is not part of val's definition. Any thoughts?

There are about 175 units currently that don't have a scale or "SI", so it should be possible to call convert for each without having val/list timeout. I put some background about sort/scale/SI at Module talk:Val/units#Sort key. Johnuniq (talk) 01:33, 21 August 2015 (UTC)

No. I'm sorry if I have missed something. "Will the unmarked units sort properly?" That is the question. I still don't know. In other words since ALIAS means "don't define this unit!", a sorting mark must mean "don't define this sorting", but the 175 units... but Convert...? What? If the unmarked ones won't sort until they are scaled, we should document that.

In response to your request for ideas about [1000]? I was at one time rather OK with the teachable moments sorting displays might bring, but No, not if many additional units could cause a timeout. Instead, let's consider the opposite direction: say "all units that don't have • will need to be configured iff sorting is wanted", since most Val/list viewers don't care to learn how it sorts, by what number, or by SI, (or by Convert?). Even if we take out the sorting flags altogether at Val/list, we still need the case of unpopulated fields to be fully documented at Val/units. — Cpiral Cpiral 06:36, 21 August 2015 (UTC)

You may be hoping for more than is achievable with a program—how can a module tell you if the correct definition has been entered so a unit will sort correctly? Defining a unit at Module:Val/units is trivially easy, despite the details shown in the documentation and comments—use the time-honored procedure of finding an example similar to what is wanted, then copy and edit. If the definition has a mistake, someone will report that it doesn't work, and it will be fixed. When was the last time a new unit was needed for val?

The point of adding [1000] would be so people could check that convert has produced the correct scale. If convert does not recognize the unit, the scale text would be [1] and searching for that would check whether something else is wanted.

Template:Val/list is produced with {{val|action=list. Perhaps Template:Val/unknown could be produced with {{val|action=unknown. It would list the units at Module:Val/units which might need a scale. That would be any unit which is not flagged with ALIAS or SI, and which has no scale, and which is not defined in convert. Each listed unit would use the default scale of 1, and they could be reviewed. To remove a unit from the unknown list, a scale of 1 could be included in the definition. Johnuniq (talk) 08:02, 21 August 2015 (UTC)

On second thoughts, Template:Val/list could be changed to include UNKNOWN if a unit has been specified with no scale and without the SI flag, and if the unit is not known to convert. Those units would have the default scale of 1 and the sort key might not be correct. This only matters if val is used in a sortable table, and if different units are used in the same table. For example, if one entry is 1 kV and another is 999 V, the sort key has to show that the former is larger than the latter. Johnuniq (talk) 11:48, 21 August 2015 (UTC)

Thanks, now here's what I have gathered, ( Y/N format )

Of the unmarked units listed at Val/list, some will sort, some won't.
Convert, unlike Val, will sort all of the units it defines. Therefore, if the unit at Val/list is known to Convert it will sort, even if Val overrides the link and markup.
Units unknown to Convert are not indicated at Val/list, because of CPU time. If CPU time was granted, perhaps it should be at a less visited page, such as at a Val/unknown.
But perhaps Val/list could remain in use, and the sorting issue be completely resolved by marking "unknown" or [1]. Units not marked would be guaranteed to sort by Convert.

I'd vote for [1] over "unknown". — Cpiral Cpiral 19:43, 21 August 2015 (UTC)

A compromise might be to query a unit's "sortable" status through a preview result. For example I just manually added ALIAS to meter and metre, because I "felt" that Convert defines them. My feeling was confirmed when the preview returned with a • ALIAS mark and removed the m wikilinks for me. Now isn't this related to the determination and/or indication that a unit is either "known" or "unknown", and therefore an option for sorting as well? This could go either way: 1) Should we therefore automate ALIAS marking. 2)Should we therefore manually determine sorting a unit on an as needed basis by adding, say, "SORT" to Val/units, and running that through a preview of Val/list to see if it returns with any sort of • and a scaling factor, and if it did, then manually add that scaling factor, in turn, to Val/units. I'd vote for (1), but could document (2). Just trying to help. — Cpiral Cpiral 21:19, 21 August 2015 (UTC)

I have put a new version in the sandbox to allow these options to be tried. A unit defined in Module:Val/units with a scale or an SI prefix will sort according to the given scale or the SI prefix's scale. Other units rely on convert to correctly scale the value so sorting with different units will work. The following can be previewed to generate two different reports:

{{val/sandbox<!--lua-->|action=list}}
----
{{val/sandbox<!--lua-->|action=list|a=unknown}}

Where useful (units with no scale and no SI), the first shows convert's scale in square brackets ("[1]" for unknown units), and the second shows "UNKNOWN" for unknown units (and, to reduce clutter, does not show convert's scale).

What convert does only matters if val is used in a sortable table, and even then it only matters if the table has instances of val which use different units. That does not happen often. Johnuniq (talk) 01:26, 22 August 2015 (UTC)

That's it! That's the information I was asking for, thank you! I really should learn how to do that. But for now, please, here is how I how I'd like the List to appear:

All sorting info on one page. Units that are sorted by Val have either "• SI", or "• scale". Units that are sorted by Convert have "•", and units that are not sorted by any of those have no mark.
Preferably a new file Template:Val/sort, that uses the fields format, has less markup, no wikilink. i.e. give Val/list fully functioning markup and hover text for all units, and the ability for horizontal layout of families of units (instead of the vertical only, demanded by the presence of sorting information,) Long reports are esp. troublesome because there is no section editing.

I think the work already done at #Request for SI units at Val/list to hide the base unit required for sorting purposes, is still applicable at a Val/sort, and not lost.

Please understand. Please read 1 and 2 again carefully. It's a lot to ask, I know, but both of our assertiveness is respectful. I only ask. Sometimes I get refused, but for respectable reasons.

Putting 1 another way, because its most important: what |a="unknown" now does? make the UNKNOWN units have no mark, because these are the ones that have no sorting. And make the unmarked units have a singular • because they're sorted. — Cpiral Cpiral 08:01, 22 August 2015 (UTC)

Template:Val/list now contains the following for testing:

=action=list=
{{val/sandbox<!--lua-->|action=list}}

=action=list|a=convert=
{{val/sandbox<!--lua-->|action=list|a=convert}}

=action=list|a=unknown=
{{val/sandbox<!--lua-->|action=list|a=unknown}}

Using action=list now provides a little more validity checking; I don't think much more can be done for that.

For units with no scale and no SI prefix, action=list shows:

Convert's scales in square brackets by default; a unit unknown to convert will show [1].
Using a=convert shows "CONVERT" for units known to convert, instead of a scale.
Using a=unknown shows "UNKNOWN" for units unknown to convert, instead of a scale.

The reason some text is shown (rather than just a bullet with nothing after it as suggested above) is so it is possible to search for the text. Johnuniq (talk) 10:16, 22 August 2015 (UTC)

Say the editor is doing a "search for the text", and the text is either "UNKNOWN" or "CONVERT" or "[1]". Why? Surely not find and replacement. Do you mean "sorting" by sorting-authority UNKNOWN or sorting-authority CONVERT? I say we just keep the CONVERT and UNKNOWN report actions available, but not active at Val/list do just [1]'s. That way they can run a CONVERT or an UNKNOWN report, save the web-page in there browser as text, and then do a "grep or sort on the text".— Cpiral Cpiral 07:11, 27 August 2015 (UTC)

I see what you mean by the power of examples, editor of few words, and a lot of "actions", thank you. It will take time for me to respond while I study and use the three report styles. Others? — Cpiral Cpiral 20:25, 23 August 2015 (UTC)

You were right when you suggested brackets. Who cares if the mark "[1]" is KNOWN by convert or UNKNOWN by Val, when we can't say whether Convert really scales all its KNOWN units perfectly harmoniously under all possible conditions. Neither the overzealous maintainer nor the one who wants a sorting certificate of authority want the CONVERT report for the right reason: they both want to be assured that the [1] is correct, but as you've said, maintainers don't need to set-it / worry-about-it 'til they need it, and as for the authority seekers, they somehow don't understand sorting and this ain't Help:sorting.

The (salient) alternatives to [1] are either a CONVERT end-field, an UNKNOWN end-field, or a blank end-field: three fields that all mean something internal about sorting. (UNKNOWN means Val sorts, CONVERT means Convert sorts, and a blank field can mean two internal things about sorting, which meaning is conveyed by its context.)

No on the two alternatives to [1] because, the "CONVERT" report and the "UNKNOWN" report are the same info (complimentary) whose meaning is internal, but Val/list, and thus Val/units, means something external. The reports are external (pointing to an audience external to the Lua internals of who sorts). Documentation's audience for Val/list and Val/units are external: 1) maintainers of Val/units such as myself, who need to use Val/list to scan and pattern all units' pagename and markup and hover-text, and to use then use {{tlusage}} to possibly remove units, add units, and change unit codes, and 2) editors who need to find unit-codes, add units, and sort units. These two audiences are not necessarily Lua programmers, so referring to the alternatives (the Lua internals of who CONVERT or UNKNOWN sorts) is confusing. For example that "UNKNOWN does not show Convert's scale" is a confusing thing to have to document. (SI is confusing for the same reason, and might better say a number, but "SI" sure looks clean and confidently inspires trust.)

[1] is complete sorting information, even if the information is that it incorrectly sorts. That one is a default is a teachable moment. We like those. — Cpiral Cpiral 07:11, 27 August 2015 (UTC)

Re your earlier comment starting "Say the editor is doing": The only reason to look at Template:Val/list would be to check for errors in the definitions of units. A possible error would be to define a unit with no scale and where the unit was unknown to convert. That would only matter if the unit were used in a sortable table and if other different units were in the same table. The way to detect that error would be to search the list page for some text that identified possibly problematic units, and searching for UNKNOWN would be the easiest. If someone wanted to know which units were defined in convert, they could search for CONVERT (per "If Convert does handle any unit's sorting, it needs an indicator" above).

It is unlikely that anyone other than you and me will use the list page, and I don't think the units need adjustment until an editor requests something for use in an article. Therefore, I'm happy for you to decide what you want the list page to show. If one of the current options suits, just remove the others that I temporarily put in the list for testing. Otherwise, use an example to show what is wanted. I think you are saying that showing the scale in square brackets is best? Johnuniq (talk) 10:13, 27 August 2015 (UTC)

Multiple uncertainties? E.g. 7.6 ± 1.5(stat) ± 0.8(syst)

In high-precision results, it's not uncommon to quote statistical uncertainties (which can be reduced by collecting more data) and systematic ones (which require improving the experiment, or the analysis) separately.

Is there a way to format that with {{Val}}?

The really messy case is when you have something like "9.11+0.25
−0.22 ±0.63 ×10¹⁸ years" (from Neutrino Ettore Majorana Observatory#Results). 71.41.210.146 (talk) 06:27, 12 September 2015 (UTC)

No, a single val template cannot do that. I would recommend just constructing the text as you did above. If desperate to use val, I think the closest would be:

{{val|9.11|+0.25|-0.22}} {{val|±0.63e18|ul=years}} → 9.11+0.25
−0.22 ±0.63×10¹⁸ years

which doesn't get the spacing around the ± correct, but is close. Johnuniq (talk) 07:19, 12 September 2015 (UTC)

Val doesn't offer two kinds of uncertainty at once. But there's the handy (wrap protected) insertions, the suffix and end parameters:

{{val| 7.6 | 1.5 |s=(stat) ± 0.8(syst)}} → 7.6±1.5(stat) ± 0.8(syst)

But there's no units help with suffix insertions:

{{val| 7.6 | 1.5 |s=(stat) ± 0.8(syst)|ul=dogs}} → 7.6±1.5 dogs(stat) ± 0.8(syst)

Unless you use the end insertion:

{{val| 7.6 |ul=cats|end= ± 1.5(stat) ± 0.8(syst)}} → 7.6 ± 1.5(stat) ± 0.8(syst) cats

And if you don't mind embedding templates and the extra parens:

{{val|9.11e18|0.63|end= {{sup sub|+0.25|−0.22}}|ul=years}} → (9.11 ^+0.25
_−0.22±0.63)×10¹⁸ parsecs

Val's usual advantage is automatic spacing, formatting, nowrapping, unit linking, and unit hovertext. Otherwise, see MOS:NUM for how to build:

{{nowrap|9.11{{thinsp}}{{sup sub|+0.25|−0.22}}{{thinsp}}±{{thinsp}}0.63{{e|18}}}} years → 9.11 ^+0.25
_−0.22 ± 0.63×10¹⁸ years

A non-breaking space character will break at a template, so use the nowrap template around the whole expression, and thinspace for spacing. {{e}} adds its own space.

— Cpiral Cpiral 12:46, 12 September 2015 (UTC)

Thanks for some nifty ideas! Let me try some:

{{val|9.11e18|0.63|end= {{±|0.25|0.22}}|u=gerbils}} → (9.11 ^+0.25
_−0.22±0.63)×10¹⁸ gerbils

{{nowrap|9.11 {{±|0.25|0.22}} {{±|0.63}}{{e|18}} wombats}} → 9.11 ^+0.25
_−0.22 ±0.63×10¹⁸ wombats

71.41.210.146 (talk) 13:09, 12 September 2015 (UTC)

It doesn't support it now, but I can't see why it couldn't, or shouldn't. It certainly would be better than the horrible hack suggested above. Parameters should be |stat= |stat+= |stat-=, and |syst= |syst+= |syst-=. Headbomb {talk / contribs / physics / books} 13:31, 12 September 2015 (UTC)

I'm not going to object, but I'm worried that less common notation has more variants. Before you jump in to implementation, we should survey some literature and see if:

There's a standard order for statistical and systematic errors
There are ever other names for the error types (ISTR having seen "type A" and "type B")
Some deranged individual ever wants three or more types of error.

I wonder if the names should be |err1= |err1+= |err1-= and |errname1= and so on.

Also, for any sort of large table, I'd wish for a concise notation using multiple positional arguments, e.g. {{Val|9.11|0.63|0.25|0.22|e=18}} for 9.11 ±0.63 ^+0.25
_−0.22×10¹⁸

71.41.210.146 (talk) 15:00, 12 September 2015 (UTC)

Are there three articles with text that would benefit from a change to val? If so, I would be happy to look at implementing a suitable syntax. Johnuniq (talk) 02:42, 13 September 2015 (UTC)

With apologies for being heavy on neutrino-related articles, but that's just where I happen to know is a good place to look:

Neutrinoless double deta decay measurements:
- Neutrino Ettore Majorana Observatory#Results
- Double beta decay#Known double beta decay isotopes
- Enriched Xenon Observatory#Results
- Kamioka Liquid Scintillator Antineutrino Detector#KamLand-Zen Double Beta Decay Search
- Isotopes of xenon (Note use of "(sys)" rather than "(syst)".
Neutrino oscillation measurements:
Other particle physics articles:
Not sure if these meet your criteria:
- Measurements of neutrino speed (But they're all in <math>)
- Anomalous magnetic dipole moment#Muon, but in <math> and in 0.999(12)(34) notation.
- Talk:Calcium-48 (Not in main space)
- Talk:Faster-than-light neutrino anomaly#Preliminary May results (Not in main space)

71.41.210.146 (talk) 09:07, 13 September 2015 (UTC)

Taking double beta decay as an example, the relevant wikitext in two of the table rows is:

Nuclide	Wikitext	Result
¹³⁶ Xe	2.165 ± 0.016 ± 0.059	2.165 ± 0.016 ± 0.059
¹⁵⁰ Nd	0.00911{{±\|0.00025\|0.00022}} ± 0.00063	0.00911^+0.00025 _−0.00022 ± 0.00063

Are you sure that val can improve that? How? Johnuniq (talk) 09:29, 13 September 2015 (UTC)

Yeah, I should have been a bit more selective. You're quite right that in a table the nobreak isn't as important; it's only the spacing that matters. 71.41.210.146 (talk) 15:57, 13 September 2015 (UTC)

Update links to higher multiples of metre

For multiple of metre that are higher than mega-, the template does not link the unit to the corresponding article:

ul=Gm links to Metre instead of Gigametre→exmpl.: 150±0.1 Gm
ul=Tm links to Metre instead of Terametre→exmpl.: 150±0.1 Tm
ul=Pm links to Metre instead of Petametre→exmpl.: 150±0.1 Pm
ul=Em links to Metre instead of Exametre→exmpl.: 150±0.1 Em

For comparison, template {{convert}} correctly links Gm, Tm, Pm and Em: 1 AU (150 Gm), 1 AU (0.15 Tm), 1 AU (0.00015 Pm), 1 AU (1.5×10⁻⁷ Em). -- Rfassbind – talk 10:40, 14 September 2015 (UTC)

I don't know why it's like that—I created the new Module:Val/units by including all the units as they were previously defined. I suspect that all the metre units could be omitted because when a unit is not defined in val, it gets the unit's information from convert. Cpiral may want to comment or fix the definitions, or anyone is welcome to have a go. I would recommend starting in Module:Val/units/sandbox and using {{val/sandboxlua}} for testing because that template invokes the sandbox modules. When satisfied, put the edits in Module:Val/units and test with the normal val template. The documentation at the units pages is much longer than needed, and you could probably ignore it and just (carefully) edit the "metre" lines. One vital point from the docs is that there must be two or more spaces between columns.

I just tried omitting the metre units from the sandbox, and here are some tests:

{{val/sandboxlua|1|ul=Gm}} → 1 Gm
{{val/sandboxlua|1|ul=Tm}} → 1 Tm
{{val/sandboxlua|1|ul=Pm}} → 1 Pm
{{val/sandboxlua|1|ul=Em}} → 1 Em
{{val/sandboxlua|1|ul=metre}} → 1 m
{{val/sandboxlua|1|ul=meter}} → 1 m

Here are links to the modules:

Module:Val • Module:Val/sandbox • same content
Module:Val/units • Module:Val/units/sandbox • different (diff)

Johnuniq (talk) 11:25, 14 September 2015 (UTC)

Thanks for informing us Rfassbind. — Cpiral Cpiral 04:20, 15 September 2015 (UTC)

But why are the metre units defined in val? My above test shows they are not required. Johnuniq (talk) 05:43, 15 September 2015 (UTC)

The end field of Val/list, status and questions

Because of all Johnuniq's many contributions—developed a units interface between Convert and other modules, finalized tested the Val module, and migrated the units old data, integrated Val/units and Val/sortkeys, integrated Convert and Val sorting—things have gotten beyond my ability to understand well enough to document them for others. .

"Marks", like ALIAS, in the new "end-field" still need answers. Some seem to have a multi-purposed nature:

ALIAS so maintainers know Convert supplies a link and markup for a unit code? Why?
a sorting scale so editors can fix Val/units that don't sort in sortable tables?
ALIAS CONVERT a multi-purpose end-field marker so maintainers know Convert sorts a unit code?
NOSPACE so editors can fix Val units that have nothing to do with Convert? Currently NOSPACE and ANGLE are synonyms? Why?
ANGLE sorting scale.

Maintainers of Val/units scan and test and evaluate all Val units. This serves editors who come here only to fix Val behavior. Documentation serves both.

Questions concerning Val/Convert interactions from a maintainer's POV:

Q. What should Val/units list?

A1. List everything, every unit on the wiki? Convert's units, would be in two different formats?

A2. List nothing, only what Convert cannot list?

A3. List what Convert cannot list, plus whatever looks good?

A3. There need be no rhyme or reason?

Looks like we're on the third path. OK then, basically "whatever looks good". In that case, we mark as ALIAS everything that Convert also handles, but we're not doing that. There is no maintenance possible where there is no understanding. So actually we're on the fourth path.

In that case here's the devil's dictionary:

ALIAS: Whatever you want to feed to deletionists, ALIAS it. There's really no difference between a maintainer marking a unit as ALIAS, and just deleting that unit. Convert handles that unit.; If you feel like seeing a unit at Val/list, don't ALIAS it. Someone might delete it. We don't ALIAS all the units Convert handles, and it doesn't matter. For example, the pascal units. Both Convert and Val list them.; ALIAS can take its own sub-fields. For example, ALIAS CONVERT means Convert sorts it. ALIAS without convert means you can add a fifth field yourself.; Manually mark as ALIAS all units handled by convert for either linking or sorting, and just unalias them as needed to override.

SI

Should we alias the base pascal unit to make a point of some kind, then delete the remaining SI versions of the base pascal unit? Why keep the base? ALIAS works itself out of its own existence.

It keeps the symbol in view, but the price is

a loss in confidence by maintainers because it's not simple enough for them

no hover-text because no HTML, and no link is permitted with these strange beasts, these SI units

a huge long list of repetitive information that makes it tedious to edit by preview

Aren't these just design questions involved with how to integrate units across the wiki? What other modules may want to share Convert units?

These questions about how to mark units are related to choices about what we're trying to achieve for editors, developers, and maintainers. These are architectural choices. Is units database redundancy needed? Is diversity needed? For example, the template template:units of force whould probably reject using Convert for reasons of redundancy, and maybe even get a Val implementation reverted back out of there. ALIASING half of Val units would remove eyes on links and scales, thus lessen diversity. Could Convert crash and "bring down our part of the wiki" because it integrated too much?

other marks: Please give examples of when searching for a mark would be valuable.

— Cpiral Cpiral 05:53, 18 September 2015 (UTC)

I think simple documentation is often best—see this July 2015 version of the val/units documentation which specifies what ALIAS does, although it fails to explain why. ALIAS is needed for the temperature units and nothing else. In val, C means coulomb (as it should), but in convert, C means degrees Celsius (for convenience because many thousands of converts operate on temperature). Another complexity is that calculating the sort key for temperatures is tricky because it involves both multiplication by a conversion factor and addition of an offset, so a simple scale is insufficient. To allow degC to generate a correct sort key, it is defined as an alias of °C (convert recognizes °C in addition to plain C). When degC is used in val, convert is given the unit code °C and it returns results for that temperature unit, including a correct sort key. It is useful to document what ALIAS does, but I don't think it should be more than a footnote because, as mentioned, it is only useful for the temperature units.

My July 2015 link above explains what ANGLE and NOSPACE do—they are not equivalent. Neither is related to the conversion scale which is used to calculate the sort key.

I don't understand the comments about SI which is documented in my July 2015 link. The version of Module:Val/units at that time had examples such as the entries to define the ampere units. The whole point of how SI works is that each ampere entry is identical, except for the unit code (also, the article link can be different for some entries, if wanted). That means the unit definitions are very simple, and "SI" does not need a precise explanation because it just works. Some further details of SI are explained here.

Johnuniq (talk) 07:36, 18 September 2015 (UTC)

About SI. Val/list could only show the base unit with SI. The links will still be maintainable at Val/units. The lack of HTML concern with SI are covered elsewhere under "Hover text".

Now I get ALIAS. Thanks. That helps a lot. Knowing that, the next step is to finish up the Val/units documentation, simplify it, etc. — Cpiral Cpiral 22:06, 18 September 2015 (UTC)

Hover text

Given any unit code, concern-level for

the existence of the unit code is major. Browser page-search functionality solves any problem how to arrange units on the Val/units page; ya just search for it.
the symbol is zero: it's simple, unambiguous markup, it's always correct for all existing unit codes deployed in articles
the link is minor: links will always need a few maintainer eyes on them, because editors accustomed to an article often overlook mislinked units.
the sorting is minor: sorting will always need visibility by a few editors, but only exists currently in a few articles
the hover text is major: a possible maintenance-work in progress, hover text is value-added feature, and is as complete a reason to use Val as nowrapping is; currently an impossible project to complete because SI breakes HTML

— Cpiral Cpiral 05:52, 18 September 2015 (UTC)

What does SI break? Are you talking about the pop-up shown by a browser when holding the mouse over a linked unit? For example, holding the mouse over "GK" in the following shows "Gigakelvin".

{{val|12.3|ul=GK}} → 12.3 GK

Johnuniq (talk) 07:43, 18 September 2015 (UTC)

Yes, take a look at this possibility in Val/units:

GK [[GK|<abbr title=Giga>G</abbr>K]] → GK

A maintainer of Val/units can write in HTML for informing article readers as to what a unit is/. It's the maintainers' job to prepare all units of Val, but it seems impossible for SI units now... Is it? — Cpiral Cpiral 17:29, 18 September 2015 (UTC)

Using the SI flag is not compulsory—it's just a convenient way of getting convert to handle a few details. See Module talk:Val/units/doc#SI flag for the background—the "would give identical results" example shows that SI is not required. If complex definitions are needed, they can be entered without relying on convert.

I don't think the GK example is desirable—it is very unlikely that readers would take the time to position the mouse cursor over "G" to see its popup, then move to "K" to see its popup, and editors might expect the popup to show the destination of the link, but it doesn't. By contrast, the current output from val shows GK which has a single popup showing "Gigakelvin" which is all that a reader requires—if the reader does not understand that, showing "Giga" and "Kelvin" in separate popups is not going to help.

When editing to post, I see there is further text in an html comment—please unhide it if a response is wanted. Johnuniq (talk) 00:16, 19 September 2015 (UTC)

Problem with sort

There is a problem with the sort: For example, 3.9335±0.0004 is not sorted between, for example, 5 and 2 (when the are not listed using Template:Val). Activating debugging, there's a strange "7000" in front of the input value: 7000393350000000000♠3.9335±0.0004. --JorisvS (talk) 11:35, 2 October 2015 (UTC)

Val number and unit
5±0.0004
3.9335±0.0004
1±0.004
2±0.0004
4±0.0004

Val number and unit
5
3.9335±0.0004
1
2
4

Looks unsorted, but press the arrow. Sorts fine, right? Yes they are usually strange because of the algorithm used to assign them. — Cpiral Cpiral 18:46, 2 October 2015 (UTC)

@JorisvS: The sort key consists of two parts. The first four digits (7000 in the first two examples below) represents the magnitude and the remaining digits are the value. If value > 0, magnitude = 7000 + floor(log10(value)) where floor keeps only the integer part of the logarithm.

7000123400000000000♠1.234 ← {{val|1.234|debug=yes}}
7000123400000000000♠ ← {{ntsh|1.234|debug=yes}}
7003123400000000000♠1.234×10³ ← {{val|1.234e3|debug=yes}}
7003123400000000000♠← {{ntsh|1.234e3|debug=yes}}

Please post an example if it still appears something is wrong. Johnuniq (talk) 23:10, 2 October 2015 (UTC)

@Cpiral: Here, Pluto's density (1.87) sorts highest, above Earth's (5.5). User:Rudy235 removed Val because of this.[1] In a preview I replaced Mars's density with one using Val (which is where I got the above value of 3.9335), and then it sorted with Pluto, not the rest anymore. --JorisvS (talk) 09:48, 3 October 2015 (UTC)

The issue concerns the tables at List of Solar System objects by size#List of objects by radius. The problem is that the table would need to use val for all items in a column, and the table should not use data-sort-type="number" for that column. The sort key generated by val handles an enormous range of values, and handles different units. For example, {{val|999|u=m}} sorts before {{val|1|u=km}}. However, val's sort key is not compatible with plain numbers. Johnuniq (talk) 10:33, 3 October 2015 (UTC)

Error in Basque Wikipedia

Moved from Module talk:val

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

I have just copied this module and the /units module and I get this error:

Luanda errorea in Modulu:Val at line 267:attempt to call local 'lookup' (a nil value).

You can see live at: eu:Protoi

Well, solved! It called to Module:...." and it should be Modulu:...." as in basque language Wikipedia. -Theklan (talk) 20:17, 13 October 2015 (UTC)

@Theklan: No, that's not it—there must have been some other issue, perhaps the fact that the page was displayed before all the modules existed and you saw a cached copy of the page that had the error. The system software (MediaWiki) understands a generic name for each namespace as well as the local name. That means "Module:" works on all WMF projects. Here are two examples to demonstrate:

eu:Module:Convert and eu:Modulo:Convert are identical
bn:Module:Convert and bn:মডিউল:Convert are identical

Further confirmation is that if you search Module:Convert for "Module:" you will see that it requires eu:Module:Convert/data (and more)—convert is very complex and it is not as easy to see as in eu:Module:Val, but it is there. If you undo your edit to Module:Val you will see that it still works. Johnuniq (talk) 01:55, 14 October 2015 (UTC)

Error message on non-numbers

{{val|A}} → Error in {{val}}: parameter 1 is not a valid number.

Currently, if {{val}} is supplied with a string that cannot be parsed as a valid number, the output is an error message with red text color. That is not graceful fallback as one would expect. It should just return the mandatory argument verbatim:

{{val|A}} → A

— Christoph Päper 10:30, 26 November 2015 (UTC)

Val is trying to do the user a favor by letting them know that they have a typo in their input, or they intended to use some other template. The error puts the page in the tracking category so others can notice and fix problems (later I will add |nocategory=true to the above so it does not emit the category). Is there a usage where it would be helpful to not show an error for the above? Johnuniq (talk) 23:15, 26 November 2015 (UTC)

It came up in Template talk:Frac, because although {{frac}} is often used with numbers it really accepts any string for each of its three parameters, so we cannot use simple {{val}} calls to pretty-print numbers. Other templates may face similar problems that would require input sanitation on their part. — Christoph Päper 10:13, 8 December 2015 (UTC)

OK, if it is needed I can implement it. If wanted from another template, it might be best to require that a new parameter be used to specify that all that val is supposed to do is format the number by inserting gaps (or commas if fmt=commas used). Then, val would do the formatting if the first parameter is a number, but there would be no formatting or error message if a non-number is used. Is that right: if not a number, the output would be identical with the input? There does not appear to be an urgent need so I'll chew it over in due course, but might need a reminder (post here) if I forget. Johnuniq (talk) 06:33, 9 December 2015 (UTC)

Recurring decimals

Would it be possible to support repeating decimals in {{val}}? There are several established notational variants, but since parentheses are already used for uncertainties here, the overline convention should probably be adopted:

{{val|1/6}}
{{val|⅙}}
{{val|1|/6}}
{{val|1|/|6}}
{{val|0.1_6}}
{{val|0.1|_6}}
{{val|0.1|_|6}}
{{val|0.1|...|6}}: → 0.16

— Christoph Päper 10:33, 8 December 2015 (UTC)

I can think about that, should be possible. However, a couple of points before I do anything. Eight examples are given—are they suggestions for possible syntax, and one should be picked? Using slash should be avoided in case val ever supports fractions as is done in {{convert}} which allows 1+2/3 for 12⁄3. Also, where would this be used? I'm thinking there may well be an alternative template which does the job already. Val offers exponents and units, but I imagine they would not be needed with repeating decimals, so if there is a template which handles this, why not use it? Or, if the template does not exist, maybe it should be created rather than adding complexity to val? Johnuniq (talk) 23:56, 8 December 2015 (UTC)

Technically, you can hack it with |end=.

{{val|12|end=.{{overline|16}}|e=-2|u=m}} → 12.16×10⁻² m

But I agree it would be nice to have support for this. Maybe using a |rec=/|errrec=/|+errrec=/|-errrec= so that

{{val|12|rec=16|e=-2|u=m}} gave the 12.16×10⁻² m

{{val|12.0|rec=16|e=-2|u=m}} gave 12.016×10⁻² m

Or something similar. Headbomb {talk / contribs / physics / books} 03:44, 12 January 2016 (UTC)

Inserting gaps (1.23456789) while handling this makes the complexity unappealing. In the last example, the module would have to concatenate "12.0" and "16" to get the value 12.016 which it uses to generate a hidden sort key. I suppose that's do-able, but what are the errrec parameters? This would never be used with a unit? And it's hard to imagine a case where an exponent would be useful, but units and exponents might not be a problem. Are you sure there are cases where this would be used? It sounds like something that would be of interest only for math editors, and they often have their own way of doing things. Johnuniq (talk) 04:47, 12 January 2016 (UTC)

Johnuniq

errrec would be for error recurring. To produce cases like (12.016±0.03)×10⁻² m² or 12.016^+0.01
_–0.02×10⁻² m². Might be a case of overenginering however. Headbomb {talk / contribs / physics / books} 14:18, 4 April 2016 (UTC)

Bug when displaying more than 2 units

Moved from Module talk:Val/units

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

There seems to be a bug when displaying 3 or more units. For example:

{{val|1|u=kg.m}} looks like kg·m Y
{{val|1|u=m/s2}} looks like m/s² Y
{{val|1|u=kg.m/s2}} looks like kg.m/s2 N (should look like kg·m/s², with a middle dot and a superscript 2)

This also happens with e.g. {{val|1|u=kg.m.s}} or {{val|1|u=kg/m/s2}}, which leads me to think that there's a bug when displaying 3 or more units.

(Here are all the above using the template: 1 kg⋅m — 1 m/s² — 1 kg.m/s2 — 1 kg.m.s — 1 kg/m/s2 — when this is fixed, the last 3 will display different to what I wrote)

—Cousteau (talk) 10:41, 9 March 2016 (UTC)

@Cousteau: Val has certain units defined in the module. If there is no such definition, val uses {{convert}} to display what convert knows. If convert has no idea, it just displays the given text. That is what is happening here. No unit "kg.m/s2" is defined so the text is displayed as entered. It is a long time since I have thought about val so I might have forgotten something, but the documented procedure for "per" units is as follows. Note that the numerator is displayed in parentheses—that is a requirement of WP:MOS, I think.

{{val|1|u=kg.m|up=s2}} → 1 (kg⋅m)/s²

If there is a need to display a unit that is not covered by these rules, a suitable definition can easily be entered. You can try that if you feel confident, but be aware that you could break all current val templates. Making a suggestion and waiting for a day or two for someone to do it would be an alternative. I like to see an example of where a unit is going to be used, but there is lots of stuff defined in val that is not used so I guess it doesn't matter. Johnuniq (talk) 11:13, 9 March 2016 (UTC)

Disregard then; from the documentation I thought "compound units" were actually generated by composing units rather than being units by themselves, and that there was some sort of parser that interpreted the . and / and [-]n as unit combinators/modifiers. (Maybe this would be an interesting addition, but I guess it is an excessively complicated change and is out of the scope of this template.) —Cousteau (talk) 11:30, 9 March 2016 (UTC)

Pointless 10^0

If you use "The value in {{val|u=MeV/c2}}" you get "The value in 10⁰ MeV/c²" instead of the (previously/expected) "The value in MeV/c²". This behaviour should be fixed. Anyone that wants the 10⁰ to appear can write {{val|e=0|u=MeV/c2}}. Headbomb {talk / contribs / physics / books} 14:10, 4 April 2016 (UTC)

I agree and I seem to recall being puzzled about why the default value was wanted, but chose to implement it so the module was compatible with the old template. There are always complexities, for example, val outputs a hidden sort key unless it is switched off (sortable=off although that doesn't seem to be in the docs)—perhaps the default value of 10⁰ was to generate a sort key corresponding to 1 specified unit? I'll wait a while to see if anyone wants to comment, but am inclined to remove the default value and make it not output a hidden sort key. By the way, that key can be seen with "debug", and I'm thinking there should be no sort key for this case:

{{val|u=MeV/c2|sortable=debug}} → 7000100000000000000♠MeV/c²

Johnuniq (talk) 00:40, 5 April 2016 (UTC)

@Headbomb: I have made the change above. Using Special:ExpandTemplates shows the following result to confirm there is no sort key:

{{val|u=MeV/c2}} → MeV/''c''2

Following are some tests. The sortable=debug option both sets sortable=on and shows the sort key, so if anyone wants a sort key with no value, they can use sortable=on.

The value in {{val|u=MeV/c2}} → The value in MeV/c²
{{val|1|u=cm2|sortable=debug}} → 6996100000000000000♠1 cm²
{{val|u=cm2|sortable=debug}} → 6996100000000000000♠cm²

Johnuniq (talk) 06:31, 12 April 2016 (UTC)

Fractions

At the time this is written, {{val|1+2/3}} gives "Error in {{val}}: parameter 1 is not a valid number.". {{convert|1+2/3|ft}} gives "1 ²⁄₃ feet (0.51 m)".

If {{convert}} can handle it, why can't {{val}}? Fractions would be a very useful thing to add to the template. Of course there are {{frac}} and {{sfrac}} but they are not as useful. They don't add units, they don't have the same sort key, they don't add prefixes, etc. One thing I've found problematic is that they don't format number with gaps. The current best solution is to use {{val}}(s) inside {{frac}} or {{sfrac}}. This is very cumbersome.

I've suggested adding gap formatting to {{frac}}. This would be easy enough. Would it be difficult to add fractions to {{val}}? I suppose it might be tricky ... but I could be wrong, after all, there is the code already written for {{convert}}.

So, it would be easy enough to get {{frac}} to do gaps but what happens when we want it to sort by value and unit? It would be more useful to add fractions to {{val}} (with its various functions) than to add gaps to {{frac}} and {{sfrac}}.

At first I thought that adding fractions to {{val}} would be too difficult to bother with (especially considering that you'd want to have the options of both {{frac}} and {{sfrac}} styles); it'd be too difficult for me; but I'm beginning to think it could be worth the effort. Jimp 06:32, 15 April 2016 (UTC)

It's complicated! Val accepts numbers in ranges, and if there is no range, in one or two uncertainty values. Perhaps I could bolt on some method of handling a fraction if all that was wanted was 1+2/3 (not -1-2/3), and if there was no range. If there was a need for that in articles, and if it looked feasible, I might be able to relax the restrictions I just mentioned. How would this relate to #Error message on non-numbers above? Johnuniq (talk) 07:22, 15 April 2016 (UTC)

GT/s → Tesla/s

In List of device bit rates it became apparent that using {{val|1|ul=GT/s}} creates a link to Tesla (unit) and not to Transfer (computing) as would be expected here. GT/s probably isn't ever required for Tesla/s as that would mean a ridiculously fast increase in a magnetic field. Could someone knowledgable please look into this? --Zac67 (talk) 09:13, 23 April 2016 (UTC)

@Zac67: I added the following three units although it appears only GT/s is needed. Hovering the mouse above the link shows a nice popup.

{{val|1.23|ul=kT/s}} → 1.23 kT/s
{{val|1.23|ul=MT/s}} → 1.23 MT/s
{{val|1.23|ul=GT/s}} → 1.23 GT/s

Johnuniq (talk) 10:08, 23 April 2016 (UTC)

Excellent - thanks! --Zac67 (talk) 10:27, 23 April 2016 (UTC)

Tolerance in the e parameter is unsupported

Is there any way to accomplish this 3×10^20±1years with the Val template? Bytesock (talk) 14:23, 27 April 2016 (UTC)

@Bytesock: No, sorry that is unlikely to be supported. By default, val outputs a hidden sort key so values can be sorted appropriately in a sortable table. That means val requires the e value to be a valid number that can be used in a calculation. Johnuniq (talk) 10:13, 28 April 2016 (UTC)

Working with Wikidata

Is there any possibility to get this template to work with Wikidata similar to the way that {convert} works? The main application I can see is the correct pluralisation of the unit. For example:

112 minute, 116 minute

gives the singular for "minute". Convert does it nicely:

112, 116 minutes (6,700, 7,000 s)

but usually we would not want it converted into seconds (or anything else). Regards — Martin (MSGJ · talk) 12:43, 21 June 2016 (UTC)

The two examples above are:

{{#invoke:Wikidata|getValueFromID|Q184843|P2047|FETCH_WIKIDATA}} → 112 minute, 116 minute
{{convert|input=P2047|qid=Q184843}} → 112, 116 minutes (6,700, 7,000 s)

These refer to:

Blade Runner (Q184843)

duration (P2047)

Something will be possible but I won't be able to start thinking about anything new for at least a week. If I forget, please remind me. Johnuniq (talk) 00:08, 22 June 2016 (UTC)

Template:♥

I can do a bit of snooping later to find out why, but does anyone know why this template invokes {{♥}}? Worm^TT(talk) 09:49, 25 September 2016 (UTC)

@User:Worm That Turned: It's not a template, it was a brilliancy from AzaToth who introduced it into Template:Convert/sandboxlua (diff), and I copied it from there to here when upgrading this template to use Module:Val (as {{convert}} uses Module:Convert). The background is as follows. Someone used {{convert|1|ft|m|adj=mid|=done}} which acccidentally set a parameter to the value "done"—the problem was that the name of the parameter is an empty string. I had previously asked if the template could support subst, and the solution was to insert {{{|safesubst:}}} before the #invoke. I never properly understood how that worked, but it had a defect in that when |=done was used, the safesubst stuff was replaced with {{done}}, and the convert ended up showing an image in the article. Extremely confusing! Using ♥ is just a trick to avoid the problem occurring again. To trigger the problem, the hapless editor would now need to use the following:

{{convert|1|ft|m|adj=mid|♥=done}} → convert

It's probably a bit academic because subst is rarely wanted, but I thought it may as well be supported since it is pretty simple and low-overhead. Johnuniq (talk) 11:59, 25 September 2016 (UTC)

I should note that {{{♥|safesubst:}}} is a parameter (triple braces). The parameter name is ♥ and the intention is that the parameter will never be defined in the template call. Therefore the default safesubst: will appear before the #invoke and the magic which I don't grasp follows. Johnuniq (talk) 02:32, 26 September 2016 (UTC)

@Johnuniq: Somehow a spade symbol ♠ (not a heart symbol) is making it into the sort key for the returned value. E.g., {{val|13.799|0.021}} at Age of the universe, is returning:

7001137990000000000♠13.799±0.021

Is that due to a similar hack somewhere else in the code? Thanks. Mike Peel (talk) 19:27, 26 September 2016 (UTC)

@Mike Peel: The ♠ comes from Module:Convert and is for compatibility with {{ntsh}}. Before {{val}} used Module:Val (that is, before my involvement here), val was modified to always generate a hidden sort key for cases where val is used in a sortable table. I made Module:Val emulate what the template did, so it also generates a hidden sort key; that key is provided by a call to Module:Convert. Convert originally did not add the ♠ because I could see not a use for it. The theory for why it might be needed is that the hidden sort key is adjacent to the displayed value, so if there were no ♠ the Javascript which sorts the table would attempt to use the concatenated text as the sort key, and that could cause problems (something to do the script trying to interpret the concatenated text as a number, which the ♠ stops). I asked Jimp about that here (permalink). I never saw a case where ♠ was needed, but I decided to implement it anyway, mainly so convert's sort key would (usually) be identical with the key produced by ntsh.

By the way, the key can be displayed or omitted as follows:

{{val|13.799|0.021|sortable=debug}} → 7001137990000000000♠13.799±0.021
{{val|13.799|0.021|sortable=off}} → 13.799±0.021 (putting this in Special:ExpandTemplates would show there is no sort key)

While I'm warmed up, I'm not entirely happy with the fact that val is outputting all that sort key stuff by default. Somehow the html bloat seems unclean, but lots of other things also cause bloat so maybe it's ok. Johnuniq (talk) 01:41, 27 September 2016 (UTC)

That's why the ♠ was added, yes. It separates the sortkey digits from the output digits. Otherwise 13.799, for example, gets sorted as 700113799000000000013.799 instead of 7001137990000000000. Jimp 02:39, 29 September 2016 (UTC)

Yes, but the sort key is designed to cover an unimaginably large range of numbers (I think it was your design) and I can't see how concatenating the input value would make any difference. To have a difference, there would need to be two different numbers which generated the same sort key, and even then only some of the hypothetical cases would sort incorrectly. Johnuniq (talk) 02:52, 29 September 2016 (UTC)

That was my plan, yeah; at the time, {{nts}} was quite limited in terms of range and precision; I'd wanted to make as full use of WP's capabilities as possible. At first, I didn't think there'd be a difference, but I ran into some problem somewhere along the line (I don't remember where exactly) and found that the ♠ to separate digits fixed it. Jimp 09:36, 4 October 2016 (UTC)

This sounds like it's an unnecessary hack - perhaps it can be simplified to at least remove the symbol? @Deskana: was finding that the sort key and the symbol were being displayed on a mobile interface (although I'm not sure which - this was a brief conversation on Facebook), which isn't a good thing to happen. It's not clear if this is due to a bug in this template's coding, or the mobile interface, though - but removing the hack would be a logical first step to fixing this. Thanks. Mike Peel (talk) 20:57, 4 October 2016 (UTC)

Raw currency symbol fails as unit

Consider the following two cases (used to express the cost of electricity in the United Kingdom):

0.084 /kWh — {{val|0.084|u=£/kWh}}
0.084 £/kWh — {{val|0.084|u=£/kWh}}

The first case fails to include the £ symbol in the displayed unit. This looks like a bug to me. Any chance of fixing it? Best wishes. RobbieIanMorrison (talk) 09:50, 6 October 2016 (UTC)

@RobbieIanMorrison: Interesting weirdness. Val does some crazy things when looking up units. After checking that the unit is not define in Module:Val/units, it asks Module:Convert to look up the unit. {{convert}} has many weird tricks of its own, and that includes treating £ as a recognized currency symbol for special treatment. Example:

{{convert|12|£/kWh|abbr=off}} → £12 per kilowatt-hour (£3.3 per megajoule)
{{convert|12|£/kWh|abbr=on}} → £12/kWh (£3.3/MJ)

Notice that convert moves the £ symbol. When abbreviated (which is what happens with val), the unit is regarded as being "/kWh" and "£" is a prefix for the value. That does not work well with val, with the result described above, namely:

{{val|12|u=£/kWh}} → 12 /kWh (val loses the £ prefix)

It's not worth changing how convert works with val to make an exception for this strange case, so there are two remaining solutions. First, we could define £/kWh as a unit known to val—but then the same problem would occur if anyone uses £/x or $/x where x is some other convert unit.

The second and proper solution may not be attractive, but the correct way to define "per" units in val is as follows:

{{val|12|u=£|up=kWh}} → 12 £/kWh

Johnuniq (talk) 11:20, 6 October 2016 (UTC)

Hello Johnuniq. At least this issued is documented in Template:Val#Introduction, namely:

To bypass the unit code system, if |u= does not recognize your unit code, it will accept any wikitext and render it as usual.

Moreover I cannot see any compelling reason to make £/kWh a special unit known to {{val}}. Probably best to live with this imperfection, particularly as there are two work-arounds: explicit markup and the use of |up=. Thanks for the quick reply. RobbieIanMorrison (talk) 11:58, 6 October 2016 (UTC)

You could use {{val|0.084|p=£|up=kWh}}, which gives "£0.084/kWh". Of course, that'll stuff up the sort key unless all the values are in pounds, on the other hand, it's usually best not to include units on table cells anyway. As for making a special exception for u=£/kWh, that seems problematic, as Johnuniq mentions, since users would expect it to work for other combos of currency & units. If we were to make u=£/kWh work, we should do it properly, i.e. include all major currencies (dollars, pounds, euros and yen initially, with the possibility of extending if needed) and any arbitrary unit. It'd be doable but it's a question of finding someone with the time, know-how and motivation. Is it worth it though, considering p=£ will give the desired result albeit a bit of a hack? Jimp 07:23, 17 October 2016 (UTC)

fmt=none

By trial and error, I discovered that fmt=none works, suppressing the use of commas or gaps to separate groups of digits. Can we document this? Peter Chastain ^[¡habla!] 16:51, 20 December 2016 (UTC)

@Peter Chastain: Sorry about the trouble, and thanks for pointing it out. I edited the documentation, see what you think. Johnuniq (talk) 03:14, 21 December 2016 (UTC)

@Johnuniq: Excellent! Thanks much! Peter Chastain ^[¡habla!] 00:57, 22 December 2016 (UTC)