Template talk:Convert/Archive January 2015

Power conversion examples?

The dox appear to have no examples of power conversion. So can anyone explain what's going on here? I'm using {{convert|6.3|hp|kw}} hp and kw are the correct abbr's, and just to be sure I tried kW with no luck either. Maury Markowitz (talk) 15:16, 4 January 2015 (UTC)

I get this:

{{convert|6.3|hp|kW}} → 6.3 horsepower (4.7 kW)

{{convert|6.3|hp}} → 6.3 horsepower (4.7 kW) -- (kW is the default for hp)

Correct capitalisation is needed always. Indeed, hp only in Module:Convert/documentation/conversion_data/doc (full list). Unfortunately not in Template:Convert#Units (doc). -DePiep (talk) 17:14, 4 January 2015 (UTC)

You're saying you want "kw" rather than "kW", right (or have I misread)? If so, I hate to say it but I believe you'd be wrong. The symbol for the kilowatt is "kW" not "kw". SI unit symbols which are named after a person (e.g. James Watt) are always capitalised. Jimp 03:30, 5 January 2015 (UTC)

I fixed this. I think the OP meant that "kW" was tried but it did not work. There must have been some other problem that caused that because, as you say, kW is correct. At any rate, the article is fixed, and Radioplane is great BTW. Johnuniq (talk) 04:32, 5 January 2015 (UTC)

Per parameters

I'm suggesting we add two new parameters. Let's call them |per_in= and |per_out= (at least till we can come up with better names). These would modify the input units by dividing them by a "per unit". For example, say you wanted to convert 32 calories per ounce to kilojoules per gram you'd do so like this.

• {{convert|32|Cal|per_in=oz|kJ|per_out=g}} → "32 calories per ounce (4.7 kJ/g)"

You could even leave out the numerator unit like this.

• {{convert|110|per_in=m2|per_out=sqft}} → "10 per square foot (110/m²)"

Or use it as a conversion for prices like this.

• {{convert|12|$|per_in=yd|per_out=m}} → "$12 per yard ($13/m)"

We could also introduce a third parameter, |per=, as a shorthand way of making the input and output per unit the same. For example, 123 barrels per second could be handled like this.

• {{convert|123|oilbbl|m3|per=s}} → "123 barrels per second (19.6 m³/s)"

It seems pretty straight forward so far but what happens when |per_in= is specified but |per_out= is not or vice versa? One solution would be to let the unspecified per parameter take the value of the default output unit for unit set by specified per parameter. So, for example, the above conversion of 32 Cal/oz could be shortened like this.

• {{convert|32|Cal|per_in=oz}} → "32 calories per ounce (4.7 kJ/g)"

This would work if the output numerator unit (kilojoules in this case) is either unspecified (and thus determined by the input numerator unit) or matches the input numerator unit (calories here) in dimension (energy in this case). However, what if you wanted to convert 500 calories per minute to kilowatts? Shouldn't you expect you could do this?

• {{convert|500|Cal|per_in=min|kW}} → "500 calories per minute (35 kW)"

It would seem reasonable but it might take a bit of a rethink of how the template does dimensional analysis. (I had been working on a way of doing this which would have worked a couple of years ago which I could dig up if it seems worth it. It involved representing dimensions (etc.) as prime numbers.) Jimp 04:08, 29 December 2014 (UTC)

P.S. I've managed to dig up the subtemplate I was intending to use to produce error messages the template would have produced when input and output units didn't match. It's incomplete but it should give people an idea of what I was driving at. Each of the seven base dimensions used in defining the SI are given a prime number. The non-SI "dimension" of currency is also given a prime number, 31, (originally I had a different prime number for different currencies but that would probably not be necessary, especially if we go with the idea of using |$= as a parameter to specify non-dollar currencies as discussed a while ago). Further, yet another prime number, 11, is introduced for special distinctions (so, for example, litres per hundred kilometres isn't counted as an area) ... that is special distinctions of a general nature but another prime number, 101, is introduced for vectors (e.g. torque vs energy). Angles were given 13 (just to be on the safe side, though mathematically you can think of them as dimensionless). Plain old numbers are given a value of 1 since they are dimensionless. All other dimensions are assigned numbers corresponding to the base dimensions they are derived from by multiplying and/or dividing the corresponding numbers as the units themselves are multiplied and/or divided. So, for example, since length is 2, area is 4 and volume is 8; and since time is 5, speed is 2⁄5. If you look at the way I assigned the primes to the base dimensions, it may seem a bit arbitrary, and it is a bit, but if you look hard enough, you might see sense in it, and if you're interested, I could go into detail, but I spare you it for now. I'm not saying we must adopt this system. It's just a suggestion of a system which would make it easier to dimensionally analyse arbitrarily formed units without having to come up with a special name in each case. This is what I had been planning to use in order to get over the types of problems I mentioned above. Jimp 05:43, 29 December 2014 (UTC)

Sure allowing any known straight unit to be used in a per-unit construct is good by principle. I recall some handling is done now, but I have not looked into that (writing documentation is a good route to learn this). Is there a nom/denom recognition at all right now (or are all availables done by predefinition?).

This, too, would be a matter of a unit-recognition module (needs redesign I understand, leaving the serve-markupcode era). For that, we need to check that we cover all reasonable options.

First question: why not recognize each and all by slash '/' leaving the or '_per_'?

Second thought: By SI, a more universal setup is:

• A quantity Q is expressed in the base quantities: $Q=f\left({\mathit {l,m,t,I,T,n,I}}\mathrm {_{v}} \right)$
• Derived dimension: dim Q = L^a · M^b · T^c · I^d · Θ^e · N^f · J^g (Superscripts a–g are algebraic exponents, usually a positive, negative or zero integer.)

(from: Template:SI base quantities, I made). This could be extended with "$".

So SI also allows writing like: "4.1 kJ·mol⁻¹".

-DePiep (talk) 07:52, 29 December 2014 (UTC)

Never mind tweaking convert! How about some opinions on the units at User:Johnuniq/sandbox3? Johnuniq (talk) 08:27, 29 December 2014 (UTC)

I see a great use for magnum per octave! -DePiep (talk) 08:34, 29 December 2014 (UTC)

I've just started my second magnum...compliments of the season to all! Johnuniq (talk) 08:48, 29 December 2014 (UTC)

This one should be consumed with an octave I propose. In our family, we have a personal magnum/octave optimum these days. -DePiep (talk) 09:09, 29 December 2014 (UTC)

I don't think the template proper can handle this type of thing yet (though it's getting harder and harder to keep track ... that's a good thing) but I think it's one of those renegade wrappers that you might have in mind (some of them have good ideas worth absorbing into the actual template).

1. If it is possible to recognise each and all by reading the slash (and I believe it is (even without Lua)), yes, that would be better.
2. The internal parameter (which I was calling |D=) was much like your Q where f was such that Q = 2^a × 3^b × 5^c × 7^d × 11^h × 13ⁱ × 19^e × 23^f × 29^g × 31^j × 101^k where a ... g are as above, h is an integer usually zero but non-zero for special cases that need distinguishing, i is for angles, j is for currency and k is for vectors. (37, being the next prime, might have been more consistent that 101 but 101 is easy to multiply by in you head.) This would give you a unique rational number for each possible dimension. The reason I had intended to use rational numbers is that numbers are easy to manipulate using the template code, I don't know whether this is still true with Lua. Perhaps using Lua we could use a code that is easier for a human to read but not too hard to manipulate. What kind of f would you suggest?

Jimp 13:33, 29 December 2014 (UTC)

I am not as much about what internal code (prime numbers or else) to use. I am looking for a universal setup that can cover all or most situations (exceptions are a headache by definition, both in code as for the wiki editor). I mentioned that "/" (or "⁄") and "_per_" probably should be protected input code (=with special meaning), easily recognised (in Lua, by text pattern) and therefor useful unitID separators. (This to be extended by e.g. space, ^+/-n exponent,  · , ..). Number handling would complete input parsing; format issues (like space/nospace, superscripts) could cause another layer of troubles to solve. At least we should prevent the need for user-side parsing, such as |per_unit= you propose: a 'natural input' parsing is preferred. Anyway, all this requires big design overhaul (into modules), and Johnuniq mentioned these months they have no time for that shortly. -DePiep (talk) 14:09, 29 December 2014 (UTC)

In Lycoming GSO-580#Specifications (VSO-580-A1A), and others, a per parameter already exists: |power/weight={{convert|0.68|hp/lb|kW/kg|abbr=on}} 0.68 hp/lb (1.12 kW/kg). Peter Horn User talk 02:21, 30 December 2014 (UTC)

Yeah, there are heaps of units already defined as something-per-something but up until now each one has had to be defined individually. We're hoping to make it work for every combination as long as the units on each side oft he slash are defined.

This could also be extended to include combining units by multiplication (e.g. giganewton-metres). Use the full-stop to represent multiplication (in the code, with a middot displayed).

One thing to watch out for would be units which have no abbreviation. You'd generally want to avoid abbreviating one part and not the other (although a unit symbol/abbreviation followed by "per" and then a unit name, e.g. "12 lb per acre", would be okay).

Jimp 04:21, 30 December 2014 (UTC)

And then there already exists this one: Lycoming IO-390#Specifications (IO-390-X){{convert|11.1|USgal/h|L/h impgal/h|sp=us|abbr=off}} 11.1 gallons per hour (42 liters per hour; 9.2 imperial gallons per hour) Peter Horn User talk 04:29, 30 December 2014 (UTC)

This would be useful, although the method mentioned by DePiep of just using the slash as the clue would be cleaner. Ideally {{convert|32|Cal/oz}} would work with the output kJ/g generated as the automatic default. Likewise, {{convert|12|$/yd}} would magically work. However, {{convert|110/m2}} would be more problematic as the code would have to do something special for the input number, whereas the other cases need enhancements only to the unit processing. Problem: The code handling units is already mega-complex. After a look-up of a unit fails, it checks for SI prefixes like "k" in "km", then it tries engineering prefixes like "e6" in "e6cuft", then combinations like "km mi". If it still hasn't worked, it tries again using Module:Convert/extra. From the module's point of view, it might work better if the special processing required could be recognized at the start with a special parameter (something like |per=/), or a wrapper template like convertper. I'll do some thinking. Johnuniq (talk) 03:16, 2 January 2015 (UTC)

Let's not embark on this from the current complicated setup. (Once this would be added, we have another half a dozen issues to be solved. Eg, scientific notation, engineering notation, prescribe type (ask me), +/-, unit exponentⁿ, compound unit by multiplication  · , ...). Then, adding another parameter like |per_in= is moving backward (adding complicated work for the editor).

We need a modular input parser, full stop. 100/ha: if you understand this, Lua can. The global pattern of a value to be converted is: pretext_number_unit. (pretext can be "$" or unrecognised=freetext; number can be ..., unit can be compound by "/" or "2" for ². -DePiep (talk) 11:33, 2 January 2015 (UTC)

I like the complete & systematic way the SI prefixes are handled. Be inspired by that. -DePiep (talk) 11:35, 2 January 2015 (UTC)

{{convert|110/m2}} may be problematic but why not use {{convert|110|/m2}} instead as with {{convert|110|/km2}} and {{convert|110|/sqmi}}?

I can't say I'm keen on the idea of further proliferation of these "wrappers". One of the beauties of {{convert}} has always been its capacity to cover a wide scope. It has thereby replaced a whole swathe of pissy little narrow templates. I hope we aren't forced back there. Jimp 03:52, 5 January 2015 (UTC)

Moot per below! Yes {{convert|110|/sqmi}} is good too. I just wanted to note that this is natural and clear to the editor, so it would be worth it if {convert} knows it. -DePiep (talk) 08:53, 6 January 2015 (UTC)

I don't understand which "wrappers" you mean. Something I said? -DePiep (talk) 09:31, 6 January 2015 (UTC)

Jimp was referring to my mention of "a wrapper template like convertper". As you say, that's moot now. Johnuniq (talk) 10:03, 6 January 2015 (UTC)

Automatic per units

On thinking this over I decided it was actually easy to implement, and the trick is so elegant I had to do it. This is now in the sandbox and is experimental at this stage—it's just been written and has not been checked much yet). It seems to work, with some irritating glitches mentioned below.

• {{convert/sandbox|10|/sqft}} → 10 per square foot (110/m²)
• {{convert/sandbox|10|/sqft|/m2}} → 10 per square foot (110/m²)
• {{convert/sandbox|12|$/yd}} → $12 per yard ($13/m)
• {{convert/sandbox|12|$/yd|$/cm}} → $12 per yard ($0.13/cm)
• {{convert/sandbox|12|$/yd|$/cm|$=€|order=flip}} → €0.13 per centimetre (€12/yd)
• {{convert/sandbox|123|nmi/h|yd/s}} → 123 nautical miles per hour (69 yd/s)
• {{convert/sandbox|36000|/h|/s}} → 36,000 per hour (10/s)
• {{convert/sandbox|1.5|/s|/h|abbr=on}} → 1.5/s (5,400/h)
• {{convert/sandbox|12|furlong/s|nmi/h}} → 12 furlongs per second (4,700 nmi/h)
• {{convert/sandbox|10|m/sqft|cm/m2}} → 10 metres per square foot (11,000 cm/m²)
• {{convert/sandbox|10|m/sqft|cm/m2|order=flip|sp=us}} → 11,000 centimeters per square meter (10 m/sq ft)
• {{convert/sandbox|2.5|$/acre}} → $2.5 per acre ($6.2/ha)
• {{convert/sandbox|2.5|e3$/acre}} → $2.5 thousand per acre ($6,200/ha)

Error checking (hold mouse over message for details):

• {{convert/sandbox|10|g/cm|oz/in2}} → 10 grams per centimetre ()
• {{convert/sandbox|10|sqft/}} → 10 sqft/
• {{convert/sandbox|10|sqft/$}} → 10 sqft/$
• {{convert/sandbox|10|/sqft|$/sqyd}} → 10 per square foot ()

Would need some magic to overcome the following irritation where an automatically generated unit type is not the same as that of a built-in unit (hold mouse over message for details).

• {{convert/sandbox|32|Cal/oz|kJ/g}} → 32 calories per ounce (4.7 kJ/g)
• {{convert/sandbox|140|m3/h|yd3/h|sp=us}} → 140 cubic meters per hour (180 cu yd/h)
• {{convert/sandbox|123|mph|yd/s}} → 123 miles per hour (60 yd/s)
• {{convert/sandbox|11|lb/mi|lb/nmi kg/km|abbr=on}} → 11 lb/mi ()
• {{convert/sandbox|1|km/h/s|mi/h/s}} → 1 kilometre per hour per second (0.62 mph/s)

If a unit in an automatic per has a combination as its default output, the automatic default breaks.

• {{convert/sandbox|32|ch/kg}} → 32 chains per kilogram (960 ft/lb)
• {{convert/sandbox|32|ch/kg|ft/oz}} → 32 chains per kilogram (60 ft/oz)
• {{convert/sandbox|32|ch/kg|ft/oz+m/g}} → 32 chains per kilogram (60 ft/oz; 0.64 m/g)

Demo of hp/cuin request above

• {{convert/sandbox|0.51|hp/cuin|kW/L|abbr=on}} → 0.51 hp/cu in (23 kW/L)
• {{convert/sandbox|0.51|hp/in3|kW/L|abbr=on}} → 0.51 hp/in³ (23 kW/L)

The last example uses in3 which I have changed to have a superscripted symbol. It needs testing. Johnuniq (talk) 04:29, 5 January 2015 (UTC)

I have enhanced the processing of automatic per units, and it should still be reasonably efficient. The new code overcomes the "following irritation" mentioned above for most cases. It is still not possible for a conversion between automatic units and defined units of the following types:

mass/length ↔ exhaust emission

mass/volume ↔ co2 per unit volume

That is because the standard meanings are:

mass/length = linear density

mass/volume = density

Please give it a bit of a workout and report any problems. It's still experimental as far as I'm concerned, but it's looking good. Johnuniq (talk) 08:42, 6 January 2015 (UTC)

Absolutely brilliant! Glad it was easy to do. -DePiep (talk) 08:55, 6 January 2015 (UTC)

• About "x per cost"-units. (sqft/$)

{{convert/sandbox|10|$/sqyd}} → $10 per square yard ($12/m²)

{{convert/sandbox|10|sqyd/$}} → 10 sqyd/$

{{convert/sandbox|10|sqyd/$|m2/$}} → 10 sqyd/$

Can I understand this error? IMO, the second and third ones are defined and can be calculated. "area per cost" might be an undesired unit for other reasons, but I guess that does not matter for these {convert} internals. -DePiep (talk) 09:05, 6 January 2015 (UTC)

I decided that currency only makes sense in the numerator, so $/area works, but area/$ is an error. In principle, someone could talk about how many square yards of material can be purchased for $1, but there is no good way to represent that in text (for example, "1.5 square yards/$" does not read well). Johnuniq (talk) 10:03, 6 January 2015 (UTC)

Unused units in /data

Johnuniq, a few weeks ago you wrote here that a lot of the units in /data are not used at all. (They are inherited from old markupcode {convert} I guess). Do you consider a cleanup? Possible criteria for deletion:

• not used in current enwiki
• unlikely to be used in other language wiki (so this enwiki data list is like a Common list)
• not completing a series (eg unit e6m is unused, but completes the enm series so keep).
• bad or missing encyclopedic description (no article)
• few uses, but unit can be replaced with sense
• implausible unit symbol or name

-DePiep (talk) 11:45, 2 January 2015 (UTC)

Yes, I would like to clean out obscure and unused stuff. There are lots of combinations that are not needed because they work automatically, and I think it would be cleaner to remove them. I will be downloading the January articles dump in due course and will inspect it. Johnuniq (talk) 04:35, 5 January 2015 (UTC)

It would also be good for documentation. Technically, we could make the lists dynamically = read from /data right away by module, instead of hard-editing by processing a script result. Example: Template:Track gauge/doc/input options for ~235 entries, using Module:Track gauge/autodocument.

Also, depending on remaining number of units and overview quality, we can make a sub-list of most common (arbitrarily) units. That reduced list can be at hand in the /doc. -DePiep (talk) 10:12, 5 January 2015 (UTC)

Yes, cleaning out unused stuff makes documentation easier to maintain, and more comprehensible. I think it would be hard to improve on the full list of units as far as documentation goes, and as you know that is guaranteed to be the same as Module:Convert/data. Johnuniq (talk) 10:31, 5 January 2015 (UTC)

re-explain: That "full list" is maintained manually or a script is run to re-fill it. iow, it may be outdated. Also, improvements (like anchors and type-sections) is limited: I can not do. On the other hand, Module:Track gauge/autodocument I mentioned (and made), reads the /data page live, and so is never outdated. It could be made today for convert/data, but the resulting size would be impractical I guess. I am also trying to get what future you and Frietjes see for documenting the /data re this. -DePiep (talk) 10:58, 5 January 2015 (UTC)

Convert/data is generated from the full list of units—the documentation is the input used to create the data as the output. I sometimes update convert/data/sandbox from my local copy of the full list of units, but convert/data always exactly matches the enwiki full list except during periods when proposed changes are being tested. Johnuniq (talk) 11:25, 5 January 2015 (UTC)

Eh, misunderstanding? I do not want to do anything in /data. This is about documenting the units. I am thinking about writing a Lua module Module:Convert/autodocument that reads Module:Convert/data as it is, and present that in a wikipage (that page having wikicode like {{#invoke:Convert/autodocument|documentData}}. This would replace any manual or non-live scripted editing of the full list page. (/extra to be included). -DePiep (talk) 11:39, 5 January 2015 (UTC)

There may be a better way of documenting the units, but I do not see an acknowledgment of an important fact:

The full list of units is exactly the same as Module:Convert/data (except that the specials table in Module:Convert/makeunits adds some magic that, due to its complexity, is not present in the full list).

As far as editors are concerned, the trickiness in the specials table is irrelevant for editing, and the full list of units shows exact definitions. It is true that the two pages can be independently edited and so are not an exact match at all times—I don't think that has been a problem.

Regarding "This would replace any manual or non-live scripted editing of the full list page": The full list page would still need to be edited when changes are made because that is how convert/data is created. Johnuniq (talk) 23:14, 5 January 2015 (UTC)

So yes, misunderstandings. Please tell me, in short: which script is used, and how is it used, to produce the page full list of units? -DePiep (talk) 09:21, 6 January 2015 (UTC)

"The full list page would still need to be edited"- wrong. The proposed Module:Convert/autodocument (functionality) reads /data as it is (live). It will represent changes in /data automatically. -DePiep (talk) 09:36, 6 January 2015 (UTC)

The full list of units is maintained manually. It is read by Module:Convert/makeunits which uses it to generate the wikitext for Module:Convert/data. Because makeunits reads it, the full list has to follow a certain format; for example, the columns must be in the order shown, and the level-two section headings must not be changed because makeunits looks for them. I originally created the full list of units with a script running on a local computer; the input to that script was a text file with the unit definitions which I had scrounged mainly from the original templates. I still use that local script because I find the text file of unit definitions helpful, however the full list of units at other Wikipedias is manually edited. For example, the slwiki units have been edited by them a little, and the zhwiki units have been entirely edited by them. Running makeunits at zhwiki generates the wikitext for zh:Module:Convert/data. I recommend a quick look at the zhwiki example because it illustrates the principle well: convert/data has lots of quirky features which editors could not easily maintain, and makeunits handles all the quirks while performing error checking on the input from the full units definitions. After changing the definitions in the full units page, they copy the wikitext from zh:Module talk:Convert/makeunits to update convert/data. Johnuniq (talk) 09:56, 6 January 2015 (UTC)

By the way, it is easy to experiment with makeunits without changing anything. As an example, go to the Overrides section, click "edit" for the Area section and delete the row for "daa" (or change "daa" to "hello"). Do not save. Find "Preview page with this module" at the bottom of the edit window. Paste "Module talk:Convert/makeunits" into the Page title, then click "Show preview". That should display the wikitext for Module:Convert/data, but it will actually display an error because the daa line is needed. Similarly, you can edit other sections and change units, then see the result in the preview. For example, in the Mass section, you could change the unit code for any of the units to "g", then preview. That shows an error because "g" would then be defined twice. Johnuniq (talk) 10:15, 6 January 2015 (UTC)

Will study this. -DePiep (talk) 10:28, 6 January 2015 (UTC)

Dump-based cleanup

Johnuniq, you mentioned here that you plan to make a January 2015 dump for analysis of current usage. I do not take that as a promise (I don't mind). But if you do that, I have this question.

We have a list of deprecated parameter values & names. These are deprecated by documentation only ("do not use").

Following that dump-check, these options can be removed from module code (or not, that is a de-deprecate). Such a code change should be asap after the dump moment: we do not want new uses of these red options while we are researching the dump (because, those would produce bad article page without the editor seeing that in preview, nor we in the dump). This is the professional attitude. For the units to be removed from /data, this same process & time issue exists.

My question is: which procedure are you gonna drive? Do you agree with the asap-rule I described? If the individual deprecations are gonna be re-discussed into long or widening talks, the dump check will be useless. -DePiep (talk) 10:39, 5 January 2015 (UTC)

I'm happy to look for the deprecated options and make a list of where they are used somewhere. A complication with removing them from the module is that there will be many non-article pages (I guess only archived talk pages) where the deprecated options are used, so they would be broken for anyone looking through the history. Johnuniq (talk) 10:54, 5 January 2015 (UTC)

Yes the archives might be broken. So what. We are not a hostage of archive versions. That would impede like 50% of improvements. I say this is no reason to keep deprecated code.

Yes we can "look at it". Now I'm anxious to read from you: "unless extreme situations ask for redicussion & possible un-deprecation, they will be removed from code asap after the dump-check". That is: asap after the dump-date there will be a straightforward update in the module(s). Actually, since they are deprecated already, we might just as well prepare a bot/AWB to replace red options with green options from that dump-based list, without "looking". The point is that re-discussion of decisions is not desired. -DePiep (talk) 11:07, 5 January 2015 (UTC)

The other method to find uses of deprecated parameters is to use a tracking category. -- WOSlinker (talk) 12:35, 5 January 2015 (UTC)

Yes. That would take the "asap" out of the process (to cover a longer dump-evaluation period). But to what means? Postpone the code removals? And if this is a end solution to guard deprecations (= deprecations and this maint category will stay in code 'forever'), it is another maintenance task in the convert code, another layer of complication.

The core point is Johnuniq's process approach wrt the deprecations, a statement that deprecated code will be removed. -DePiep (talk) 13:11, 5 January 2015 (UTC)

Cleanup is good, but please comment at #Automatic per units above because I want to know if that is worth pursuing. Johnuniq (talk) 23:16, 5 January 2015 (UTC)

These topics are completely unrelated, they are a complete disjoint. so that simplifies matter. This thread only plays if and when you plan to use a fresh wp-dump for usage checking. (But if you gonna make a fresh dump, be sure to have grasped & this thread).-DePiep (talk) 09:12, 6 January 2015 (UTC)

I'll download January when it is prepared, probably in a week. At the moment, the latest available is 2014-Dec-21. Johnuniq (talk) 09:31, 6 January 2015 (UTC)

This is not a reply to the main question here. What is unclear about this? -DePiep (talk) 09:37, 6 January 2015 (UTC)

There have been several new comments recently, so someone looking at the activity here might not want to examine every recent comment, and might just look at the bottom of the page. I wanted to alert people like WOSlinker that there was something I wanted feedback on. Re the issue in this section, I think I've replied. I wouldn't want to commit to removing all the deprecated options until we have had a chance to examine how they are used in articles, if they are used. The January dump will not be available for at another week, and I will need a few days after that to find time to extract the data, and will then report here. Johnuniq (talk) 10:23, 6 January 2015 (UTC)

Well yes, a blind commitment would not be good indeed. OTOH, taking too much time for code edits in itself introduces to problem of 'outdated data' (as described). Also, presenting no plan at all for this leaves too much vague routes for this talkpage. I must expect re-opening discussions already done, and at that an introduction of "I just like/dontlike" arguments as I have encountered more often on this page. This would make the double dump-check (parameter usage and unit usage) less effective, both for the module-side as for the editors-side. -DePiep (talk) 11:20, 10 January 2015 (UTC)

Another unusual one, horsepower per cubic inch

For Lycoming IO-580#Specifications (IO-580-A1A) | specpower=0.51 hp/in³ (24.7 kW/L) replace with 0.51 hp/cu in (23 kW/L). Peter Horn User talk 01:19, 28 December 2014 (UTC)

Make that {{convert|0.51|hp/cuin|kW/L|abbr=on}} Peter Horn User talk 01:21, 28 December 2014 (UTC)

I would like to investigate this a little to see what other usage there is. The specpower field is in {{pistonspecs}} and it displays "Specific power:...". Searching for "specific power" led me to Honda F20C engine which shows they handle it with "specific power of 123.45 bhp (92.06 kW) per liter". In other words, the convert applies to the power, and the "per liter" is added manually. I wonder if that is a good way to handle it in general rather than making up a bunch of odd units. I'm busy on an irritating project at the moment, and may not get back to this for a few days. If anyone would like to find other cases of "specific power", that would be good too. On the other hand, if only the two units above are needed (hp/in³ and kW/L), they would be easy to add and probably worthwhile. Johnuniq (talk) 03:47, 28 December 2014 (UTC)

Adding new units for each case might get a bit unwieldy but adding "per litre", "per acre", etc. won't be viable either; pounds per hectare, kilojoules per ounce, kilometres per gallon, etc. are useless units. Perhaps adding new parameters to deal with these unit₁-per-unit₂ conversions would be a better solution (in the long run). I'll explain more below since it seems worth its own heading. Jimp 04:08, 29 December 2014 (UTC)

In Lycoming GSO-580#Specifications (VSO-580-A1A), and others, such a "useless conversion", or "impossible conversion" already exists: |power/weight={{convert|0.68|hp/lb|kW/kg|abbr=on}} 0.68 hp/lb (1.12 kW/kg). Peter Horn User talk 13:57, 29 December 2014 (UTC)

@Peter Horn: This has not been forgotten, but the issue led to a significant development from Jimp's suggestion, culminating in #Automatic per units below. When checking some details, I found there are some ugly glitches associated with determining a default output unit when the input is an automatic per unit, and that has delayed me. However, it will be finished soon, although there will probably be another couple of weeks delay while I fiddle getting the code ready for a new version. At any rate, when it's all done, it will be possible to convert most sensible units of the form x/y. Johnuniq (talk) 09:55, 10 January 2015 (UTC)

Thanks. Peter Horn User talk 21:49, 10 January 2015 (UTC)

International petroleum units

I think I've mentioned this before, but there is a gap in the Convert template that does not cover common petroleum units. Of course, the easy conversions of barrels of oil to cubic metres are handled,e.g. the oil tank contained 800 barrels (130 m³) and the oil well produced 800 barrels per day (130 m³/d).

Barrels versus tonnes

Barrels applies mostly to US oil companies who historically shipped oil in standard size barrels. Standard Oil (an oil monopoly) established the US standard because it controlled the US market and shipped its Standard size blue barrels (bbl) of 42 US gallons on railroads which it controlled. OTOH, European companies such as BP and Shell shipped oil from overseas by tanker, and so they would measure the amount in tons, originally long tons, today tonnes (sp=US = "metric tons"). The problem is barrels are a volume measure, while tonnes are a mass measure. To do the conversion, you need to know the density.

Canada, where I worked most of my careeer, was on the metric system, so it was dead simple: tanker trucks roared into the separation plant at a rate of 1 per minute, weighed in at e.g. 40,000 kg; while the truck was being weighed the driver ran into the office with an oil sample; ran it through the analyzer and found its density was, e.g. 900 kg/m3, the driver dumped his oil and weighed out empty at, e.g. 10,000 kg, so the total weight of oil was 30,000 kg. The computer did all the math and found the total volume of oil was 30,000/900 = 33.3 m3. The conversion factor from m3 to bbl is x 6.29 = 209 barrels of oil. Drop the decimal places because you can't really measure crude oil accurately. Amount in US units = 209 barrels, in European units, 30 tonnes. Simple.

However using US units, it gets a lot more complicated because the American oil companies (and other oil people) use API gravity.

API gravity versus specific gravity

API gravity is really an inverted density scale invented by the American Petroleum Institute a century or so ago based on a French standard for measuring wine, the Baume scale. Wikipedia needs to handle this because it is the most common standard for measuring oil density world wide.

API gravity, in degrees API (°API), can be converted to specific gravity by SG = 141.5 / (API + 131.5), and the reverse API = (141.5 / SG) - 131.5. (the xx1.5 is because of an error in the first batch of densometers, which the API correcting by modifying the standard rather than recalling the densometers.) Specific gravity (SG), also known as relative density (RD) I don't think is handled by Convert, nor does it handle conversions from the SI density standard of kilograms per cubic metre (kg/m3) or the scientific standard of grams per cubic centimetre (g/cm3). Specific gravity and relative density are dimensionless ratios, so they are unitless.

Once you know the specific gravity or density the conversion from American to European units is easy. There are a number of different oil benchmark standards worldwide:

• West Texas Intermediate (WTI): API gravity = 39.6 °API; specific gravity = 0.827
• UK North Sea Brent blend (Brent): API gravity = 38.06 °API; specific gravity = 0.835
• OPEC oil basket blend (OPEC): API gravity = 32.7 °API; specific gravity = 0.862
• Western Canadian Select (WCS): API gravity = 20.5 °API; specific gravity = 0.930
• Alberta oil sands bitumen: API gravity = 8 °API; specific gravity = 1.014

The global average these days is around 32 °API; specific gravity = 0.865 because the world oil supply is getting heavier as the light oil is used up.

Proposed Convert additions

Take a typical oil industry article, e.g. API gravity:

Crude oil is classified as light, medium or heavy, according to its measured API gravity.

• Light crude oil is defined as having an API gravity higher than 31.1 °API (less than 870 kg/m³)
• Medium oil is defined as having an API gravity between 22.3 °API and 31.1 °API (870 to 920 kg/m³)
• Heavy crude oil is defined as having an API gravity below 22.3 °API (920 to 1000 kg/m³)
• Extra heavy oil is defined with API gravity below 10.0 °API (greater than 1000 kg/m³)

or:

Crude oil with API gravity less than 10 °API is referred to as extra heavy oil or bitumen. Bitumen derived from the oil sands deposits in the Alberta, Canada area has an API gravity of around 8 °API. It can be diluted with lighter hydrocarbons to produce diluted bitumen, having an API gravity of lower than 22.3 API, or further "upgraded" to an API gravity of 31 °API to 33 °API as synthetic crude.

or SS Torrey Canyon:

SS Torrey Canyon was an LR2 Suezmax Class oil tanker with a cargo capacity for 120,000 tons of crude oil. She was shipwrecked off the western coast of Cornwall, England in March 1967, causing an environmental disaster. At that time she was the largest vessel ever to be wrecked.

or Amoco Cadiz:

Amoco Cadiz contained 1,604,500 barrels (219,797 tons) of light crude oil from Ras Tanura, Saudi Arabia and Kharg Island, Iran. Severe weather resulted in the complete breakup of the ship before any oil could be pumped out of the wreck, resulting in her entire cargo of crude oil (belonging to Shell) and 4,000 tons of fuel oil being spilled into the sea.

Convert should be able to handle these conversion automatically without the author having to work through it on a calculator. It should do density conversions from API to SG or RD, kg/m3, and g/cm3. It should provide an "API=xx.x" option to given the density for conversions of oil volume (bbl, m3) to oil mass (tonnes, long tons, short tons) or vice versa. It should have an "oil=WTI or Brent or light or heavy or medium or OPEC or world" option to select standard benchmark densities, with a default of "world". What do you think? RockyMtnGuy (talk) 20:23, 10 January 2015 (UTC)

That looks interesting. A problem is that even if convert handled all the issues raised, would general editors be able to use it, or would it lead to cases of "the computer output this so it must be correct"? That is, a general editor can safely do things like convert kg to oz, however, because oil measurements are more complex, they may blunder by entering bogus inputs into convert to produce impressive-looking but invalid outputs? At any rate, putting my doom-and-gloom to one side, please make a list of examples that cover everything wanted. There is no need to worry about the syntax—just put whatever seems reasonable and we can think about details later. Before trying to digest the above I would want to understand what convert would see and what outputs it would have to produce. In other words, what might "density conversions from API to SG" look like in a convert (an example like {convert|12|X|Y} with wanted output)? Johnuniq (talk) 21:26, 10 January 2015 (UTC)

Have you had a chance to look at {{bbl to t}}? Perhaps it could use some brushing up (it only does bbl to t, not the reverse, m3 isn't included and it doesn't convert densities) but it's a start. Jimp 14:17, 11 January 2015 (UTC)

Hi Jimp. I believe we discussed {{bbl to t}} in the past. It's okay as far as it goes, but it doesn't go far enough so it's not generally useful for all these petroleum articles. Bills of lading that I seen for tankers state the amount of oil in tonnes, long tons, barrels, and cubic metres. This makes them generally useful worldwide because tankers might pick up and deliver oil anywhere on the planet.

As for the issue of general editors using it, even New York Times and Washington Post editors don't understand this stuff and often get it wrong, so we have to make some decisions for Wikipedia editors. If in doubt, you can default to the world average which is about 32 degrees API (specific gravity 0.865; 865 kilograms per cubic metre). However, if editors don't like that they could use a parameter such as "oil=OPEC" which might give the official OPEC average of 32.7 °API (862 kg/m3). The difference is not material. You can't measure crude oil very accurately because it contains significant amounts of salt water, sand, and dissolved gasses in addition to petroleum of varying qualities. They call it "crude" for a reason. Examples:

• Amoco Cadiz contained 1,604,500 barrels (219,797 tonnes) of light crude oil... {Convert |1,604,500 |oilbbl |t |oil=light} ... In reality there are far too many significant digits there - my physics professors would have deducted marks for an answer like that.
• Torrey Canyon had a cargo capacity of 120,000 tonnes (650,000 barrels) of oil... {Convert |120000 |t |oilbbl}... No oil grade - use world average.
• WTI is a light crude oil, with an API gravity of around 39.6 degrees API (specific gravity 0.827). {Convert |39.6 |API |SG}
• Western Canadian Select is a heavy crude oil with an API gravity level of between 19 to 22 degrees API (940 to 922 kg/m3)... {Convert |19 |to |22 |API |kg/m3} ... note that API is an inverted density scale.
• API gravity is a measure of how heavy or light a petroleum liquid is compared to water: if its API gravity is greater than 10 degrees API (specific gravity 1.0), it is lighter and floats on water; if less than 10, it is heavier and sinks... {convert |API |SG}}
• Orimulsion contains raw bitumen which has an extremely high viscosity and specific gravity between 8 to 10 degrees API (SG 1.014 to 1.000)... {Convert |8 |to |10 |API |SG}... Note that the article called it "specific gravity", and then gave it in degrees API.

Anyhow, that's a start, syntax approximate. There are lot more articles like these. RockyMtnGuy (talk) 16:09, 11 January 2015 (UTC)

I was thinking that we'd discussed {{bbl to t}} before. If {{bbl to t}} doesn't go far enough, there are a couple of options; {{convert}} could take up the slack, {{bbl to t}} could be extended or we could do a bit of both. I think I'd be leaning toward the third of these options. Currently {{convert}} only does conversions within the same dimension (or it's inverse, e.g. mpg to l/100 km). To break with that, it seems to me, would be more trouble than it's worth. So keep conversions from volume to mass and vice versa separate but I can't see why we shouldn't add API and SG to {{convert}} (though technically dimensionless they can be directly converted to density units). Then {{bbl to t}} could be extended to go the opposite direction (from mass to volume) and extra units (long tons, m3, etc.) could be added. Perhaps a new name would be appropriate (if if's doing more than converting barrels to tonnes). Jimp 06:21, 12 January 2015 (UTC)

That's true, although anything is possible, and I was wondering if the "offset" from temperature conversions could be press ganged into service, with the inverse feature. I'm just collecting information to clarify what would be needed at the moment, without approaching any kind of view about what to do. Johnuniq (talk) 07:15, 12 January 2015 (UTC)

Oil options

You mentioned:

• Option "API=n" where n is a number like 39.6
• Option "oil=w" where w is a word: WTI, Brent, light, heavy, medium, OPEC, world
• The default is oil=world

What about WCS and Alberta? Are they acceptable oil words?

Is oil=w merely a way of specifying API=n? In that case, do not have option "oil". Instead, allow API to be a number or one of the defined words. The word/number equivalences are:

• oil=WTI: API=39.6
• oil=Brent: API=38.06
• oil=light: API=?
• oil=heavy: API=?
• oil=medium: API=?
• oil=OPEC: API=32.7
• oil=world: API=32
• oil=WCS: API=20.5
• oil=Alberta: API=8

Options are case-sensitive. What about making them all lowercase for simplicity (wti, brent, opec not WTI, Brent, OPEC)?

The option "API" may be dubious because only specialists would think that referred to oil. Perhaps make the option oil with examples oil=39.6 or oil=opec. Please provide a fixed list of equivalences. Johnuniq (talk) 07:15, 12 January 2015 (UTC)

Negative exponents

When adding {{convert}} to the Moon article, I failed to work out how to set up the template to cope with negative exponents for scientific notation for atm (3 × 10⁻¹⁵atm at Moon#Atmosphere), or indeed negative exponents at all when I tried to test it (the documentation makes no mention that I can find and I've not managed to find an article that uses it either). Thryduulf (talk) 21:03, 11 January 2015 (UTC)

Sorry, that's on my TODO list and won't be soon. The issue is that convert does not format the number entered as input apart form inserting commas. It will format the output, but it chooses to use scientific notation when the value is very small or large. The first of the following demonstrates that point, while the second is a gigantic kludge which happens to work:

• {{convert|3e-15|atm|atm|abbr=on}} → 3×10⁻¹⁵ atm (3.0×10⁻¹⁵ atm)
• {{convert|0.3|nPa|atm|abbr=on|order=flip|sigfig=1}} → 3×10⁻¹⁵ atm (0.3 nPa)

For the future, I was thinking of seeing how much work would be involved in formatting an input number like 3e-15 in scientific notation, and I would like some way for the user to control when the output uses scientific notation. Perhaps it could follow the rule that if the input uses e-notation, then the input and output should use scientific notation...although there probably should be a range of values where normal decimals are used such as 0.1 to 99.9. Johnuniq (talk) 01:25, 12 January 2015 (UTC)

{{Rnd}} is still managing. {{rnd|3e-15|15}} → "3×10⁻¹⁵". Jimp 06:27, 12 January 2015 (UTC)

Added to /documentation, saying it's incomplete. (Thryduulf should not have been lost in searching).

Some background: I note that Scientific_notation#Normalized_notation mentions the "one integer digit" rule, with exponent to follow. {{convert}} (and {{rnd}}) apply this too:

{{convert|34.5e-15|atm|atm|abbr=on}} → 34.5×10⁻¹⁵ atm (3.45×10⁻¹⁴ atm)

This leaves behind the "3-fold exponent" (3-6-9-...) we use in engineering notation. I made that show in the example (a 10¹⁵ does not). {{rnd}} has some spacing issue I did not research yet. -DePiep (talk) 09:28, 12 January 2015 (UTC)

...but I did manage to find a -future- {convert} issue ;-). So far, five number notations are relevant: scientific (SciNot), engineering (EngNot), single number full decimal (PlainDec), SI-prefixed, fractions (Frac). Scientific notation notes the fine point that EngNot always corresponds with an SI prefix (and so with spoken value "picoPascal", while SciNot 1×10^-8 does not). A priori I assume that the current EngNot form (add a "e6" prefix to the unit) will be covered too (add "e6" to the input number).

So if and when {convert} starts (re-)formatting input values, it should cover EngNot, SciNot, SIprefixed, PlainDec, Frac. BTW, "formatting" is about notation here, not about spaces or correct slash character &tc.

Basic rule could/should be that input notation = output notation. Plus a big-number-rule can apply (as it does now). Then {convert} could have a (new) parameter to set one of the other options. There also can be a need to change notation between input and output (I hope with sound and uncomplicated reasoning).

Now, the user input "3×10¹²" or "3.1×e12" is ambiguous wrt SciNot or EngNot. This requires a default plus again the parameter set option.

Note that these are thoughts to make the module more universal, and less dependent on (old) conventions & tricks. I also note that any big change will not happen soon, as J noted -- no problem. (I'm just seeding the thinking here). -DePiep (talk) 10:10, 12 January 2015 (UTC)

Just mentioning for the archives: {convert|17|μm|m|abbr=on}} → 17 μm (1.7×10⁻⁵ m) -DePiep (talk) 10:54, 16 January 2015 (UTC)

Thank you all for the replies. I've just left the article as-is for now - is there a list anywhere of changes that are known to be awaiting features so that they can be found and fixed when that feature arrives? Thryduulf (talk) 12:54, 12 January 2015 (UTC)

No, there is no such list. There are thousands of converts with invalid options (mainly typos like abr=off instead of abbr=off), and I occasionally contemplate finding and fixing them. Johnuniq (talk) 22:29, 12 January 2015 (UTC)

Well changing abr=off (or abr=of as I originally typed) to abbr=off seems like the sort of thing that AWB or a bot could take care of, leaving humans free to sort out things that do require humans. Thryduulf (talk) 02:51, 13 January 2015 (UTC)

Johnuniq, I think Thryduulf asked if a list of "planned features" exists (I think: only in this page's archives, as scattered sections). While typos you mention could be listed in a new maintenance category: "Articles with unrecognized convert parameters". -DePiep (talk) 08:43, 13 January 2015 (UTC)

That's right: we don't have a planned features list. Re warnings: we just need to add |warnings=1 to {{convert}} to enable level-1 warnings. That will show all broken options in articles and list pages in Category:Convert invalid options. However, the code does not detect unused numbered arguments (for example, {{convert|1|m|ft|hello}} gives no warning, but {{convert|1|m|ft|hello=on}} does give a warning). We can't use |warnings=2 because that also displays warnings for missing options like |abbr= but there are several templates that call convert with empty options. Johnuniq (talk) 09:14, 13 January 2015 (UTC)

I forgot that option. I guess some time in the future you'll activate that category for another cleanup, maybe with those numbered params added. No request from me. -DePiep (talk) 09:40, 13 January 2015 (UTC)

Change in2 and in3

Currently the unit in2 is an alias for sqin and has the symbol sq in. Similarly, in3 is an alias for cuin and has the symbol cu in.

I'm proposing that be changed as in the following (which uses fixed wikitext for the results):

Convert	Current output	Proposed output
{{convert|1.2|in2|abbr=on}}	1.2 sq in (7.7 cm2)	1.2 in2 (7.7 cm2)
{{convert|1.2|in3|abbr=on}}	1.2 cu in (20 cm3)	1.2 in3 (20 cm3)

That would be similar to unit lbf/in2 which has symbol lbf/in².

There are around 25 articles using in2 in a convert, and 120 using in3. I looked at a couple and it seems that in² and in³ might have been wanted at least in some cases. Where that isn't wanted, the converts could be changed to use sqin or cuin.

This arose from considering #Another unusual one, horsepower per cubic inch above where a unit with symbol hp/in³ is wanted. I'm thinking that the unit code should be hp/in3 to make that clearer, rather than the hp/cuin proposed. Of course nothing is ever simple, and it's only about two-thirds of cases where editors have chosen to use hp/in³; the rest use hp/cu in. It's not clear whether the latter was used because of its simplicity, or whether it was really wanted. Any thoughts? Johnuniq (talk) 02:16, 2 January 2015 (UTC)

So, this keeps input options sqin, in2 (I talk squares only for simplicity), for both straight and compound (/) input.

Then, the output shows sq in, or in2, following that input (is a change).

but in a compound, it always shows in2 (a change).

• (I assume, this applies to all inn units; same for ftn?, in2, in3 and ft2, ft3. Any other imperial units? I hope this list will not need exceptions).
• This I find an unneeded complication: "do so for straight units, but change behaviour in compound units". For the editor, this behaviour change is not to be understood. Yes it can be described (documented) correctly, but that does not count as a clarification for the editor. Simply: if we find "sq in" an acceptable unit symbol, then "Pa/sq in" is acceptable too. At least it would require to check *not* what is used in enwiki (or, worse, what we think was intended in enwiki), but what is used in the sources. Put this way: if the editor sees "Pa/sq in" in the source, why change that by {convert}?

So, the switch in behaviour proposed should be based on very convincing practice in the sources. When doubt, it should allow two-way output in both circumstances: editors responsibility. (Or, third source outcome possible, don't output "sq in" altogether). Maybe needs MOS-approach. -DePiep (talk) 11:19, 2 January 2015 (UTC)

I have to agree with DePiep here. Unexpected switches in behaviour are just going to cause confusion (we can find ample examples of this in the template (past and present) for many of which I can take the blame). The template is already complicated enough, it might be best to avoid making it more so if there's no real gain. Jimp 03:43, 5 January 2015 (UTC)

Currently, lbf/in2 uses the superscripted symbol I mentioned, and it seems to me that it would be more consistent for people to use "in2" when they want in², and "sqin" when they want sq in. I looked at some May 2014 articles where I saw some bird articles with a volume converted using cm3 and in3, and it looked to me as if they would have preferred "in³" rather than "cu in"—see "a passenger pigeon needed to eat about 3.7 cu in (61 cm³) of food a day" in Passenger pigeon#Diet for example. Later, I'll have a look in the January 2014 2015 articles to get a better idea. Johnuniq (talk) 04:53, 5 January 2015 (UTC)

re Johnuniq: Your first sentence says what I tried to say: why you enter form A, it shows form A - full stop. No switch to form B. About your second sentence: "they would have preferred" is not enough. If {convert} does a switch from form A-input to form B-output, it should be MOS-based. (similar issue exists with "*" and "by" range separator - unbased form change by {convert}). -DePiep (talk) 10:23, 5 January 2015 (UTC)

re Jimp: for me, the 'confusion' Jimp mentions is on the editors side, not the Lua-programmers side. It is what I named 'easy to document well'. -DePiep (talk) 10:23, 5 January 2015 (UTC)

What does MOS say about in³? Johnuniq (talk) 10:36, 5 January 2015 (UTC)

Don't know, didn't look. I'm saying: if {convert} applies a change-of-form rule, it must be MOS-based. Either an existing rule or to be created (asked for). -DePiep (talk) 10:50, 5 January 2015 (UTC)

This topic has been discussed in the past a few times. For U.S. Customary/Imperial units, it has always been the winning argument that 1.) sq and cu (e.g.. sq in and cu in) are the most common way of writing these types of measurements, and 2.) writing the conversion of units when both are abbreviated would give a strong contrast between measurement systems: 1,500 cu ft (43 m³). At one time there was a similar argument, whereby if an editor wanted to use sq ft (or similar) as the abbreviation then sq m should be used for the metric unit. Seeing this debate pop-up from time to time over the years, I still oppose changing this. —MJCdetroit ^{(tell me)} 04:55, 21 January 2015 (UTC)

There will be no change for how convert handles sqin and cuin (they will continue to show symbols sq in and cu in). The aim is to support in² and in³ for cases where that is needed. The existing unit lbf/in2 already outputs lbf/in² as the symbol, and the new unit hp/in3 will output symbol hp/in³ (the new unit would replace the manually typed wikitext, for example, here). I found quite a few articles where the superscripted symbol is wanted, for example Holden Monaro#HK has a few like "161 in³ (2.6 L)" in the infobox (it does not use convert). Johnuniq (talk) 06:45, 21 January 2015 (UTC)

Tables: line break

I've had a quick look at some of the converts in articles at 12 January 2015. What do people think of the following?

• Convert has |disp=br which inserts a line break without parentheses between the input and output (example ("Elev.")).
• Some articles use wikitext like |disp=x| <br/>(|) which inserts a line break and parentheses (example 1, example 2, example 3).
• One article uses parentheses and <small> for the output (here).

I'm wondering whether convert should add an option to make these easier:

• |disp=br for line break without parentheses (this exists)
• |disp=br() or (not both!) |disp=(br) for line break with parentheses (possible new option)
• Don't bother supporting <small>?

Or, should these variations be discouraged, or at least not supported by convert? Johnuniq (talk) 04:31, 21 January 2015 (UTC)

IMO:

Keep disp=br.

Add disp=br() as described. Not disp=(br), looks plain incorrect to me.

A genuine need in tables. In spinoff {{Track gauge}} I added this option for the same reasons. It also may be useful in infoboxes (with {{convert}} in template code; don't know if this is correct layout though).

|x|...= remains the same, I assume, for other situations.

To consider. The options for |disp= are: b (the default), sqbr, comma, or, br, x|... (this should be the complete list). Maybe add in the same spirit: |disp=br[], |disp=br,, |disp=bror?

Is there any other predictable use of x-double-input: |disp=x| <br/>(|) it could cover?

About: <small>. Don't bother indeed. The usage example shows no urgent need for this. It may even be called bad formatting, for font-size should not be used this way without good reason. Note that in mobile view, the small print disappears (font shows regular size), so it can not convey any information, just illustration then. I learned from EDokter to be suspicious with inline formatting always.

So, don't bother. Status should be: not documented (even it is seems to work), no promises, "not supported". This for any tag (<br/> an exception). But no need to strip tags either (Lua cannot anyway).

-DePiep (talk) 08:16, 21 January 2015 (UTC)

Watts

The article Solar energy refers to various derivatives of Watts—kilowatts (kW), megawatts (MW), gigawatts (GW), terawatts (TW), petawatts (PW). At one point, kW are converted to horsepower (HP) and TW are compared with exajoules (EJ), but otherwise the various figures given are not converted. It appears that {{convert}} does not handle these units, only kWh and so on. Are there any equivalent units that should be given in these cases? —sroc 💬 14:29, 21 January 2015 (UTC)

Module:Convert/documentation/conversion data/doc has all available units. #Power is about W and hp.

this section says Watt kan have all the SI-prefixes (name & symbol).

Here they are (note: |abbr=~ is used here to return both name and symbol; convenience/clarity only):

{{convert|100|W|hp|abbr=~}} → 100 watts [W] (0.13 hp)

{{convert|100|MW|hp|abbr=~}} → 100 megawatts [MW] (130,000 hp)

{{convert|100|TW|hp|abbr=~}} → 100 terawatts [TW] (1.3×10¹¹ hp)

"hp" does not take prefixes:

{{convert|100|MW|Mhp|abbr=~}} → 100 megawatts [MW] ()

I think one can not convert TW (Watt) into EJ (Joule), for being power vs. energy. However, Wh and J do match:

{{convert|100|Wh|J|abbr=~}} → 100 watt-hours [Wh] (360,000 J)

{{convert|100|GWh|EJ|abbr=~}} → 100 gigawatt-hours [GWh] (0.00036 EJ)

Does this clarify? All this may not be easy to find, I could agree. Some day, I hope to create an easy-to-search unit documentation ("Watt" should give a hit).-DePiep (talk) 16:24, 21 January 2015 (UTC)

Ah, I see my problem now:

{{convert|45|–|52|KW|hp}} → 45–52 KW

{{convert|45|–|52|kW|hp}} → 45–52 kilowatts (60–70 hp)

Thanks! —sroc 💬 03:27, 22 January 2015 (UTC)

I've added a warning to the top of the documentation page about this case-sensitivity. The issue appears on this talkpage quite regularly (and that is just top of the iceberg editors). -DePiep (talk) 08:34, 22 January 2015 (UTC)

Fathom symbol

Fathom states that ftm is the abbreviation (symbol) for fathom, and a recent edit has replaced convert's fathom with ftm. I don't have an opinion on that, but I think such changes should be mentioned here in case anyone has an opinion. The change would affect about 80 converts, for example:

• Atlantic Ocean {{convert|3926|m|fathom ft}} → 3,926 metres (2,147 fathoms; 12,881 ft) → 3,926 metres (2,147 ftm; 12,881 ft)
• Geography of the Falkland Islands {{convert|200|m|fathom}} → 200 metres (110 fathoms) → 200 metres (110 ftm)
• Labrador Sea {{convert|100|–|200|m|fathom ft|abbr=on}} → 100–200 m (55–109 fathoms; 330–660 ft) → 100–200 m (55–109 ftm; 330–660 ft)

If anyone wanted "fathoms" instead of "ftm", they would use the appropriate option such as abbr=off, although that would also spell out "feet" rather than "ft", not a problem. Johnuniq (talk) 00:18, 27 January 2015 (UTC)

Not clear yet. Does this say that somehow the symbol is used where name is expected/intended, or v.v.? (that, I would oppose) -DePiep (talk) 00:52, 27 January 2015 (UTC)

The examples show the change, but they need an explanation: each shows a convert from an article; the output after the first right-arrow is what convert currently displays; the output after the second right-arrow shows what convert would display given the change to the unit. The first example shows that "2,147 fathoms" would become "2,147 ftm". Johnuniq (talk) 01:14, 27 January 2015 (UTC)

I get it. more here about the ~-prefixed code. -DePiep (talk) 16:58, 28 January 2015 (UTC)

January 2015 all articles dump

I have just downloaded the 2015-01-12 "all articles" dump (which only became available in the last 24 hours). I'll examine the converts as discussed, although that might take a few days. Meanwhile, here are some stats: in the 2014-05-02 dump (255 days ago) there were 1.77 million converts in 462 thousand articles. That is now 1.90 mill+ion converts in 492 thousand articles. I find it hard to believe, but that means 510 converts are added to articles per day, and 122 articles have their first converts added per day. These number only include {{convert}} templates—there are lots of others from things like infoboxes and {{height}}. Johnuniq (talk) 10:43, 16 January 2015 (UTC)

More stats: with 698,034 pages transcluding (all ns), that is 492k/698k = 70.4% in articles. Or, 200k+ in non-articles. And 1900k/462k = 3.9 {{convert}}s average per converting article. -DePiep (talk) 11:11, 16 January 2015 (UTC)

And right now the counter has hit 700000 pages with a {{convert}} (all namespaces). Since my previous post here (January 16), that's +1966 pages in 12 d 8 h 35 min or +159 pages/day or ~1 page/9 min. -DePiep (talk) 18:26, 28 January 2015 (UTC)

Scientific notation

Per the discussion at #Negative exponents just above, I have implemented the suggestion to transform input like 1.2e3 to scientific notation. Example:

• {{convert/sandbox|3e-15|atm|nPa|abbr=on|lk=on}} → 3×10⁻¹⁵ atm (0.30 nPa)
• {{convert/sandbox|3e-15|atm|nPa|1|abbr=on|lk=on}} → 3×10⁻¹⁵ atm (0.3 nPa)

@Thryduulf: This is in the sandbox for testing, and will be live in a couple of weeks. Johnuniq (talk) 04:01, 20 January 2015 (UTC)

More details: When the input uses e-notation, the input value is displayed as a power of ten, and the output is displayed in scientific notation, except that an output value satisfying 0.01 <= v < 1000 is shown as a normal number. In addition, if the output value is 1000 and sigfig=4 is used, the value is displayed as a normal number.

• {{convert/sandbox|0.000123e1|m|m}} → 0.000123×10¹ metres (1.23×10⁻³ m)
• {{convert/sandbox|0.00123e1|m|m}} → 0.00123×10¹ metres (0.0123 m)
• {{convert/sandbox|0.0123e1|m|m}} → 0.0123×10¹ metres (0.123 m)
• {{convert/sandbox|0.123e1|m|m}} → 0.123×10¹ metres (1.23 m)
• {{convert/sandbox|1.23e1|m|m}} → 1.23×10¹ metres (12.3 m)
• {{convert/sandbox|12.3e1|m|m}} → 12.3×10¹ metres (123 m)
• {{convert/sandbox|123e1|m|m}} → 123×10¹ metres (1.23×10³ m)
• {{convert/sandbox|1e3|m|m}} → 1×10³ metres (1.0×10³ m)
• {{convert/sandbox|1e3|m|m|sigfig=4}} → 1×10³ metres (1,000 m)

The following demonstrates that rounding the input works.

• {{convert/sandbox|2.3456e6|m|m}} → 2.3456×10⁶ metres (2.3456×10⁶ m)
• {{convert/sandbox|2.3456e6|m|m|adj=ri2}} → 2.35×10⁶ metres (2.3456×10⁶ m)

In a range, any e-notation switches the output to scientific notation.

• {{convert/sandbox|1000|-|2500|m|m}} → 1,000–2,500 metres (1,000–2,500 m)
• {{convert/sandbox|1000|-|2.5e3|m|m}} → 1,000–2.5×10³ metres (1.0×10³–2.5×10³ m)

Examining all converts in articles at 12 January 2015 shows only four usages of e-notation. Two of those were not intended and were better expressed another way, and I have edited the articles concerned to fix them. That means there is only one article Silverton Tramway using e-notation. The following shows the relevant converts in the article using convert/sandbox to show how it behaves (convert gives the same result):

• {{convert/sandbox|90e6|t|sigfig=3|spell=in}} → ninety million tonnes (88,600,000 long tons; 99,200,000 short tons)
• {{convert/sandbox|19e6|km|mi|spell=on}} → nineteen million kilometres (twelve million miles)

The article is using 90e6 as a convenient and reliable way to say 90,000,000, and scientific notation is ignored when spelling is in effect.

The input number is used as given—it is not normalized, and so the result is only valid scientific notation if valid input is used.

• {{convert/sandbox|12.3e-6|m|m}} → 12.3×10⁻⁶ metres (1.23×10⁻⁵ m)
• {{convert/sandbox|12.3e6|m|m}} → 12.3×10⁶ metres (1.23×10⁷ m)

I decided that it was better to use the input as given because it puts editors in control of the process—if proper scientific notation is wanted, use the correct input. I have also finished "automatic per units" and it is in the sandbox, and will post again (in a day or two) with a little more detail about updating the module to make this live. Johnuniq (talk) 04:25, 20 January 2015 (UTC)

Great! We need bigger barnstars. So this is what you do when you have "not much time" ;-) -DePiep (talk) 07:03, 20 January 2015 (UTC)

btw, in later stages, you think we should deprecate and delete "e6m" unit input options? -DePiep (talk) 07:04, 20 January 2015 (UTC)

The engineering notation units like e6m are used quite a lot as they are good for saying "million":

• {{convert|12.3|e6m|e6m}} → 12.3 million metres (12.3×10^⁶ m)
• {{convert|12.3|e6m|e6m|abbr=off}} → 12.3 million metres (12.3 million metres)

Johnuniq (talk) 09:59, 20 January 2015 (UTC)

Thank you for your work on this! Thryduulf (talk) 10:16, 20 January 2015 (UTC)

Side issues

It looks pretty good. It does, though, remind me of a couple of things wrong with the template as is currently is.

• {{convert/sandbox|2.3456e6|m|m|adj=ri2}} → 2.35×10⁶ metres (2.3456×10⁶ m)

How are the plans going with respect to getting rid of this type of abuse of the adj parameter? We probably need (a) new parameter(s) for input rounding.

• {{convert/sandbox|19e6|km|mi|spell=on}} → nineteen million kilometres (twelve million miles)

spell=on should override the abbreviation of the output unit; beside being against the MOS, "twelve million mi" is just hideous.

A bit off-topic but you know, it's has to be mentioned. Jimp 05:50, 20 January 2015 (UTC)

Jimp, off topic indeed! -DePiep (talk) 06:05, 20 January 2015 (UTC)

Yeah, adj=ri2 is not ideal, but I was just showing off! Searching the all-articles dump shows that the option is only used once, at Muisca raft, so fixing the terminology can wait:

• {{convert|{{#expr: .798 * 287.5}}|g|ozt|adj=ri0|sigfig=3|abbr=off|order=flip}} → 7.38 troy ounces (229 grams)

I also agree about the hideous "(twelve million mi)". I might think about that... Johnuniq (talk) 09:59, 20 January 2015 (UTC)

Minor scream in the dark

I have just now for the first time realized that the table sorting REQUIRES numbers either to be written out or to be in 2e14 syntax, whereas the convert can only take 2e14 as input and generate either written out or x10^14 syntax.

That's external software we import, I think. Is there any chance (not having looked at the template code here, and not having time to today) that we could offer an output mode which output in the 2e14 format so that tables will sort correctly again?...

Georgewilliamherbert (talk) 04:06, 27 January 2015 (UTC)

I have to go somewhere soon, and am up to my neck in an irritating debugging problem unrelated to convert, and am really annoyed by Arbcom's current nonsense (I saw your excellent comment before noticing this, thanks!). What I'm saying is that I can't think at the moment, but will fix whatever the problem is. I guess it's Young's modulus, but you might have to spell out exactly what you want convert to do. At any rate, are you aware that the following should generate a sort key even though it's only displaying the output?

• {{convert|32100|GPa|psi|precision=3|disp=number|sortable=on}} → 4.66×10⁹

You can put that convert into Special:ExpandTemplates to see exactly what it outputs.

The problem is that convert's idea of a sort key might not agree with what {{val}} outputs, and all the sort keys would have to be compatible. Will look later. Johnuniq (talk) 04:32, 27 January 2015 (UTC)

Aha. That may do it...

That table ( Young's Modulus for those following along at home) has numerous problems; I am going to have to fix the totality of the values by finding the units in the source, then converting the other side to match. I started with Carbyne because it was at the bottom (and, as it happened, got the value wrong from the source when I looked, but who knows). So sort keys being compatible should eventually happen.

Well, it does introduce a glitch, that I will also have to use convert and output the source with the sortable tag on, to get the scientific and sortable notations in the original units if they were entered from the source in scientific notation. But I can do that. The prolific use of val is not necessary.

It still would make sense to see if we could align default behavior of the template with the tables, so the secret magic of the sortable=on was not needed, but it's not urgent if I can work around.

Thanks! Georgewilliamherbert (talk) 04:45, 27 January 2015 (UTC)

@Georgewilliamherbert: I just started looking at using convert with some clever features but will have to go again soon. Meanwhile I notice the article has changed. I was going to put something like the following in most places. It would replace the two lines that are currently there.

{{convert|19-27<ref>Hello world!</ref>|GPa|e6lbf/in2|sigfig=3|disp=tablecen|sortable=on}}

Johnuniq (talk) 07:06, 27 January 2015 (UTC)

I actually prefer having two lines. It makes it easier to tag which one was the source unit, which has been a perennial failure mode of updates. With the way it is now it's stunningly obvious (including my comments) which units the source used...

Georgewilliamherbert (talk) 21:19, 27 January 2015 (UTC)

Fine, particularly since I noticed one example with two references on the input value and convert only handles one reference embedded with the value. The above example I posted gives a great result, but it is hard to make it work for all the variations in the table in question. By the way, the convert procedure for showing which value is in the reference is to always put that value as the input, then use |order=flip if it is wanted as the output. Some weird options can be applied to round the input where necessary, but it quickly becomes a nightmare in complex cases. Following is an example which won't look very attractive since it's not in a table, but it shows the idea.

• {{convert|19-27<ref>Hello world!</ref>|GPa|e6lbf/in2|sigfig=3|disp=tablecen|sortable=on|order=flip}} →

style="text-align:center;" data-sort-value="7010190000000000000"|2.76–3.92 million |style="text-align:center;" data-sort-value="7010190000000000000"|19–27

References

I'm just mentioning order=flip in case it is news, but if it were used in a mixed table, use of sortable=out might be needed instead of sortable=on (which is the same as sortable=in). Explanation on request. Johnuniq (talk) 22:04, 27 January 2015 (UTC)

I think I need to run off to a test page for a while. And I don't entirely understand at the moment, but, that's what time and experimentation and questions are for.

Thanks! Georgewilliamherbert (talk) 22:06, 27 January 2015 (UTC)

In the long run, I am unhappy with the reference setup this way. It shows well in an instance or two, but not in general. And once it is in a parameter, it can not be separated any more (ref tags are processed before Lua sees & handles an input string). First thought is to use a parameter |ref=<ref>Hello moon</ref> (that can be positioned where it is right). For non-standard situations there could be |ref1=, like in ranges of when flipped. -DePiep (talk) 19:33, 28 January 2015 (UTC)