Template talk:Convert/Archive February 2010

Reminder for fraction/color codes use disp=output only

01-Feb-2010: This is another reminder that the option "disp=output only" has been available for over 3 months, to show results only. Users who prefer to put fraction-characters in numerals, or mix words plus digits, or change colors (etc.), can get the result as separate text by setting "disp=" as follows:

• {{convert|1+1/2|m|ft|disp=output only}}   gives:   4.9 ft
• {{convert|1+1/2|m|ft|abbr=in|disp=output only}}   gives:   4.9 feet
• {{convert|1+1/2|m|ft|abbr=out|disp=output only}}   gives:   4.9 ft
• {{convert|1+1/2|m|ft|abbr=none|disp=output only}}   gives:   4.9 feet

Inserting the option disp=output only (or disp=output number only) allows mixing fractions, words plus digits, setting colors, etc.

• this board is 8¼ feet ({{convert|8+1/4|ft|m|disp=output only}}) long
• The pool is 9 and ½ feet deep ({{convert|9+1/2|ft|m|disp=output only}}).
• a green sign noted "<font color=darkgreen>25 mph</font>" ( {{convert|25|mph|km/h|disp=output only}})
• a green sign noted "25 mph" (40 km/h).
• the astronaut stated, "The crater is 357.5 meters wide [{{convert|357.5|m|ft|disp=output only}}]"

Remember to insert parentheses, or other separators, in the resulting output text, as needed, for the phrase or literal quotation. -Wikid77 (talk) 13:34, 1 February 2010 (UTC)

What happened to this conversion?

Someone else can see this awful bold red text, right? It's puking all over the Everglades article. Any idea how it can be fixed? --Moni3 (talk) 00:18, 3 February 2010 (UTC)

4,000,000 acres (16,000 km²)

Hey..wha...now it's fine. Am I going completely nuts? --Moni3 (talk) 00:57, 3 February 2010 (UTC)

There was some brief vandalism in {{Precision/10}}, it has been subsequently reverted, and the template protected. Thanks! Plastikspork _―Œ^(talk) 01:10, 3 February 2010 (UTC)

Temperature conversion problem

The template seems to have a problem converting 0°C to °F: 0 °C (32 °F) ReelExterminator (talk) 00:35, 3 February 2010 (UTC)

There was some brief vandalism in {{Precision/10}}, it has been subsequently reverted, and the template protected. Thanks! Plastikspork _―Œ^(talk) 01:10, 3 February 2010 (UTC)

param synonyms

Could the on/off parameters have yes/no synonyms added to them please? This simple change would certainly make this template a bit more user friendly, since it would be one fewer parameter value to remember. Thanks!
— V = I * R (Talk • Contribs) 23:15, 4 February 2010 (UTC)

Temperature conversion

Hello. I've just added {{convert|15|C|F|C-change}} to measure temperature difference, as said in Celsius-Fahrenheit conversion section above, but it doesnt work. Am i missing something? Regards. Rehman⁽⁺⁾ 01:37, 9 January 2010 (UTC)

The C and F parameters require the degree symbol for absolute temperatures - eg {{convert|15|°C|°F}} gives 15 °C (59 °F). For temperature differences do not use the C or F parameters at all - eg {{convert|15|C-change}} gives 15 °C (27 °F)  Stepho  (talk) 04:40, 9 January 2010 (UTC)

For completeness; absolute temperatures don't require the degree symbol. {{convert|15|C|F}} or {{convert|15|C}} for the default Fahrenheit works just fine. Saves finding the degree symbol every time! Bleakcomb (talk) 07:19, 9 January 2010 (UTC)

Got it. Thank you (both). Regards. Rehman⁽⁺⁾ 07:26, 9 January 2010 (UTC)

Bad terminology isn't going to help anyone understand what you are talking about. Degrees Celsius and degrees Fahreinheit are never "absolute temperatures". Absolute temperatures are temperature readings in kelvins or degrees Rankine. What Bleakcomb and Stepho are improperly calling "absolute temperatures" above are "temperature readings" (as opposed to "temperature intervals" or "temperature differences") in degrees Celsius or degrees Fahrenheit. Gene Nygaard (talk) 23:01, 5 February 2010 (UTC)

And {{convert|15|C-change|0}} gives 15 °C (27 °F) Peter Horn User talk 03:57, 10 January 2010 (UTC) Peter Horn User talk 04:00, 10 January 2010 (UTC)

I've just created the subtemplate {{Convert/K-change}} for people who work in kelvins. You can now write "The temperature of the solution is raised by {{convert|5|K-change}}" to get: "The temperature of the solution is raised by 5 K (9.0 °F)". +Angr 17:38, 15 January 2010 (UTC)

Useless as tits on a boar—and a whole lot more counter-productive

This template still has far too many options that clutter everything up, steepening the already near-impossible learning curve, and making it unnecessarily difficult to find useful information in the documentation.

For example, look at the energy units. They include "U.S. gallon-atmospheres" and "imperial gallon-atmospheres". What an incredible waste of resources! Just imagine of all the other many problems which this template has, that could have been solved or mitigated, had the creators of this incredibly complex machine not gone off on such weird tangents.

• These conversions have been here for 2¼ years
• Yet absolutely no Wikipedia articles actually use these conversions. See Special:WhatLinksHere/Template:Convert/usgalatm and Special:WhatLinksHere/Template:Convert/impgalatm
• There's not a snowball's chance in hell that any Wikipedia article will ever use these conversions.
• In entire life, I've never seen anybody ever use U.S. gallon-atmospheres or imperial gallon-atmospheres.
• I doubt very much that you could show me a single reliable source untainted by Wikipedia which expresses a measurement in these units. A Google search for the phrase "gallon atmospheres" without the word "Wikipedia" gets a grand total of three hits—and none of them deal with a unit of energy.
• This must arise from some strange notion that liters convert to gallons, and because "liter-atmospheres" are in fact used, that "gallon-atmospheres" are a reasonable unit to which they could be converted.
• OTOH, I have seen ft³·atm used—but never under either of the two names you use for it. It isn't a "cubic foot of atmosphere", and "standard cubic foot" is a term normally used for a cubic foot of volume, most likely of a gas, measured under specified standards for pressure and temperature. The standard cubic foot is a unit of volume, not of energy. The energy unit should be called a "cubic foot-atmosphere" (completely parallel to the "liter-atmosphere); it is the product of a volume in cubic feet and a pressure in atmopheres. That results in units of energy. Even your symbolic form "cu ft atm" doesn't include the middot to indicate that multiplication; and "scf" just plain isn't an energy unit in any case. But why should I be surprised to find any more evidence that the makers of this template don't know anything about dimensional analysis, given the near-total lack of it in this template. Gene Nygaard (talk) 05:19, 5 February 2010 (UTC)

Hi Gene. Your criticisms are probably correct but that's a pretty strange way to ask for volunteers to fix things for you. Has this form of motivation ever worked for you before? Cheers.  Stepho  (talk) 06:26, 5 February 2010 (UTC)

Indeed, the first thing I thought of when I read this was...we're volunteers. Quit demanding things be done, especially that things be done your way. Having various conversions is completely irrelevant. Doesn't bloat the code in the least. So sorry you don't like it, especially when you show every indication of just criticising rather than trying to help fix it. — Huntster (t @ c) 07:12, 5 February 2010 (UTC)

The waste of resources involved here is comparable to the waste of resources involved in writing this section. If the units in question are useless, I don't mind if we get rid of them (though, as noted above, they're not getting in the way). Yes, dimensional analysis might have been good but at the time I didn't think it worth pushing the template limits and I can only recall seeing one instance where this caused a problem (which I suspect was done on purpose to prove how terrible the template is). JIMp _talk·cont 10:59, 5 February 2010 (UTC)

to Stepho--note that I'm a volunteer, too. And I have volunteered far, far too much of my time running around cleaning up after the problems which {{convert}} causes.

To Jimp--Yes, they are getting in the way. The biggest problem with respect to waste of resources deal with our biggest resource: the editors who create and modify our articles. They need to wade through a long list of units to find out not only what the convert template can handle, but also what hoops you need to jump through to get the template to handle them. Having useless conversions gives them a whole lot of nonsense to wade through, before they can find what they are looking for. This behemoth is far too complex in the first place; it is already a dangerous weapon in the hands of the majority of the editors on Wikipedia. Everything that needlessly gets in the way of their understanding the template's documentation only exacerbates that problem.

Then that wastes a whole lot more resources—including the time of people like me who try to do what we can to clean up after others who give up on trying to figure out the nuances of the use of this template.

The other wasted resources include the time and abilities of those editors who are capable of understanding the internal workings of, and trying to edit, such a monstrously complex template, who should also be trying to establish a consistent look and feel across the board to that other editors can figure it out more easily. The strange use of "of" in the unit name to indicate multiplication in one of these useless units is one of the glitches keeping that consistent look and feel from being achieved. Gene Nygaard (talk) 11:58, 5 February 2010 (UTC)

I think we all agree that the template needs work - only the tone in which things are asked for needs to change. Jimp, I'm appreciative of the time you've volunteed (which is what I meant but must have said it wrong) and I'm willing to volunteer some of my own time. I'm a programmer by trade but is there any documentation on how this template works to help things along?  Stepho  (talk) 12:58, 5 February 2010 (UTC)

If you and others know it needs work, why is it that none of that work ever gets done?

Others in the same category as those gallon-atmospheres include:

Barye: it never was used under that name other than in nerdy cross-word puzzles. It isn't used on Wikipedia, anywhere outside articles about units or systems of units. When the unit was used, it almost always was without any special name, merely called "dynes per square centimeter". That's like the situation for the first 15 years or so of the International System of Units (SI), when the units of pressure didn't have a special name and were merely called newtons per square meter. Gene Nygaard (talk)

question

Is there a way to have an output on 2 rows? i.e. x km <br> (y mi) ? Nergaal (talk) 18:33, 5 February 2010 (UTC)

• Again, to handle any special formatting, use the option "disp=output only" after the text "x km" plus "<br>" then {{convert|x|km|mi|disp=output only}}. -Wikid77, 15 February 2010

Ampere-hours to coulombs

This conversion is missing. Ampere-hour should be convertable to Coulomb, which is a fairly simple conversion: Ah * 3600.0 = C
— V = I * R (Talk • Contribs) 21:22, 5 February 2010 (UTC)

They are, of course, coulombs. And the symbol for ampere-hours is A·h. But just because it can be done doesn't mean it should be done. See the "U.S. gallon-atmospheres" and "imperial gallon-atmospheres" discussion above. Make your case for this being a useful addition here. It's time to stop just piling on new conversions just because they can be done. How often ae such conversions being made now, without the template, for example? Do you have any idea? Gene Nygaard (talk) 22:08, 5 February 2010 (UTC)

OK, here's a good reason: I can use it. Who the hell are you? I should hardly need to justify myself to the likes of you, so that's all that you should need to fucking know. You people here in this fucking namespace are completely ridiculous, locking down all of these templates and completely short circuiting the normal editing process. If you want to be responsible for all the changes on these pages then either STFU and do what we ask you to do, or unprotect the damn things and get the fuck out of the way.
— V = I * R (Talk • Contribs) 07:08, 7 February 2010 (UTC)

Woah Ohms, Gene's the only one that voiced an opinion on your request. No one is locking down anything or blocking the creation of new templates (if they are, let me know and I'll have something to say about that). When Jimp has time, I'm sure he'll be able to create the conversion you are wanting. — Huntster (t @ c) 09:04, 7 February 2010 (UTC)

(polite cough) Ohms law, →WP:CIVIL please. —Sladen (talk) 13:07, 7 February 2010 (UTC)

Anyway, I agree that this template is effect carved in stone. Improvements nobody disagrees with aren't implemented because none of the very few people who both understand how the template works and are administrators can be arsed to do so. As a result, I format more and more conversions by hand. ― A._di_M. (formerly Army1987) 16:28, 7 February 2010 (UTC)

Ditto. Gene Nygaard (talk) 16:35, 7 February 2010 (UTC)

Gene has a point that there is no need to create more useless conversions but I'm sure you'll find a use, V=IR. {{convert|1.00|A.h}} -->> "1.00 ampere hour (3,600 C)". JIMp _talk·cont 19:04, 8 February 2010 (UTC)

Eh? Seem to be some glitches yet

Note that I never should it wouldn't be useful, or that it shouldn't be here. What we do need is that change of attitude you are starting to show now, Jimp. We need at least some minimal showing that a conversion would be useful in Wikipedia articles. If the unit rarely appears in Wikipedia articles, or if it appears only in articles about units of measure and systems of units, we don't need it in convert. We still haven't had that; adding the conversion now is premature.

We need some consideration of the advantages and disadvantages of adding some new conversion. (We also need some sensible way to get rid of those that clearly have no advantages and many liabilities, but that can be dealt with elsewhere such as the discussion above about "gallon-atmospheres".)

It would be nice to consider all the ramifications first, also. In fact, I had started a little caveat to put into this discussion, but hadn't gotten around to finishing it. Naturally, what it would have warned of was ignored.

In addition to being not-yet-documented, there are a few other problems:

{{convert|313|A·h}} -->> "313 A·h"

{{convert|313|Ah}} -->> "313 Ah"

{{convert|313|mA.h}} -->> "313 mA.h"

{{convert|313|A.h|disp=semi}} -->> "313 ampere hours (1,130,000 C)"

• but only documented on talk page and also gone from {{convert|313|m|ft|disp=semi}} -->> "313 metres (1,027 ft)"

{{convert|3600|C|A.h}} -->> "3,600 °C ()"

{{convert|3600|C}} -->> "3,600 °C (6,510 °F)"

So, what are we going to do about these, especially those last two? Options, anyone? Gene Nygaard (talk) 15:20, 9 February 2010 (UTC)

Regarding the improvements nobody disagrees with

{{edit protected}}

Here's the current code of {{convert/imppt}}.

{{convert/{{{d}}}Imp|{{{1}}}|{{{2|}}}|{{{3|}}}|{{{4|}}}|s={{{s|}}}|r={{{r}}}
|u=pt
|n=pint
|o=ml usoz
|b=0.00056826125
|j=-3.245451958-{{{j|0}}}}}<noinclude>
[[Category:Subtemplates of Template Convert]]
</noinclude>

Here's the new code.

{{convert/{{{d}}}Imp|{{{1}}}|{{{2|}}}|{{{3|}}}|{{{4|}}}|s={{{s|}}}|r={{{r}}}
|u=pt
|n=pint
|o=l uspt
|b=0.00056826125
|j=-3.245451958-{{{j|0}}}}}<noinclude>
[[Category:Subtemplates of Template Convert]]
</noinclude>

Here's the current code of {{convert/uspt}}.

{{convert/{{{d}}}US{{{r}}}|{{{1}}}|{{{2|}}}|{{{3|}}}|{{{4|}}}|s={{{s|}}}|r={{{r}}}
|u=pt
|n=pint
|o=ml impoz
|b=0.000473176473
|j=-3.324976857-{{{j|0}}}}}<noinclude>
[[Category:Subtemplates of Template Convert]]
</noinclude>

Here's the new code.

{{convert/{{{d}}}US{{{r}}}|{{{1}}}|{{{2|}}}|{{{3|}}}|{{{4|}}}|s={{{s|}}}|r={{{r}}}
|u=pt
|n=pint
|o=l imppt
|b=0.000473176473
|j=-3.324976857-{{{j|0}}}}}<noinclude>
[[Category:Subtemplates of Template Convert]]
</noinclude>

JIMp _talk·cont 08:27, 9 February 2010 (UTC)

 Done. — Huntster (t @ c) 08:49, 9 February 2010 (UTC)

There's something wrong with it: 20 imperial pints (11 L) ― A._di_M. (formerly Army1987) 10:56, 9 February 2010 (UTC)

Well, I'd initially reverted the above fixes I'd committed, but I realised those changes couldn't have caused A di M's problem, so I went to {{Convert/l_uspt}} and found the culprit. Everything should be dandy now. I also went to {{Convert/l_imppt}} and fixed the same error there, and protected both templates. — Huntster (t @ c) 12:26, 9 February 2010 (UTC)

Drams/drachms

RockyMtnGuy, I'll call on your knowledge of Canadian English. Do you have any idea if this is correct or not?

• {{convert|3.5|drachm|oz|sp=ca}} → 3.5 drachms (0.22 oz)
• {{convert|3.5|drachm|USoz|sp=us}} → 3.5 drams ()

Gene Nygaard (talk) 16:05, 9 February 2010 (UTC)

I do find some evidence in the name of the Rare Drams distillery in British Columbia. Gene Nygaard (talk) 17:43, 9 February 2010 (UTC)

Drachm is just an archaic spelling of dram. You have to keep in mind that there are two units called drams - one of mass, and one of fluid volume. the Canadian dram mass will the the same as the US and UK dram mass - exactly 1/16 of an ounce mass or 1.771 845 195 3125 grams, but the fluid dram will be the same as the British fluid dram - 3.551 632 812 500 0 ml, and different from the American fluid dram - 3.696 691 195 312 5 ml. In both cases it's 1/8 fluid ounce, but the size of the fluid ounce is different in the US than the UK or Canada. However, the dram is not often used in Canada. The conversion 3.5 drams (210 US fl oz) is completely whacked regardless. RockyMtnGuy (talk) 21:36, 9 February 2010 (UTC)

Okay. So "sp=ca" is broken when it gives you the British spelling both there and in

• {{convert|3.5|dram|oz|sp=ca}} → 3.5 drachms (0.22 oz)

So let's get that fixed too. Gene Nygaard (talk) 22:48, 9 February 2010 (UTC)

I was more concerned about the "sp=us" example. One would expect 3.5 US fluid drams to be 0.44 US fluid ounces, not 210 fluid ounces.RockyMtnGuy (talk) 03:10, 10 February 2010 (UTC)

The Canadian spelling is "drams" and "fluid drams", at least in English. I've never known anybody to use them, though, since grams and millilitres are more understandable. RockyMtnGuy (talk) 03:24, 10 February 2010 (UTC)

That conversion error, of course, is just a case of the lack of dimensional analysis coming back to bite us. It is a conversion from the code for a mass unit, the avoirdupois dram, as "dram", and a volume unit, the U.S. fluid ounce, as "USoz". Apparently the thinking was that if you are distinguishing U.S./imperial, then you are dealing with volume units. If you are dealing with the mass units, the distinction would need to be between the apothecaries unit and the avoirdupois unit, a distinction not made in Template:convert.

As far as spelling goes—the modern spelling throughout the English-speaking world is whichever spelling fits in a particular crossword puzzle. That's the only place they are used.

These drams/drachms have disappeared from use all around the world, I'm sure. We aren't ever going to have to use this conversion on Wikipedia. In my whole lifetime, I've never seen anybody express a contemporary measurement in drams. Not sure if I've even seen it in anything historical; I don't recall any specific measurement in drams, but but it seems likely that I might have seen it used two or three times in something written back in the 18th or maybe even 19th century. I don't understand why these anachronisms have such great longevity in lists of conversion factors.

Of course, they never were used in coinage in the English-speaking world (the "drach" spelling might have been rarely used for the Greek coinage usually called "drachmas"), the one area in which precise measurements of small amounts of mass were common. For coinage, the apothecaries/troy ounce was subdivided differently, into the pennyweight (1/20 ozt) instead of "drachms" (1/8 ozt) and "scruples" (1/24 ozt).

In the U.S., "drams" also survives figuratively in the phrase "dram shop act", where they are an exaggeration, an understatement, a meiosis. Nobody ever sold liquor by the dram; could you imagine how much business a pub in Scotland that squeezed 210 drinks out of a 750 mL bottle of whisky would get?

"Och, I only had but a wee dram". How many wives ever bought into that excuse? Or police officers? In any case these drams of liquor would refer to fluid drams, but

{{convert|3.2|fldr|floz}} -->> "3.2 fldr"

{{convert|3.2|USfldr|USfloz}} -->> "3.2 USfldr"

convert doesn't appear to handle fluid drams. Note that the fluid dram does survive in very limited use. I can still go to a local store in my small town and buy essential oils (used in food flavorings and fragrances) in one-fluid-dram bottles. Sometimes they say "fl dr" or "drams" on the bottle, sometimes not, but they still exist. Of course, as RockyMtnGuy has already pointed out, there are also imperial fluid drachms which differ from U.S. fluid drams.

However, when dra(ch)ms were units of mass, they were probably more likely to be the apothecaries drams, equal to 1/8 apothecaries ounce (3.8879346 g), rather than the 1/16 avoirdupois ounce unit this template has, {{convert|1|dram|g|9|}} → "1 drachm (1.771845195 g)".

But why are these conversions here in the first place? The problem is the same as that with "gallon-atmospheres", though those might even cross over into the realm of Wiki-inventions. They don't even appear in cross-word puzzles or lists of conversion factors.

Each is used in exactly one Wikipedia article. Special:WhatLinksHere/Template:Convert/dram, Special:WhatLinksHere/Template:Convert/drachm.

1. One of those uses is a conversion of modern nutrition label information from "grams" of fat and the like to "drachms" of fat. Really helpful stuff; sure glad we got that!!!! Can't wait until somebody updates the rest of the Wikipedia articles with nutritional information, so that we'll be able to understand what they're talking about!
2. The other one converts an old recipe for Coca-Cola, and

• It mis-converts them. Most of these are not the avoirdupois "drachms" which result from our Template:Convert, nor are they apothecaries drachms of mass. They are used for liquids—for those essential oils I mentioned above as still being available for purchase in one-fluid-dram bottles. These "drachms" should be "U.S. fluid drams" instead. (There is a slight possibility that a couple of them might be either avoirdupois or apothecaries units of mass, or more likely the fluid drams used for powders, too, just as American cooks use teaspoons and cups for sugar and salt. However, I don't know which for certain, and this template isn't going to answer that question for us.)
• These conversions also demonstrate the problems of the refusal of the editors of this templates to fix singular usage. Everything that has an absolute value less than or equal to one and greater than zero should be singular, but isn't here:

• {{convert|1/4|drachm|2|abbr=on}} orange oil → 1⁄4 drachm (0.44 g) orange oil

Note that adding the broken but still-available and still-often-used "sing=on" parameter doesn't fix it correctly, either:

• {{convert|1/4|drachm|2|abbr=on|sing=on}} orange oil → 1⁄4-drachm (0.44 g) orange oil

It does successfully remove the "s", but it also improperly sticks in a hyphen which doesn't belong there.

They do not belong here in Template:Convert. And no, we don't need to add conversions for U.S. fluid drams and imperial fluidrams either. Gene Nygaard (talk) 11:09, 10 February 2010 (UTC)

• A few of the various options do consider fractions to be singular, while zero is plural; however, some people prefer that decimals 0<x<1 also be plural (such as: 0.45 metres) while only fractions below 1 are singular, as: 45/100 metre. This distinction needs to be decided. -Wikid77 07:10, 12 February 2010

Astronomical units of length

I was looking through List of nearest stars & many of the articles for stars (starting with Proxima Centauri & so on), and I could not help but notice that while the Parallax measured in arcseconds was correct as per cited reference(s), the derived distance in light-years was almost always slightly more than the correctly calculated distance (due to the editor(s) using 3.2616 ly/Parsec instead of the correct number (see below)).

As I have used this very comprehensive template a number of times before, for conversions including length (metres to feet) & population density (/km² to /sqmi), I was wondering if someone would be willing to include a conversion for Astronomical units of length: FROM arcsecond(s) AND/OR milliarcsecond(s) TO light-year(s) AND/OR parsec(s) AND/OR metre(s) AND/OR kilometre(s) (frequently used in Astronomy/Astrometry) AND/OR AUs.
Note: The article Astronomical unit claims that the distance of the AU is defined by the International Astronomical Union and that they have since updated their definition of that distance from the old value of 149,597,870,691 ± 6 metres to the new value and I quote:"The International Astronomical Union (IAU) currently accepted best estimate (2009) of the value of the astronomical unit in metres is A = 149 597 870 700(3) m, based on a comparison of JPL and IAA–RAS ephemerides."(See:AU for ref.s);end-quote. (as at 2010-02-10 this value is not included in Template:Convert OR Template:Convert/list_of_units/length, furthermore I have not noticed any representation of the margin of error of the measurement of the AU (either 6 OR 3 metres) in either of the aforementioned articles, while Template:Convert does support use of the +/- representation).

If anyone is so inclined to expand on this template to convert FROM arcsecond(s), below are some ways I would suggest the math should be handled for point variables:

• arcsecond(s) TO parsec(s) → 1/arcsec
• arcsecond(s) TO light-year(s) → 969394202136/94607304725.808/pi/arcsec OR
  969394202136/94607304725.808/pi/arcsec ± 1944/9460730472580.8/pi/arcsec
• arcsecond(s) TO metre(s) → 969394202136e5/pi/arcsec OR
  969394202136e5/pi/arcsec ± 1944e3/pi/arcsec
• arcsecond(s) TO petametre(s) → 96.9394202136/pi/arcsec OR
  96.9394202136/pi/arcsec ± 1944e-12/pi/arcsec
• arcsecond(s) TO AU(s) → 648e3/pi/arcsec

If anyone is so inclined to expand on this template to convert FROM milliarcsecond(s), below are some ways I would suggest the math should be handled for point variables:

• milliarcsecond(s) TO parsec(s) → 1e3/mas
• milliarcsecond(s) TO light-year(s) → 969394202136/94607304.725808/pi/mas OR
  969394202136/94607304.725808/pi/mas ± 1944/9460730472.5808/pi/mas
• milliarcsecond(s) TO metre(s) → 969394202136e8/pi/mas OR
  969394202136e8/pi/mas ± 1944e6/pi/mas
• milliarcsecond(s) TO petametre(s) → 96939.4202136/pi/mas OR
  96939.4202136/pi/mas ± 1944e-9/pi/mas
• milliarcsecond(s) TO exametre(s) → 96.9394202136/pi/mas OR
  96.9394202136/pi/mas ± 1944e-12/pi/mas
• milliarcsecond(s) TO AU(s) → 648e6/pi/mas

Wherever arcsecond(s) are defined as a value +/- a margin of error, below are some ways I would suggest the math should be handled for ranged variables:

• arcsecond(s) with error TO parsec(s) with error → (1/( arcsec - arcsecERR )+1/( arcsec + arcsecERR ))/2
  ± (1/( arcsec - arcsecERR )-1/( arcsec + arcsecERR ))/2
• arcsecond(s) with error TO light-year(s) with error → (96939420215544/( arcsec - arcsecERR )+96939420211656/( arcsec + arcsecERR ))/2/9460730472580.8/pi
  ± (96939420215544/( arcsec - arcsecERR )-96939420211656/( arcsec + arcsecERR ))/2/9460730472580.8/pi
• arcsecond(s) with error TO metre(s) with error → (96939420215544e3/( arcsec - arcsecERR )+96939420211656e3/( arcsec + arcsecERR ))/2/pi
  ± (96939420215544e3/( arcsec - arcsecERR )-96939420211656e3/( arcsec + arcsecERR ))/2/pi
• arcsecond(s) with error TO petametre(s) with error → (96.939420215544/( arcsec - arcsecERR )+96.939420211656/( arcsec + arcsecERR ))/2/pi
  ± (96.939420215544/( arcsec - arcsecERR )-96.939420211656/( arcsec + arcsecERR ))/2/pi
• arcsecond(s) with error TO AU(s) with error → (1/( arcsec - arcsecERR )+1/( arcsec + arcsecERR ))*324e3/pi
  ± (1/( arcsec - arcsecERR )-1/( arcsec + arcsecERR ))*324e3/pi

The above multipliers have already been simplified (ie.(149,597,870,700/9,460,730,472,580,800)*(180*3600)/pi=969394202136/94607304725.808/pi ly/pc) and must not be simplified further (eg.3.261563777167433562138639707045508374088175835353338611512129463342885876338043165939480943288086673 ly/pc) as this would only reduce accuracy (ie.Pi is both an Irrational number and a Transcendental number). Furthermore the above output equations have already been simplified and must not be simplified further as this would only introduce further errors (ie.1/arcsec DOES NOT EQUAL (1/( arcsec - arcsecERR )+1/( arcsec + arcsecERR ))/2 AND
the use of 1/arcsec IS NOT COMPATIBLE WITH ± (1/( arcsec - arcsecERR )-1/( arcsec + arcsecERR ))/2), trust me on this or do the math and see for yourself (if I am wrong, I would very much like to know).--202.168.102.96 (talk) 10:21, 10 February 2010 (UTC) additions/edits--202.168.102.96 (talk) 11:28, 10 February 2010 (UTC)

I've gone ahead and updated "Convert/AU" based on the above figure, and also updated "Convert/pc" (parsec) to go along with this. That's about all I'm capable of doing (and Jimp, make sure I did it right?). Testing this change, parsec to lightyear seems to be accurate to your example to 13 decimal places, which I believe is the limit to this Convert template: 1 parsec (3.2615637771418 ly). — Huntster (t @ c) 10:48, 10 February 2010 (UTC)

To Huntster, the update to Template:Convert/pc appears to be as good as it can be (for b=969394202136e5/pi), but the Template:Convert/AU update is confusing me a bit. Did you intend for Template:Convert/AU to have two different values of b=... ?
Beyond that, I have no idea if it is even possible for this template to convert a single input of say {convert|1|pc|ly|20} to output 1 parsec(s) (3.2615637771674 ± 0.0000000000654 ly) OR 1 parsec(s) (3.2615637771674 ± 6.54e-11 ly) OR 1 parsec(s) (3.2615637771674(654) ly) as the margin of error in the IAU's measure of the AU requires (excessive accuracy should not matter, I just wanted to be able to use this template to convert arcsec ± error to ly ± error). BTW, is there any chance that this template could output the answer with error margin in the same format as the International Astronomical Union & Committee on Data for Science and Technology & National Institute of Standards and Technology (as quoted above)?--202.168.102.96 (talk) 12:19, 10 February 2010 (UTC)

Yikes, thanks for pointing out my error. Thankfully the template just reads the first instance of "b=", so it really didn't matter, but good to get rid of it nontheless. As far as I know, this template isn't capable of outputting margin of error, so that's a question Jimp will have to answer when he returns. Further, there may be some kind of server or code-induced restriction on the level of accuracy, so the thirteen decimal places may be as good as we can possibly get. — Huntster (t @ c) 13:03, 10 February 2010 (UTC)

Gotta love this tilting at windmills! You do realize, don't both of you, that your change of 6 pm/m (6 parts per trillion) cannot possibly make any difference whatsoever in any measurement expressed in parsecs?

To User:202.168.102.96. Can you tell is what the relative error is in this conversion which you gave us above?

• arcsecond(s) TO parsec(s) → 1/arcsec

Hint. It isn't a constant. So what is the

relative error for 0.01234567890123 arcsecond, inverted and called 81.00000072903 parsecs?

relative error for 123.4567890123 arcseconds, inverted and called 0.0008100000072903 parsec?

What we really need is a limit of about 4 significant digits to be applied in rounding any conversion involving parsecs—even that is probably beyond the actual precisions we have. Just don't let the results ever have more than that, on either side of the equation.

Now, can anybody tell me why these do not work?

• {{convert|21|pc|Pm}} → 21 parsecs (650 Pm)
• {{convert|21|kpc|Em}} → 21 kiloparsecs (650 Em)
• {{convert|21|Mpc|Zm}} → 21 megaparsecs (650 Zm)

when these do?

• {{convert|21|pc|m}} → 21 parsecs (6.5×10¹⁷ m)
• {{convert|21|kpc|m}} → 21 kiloparsecs (6.5×10²⁰ m)
• {{convert|21|Mpc|m}} → 21 megaparsecs (6.5×10²³ m)

and when these do?

• {{convert|21|PJ|erg}} → 21 petajoules (2.1×10²³ erg)
• {{convert|21|EJ|erg}} → 21 exajoules (2.1×10²⁶ erg)
• {{convert|21|ZJ|erg}} → 21 zettajoules (2.1×10²⁹ erg)

Gene Nygaard (talk) 16:24, 10 February 2010 (UTC)

I'll add these when I get a better handle on the code. Or Jimp will get to them first. I agree with you that a shorter default significant digit limit would probably be a good thing. I'm just not sure if that's currently possible to specify. Good idea though. Also, may I ask that in the future, you take a less confrontational tone when dealing with such minor things are the above missing conversions? Remember that each unit is individually created, and that's *all* that's wrong...it was just a simple oversight and is easily fixed. Just point out the units that need to be made. — Huntster (t @ c) 05:26, 11 February 2010 (UTC)

Okay, wasn't as difficult as I feared. Pm, Em, Zm done, Ym created for the hell of it. — Huntster (t @ c) 05:44, 11 February 2010 (UTC)

By the way, your conversion factor equivalent to 30.856775814913673 Pm/pc is calculated using d/θ. But, technically, it should be d/tan θ as the parsec article explains.

Using d/θ is, in fact, good enough for any practical measurement in parsecs (since θ ≈ tan θ within 8 parts per trillion for an angle of one second of arc, and the best measurements of distances in parsecs have fewer than half enough significant digits to matter). But it is nowhere near good enough to express a conversion factor to 17 significant digits, as you have done.

Since a second of arc is π/648,000 radian, we have

• your calculation: 149597870700 m/(π/648,000 rad) = 30856775814913673 m
• correct: 149597870700 m/tan(π/648,000 rad) = 30856775814671916 m

giving an error of 241757 m in your conversion factor.

Gene Nygaard (talk) 17:02, 10 February 2010 (UTC)

Correction. I forgot to account for the uncertainty in the best estimate of the length of an astronomical unit. If it is ±3 m, the correct value given above should be ±620,000 m, so the error in our knowledge of the length of an astronomical unit is still more than 2.5 times as great as the error in using θ instead of tan θ. (It seems there was also some discussion above about ±6 m rather than ±3 m, which would double that error.) The total error from both causes is thus roughly 1,000,000 m. Round your conversion factor off to 30856775815000000 m; that's the most precision you can justify, and you'll never have 10-digit precision in any actual measurement using parsecs either now nor any time in the next millennium.Gene Nygaard (talk) 17:13, 10 February 2010 (UTC)

I never conceived nor intended to cause either offence or a rant against accuracy, especially since Template:Convert & Template:Convert/list_of_units appear to give conversion factors to the highest standard of accuracy (eg.0.2780138203095378125 Newtons/ounce-force & 2,684,519.537696172792 Joules/horsepower-hour) rather important for a math template I think, and I was taught to round off my result after doing the math not before (eg.3 rounded to nearest 5 + 4 rounded to nearest 5 = 10, preferring 3+4=7 rounded to nearest 5 = 5).
So Gene Nygaard, I sincerely appreciate your correcting my bad math, I have thought that my Parsec numbers were correct for years now & likely would never have caught my mistakes without you, but I cannot agree that reducing inaccuracy is Tilting at windmills (or that inaccuracy is an imaginary enemy, or fighting it is unwinnable or a futile battle). So referring to the Parsec article which claims that in 1989 measured parallaxes had an astrometric precision of about 970 microarcseconds and that in December 2011, this is intended to be within 20 microarcseconds (a reduction of error by one full order of magnitude every 13.1 years). So in light of your correction, I now request that the following numbers are considered by whomever intends to update this template:

• new calculation: 149597870700/tan(π/648e3 rad) = 30,856,775,814,671,915.807871616093599612514853018460021328632464109734923191617779213902789000350293414279784122249383525 m/Parsec
• wikipedia's limit:{formatnum:{#expr:149597870700/tan(pi/648e3)}} = 30,856,775,814,672,000 m/Parsec
• standard uncertainty:618,794.418736440928658317115210108652599686068794186292501771077713404746029835314416457139124776612474554 m/Parsec
• new calculation: 1495978707/94607304725808/tan(π/648e3 rad) = 3.261563777141879829055509772996751792327828723608238282532529264134425773668731085423760007511531449 ly/Parsec
• wikipedia's limit:{#expr:1495978707/94607304725808/tan(pi/648e3)} = 3.2615637771419 ly/Parsec
• standard uncertainty:6.540662166941951993415992731098581991370206160845252490346834724301511947259415943191817116240942824e-11 ly/Parsec
• Relative standard uncertainty of 2009 measure = u_r(AU₂₀₀₉): 2.005376136680533648798786011063190888050520895549083507109035342706919958854735223179884471443883994e-11 dimensionless

Now, getting off the side-topic of accuracy (desired versus possible), my initial request was for an addition to this template so that the input data of parallax (measured in either arcseconds or milliarcseconds) could be converted directly (to the same highest standard of accuracy to which this template strives) into light-years AND parsecs for the article List of nearest stars & many of the other articles for stars (starting with Proxima Centauri & so on) preferably maintaining a 'data ± error' output format identical to that used by CODATA & NIST & IAU (as quoted above, A = 149,597,870,700(3) m).--202.168.102.96 (talk) 03:56, 11 February 2010 (UTC)

Okay, both sides make valid points, so let me find the average. Gene, thanks for the correction. I was working off the parsec = (360*60*60)/2pi, which I've seen many places, including the Parsec page. Though, I hate tangents and sines, so I may have just mentally skipped that. :D My take is that if a higher precision (within reason...aka, not going into decimal points) is available, then it should be used. As IP says, round after the computation, not before. Regarding IP's original request, again, this will have to be something Jimp handles. — Huntster (t @ c) 05:05, 11 February 2010 (UTC)

My reply to 202... got an edit conflict with your additions, Huntster; I've dealt in part with the "rounding after computation" below (when the calculations only have 47-bit mantissas, it doesn't do you one bit of good to have more than 14 decimal digits in your conversion factors). Might get into some of the other factors involved later.

1. That compact method of expressing error in the results should never be used in any Wikipedia article in which it is not explicitly explained. Period. It should never be available through convert or any other template, unless that template includes the explanation (and then you get into the issue of not duplicating it).

2. That wasn't the accuracy I asked you about. I want to know the relative error in converting from an angle in seconds to a distance in parsecs. That error is bigger, in relative terms, for bigger angles, having to do with the θ vs. tan θ problem but with angles where the difference between them is greater than it is at the one-second level. What is it for Proxima Centauri?

3. Of course, if you had actually used template convert, you would have seen that it works a whole lot better than you do in some other areas, too. For example, it gets the capitalization of the unit names correct most (but not all) of the time, something that you should learn if you enter any of these units without using the template (it does get it right in these examples):

• {{convert|1|ozf|N|19|abbr=none|sp=us}} → 1 ounce-force (0.27801382030953 newtons)
• {{convert|1|hp.h|J|12|abbr=none|sp=us}} → 1 horsepower-hour (2,684,519.5376961 joules)
• {{convert|1|pc|m|0|abbr=none|sp=us}} → 1 parsec (3.0856775814671×10¹⁶ meters)
• {{convert|1|pc|Pm|0|abbr=none|sp=us}} → 1 parsec (31 petameters)

as you can see, asking for more precision than it can give has no effect.

4. Worse yet, you cannot even make a simple conversion to the SI petameters from any unit. Looks like Huntster fixed this already.

5. Don't know how you got a horsepower-hours conversion factor; if this damn template had a consistent look and feel "hp.h" should have worked. What does work? Use it with the convert-to factor as |J| and |abbr=none| to see the proper spelling of those units.

I've fixed the "hp.h" issue. It just needed a redirect to "hph". If you ever find a unit that doesn't seem to work but logically should, just let me know. — Huntster (t @ c) 11:23, 12 February 2010 (UTC)

6. As you have seen in your own parsec conversion (before I did it above), the last three digits in Hunster's entered conversion factor are useless. The calculator probably uses a 47-bit mantissa, I'd guess. So anything beyond 14 decimal digits doesn't help a bit (2⁴⁷ 140,737,488,355,328).

For any actual measurements in parsecs, 30.85678 Pm/pc would be more than enough. That's far greater precision than your input values will ever have, whether measured in parsecs or in light-years or in meters (for anything that a reasonable person would want to convert to parsecs; for other things, a measurement in meters might be more precise, of course).

7. How are you defining a light-year? What's the "year" used there, exactly? Is there a universally accepted standard in that regard? If so, who defined it? answered at light-year (though any of the reasonable possibilities would probably have no effect on real-world measurements in light-years)

8. The request for error ranges (as long as it is not in the compact format for uncertainty in the last digits) is reasonable enough. We should consider whether to include it; that includes factors such as how often it might be used, how difficult it is to implement in the template, etc.

But {{Starbox astrometry}} already does that in the infobox at Proxima Centauri. It takes the inputs:

| parallax=768.7

| p_error=0.3

and spits out, among other things,

Distance	4.243 ± 0.002 ly (1.3009 ± 0.0005 pc)

and if you want to use those numbers elsewhere in the article, you can copy them from the infobox output.

That makes it much less useful as an addition to this template, when it would at best duplicate what is done already by a template specific to those types of articles, and probably wouldn't do it as well. Gene Nygaard (talk) 06:32, 11 February 2010 (UTC)

Call for new features

12-Feb-10: Before changing Convert to allow deleting 2,500 display-subtemplates (long-term), I guess we need to consider what other features that people might want added to Convert, if possible at the same time. Currently, the following are proposed:

• allow commas in the input number: {Convert|4,005,070|km|mi}
• allow leading-spaces before the amounts: {Convert| 4| km| mi}
• allow comma-display options: comma=in, comma=out, comma=none
• allow input-rounding options: round=2
• allow singular unit names for fractions 0<x<1.
• allow reversing the from-to amounts: order=reverse (currently: disp=flip)
• allow semicolon as a separator (disp=semi): 1.61 km; 1 mile
• allow midtext insertion (mid=radius): 1-mile radius (1.6 km)
• allow midtext hyphenation (mid=-radius): 1-mile-radius (1.6 km) impact crater
• allow sp=us, sp=uk, sp=en but reject others (error for sp=latin)

Are there any other major features that we need to add with the first migration to a hybrid Convert (which will allow bypassing the thousands of display subtemplates)? Other features could be added later. Currently, as a way to remove all commas from any conversion, just wrap the whole {Convert...} inside FORMATNUM with R: {{formatnum:{{Convert|1300|mi|km}}|R}} to omit commas. Remember, the plan is to migrate Convert to allow deleting groups of the 2,500 display-subtemplates. For detailed explanation, see essay: WP:A plan to reduce Convert subtemplates. -Wikid77 (talk) 07:10, 12 February 2010 (UTC)

Why suggest such a clumsy kludge to strip commas; we already have it in "convert". It comes, of course, at the cost of an inconsistent look and feel and at the cost of not being able to use another parameter for its designated purpose. This one isn't "wrapped" inside anything; I have convert on the outside, and it is the only template I have explicitly called on:

• {{convert|233435993|in|m|sp=us|abbr=comma|disp=or}}

But yes, get rid of the work-around somebody has added here. Is there any easy way to find any articles which have used that parameter with the "comma" value to accomplish this? If so, you might review them if it deleted; if not, the numbers will still be correct anyway, even if their formatting is changed by deleting this. Gene Nygaard (talk) 10:32, 12 February 2010 (UTC)

A bunch of suggestion of dubious utility; how about tackling the big problem: Let's have some dimensional analysis.

Then there are is the dumb ideas category

A default to "sp=en" as if that were the standard spelling for the English language.

If you've been paying attention to the talk page, we also need sp=ca so we can fix the spelling of drams.

A really dumb idea to change the default for {{convert|7000000|km}} which now gives 7,000,000 kilometres (4,300,000 mi) to instead give us 7,000,000 kilometres (4,349,598 mi)

That's a significant change that should not be done without human (not a bot) review of every conversion already existing on Wikipedia. Editors have relied on the existing rounding in the conversions we have now. Furthermore, the existing rounding has greatly reduced the cases of silly overprecision which make the numbers seriously interrupt reading (even when they are the units you'd ignore anyway).

Gene Nygaard (talk) 09:55, 12 February 2010 (UTC)

Suggestion:

1. A consistent look and feel.

• Don't have things like {{convert|7|kW.h}} and {{convert|7|kW·h}} work while {{convert|7|hp.h}} and {{convert|7|hp·h}} give error messages:

7 kilowatt-hours (25 MJ) and 7 kilowatt-hours (25 MJ)

7 horsepower-hours (5.2 kWh) and 7 hp·h

there could be lots of examples of the existing lack of a consistent look and feel in other areas besides the input units used. Gene Nygaard (talk) 10:05, 12 February 2010 (UTC)

Consistent look and feel, continued:

• 9 hm³ (320,000,000 cu ft)
• 9 km³ (2.2 cu mi)

Gene Nygaard (talk) 10:11, 12 February 2010 (UTC)

Suggestion to Wikid77: Start keeping not only a list of features which have been requested, but also a list of the requests which have been objected to. Gene Nygaard (talk) 10:21, 12 February 2010 (UTC)

Here are some more ideas to get the ball rolling.

Requests:

1. output: in³, in², ft³, mi³, etc.
   • default to that in unit-combination symbols which now use "sq" or "cu" (e.g. ft³·atm rather than "cu ft atm"), keep defaults at "sq" and "cu" when the unit stands alone
2. negative exponent format for unit combinations
   • should be able to {{convert|25|m/s2|ft/s2|PARAMETER=WHATEVER}} and get either "25 m s⁻² (82 ft s⁻²)" or "25 m·s⁻² (82 ft·s⁻²)" to conform with the format used in the rest of the article
3. convert ergs per second (default to watts)
4. I'm not sold on your "mid=" being a good idea, but it is more likely to be useful if you add "mid2=" and "mid3=" for double and triple conversions. For example, if it could be used to get: 16 ft high by 22 ft wide by 7 ft high (4.9 by 6.7 by 2.1 m)

Fixes

• fix abbr=none to always work
• fix abbr= to not cause error messages in temperature ranges
• fix abbr=off in temperatures (we can discuss whether or not to default to abbr=on)
• fix uppercase spelled-out unit name
• fix {{convert|3|A.h}}→3 ampere hours (11,000 C) but {{convert|3|A.h|C}}→3 ampere hours () and {{convert|10800|C|A.h}}→10,800 °C () and {{convert|3|A·h}}→3 A·h
  • lmao, I was desperately trying to fix this, then I realised "C" is an imput for Celsius (since it's rather tedious to manually enter the degree sign if you don't know its available in the below cheatsheet). Type out "coulomb" to see everything work. I see no realistic way around this situation. — Huntster (t @ c) 12:47, 12 February 2010 (UTC)

So where does this "coulomb" input option appear on our other cheatsheet, Template:Convert/doc? That's a bigger problem. When changes are made, the documentation should be updated. But not only is this not there, but a search for "ampere" and for "A.h" in the documentation still comes up empty, and that ampere-hour conversion was added four days ago.

There are realistic ways around it. Here's one suggestion. Use dimensional analysis; don't allow conversions from current electric charge to temperature or vice versa. Don't allow {{convert|3|dram|USoz}}. Don't allow "a {{convert|12|oz|mL|adj=on}} soft drink can". In the cases with ambiguity in possible names of input units, don't provide a default to-units conversion without specifying output units; instead provide a context-specific note about the quantities involved and that either an output unit is needed or other input unit-names such as "°C" or "coulomb" in this case can be used as the input rather than the ambiguous "C" to get default output units. Gene Nygaard (talk) 14:18, 12 February 2010 (UTC)

• delete "U.S. gallon-atmospheres" and "imperial gallon-atmospheres" discussed on talk
• delete "drams" and "drachms" discussed on talk
  • delete a whole lot more nonsense

Look and feel

1. Use standard symbols for units to the greatest extent possible, not only for output but as an acceptable input parameter
   • That will be to a much greater extent if we have dimensional analysis than what is possible without it. Consider the ampere-hours example above.
2. For unit combinations involving multiplication,
   • using either a dot on the line or a middot should always work (debatable: hyphens for that purpose in the input parameter)
   • an option of &middot; or &nbsp; to separate unit symbols in output so the article can remain consistent
3. use consistent ⁿ format for output

A start—take advantage of Wikid77's invitation; jump in and add to this. Gene Nygaard (talk) 12:21, 12 February 2010 (UTC)

Requests

1. Some units should be made input-only, not available for output
   • I can put up with 321 dunams (32.1 ha). But we should never be allowing 321 acres () and 321 acres () which have several other issues including but not limited to the ambiguity evident in the output, besides not being appropriate for output in any case (probably not even as input for some of them; certainly not without a strong showing that that particular units is used on Wikipedia).
   • There are lots of others that should either fall into this category, or be deleted entirely. For starters, I'll name the barye. Gene Nygaard (talk) 15:06, 12 February 2010 (UTC)

Look and feel

1. All spelling issues in the output (including adjective forms and singular/plural nouns and accented letters as well as Canadian English and the like) should be dealt with through appropriate parameters. The unnamed input-unit parameter should only affect the numerical results; it should never be used to modify spellings in the output. Gene Nygaard (talk) 15:06, 12 February 2010 (UTC)

Problem with whitespace

I don't know if this is due to recent changes in MediaWiki, but the template seems to be intolerant to whitespace in the options. For example, as of writing this, the following works

{{convert|20|m}} producing 20 metres (66 ft)

but the following doesn't work

{{convert| 20|m}} producing 20 metres (66 ft)

and of course, this doesn't work either

{{convert|20| m}} producing 20 metres (66 ft)

I was playing around a bit in the sandbox, and it appears there is a way to fix this. If you wrap the input arguments inside of a dummy if statement, {{if:1| {{{1}}} }}, for example, it will strip the whitespace. As of writing this, the sandbox version works:

{{convert/sandbox| 20|m}} producing 20 metres (66 ft)

{{convert/sandbox|20| m}} producing 20 metres (66 ft)

At the moment, I only wrapped the first two inputs, but the others could probably be wrapped as well. It shouldn't be a problem for named parameters, just the unnamed ones (for some reason). Plastikspork _―Œ^(talk) 01:52, 6 February 2010 (UTC)

• The errors generated for whitespace, preceding the parameters, have existed for months, and have been fixed in the Gconvert variation (21Oct09) of Convert. Hence, using Gconvert allows whitespace, as:

{{Gconvert| 20|m}}   produces: 20 metres ()

The tolerance for leading-spaces is handled when Gconvert also allows commas in the input amount (such as 5,280 by invoking {{FORMATNUM:{{{1}}}|R}}. Hence, leading-spaces and input-commas are intended to be allowed when we migrate to the proposed, reduced-subtemplate update to Convert to omit 2,500 display subtemplates. -Wikid77 07:10, 12 February 2010

Right, adding the FORMATNUM parser function takes care of both the whitespace and the commas. Since there appear to be no objections, I will make the change. Please revert if this causes a problem. Plastikspork _―Œ^(talk) 19:42, 13 February 2010 (UTC)

Displaying unit name by disp=unit

08-Nov-2009: To finish Template:Convert/3 (for 3-amount conversions), I had to implement a new display type, as disp=unit, to display just the unit name (as singular, plural or hyphenated) for an input-unit symbol:

• {{convert|1 |ft|disp=unit}}           gives: foot
• {{convert|9 |ft|disp=unit}}           gives: feet
• {{convert|7 |m3|disp=unit|abbr=on}}       gives: m³
• {{convert|7 |m3|disp=unit|abbr=off}}       gives: cubic metres
• {{convert|1 |cuyd|disp=unit|lk=on}}       gives: cubic yard
• {{convert|1 |cuyd|disp=unit|adj=on}}      gives: cubic-yard

The option disp=unit can also be used, during article writing, as a means to display a unit name or symbol for a specific unit-code when writing an article. -Wikid77 10:31, 8 November 2009

• I have added "disp=unit" to the Convert/doc. -Wikid77 22:19, 12 December 2009

So why is it that

• {{convert|1 |t|disp=unit|sp=us}}      gives: metric ton

Which, even with the sp=us parameter set, gives us a spelling more foreign to American English than

• {{convert|1 |l|disp=unit|sp=backwards}}      gives: litre

Why hasn't this been fixed? Gene Nygaard (talk) 04:07, 4 February 2010 (UTC)

Note that

• {{convert|1 |l|disp=unit|sp=us}}      does give American English: liter

Gene Nygaard (talk) 15:10, 4 February 2010 (UTC)

Why? Because tonne vs metric ton is not a spelling difference so it never occurred to me to treat it as one, though I'm not opposed to so doing. JIMp _talk·cont 20:28, 4 February 2010 (UTC)

I don't know how you could not see that it is a spelling problem. Especially when this issue has been raised before. It is the same unit; it's not like "litres" vs. "liters" where it takes 4.5 of those dinky "litres" to make a gallon, but only 3.8 "liters" to make a gallon. ;-) Okay, I'll be more serious: It isn't like "U.S. gallons" vs. "imperial gallons", which are different units. It isn't even like "lb" which stands for one unit in some {{convert}} conversions, and "lb" which represent an entirely different unit in other conversions with this template. It isn't even like the symbol "t" which is a common symbol for long tons, and a common symbol for short tons, as well as being our symbol for this unit, whether it is spelled "tonnes" or "metric tons". It is one unit, spelled two different ways. You don't need to do anything different to calculate the numeric part of the result; you just need to fix the spelling of the output to agree with the "sp=" parameter.

Furthermore

• {{convert|3|t|disp=unit|vocabulary=us|words=us|dictionary=us|flavour=us}}      also gives: tonnes

In any case, even if you choose for some strange reason not to characterize this as a "spelling" problem, you already knew it was a problem. It is one of problems (like the improper default to British spellings in the first place) which improperly causes this template to introduce British English into thousands of Wikipedia articles in which it does not belong in accordance with our national varieties of English rules. Now, you don't have any other parameter that takes the place of the "vocabulary=us" or "words=us" or "dictionary=us" or "flavour=us" in my example, do you? There certainly isn't any such documented parameter. The "sp=" parameter is the one that at least the careful editors know, the one they will try to use for this purpose, until they find out it is broken and doesn't work.

Those ownership issues are, of course, a root cause of many of the problems with this template. It shouldn't depend on your characterization of the problem. Whether or not these things get fixed should not be up to the whim of one person, and thus dependent upon deficiencies in his or her vocabulary.

Note further that other units need fixing as well, such as

• {{convert|7|toe|disp=unit|sp=us}}      gives: tonnes of oil equivalent
• {{convert|3|MT|disp=unit|sp=uk}}      gives: metric tons
• {{convert|7|kt|disp=unit|sp=us}}      gives: kilotonnes

and since reassignment part that error message wasn't implemented, we do have

• {{convert|7|ktTNT|sp=us}}      gives: 7 kilotonnes of TNT (29 TJ)

and in the opposite direction, even with abbr=on, we get

• {{convert|29|TJ|ktTNT|sp=us|abbr=on}}      gives: 29 TJ (6.9 kilotonnes of TNT)

but for this, the "disp=unit" parameter is broken as well

• {{convert|7|ktTNT|sp=us|disp=unit}}      gives: kilotonnes of TNT

How many others are there in the same vein? Gene Nygaard (talk) 23:37, 4 February 2010 (UTC)

No offence Gene, but that spiel (and berating) was quite unnecessary. Next time, just say "Yes, I'd greatly appreciate it if you would change the template to allow this function". You know...honey vs. vinegar and all that. — Huntster (t @ c) 00:20, 5 February 2010 (UTC)

Been there. Done that. Obviously didn't work. So here's Plan B. Gene Nygaard (talk) 01:03, 5 February 2010 (UTC)

No, it should not depend on the whim of one person. The thing is that it's all protected I can't easily do anything with it. As I say, I'm all for the change. I was just trying to answer your question as to why sp=us doesn't give metric ton. I still don't see it as a spelling issue, though, you call it gasoline I call it petrol, you call them fries I call them chips, etc. etc. etc. They are not merely different spellings but completely different terms but, hey, let's leave that be since the sp parameter doesn't have to be strictly for spelling (in this sense) alone. As for the default's being for British-Australian-Canadian-New Zealand-Irish-etc. spelling as opposed to US spelling, it's no less appropriate than having it the other way round and if we are to have no dialect default (i.e. you'd have to specify either way) on this template, why should there be one on any? JIMp _talk·cont 10:46, 5 February 2010 (UTC)

No matter what you say, "ton(ne)s" is a spelling issue. Our newspapers might say "The USDA announced the sale of 60,000 tons of wheat to Algeria" and all Americans who care about sales of wheat to Algeria will know what is meant, but here on Wikipedia we should also be explicitly disambiguating those units. You might argue that this involves a little bit more than the spelling issue, but I don't see how that matters in the least. The one possible solution that many of us would be aware of and would expect to solve the problem is broken and doesn't work. It would never cause results contrary to the intentions of some editor who added "sp=us" to a template using tons—"long tons" and "short tons" and "pounds" and "troy ounces" are spelled the same in any variety of English. Furthermore, nobody's likely to try to use "365 meters ()" and expect to get both those numbers and that spelling mixture.

It needs fixing. Editors who run across this nasty template throwing British spellings into an article using American English, as it so often does, need to be able to rectify the problem by simply adding "sp=us". When the parameter is broken, most will likely just throw up their hands, say to hell with it, and leave the wrong spelling there. A few of the smarter ones will throw out the template and fix it in the text—which will work only until some damn fool comes along later and re-adds the template with the British spellings, something likely to happen sooner or later.

How other templates might handle this isn't particularly relevant except for their ability to demonstrate ways to deal with the problem; those that don't deal with it are no help at all. This is the widely used template under discussion here, and the one in need of fixing now. I doubt very much that there are any other templates which have caused thousands of articles to use improper varieties of English as this one has (the few hundred I've fixed hasn't alleviated the problem very much). But, for example, there are no defaults in {{Infobox ship}}. You choose to put the information in one of two related parameters: "Ship draft"/"Ship draught", "Ship honors"/"Ship honours", "Ship armor"/"Ship armour". The samples in the documentation, to be copied into an article and used there, include both parameters in each pair, and the one chosen determines the spelling used in the infobox. You are stuck with "cancelled" even if the text uses "canceled", but that isn't, in the strictest sense, a national varieties of English issue. Gene Nygaard (talk) 13:48, 5 February 2010 (UTC)

Okay Gene, so to make sure I understand what you're wanting...you want the default "tonne" to read "metric ton" if "sp=us" is used? If tonne and metric ton are the same thing, perhaps the term tonne could be done away with in favour of the (apparently) more internationally recognisable metric ton? Personally speaking, I don't understand the need for two terms that identify the exact same thing. This would have the additional benefit of doing away with the ambiguous "t" abbreviation and force folks to use MT, ST or LT. I'm sure a lot of Americans who don't know better use "t" for every instance of ton they apply, no matter the actual measurement. — Huntster (t @ c) 00:51, 6 February 2010 (UTC)

That would be fine with me. Let's get it done.

Note, however, that it has nothing to do with "knowing better" nor with Americans. Americans also use "t" for long tons in naval ships, as do many people in other parts of the world. And there is nothing wrong with doing so. There is no "knowing better" about it. The CGPM might define the symbol "t" as the one to use for the "metric ton/tonne", but so what? Short tons and long tons are outside their jurisdiction; they cannot tell us what the proper symbols for them are, and they don't try to do so. If they are stupid enough to use an ambiguous symbol for their units, that's their problem. Where it becomes a problem for us it that we often should be visibly disambiguating those units by spelling them out rather than using "t", but this convert template doesn't always let us do that (even though its documentation says that it should do so). Gene Nygaard (talk) 02:51, 7 February 2010 (UTC)

I do have a better idea, however; one that will obviate the need to fix the "sp=" parameter for tons. Let's do our part to eliminate the confusion of the twenty or so different units called "tons" that appear in Wikipedia articles. Let's only allow "tons" as input units, and never have "tons" of any sort as our output. Rather we should use only [prefix]joules or [prefix]watts or [prefix]newtons or cubic [prefix]meters/meters or [prefix]grams or pounds or British thermal units or cubic feet or pounds-force or whatever for output. Then once we get that accomplished, we can send a bot around to add "disp=output only" to all of various input-ton conversions. Then we won't have to worry about whether "sp=us" works with tons or not; the question will be moot. And in any case, that is starting to look like it would be a solution more easily accomplished than getting the broken "sp=" parameter fixed. Gene Nygaard (talk) 03:12, 7 February 2010 (UTC)

This is not the only template which (potentially) throws the wrong dialect into articles, fair point that it's widely used though. What's the solution? Default to American English? We'll have the same problem (just in the other direction). I'd argue that ditching tonne altogether (in favour of metric ton) would violate ENGVAR. Metric ton is never used where I'm from. I see the sense in the idea of not converting to tons (pounds, for example, would be simpler than long and short tons). JIMp _talk·cont 19:46, 8 February 2010 (UTC)

I'm in Canada, and as you say, metric ton is never used - it's always tonne. The fundamental problem, as I see it, is that the US uses its own unique spelling of SI units. The rest of the English speaking world uses tonne instead of metric ton, metre instead of meter, and litre instead of liter, etc. The other English-speaking countries decided to use French spelling for SI units so they always knew when they were using metric units and when they were using imperial ones. Apparently the Americans did not like this solution and insisted on using their own spelling instead.

So, I would say that when the SP=US parameter is used, you should always use American spelling (metric ton, meter, liter), and when it is not you should use the spelling everyone else uses (tonne, metre, litre). As usual, the Americans are out of step with the rest of the world, and as usual are quite obstinate about it, so let's give them their own parameter to make it all better.RockyMtnGuy (talk) 23:11, 8 February 2010 (UTC)

This isn't an SI unit. We would be much better off if our metric units of mass were always the SI units, with prefixes chosen appropriately. In any case, there are no international standards for the spelling of units which are part of SI. It is only the symbols for those units that have a uniform, international standard. Even though the Italians spell the unit chilogrammo, its symbol is still "kg". Gene Nygaard (talk) 15:29, 9 February 2010 (UTC)

No, tonne is not an SI unit, it is a non-SI unit accepted for use with the International System of Units - a fairly fine distinction. Other examples are the minute, hour, day, hectare, and litre. No there are no international standards for, spelling only national ones. However, there are really only two national standard spellings used in the English-speaking world - the American spelling, and the spelling used by all the other English-speaking countries.RockyMtnGuy (talk) 21:06, 9 February 2010 (UTC)

Sure--do you want to meet at the Canadian Tyre store and do some shopping? Do you need to stop for some petrol first? Gene Nygaard (talk) 23:16, 9 February 2010 (UTC)

What I meant was that there are really only two spelling systems for metric units used in the English-speaking world - American and everybody else. In Canada, anything related to automobiles is likely to use American spelling since the automobile industries are so tightly integrated, but that doesn't include metric units. Canadian metric spelling is taken from the official English translation of the French SI document rather than anything published in the US. In general, most Canadians speak a non-distinct dialect of American English which is virtually indistinguishable from that spoken in the Western US, but Canadians have increasingly been switching from American to British spelling in recent years, for some reason. RockyMtnGuy (talk) 03:10, 10 February 2010 (UTC)

If I were more grumpy, I'd suggest completely ignoring the desires of Americans for individuality and pain-in-the-assery and go with the most widespread and accepted version. — Huntster (t @ c) 23:16, 8 February 2010 (UTC)

{{edit protected}}

Here the current code for {{convert/t}}.

{{convert/{{{d}}}|{{{1}}}|{{{2|}}}|{{{3|}}}|{{{4|}}}|s={{{s|}}}|r={{{r}}}|u=t|n=tonne|o=LT ST|b=1000|j=3-{{{j|0}}}}}<noinclude>[[Category:Subtemplates of Template Convert]]</noinclude>

Here's the new code.

{{convert/{{{d}}}|{{{1}}}|{{{2|}}}|{{{3|}}}|{{{4|}}}|s={{{s|}}}|r={{{r}}}|u=t|n={{#ifeq:{{{r}}}|er|metric ton|tonne}}|h={{#ifeq:{{{r}}}|er|metric-ton|tonne}}|t=tonne|o=LT ST|b=1000|j=3-{{{j|0}}}}}<noinclude>[[Category:Subtemplates of Template Convert]]</noinclude>

... or if we want the default to go to pounds (as opposed to long and short tons) ...

{{convert/{{{d}}}|{{{1}}}|{{{2|}}}|{{{3|}}}|{{{4|}}}|s={{{s|}}}|r={{{r}}}|u=t|n={{#ifeq:{{{r}}}|er|metric ton|tonne}}|h={{#ifeq:{{{r}}}|er|metric-ton|tonne}}|t=tonne|o=lb|b=1000|j=3-{{{j|0}}}}}<noinclude>[[Category:Subtemplates of Template Convert]]</noinclude>

JIMp _talk·cont 08:04, 9 February 2010 (UTC)

 Done. Okay, I've committed the first version. If it's decided to default to something besides tons, let me know and I'll commit the second one. — Huntster (t @ c) 08:24, 9 February 2010 (UTC)

Thanks. Now when I see an article using

• {{convert|41520|t|LT}} → 41,520 tonnes (40,860 long tons)

I'll be able to fix it by simply adding "sp=us"

• {{convert|41520|t|LT|sp=us}} → 41,520 metric tons (40,860 long tons)

Now you can tackle

• {{convert|3.1|Å|pm|sp=us}} → 3.1 ångströms (310 pm)
• {{convert|3.1|Å|nm|sp=en}} → 3.1 ångströms (0.31 nm)
• {{convert|3.1|Å|nm|sp=us}} → 3.1 ångströms (0.31 nm)
• {{convert|3.1|angstrom|nm|sp=us}} → 3.1 ångströms (0.31 nm)
• {{convert|3.1|angstrom|nm|sp=en}} → 3.1 ångströms (0.31 nm)
• almost looks like this does something! {{convert|3.1|angstrom|nm|sp=sw}} → 3.1 ångströms (0.31 nm)

I'll leave it to our Canadian buddy and the rest of you to worry about being able to fix "sp=" to work here:

• {{convert|41520|MT|LT|sp=ca}} → 41,520 metric tons (40,860 long tons)
• {{convert|41520|MT|LT|sp=uk}} → 41,520 metric tons (40,860 long tons)

Gene Nygaard (talk) 15:57, 9 February 2010 (UTC)

There really is no such thing as Canadian spelling. Canadians use either American spelling or British spelling (unless they're French Canadians). For units, they will almost always use British spelling, so you could say that sp=ca is the same as sp=uk. In this case they would both use tonne instead of metric ton.RockyMtnGuy (talk) 21:17, 9 February 2010 (UTC)

What's the use of this? Get rid of disp=unit

I just noticed that Wikid77's Convert/3 option makes {{convert}} an even more egregious violator of the WP:ENGVAR rules than it has been, and it has already infected thousands of articles without the /3 option. If this stays, it'll get much worse:

• {{convert/3 |5|by|6|by|7|m|ft|sp=us}}     gives: {{convert/3|5|by|6|by|7|m|ft|sp=us}}
• {{convert/3 |5|-|6|-|7|L|in3|sp=us}}     gives: {{convert/3|5|-|6|-|7|L|in3|sp=us}}

Just like convert already does with tons, this option doesn't just default to British English, but it totally ignores the "sp=us" parameter. But this does it for "metres" and "litres" as well.

As far as using that to "disp=units" option goes, that's useless for any conversions on Wikipedia, triple or otherwise. You can see what units it gives you for the input by previewing it without setting abbr=on. Do you think Wikipedia editors are so stupid that they cannot distinguish the name of the unit from the number in front of it, if they see the number as well as the name? Doesn't make any sense whatsoever.

Furthermore, there are a number of other problems with this parameter:

It often doesn't work:

{{convert|7|C|disp=unit}} → °C

{{convert|7|K-change|disp=unit}} → K

It doesn't ever help you display units used only in output

{{convert|7|Gs}} → 7 gigaseconds (22 daa)

• but since {{convert|22|daa}} → 22 decares (0.022 km²; 0.0085 sq mi)
• you cannot use {{convert|22|caa|disp=unit}} → decares to figure out what the hell "daa" is supposed to mean in that first conversion. Gigaseconds to decares in a default conversion? Time units to area units? Sure, this idiotic template doesn't do even rudimentary dimensional analysis, but when it picks the default unit it shouldn't pick a unit that measures a different quantity.
• When "abbr=none" does work (it does here, but often doesn't), skipping the disp=unit parameter can tell you what that "daa" is supposed to be: {{convert|7|Gs|abbr=none}} → 7 gigaseconds (22 decades), but since that is used as an output unit only, you cannot use "disp=unit" to figure that out.

There doesn't seem to be much reason to keep disp=unit, even if the problems with the /3 option ignoring the spelling parameter are fixed. Gene Nygaard (talk) 12:00, 7 February 2010 (UTC)

• The option as "disp=unit" is needed to allow the Convert/3 format to determine the unit name or symbol for 3 amounts. The various options have been added, during prior years, to support actual article text, rather than support all hypothetical combinations of options. -Wikid77 07:10, 12 February 2010

You need to fix it in its hidden use, too. Why haven't you fixed the spelling (national varieties of English) issues? Why do we still improperly get "metres" and "litres" with the "sp=us" option set in

• {{convert/3 |5|by|6|by|7|m|ft|sp=us}}     gives: {{convert/3|5|by|6|by|7|m|ft|sp=us}}
• {{convert/3 |5|-|6|-|7|L|in3|sp=us}}     gives: {{convert/3|5|-|6|-|7|L|in3|sp=us}}

Furthermore, there is a big difference between "is needed for" and "is used for"; I'm sure there are various other ways that it could be done. But the real question is, how would it be used in article text? If you don't have any realistic use for it in articles, that should be made clear. Even if you cannot come up with a better way to make three-way conversions, this "disp=unit" option should never be included in the documentation of this template. Gene Nygaard (talk) 20:38, 14 February 2010 (UTC)

Sigfig ignored when converting temps

The sigfig parameter seems to be getting ignored when converting temps. For instance: {{convert|9|–|22|C|F|sigfig=2}} yields 9–22 °C (48–72 °F), and {{convert|30|C|F|sigfig=2}} yields 30 °C (86 °F). Otherwise it seems to be working fine with other units. – VisionHolder « talk » 16:21, 12 February 2010 (UTC)

Yes, it also appears to me to be ignored in the ranges. Can someone fix it?

sigfig=3 9–22 °C (48.2–71.6 °F)

sigfig=4 9–22 °C (48.20–71.60 °F)

sigfig=5 9–22 °C (48.200–71.600 °F)

Specifying location of rounding with respect to decimal point does not work with ranges either, though it does work for ranges of at least some other units:

{{convert|9|–|22|C|F|1}} → 9–22 °C (48.2–71.6 °F)

{{convert|9|–|22|C|F|2}} → 9–22 °C (48.20–71.60 °F)

{{convert|9|–|22|C|F|3}} → 9–22 °C (48.200–71.600 °F)

Not ignored in the conversion of a single reading; not good, either (probably loosely based on number of significant digits in equivalent absolute temperatures in kelvins or degrees Rankine rounded at same place with respect to decimal point as the input number was)> That's more of a problem of converting between scales with additive differences; the whole notion of significant digits isn't really appropriate for that (significant digits are only appropriate for multiplication and division), whether is in in meters (translation of axes) or degrees Celsius or whatever. It's generally better to specify the location of the decimal point in those cases.

sigfig=3 30 °C (86.0 °F)

sigfig=4 30 °C (86.00 °F)

sigfig=5 36.234567 °C (97.222 °F) (sigfig only affects output number, not input number)

sigfig=5 41.234567 °C (106.22 °F)

Seems okay for temperature intervals

sigfig=3 30 °C (54.0 °F)

sigfig=4 30 °C (54.00 °F)

sigfig=5 30 °C (54.000 °F)

sigfig=5 41.234567 °C (74.222 °F)

Gene Nygaard (talk) 19:22, 12 February 2010 (UTC)

• Okay, I have changed Template:Convert/Dual/LoffAoffDxSoffT to handle the sigfig=n parameter in temperature-range conversions. However, trailing zeroes are still dropped during rounding, so this template will need to use the special number-rounding templates which display trailing zeroes in numerals.

sigfig=4:   9–22.4320 °C (48.20–72.38 °F)

sigfig=5:   9–22.4320 °C (48.200–72.378 °F)

sigfig=6:   9–22.4320 °C (48.2000–72.3776 °F)

sigfig=7:   9–22.000 °C (48.20000–71.60000 °F) ← dropped all trailing zeroes

The standard MediaWiki "round" operator thinks it's a "neat feature" to drop trailing zeroes, regardless of how many digits are requested, so it even causes a dollar-and-cents amount to drop ".00" (such as "$100.00" currently rounding as $100). This is another reason that Convert might seem overly complex: it has to reverse the effects of "smart-ass" software that thinks "no one on earth would ever want those trailing zeroes" (not even a banker?). Such problems are typical wiki-spastic notions in that software. Remember, MediaWiki was formerly so backward that templates didn't even allow parameters. So, let's be thankful that all these conversions are even possible at all. -Wikid77 (talk) 09:33, 13 February 2010 (UTC)

There still appears to be a problem for the two examples originally posted.

• {{convert|9|–|22|C|F|sigfig=2}} yields 9–22 °C (48–72 °F) → should yield (48–72 °F), not (48.2–72 °F)
• {{convert|30|C|F|sigfig=2}} yields 30 °C (86 °F) → should yield (86 °F), not (90 °F)

However, in the latter case, changing sigfig to 3 yields (86 °F). So it looks like it's still a little off. – VisionHolder « talk » 15:41, 13 February 2010 (UTC)

• Okay, I have submitted edit-requests to the rounding templates for single-temperature conversions. Thanks for taking time to check those conversions. See the corrections to using {ordomag|( {5} )} in those 2 talk-pages:

• Correction for positive temperatures in: Template talk:Convert/sroundT0.
• Correction for negative temperatures in: Template talk:Convert/sroundT1.

Those changes will likely have been applied now. To allow trailing-zeroes in temperature ranges, we will need to use {rnd|amount|#dec} rather than "round" as an infix operator. -Wikid77 (talk) 19:10, 14 February 2010 (UTC)

I said above that sigfig worked for temperature differences. However, I'd forgotten about the related problem with the bad default rounding for temperature differences, until I saw A_di_M's example below:

• {{convert|9|F-change}} → 9 °F (5.0 °C)

Can that be fixed too? (Note that the temperature-change conversions are strictly multiplication; no additive offsets involved here.) Other conversions do default to an extra digit of precision when the input only has a single digit known to be significant—IIRC that is the documented working of the template, so this should be fixed the same way, I'd say. Not two extra digits as it does now: it should be 5.0 °C rather than 5.00 °C or even the best-in-a-more-absolute-sense 5 °C. Gene Nygaard (talk) 20:17, 14 February 2010 (UTC)

Temperature and temperature difference

Perhaps there should be some acknowledgement of the distinction between temperature and temperature difference, if only in the documentation. A winter temperature of 9.0°F is -12.8°C; but a house which is 9.0°F warmer is 5.0°C warmer. Pol098 (talk) 17:34, 14 February 2010 (UTC)

• {{convert|9|F}} → 9 °F (−13 °C)
• {{convert|9|F-change}} → 9 °F (5.0 °C)

― A._di_M. (formerly Army1987) 17:38, 14 February 2010 (UTC)

• {{convert|9|°F}} → 9 °F (−13 °C)
• {{convert|9|°F-change}} → 9 °F (5.0 °C)

Oops! Another big look-and-feel problem. Gene Nygaard (talk) 20:42, 14 February 2010 (UTC)

Then see Template:Convert/doc and search the page for "change". Nothing there about this conversion

So let's try Template:Convert/list of units/temperature. Suprise, surprise: Nothing there either.

Undocumented features are worthless. Nobody can find them to use them. There's not a whit of a guarantee that it will continue to work in the future. Gene Nygaard (talk) 20:50, 14 February 2010 (UTC)

I was going to just fix it, but even the documentation itself is a One Thousand and One Nights maze of transclusions. Gosh. ― A._di_M. (formerly Army1987) 22:19, 14 February 2010 (UTC)

• Added into Convert/doc: Finally, I just appended 2 rows in the documentation table about temperatures, as "Celsius change" and "Fahrenheit change". I must agree (as above): the Convert/doc table-templates seem just about as bizarrely convoluted as the Convert subtemplates, and I couldn't determine any meaningful use for the other columns in the table. I realize all this ultra-mondo-complificationer-alizationism might seem extremely demoralizing, but keep thinking of ways to simplify and improve it. Thanks. -Wikid77 (talk) 02:22, 15 February 2010 (UTC)

I hadn't realized what a total mess of transclusions that is. Somebody must have gone to the stub-sorters for advice before creating our documentation.

Documentation cleanup

From thread drift in #Temperature and temperature difference section

A. di M.: "I was going to just fix it, but even the documentation itself is a One Thousand and One Nights maze of transclusions. Gosh."

Wikid77: "I must agree (as above): the Convert/doc table-templates seem just about as bizarrely convoluted as the Convert subtemplates, and I couldn't determine any meaningful use for the other columns in the table. I realize all this ultra-mondo-complificationer-alizationism might seem extremely demoralizing, but keep thinking of ways to simplify and improve it. Thanks."

A couple of suggestions for starters:

1. Use "symbol" rather than "symbol/abbreviation" or "abbreviation" in the headers. While, in some contexts, some people might quibble about making a distinction between symbols and other abbreviations, it doesn't matter here. What we need is to narrow that column up considerably.
2. Get rid of the "system" column.
   • Alternative: retain only "metric" and "other"
3. Reduce the maze accordingly. That will eliminate the bottom level of transclusions, or at least greatly reduce it. There aren't enough units in any category to make it very difficult to find something if that is reduced.
4. Don't express any conversion factors with more than 14 decimal digits, the most that is actually used in the calculations. That will also reduce the width of those columns. Better yet, reduce them to 8 significant digits (more than enough for 99.9999% of the conversions ever needed, on Wikipedia or in the real world), and we won't have to worry about updating the documentation if a minor change is made in the precise factor. A footnote in the tables can explain that only x digits are shown, and the rare user who has any need to see what more precise number is used can look at that conversion subpage and find it; it doesn't need to be in the general documentation. Gene Nygaard (talk) 16:04, 15 February 2010 (UTC)

There are probably several ways that are more of a revamp. What we need in the documentation is to show the units that can be converted, and the parameters to use to get them. I'll through out some suggestions; they might not all be compatible with each other. Think about them; try to figure out what will work.

1. Move the conversion factors to one list separately accessible from the main documentation page.
   • Only list separate units; there's no reason to include each prefix option which only involves moving the decimal place.
2. Make it so that the output does not depend on the particular form of the input; all spelling and variations in the symbols and their spacing and punctuation and the like should be accomplished through other parameters.
   • Or at least, all except the ones where the symbols used for input-unit parameter differ, as in "km/L" vs. "km/l".

Gene Nygaard (talk) 17:56, 15 February 2010 (UTC)

Requesting extra parameter

It would be useful to have a parameter which allows height or length in feet/inches to be displayed as X' YY" rather than X ft YY in. These symbols are commonly used. — Twas Now ( talk • contribs • e-mail ) 18:55, 17 February 2010 (UTC)

That wouldn't be done with a parameter, however, these symbols may be widely used but are not so easy to read for metricated people which is why MoS recommends they not be used. JIMp _talk·cont 19:46, 17 February 2010 (UTC)

Of course it would be done with a parameter. It would be done with a parameter even if you followed the ill-advised practice of using the unnamed parameter identifying the input units fpr that purpose, something already done far too often in this template. We need to get rid of the ones where that is done now. Gene Nygaard (talk) 23:04, 17 February 2010 (UTC)

I would advise against having 9' 10" style output. I was born the year Australia went metric, so as a kid I had to deal with both metric units and units that the adults found comfortable but newer generations (in Australia) don't understand what all the tick marks are for.  Stepho  (talk) 04:36, 18 February 2010 (UTC)

• For now, if a quotation contains 9' 10", just use "disp=output only" for the editorial comment of the converted amount:

• "the 10-foot board, they used, was actually 9' 10" [3.02 m] in length"

The comment in "[...]" is specified by "[{{convert|9|ft|11|in|m|abbr=on|disp=output only}}]" . In general, "Wikipedia does not subset reality" so we must be prepared to quote almost anything (except phone, credit-card numbers, etc.), yet we need to be careful not to encourage conflicts with the MoS. I suppose we could have a unit as "ft&tics" but even that unit-symbol code is a matter for debate here. -Wikid77 11:55, 20 February 2010

Yeah, your suggestion is probably the best available, and I don't see any need to go further with a special unit. Though, the hardcore quote folks will likely argue that any conversion, even inside brackets, takes away from the directness of the quote. — Huntster (t @ c) 05:21, 21 February 2010 (UTC)

Category:2010 Convert unit subtemplates

20-Feb-2010: Beyond hoping to get all new subtemplates documented into {{Convert/doc}} and such, we have been tagging the new templates with yearly category-names. Hence, also look for newer templates under:

• Category:2009 Convert unit subtemplates - those created in year 2009
• Category:2010 Convert unit subtemplates - those created in year 2010

If anyone knows of other new Convert subtemplates, please try to update them to link those categories for each year. -Wikid77 11:55, 20 February 2010

Would it not be better to categorise the subtemplate by type rather than by their date of creation? If the 3,114 members of Category:Subtemplates of Template Convert were pushed down in to Category:Subtemplates of Template Convert (Length), Category:Subtemplates of Template Convert (Area), etc. Maintenance would be easier, as would spotting errors, and missing or useless conversions. Iain Bell (talk) 11:05, 21 February 2010 (UTC)

New density units lb/USgal & kg/L

20-Feb-2010: I have completed 2 new subtemplates for density, to handle pounds-per-US-gallon & kilograms-per-litre (kg/L):

• {{convert|5|lb/USgal}}   gives:   5 pounds per US gallon (0.60 kg/L)
• {{convert|8.4|lb/USgal}}   gives:   8.4 pounds per US gallon (1.01 kg/L)
• {{convert|2|kg/L}}   gives:   2 kilograms per litre (17 lb/US gal)
• {{convert|7|kg/L|sp=en}}   gives:   7 kilograms per litre (58 lb/US gal)
• {{convert|8|kg/L|sp=us}}   gives:   8 kilograms per liter (67 lb/US gal)

I don't know if those units have been discussed before, or how the imperial gallon should be handled, so I haven't used those conversions in any articles yet. -Wikid77 11:55, 20 February 2010

No, we already had "lb/USgal", added by Jimp last August. Don't remember what it defaulted to; and, of course, it wasn't documented.

Now, after you "fixed" his orphan, we have this ludicrous nonsense

18.355 pounds per US gallon (2.2 kg/m³) [ corrected 23-Feb-10 ]

18.355 pounds per US gallon (2,199.4 kg/m³) [ live result ]

18.355 pounds per US gallon (2.1994 kg/L)

That includes a default rounding problem in the first one, of course. We can change the second one to convert one place after the decimal point, too:

18.355 pounds per US gallon (2,199.4 kg/m³)

18.355 pounds per US gallon (2.2 kg/L)

So I guess now 1 m³ = 1 L, in the template:convert universe!

Why doesn't that surprise me?

But look what happens when we try to change the first one to have three places after the decimal point:

Specifying the rounding to three places after the decimal point gives us:

{{convert|18.355|lb/USgal|3|kg/m3}}→18.355 pounds per US gallon (2.199 kg/L)

{{convert|18.355|lb/USgal|3|kg/L}}→18.355 pounds per US gallon (2.199 kg/L)

Now, even though I asked for "kg/m3" in the first one, I still get "kg/L".

We can, of course, also get

1 pound per US gallon (201.97402597402 lb/cu yd)

1 pound per cubic yard (0.0049511316872428 lb/US gal)

Which

1. is off by a factor of 1,000; it implies that 0.20197318211872 U.S. gallon is a cubic yard. However, (36³ in³/yd³)/(231 in³/USgal)) = 46656/231 USgal/yd³ = 201.97402597402597402597402597403 USgal/yd³
   • actually off by a facor of 1000.004178+
2. has the problem of a missing space in the output "cu yd"

Gene Nygaard (talk) 01:26, 22 February 2010 (UTC)

The good news is that most of the above problems are simple fixes. You've already fixed Jimp's problem of having the conversion factor for lb/USgal inverted from the correct-but-for-the-decimal-point one you have now. You could, like he did, divide both numerator and denominator by 77×10ⁿ to get his numbers (inverted), and could even take it to the logical step of getting it to a division of two integers so that their conversion to binary doesn't introduce errors before the division, but it won't matter—you already have more than twice as much precision as we'll ever need. I could fix the current problems myself, except one I haven't figured out yet. But like I told Huntster, I'm not going to start doing that until I see some evidence of a general commitment to fixing the numerous problems this ugly behemoth has now.

Now let's get into the bigger issues:

Look and feel problems

Contrast {{convert|5|l|USgal|abbr=on}}→5 L (1.3 US gal)

with {{convert|5|kg/l|lb/USgal|abbr=on}}→5 kg/l (42 lb/US gal)

Contrast {{convert|5|L|U.S.gal|abbr=on}}→5 L (1.3 U.S. gal)

with {{convert|5|kg/L|lb/U.S.gal|abbr=on}}→5 kg/L (42 lb/U.S. gal)

Contrast {{convert|5|km2|mi2|abbr=on}}→5 km² (1.9 sq mi)

and {{convert|5|km²|mi2|abbr=on}}→5 km² (1.9 sq mi)

with {{convert|5|km3|mi3|abbr=on}}→5 km³ (1.2 cu mi)

and {{convert|5|km³|mi3|abbr=on}}→5 km³ (1.2 cu mi)

with {{convert|5|kg/m3|lb/USgal|abbr=on}}→5 kg/m³ (0.042 lb/US gal)

and {{convert|5|kg/m³|lb/USgal|abbr=on}}→5 kg/m³ (0.042 lb/US gal)

and all the permutations of the above

Missing conversions—same size as kilograms per liter

There are numerous other units which are, in modern definitions (with 1 litre (1,000.00000 cm³) rather than the confusing situation when I first learned these units, back when that wasn't true), the same as kilograms per liter:

• The most commonly used density units, by far, on Wikipedia aren't the one you have (kg/L), but rather the equivalent grams per cubic centimeter (g/cm³).
• kilograms per cubic decimeter (kg/dm³)
• megagrams per cubic meter (Mg/m³)
• grams per milliliter (both g/ml and g/mL symbols, to allow consistency within a Wikipedia article)
• metric tons per cubic meter/tonnes per cubic metre (all of the others have national varieties of English issues to be dealt with too).

Missing conversions—other metric units

• grams per liter (both g/L and g/l, same size as kg/m³, and like them common for gases)
• grams per cubic meter (g/m³) (most likely to be used with numbers in scientific or engineering notation)

Missing conversions—English units

• pounds per cubic foot (lb/ft³) (the most common English units in density; the ones we already have in convert, lb/yd³ improperly expressed as "lb/cuyd", are pretty much limited to the construction industry and civil engineering, for things such as density of gravel and aggregate).
• pounds per cubic inch (lb/in³, are used on Wikipedia, common in mechanical engineering for things such as steel)
• slugs per cubic foot (are used on Wikipedia; whether it is common enough to be included in this template is debatable)

but we don't need their equivalent in gravitational inch-pound force-second system (preferred system for NASA engineers, for example), pound-force seconds squared per inch to the fourth power (1 lbf·s²/in⁴ = 12⁴ slug/ft³ = 20,376 slug/ft³). Let's get over the notion that just because a conversion can be done, we should include it in this template.

• ounces per cubic inch (oz/in³)

Others to consider

• your already identified lb/imp gal
• metric tons per oil barrel
• degrees API (°API)
• millions of metric tons per teaspoon (just kidding; we do see strange things like this for density of neutron stars and the like, but don't need to be able to handle them in template:convert)
• perhaps conversions based on the 1901–1964 definition of the liter/litre (but not unless there is a specific showing that this would be useful on Wikipedia; that requires both measurements of density stemming from that time period, and densities measured precisely enough so that a one-part-in-35,000 difference in conversion factors would make a difference in the result)
• ounces per fluid ounce (either U.S. or imperial)
• pounds per Winchester bushel (note that Canada as well as the United States uses bulk density in these units as a quality factor in grading grains such as wheat and barley, even though the Winchester or U.S. bushel is slightly different from the imperial bushel); to open another can of worms, you will also see kilograms per hectolitre in this context.

Gene Nygaard (talk) 15:05, 22 February 2010 (UTC)

• Okay, thanks for listing all those details. I have reworked the kg/L as 1/1000 of kg/m3, see the subtopic below: #Redid density units lb/USgal & kg/L. -Wikid77 17:39, 23 February 2010

Redid density units lb/USgal & kg/L

23-Feb-2010: I have reworked some subtemplates for density, corrected by a factor of 1000x, to handle pounds-per-US-gallon & kilograms-per-litre (kg/L):

• {{convert|1000|kg/m3|kg/L}}   gives:   1,000 kilograms per cubic metre (1.0 kg/L)
• {{convert|5|lb/USgal}}   gives:   5 pounds per US gallon (0.60 kg/L)
• {{convert|8.4|lb/USgal}}   gives:   8.4 pounds per US gallon (1.01 kg/L)
• {{convert|2|kg/L}}   gives:   2 kilograms per litre (17 lb/US gal)
• {{convert|7|kg/L|sp=en}}   gives:   7 kilograms per litre (58 lb/US gal)
• {{convert|8|kg/L|sp=us}}   gives:   8 kilograms per liter (67 lb/US gal)
• where {{convert|1|kg|lb|9}}   gives:   1 kilogram (2.204622622 lb)

Converting to other units:

• {{convert|1|kg/L|g/cm3}}   gives:   1 kilogram per litre (1.0 g/cm³)
• {{convert|4|kg/L|g/cm3}}   gives:   4 kilograms per litre (4.0 g/cm³)

The correction was based on the calculation that all new Convert subtemplates for density should be normalized to 1 kg/m³ (has internal parameter b=1.0), so for kg/L then b=1000.0, and for lb/USgal then b=(453.592370380378 / 3.785411784).

I still haven't created density templates for the imperial gallon, so I haven't used those conversions in any articles yet. I apologize that it takes me 3 days to find time to rework these issues. -Wikid77 17:39, 23 February 2010

I tweaked some of your numbers. Gene Nygaard (talk) 14:23, 24 February 2010 (UTC)

Overview at WP:Convert

24-Feb-2010: I have created an essay titled "WP:Convert" to provide an overview of all issues about Template:Convert, including plans for future updates, and instructions for custom-tailoring the subtemplates, beyond the basic documentation. As you might know, when information does not fit within a single talk-page, template or article, it can be described as an essay in Category:Wikipedia essays, as a last resort. -Wikid77 13:26, 24 February 2010

Very nice. Expand to your heart's content. Once it is fleshed out, do you want to place a link to it prominently in the /doc page? This may allow the documentation page to be trimmed down a bit from its current, ahem, unwieldy length. If I may suggest, though: try to keep the tone neutral...let this be a more in-depth user guide to the template, rather than an essay for pointing out flaws and shortcomings. I believe your other Convert essay can safely be held in reserve for that purpose ;) — Huntster (t @ c) 00:15, 25 February 2010 (UTC)

Density overview at Convert/density

24-Feb-2010: I have created an overview subtemplate as {{Convert/density}} to cover issues about density conversions. Because Wikipedia talk-pages do not yet have "topic streams" as in a chat forum, the typical discussions of topics are all jumbled together. However, a subpage can be created to focus on issues about just a single topic. In this case, the subpage is "/density" to focus on density conversions:

• Template:Convert/density - provides an overview of density issues
• Template_talk:Convert/density - talk-page for density issues, beyond Template_talk:Convert.

That talk-page has a copy of the above density issues, requesting more subtemplates for densities as g/cm3, kg/dm3 or lb/cuft.
Although the prefix "Template:" gives the impression of being a page to be included within an article, that prefix also applies to any subpage, which must be tagged as "non-transcluded". Wikipedia currently has limited use of subpages, but the concept could be extended. For example, "London/scenes" could be a subpage of the article "London" but showing scenes of the city, as an image-based page, rather than the current focus (or text-bias) that articles should be text with minor images inserted. Similarly, "London/maps" or "London/festivals" could be created as "sub-articles" that focus on other aspects of the city, rather than try to squeeze the main article to fit a minimal description of the city, squeezed with just 2 maps or a short list of 20 festivals. The same concept applies to templates, where {{Convert/density}} focuses on conversions about density, allowing ample space for a dedicated, long-term discussion. -Wikid77 (talk) 13:27, 24 February 2010

I also fixed density for Template:Convert/lb/cuin. -Wikid77, 14:43, 24 February 2010

It doesn't really matter for what you have done, but the "London" discussion above is irrelevant and wrong. Subpages have been disabled in the main article space; slashes used there are just part of an article name. (Even if you created "London/scenes" it wouldn't have a link back to the "London" article just below the article name; contrast that with the link back to Template:Convert on the Template:Convert/density page.)

If everyone is in agreement that this is the way we should go, we should have links to those Template/Template talk subpages on this talk page. We might transclude those discussions here, but I'd suggest not doing so. We should line up a bot for periodically archiving stale discussions on those talk pages, unless it is done automatically. We should have some criteria for the creation of such pages and standards for how they are named. Gene Nygaard (talk) 17:09, 24 February 2010 (UTC)

• That's fine; we perhaps can define guidelines in a subpage named "{{Convert/subpages}}" - see next topic. -Wikid77, 23:14, 24 February 2010

Setting guidelines for Convert subpages

24-Feb-2010: For years, article talk-pages have used subpages to split the discussion into special topics, such as the U.S. NRHP. For Convert, we could have an anchor, or base, subpage as {{Convert/subpages}}, which would define the guidelines for creating other subpages. In general, there are not many issues about subpages for worry:

• This talk-page could have a top-box that links the major subpages.
• If a subpage gets created with an awkward name, then it could be move-renamed into a better name.
• Once discussions are split to subpages, they tend to be shorter and don't need auto-bot-archiving of old topics. After several months, old topics could be hand-archived into an archive page. Perhaps topics on subpages tend to be more focused on making changes, rather than just broad speculation, so the discussions tend to stay too short to archive, even after years.

However, having a central "Convert/subpages" would help other users to see how the talk-page issues are being split for a more productive focus on each topic. Also, because Convert has over 3,140 subtemplates, then Convert/subpages could help clarify which subpages are for talk-topics versus which are converter subtemplates. -Wikid77, 23:14, 24 February 2010

This seems like a logical idea, especially considering the great traffic that this talk page already sees. I would suggest, though, that no more than one subpage be created, set aside just for subtemplate issues, or issues relating to code updates or more sweeping changes to the architecture (aka, stuff that regular editors will likely have no interest in). I don't see a pressing need for multiple subpages at this point. — Huntster (t @ c) 00:07, 25 February 2010 (UTC)

• I have created a top-box to list the major subpages, using a wikitable with "class=infobox width=240px" alongside the Table of Contents. Width is 240px to avoid overlapped boxes, and "class=infobox" forces right-side placement, but requires "colspan=2" for the text to span both infobox columns. I think we will need a few multiple subpages, otherwise we are just exporting some clutter into a 2nd sub-clutter, rather than focusing each subpage as a long-term discussion to resolve each major issue as a dedicated discussion. I concur with keeping technical topics separate, but that varies with each user: I see reducing 2,500 subtemplates as "non-technical" or 32m=100ft as wrong anywhere in the world, whereas others see the need to emphasize 13-digit precision by "square root of 3" and others demand a minus sign have 9 pixels, not 5, to deprecate 50-year computer standards. So, on balance, it's all technical here. -Wikid77 (talk) 09:24, 25 February 2010 (UTC)

Better precision for Convert/ft

25-Feb-2010: Back on 30Oct09, I began a proposed higher-precision for m-to-feet conversions, in Template:Convert/ft/sandbox. The basic problem has been Convert auto-rounding gives 32m=100ft rather than 105ft (and such). Now, 3 months have passed to consider the issue. Compare the increased precision of the ft/sandbox version:

• {{convert|30|m|ft}} →   30 metres (98 ft) & ft/sandbox →   30 metres ()
• {{convert|31|m|ft}} →   31 metres (102 ft) & ft/sandbox →   31 metres ()
• {{convert|32|m|ft}} →   32 metres (105 ft) & ft/sandbox →   32 metres ()
• {{convert|64|m|ft}} →   64 metres (210 ft) & ft/sandbox →   64 metres ()
• {{convert|3000|m|ft}} →   3,000 metres (9,800 ft) & ft/sandbox →   3,000 metres ()
• {{convert|3100|m|ft}} →   3,100 metres (10,200 ft) & ft/sandbox →   3,100 metres ()
• {{convert|3200|m|ft}} →   3,200 metres (10,500 ft) & ft/sandbox →   3,200 metres ()
• {{convert|6000|m|ft}} →   6,000 metres (20,000 ft) & ft/sandbox →   6,000 metres ()
• {{convert|6000|m|ft|0}} →   6,000 metres (19,685 ft) & ft/sandbox →   6,000 metres ()

The amounts are still auto-rounded, such as 6000 m ~= 20,000 ft, but the rounding is better as giving 32m=105ft or similar amounts. Inside of Template:Convert/ft/sandbox, the default precision is set as j=-0-{{{j|0}}}. It works, so I wonder if anyone objects to submitting ft/sandbox for edit-protect update as the current version of Convert/ft. The impact has been minimal because few articles contain numbers like 32m=100ft, and Wikipedia has contained so much other bogus stuff like "the worst damage from Katrina happened in New Orleans" (not all those Mississippi towns that flooded over 90% in hours not days?). -Wikid77 11:43, 25 February 2010

I strongly object. Will explain later. Keep the j factors as the common logarithm of b, as they have been. Note also that part of the default rounding includes an extra, not-necessarily-warranted digit when there is only one clearly significant digit in the input (e.g., your 30 m --> 98 ft). That must take place somewhere in the rounding routines; it doesn't depend on the j factor. Gene Nygaard (talk) 13:09, 25 February 2010 (UTC)

Okay, figure out the best method for dealing with this problem and I'll commit the changes. I agree that 32 should not equal 100, but I'll leave it to your two superior minds to determine the best route in addressing the issue. Note that I myself don't see an issue with Wikid's proposal, but I'll take your word for it. — Huntster (t @ c) 13:19, 25 February 2010 (UTC)

Some preliminary questions for Wikid77:

Can you offer a theoretical basis for your change?

Do you even understand why logarithms might be useful in this context?

• First, in theory, there's no rush, because people find many problems in Wikipedia & the results "(100 xx)" are rare. The change to "j= -0" (from j=-0.5...) adds just a half-digit of precision, and in theory, it would be better to be sometimes over-precise rather than 5% wrong (105ft/100ft). -Wikid77, 01:19, 26 February 2010

Have you checked the limits of where your change is effective?

When do you stop getting the extra digit? Where would you like that to happen? Are the two the same?

• Setting j=-0 works best for integers, whereas fractions would get too much precision as the extra digit, so the j value needs to be zero only for integers. See far below: #Better integer precision for Convert/ft. -Wikid77, 2 March 2010

Have you checked other conversions for similar problems?

Do you have any reason to believe that the problem you perceived is specific to conversions involving feet? Have you tried other units?

• The problem occurs in many conversions, but using the 80/20 rule, we try to fix the most frequent problems first. I already fixed rounding in ft&in, so m-to-ft is next, then perhaps kg-to-lb, to avoid the potential shock of fixing all the rounding at the same time. -Wikid77, 01:19, 26 February 2010

I strongly suspect that the solution lies elsewhere than in changing the j parameter for feet. I'll start working on the answers to the above questions, too. Gene Nygaard (talk) 14:58, 25 February 2010 (UTC)

Wikid77, can you set up a sandbox test for the {{Convert/round}} before Huntster's changes[1] to it? I can't think of a simple way to do it. This used to work a lot better than it does now, and the change isn't due to a problem with the j factors. Let's find out where it is.

Or maybe it would be easier to get Huntster to undo that change long enough for us to check out if it makes a difference in the conversions Wikid77 raised questions about.

Or does somebody know where else in the stream the changes might have taken place? Gene Nygaard (talk) 15:22, 25 February 2010 (UTC)

Note that 31 metres (102 ft) is no different from 46 kilograms (101 lb) or 47 kilograms (104 lb).

Yet we do get 84 imperial gallons (101 U.S. gal) and 85 imperial gallons (102 U.S. gal). Why is that different?

Going off half-cocked, and trying to fix what is misperceived as a problem with the j parameter for feet, isn't the way to fix this problem. Gene Nygaard (talk) 15:34, 25 February 2010 (UTC)

More examples

31 kilometres (102,000 ft)

27 U.S. gallons (100 L)

But this works better

84 feet (1,010 in)

Gene Nygaard (talk) 15:59, 25 February 2010 (UTC)

Yes, if changing back won't be detrimental to operations, then I'll change back to the old version for a little while. Just let me know when you want it done. — Huntster (t @ c) 16:12, 25 February 2010 (UTC)

I've made a little table for testing. If you or Wikid77 or anybody else want to add some, do it fairly quickly. Then change to old version to see if any of these come out different . If not (or at least not outside the ft/sandbox examples), then the problem is elsewhere. But if any are different, it warrants closer scrutiny as to how the changes affected that.

I was going to use "disp=output only". But, surprise! It's broken, like so many things here. Why don't these work?

{{convert|84|impgal|U.S.gal|disp=output only}} → 101 U.S. gal

{{convert|27|U.S.gal|L|disp=output only}} → 100 L

Gene Nygaard (talk) 17:27, 25 February 2010 (UTC)

Table for testing changes in Template/convert/round

argument	current result	coded convert for testing abbr=on
convert|31|m|ft	100 ft	31 m (102 ft)
convert|63|m|ft	210 ft	63 m (207 ft)
convert|65|m|ft	210 ft	65 m (213 ft)
convert|31|m|ft/sandbox	102 ft	31 m ()
convert|63|m|ft/sandbox	207 ft	63 m ()
convert|46|kg|lb	100 lb	46 kg (101 lb)
convert|84|impgal|U.S.gal	101 U.S. gal	84 imp gal (101 U.S. gal)
convert|32|km|ft	100,000 ft	32 km (105,000 ft)
convert|27|U.S.gal|L	100 L	27 U.S. gal (100 L)
convert|84|ft|in	1010 in	84 ft (1,010 in)

Okay, test complete. There were no differences in any of your above table results. Here are the results just for transparency's sake:

Table for testing changes in Template/convert/round 
argument 			current result	coded convert for testing abbr=on
convert|31|m|ft 		100 ft		31 m (100 ft)
convert|63|m|ft 		210 ft		63 m (210 ft)
convert|65|m|ft 		210 ft		65 m (210 ft)
convert|31|m|ft/sandbox		102 ft		31 m (102 ft)
convert|63|m|ft/sandbox		207 ft		63 m (207 ft)
convert|46|kg|lb 		100 lb		46 kg (100 lb)
convert|84|impgal|U.S.gal 	101 U.S. gal	84 imp gal (101 U.S. gal)
convert|32|km|ft		100,000 ft	32 km (100,000 ft)
convert|27|U.S.gal|L		100 L		27 U.S. gal (100 L)
convert|84|ft|in		1010 in		84 ft (1,010 in)

— Huntster (t @ c) 17:55, 25 February 2010 (UTC)

• Again, let's remember "there's no hurry on this" - Wikipedia's rampant vandalism has increased the reader tolerance for problems (some jokes have stayed in articles 3 or 11 months). I don't mind trying to find a long-term solution, with the basic understanding that 32 should be converted between 31.5 and 32.5, in theory for measurements, so for metres, 31.5–32.5 metres (103–107 ft) and hence 105ft is between 103-107 but 100ft isn't. Others in these discussions have recommended to "err on the side of extra precision not less" as a guideline. -Wikid77 (talk) 01:23, 26 February 2010 (UTC)

World uses shifts/factors not divisors

26-Feb-2010: Although Convert has been developed to handle many systemic problems in MediaWiki math (such as MediaWiki always rounding $100.00 as $100), one of the confusing issues is:

Convert bases the conversions on divisors as parameter {b}, rather than the typical use of "conversion factors" and "shift amounts".

For that reason, I began setting {b} (within subtemplates) as inverted, b=1/f, where f would be a normal person's conversion factor. Also, because {b} is a divisor (not a multiplier factor), that's why the logarithm is negative, because the result is being adjusted by division, hence subtracting the logarithm as negative {j}, whereas a factor would add the logarithm to indicate multiplication for more digits. I am stating these issues to help clarify how the precision, of significant digits, is being determined inside Convert.

Meanwhile, let's consider, for a minute, how conversions would be done, in a more generalized manner, using "conversion factors" and "shift amounts" as in a typical mathematical transform. To convert an amount x-to-y (such as a temperature), it is necessary to shift x (by +32 or -32), then multiply by the conversion factor (f), then shift the result (by +32?). The general formula is:

• General conversion x-to-y units:   y = (x + a)*f + c
• Fahrenheit conversion C-to-F degrees:   F = (C+0)*1.8 + 32

Instead of that typical formula, Convert has no shifts of a or c (for -32 or +32), and instead of the conversion factor f, the Convert math uses a divisor {b} as the inverse of f, or b=1/f. Therefore, most people think, "WTF is friggin {b}?" and no wonder there are 1,400 customized subtemplates for temperatures because conversion requires shifting by -32/+32 and a divisor {b} can't perform shifts. So, a whole massive group of subtemplates were created for temperatures to hard-code -32 or +32 because Convert had no general shift amounts, as an a or c.

I hope that clarifies the unusual practice of dividing by {b} and subtracting the logarithm as a negative {j} to adjust the precision of the result. The emphasis is on the unusual divisor {b}, and therefore, expect the precision, of the result, as also being determined in an unusual manner that most people would not understand. I don't have time to analyze everything, now, so that's why I explained this aspect, along the way, towards fixing the precision values. -Wikid77 (talk) 05:54, 26 February 2010 (UTC)

No, now you've really got me really confused.

You say "I began setting {b} (within subtemplates) as inverted, b=1/f, where f would be a normal person's conversion factor." and "instead of the conversion factor f, the Convert math uses a divisor {b} as the inverse of f, or b=1/f".

But I see b = f in the templates. They have my "normal conversion factor". Jimp did have the "convert/lb/USgal" factor inverted; it didn't work with the rest of convert. The "normal conversion factor" to be is the factor you'd need to multiply the input by to get the base results we are using (should be to the units in terms of SI base units in this template). This, of course, has nothing whatsoever to do with whatever units are chosen for the default output if no output units are specified. In other words, the "conversion factor" we are talking about is the one to those base units; the "conversion factor" between the input units and the output units is the conversion factor for the input unit divided by the conversion factor for the output unit.

You say "Also, because {b} is a divisor (not a multiplier factor), that's why the logarithm is negative, because the result is being adjusted by division, hence subtracting the logarithm as negative {j}, whereas a factor would add the logarithm to indicate multiplication for more digits."

note that subtracting a negative number is the same as adding its additive inverse, the positive number.

note that log (1/x) = −log (x)

In most calculators, "shifting" and the like is done with binary numbers, not with decimal numbers. The arithmetic shift is the operation used for multiplying or dividing; yet in your terminology above, you use "shifting" to refer to the addition/subtraction operations. I'm just totally confused by what you are saying. Gene Nygaard (talk) 15:19, 26 February 2010 (UTC)

Forgot to mention that in the templates, I see j = log₁₀(b), yet as near as I can figure, you are claiming that we should be using j = −log₁₀(b). Is that part of the problem here, with some of the templates having j = log₁₀(b) and others having j = −log₁₀(b)? Gene Nygaard (talk) 15:45, 26 February 2010 (UTC)

One more point. MediaWiki math must do logarithms; didn't Huntster use them in his changes to the round function? If so, no human should ever have been entering j factors for each conversion. The convert template should have been doing that calculation from the b factors entered for each conversion, shouldn't it? Why have human editors been entering a j factor? Even if we only have a natural logarithm function, log₁₀(x) = ln(x)/ln(10). Gene Nygaard (talk) 15:52, 26 February 2010 (UTC)

• Well, perhaps I did not examine enough conversions for {b} as a conversion factor. I understand the viewpoint that Convert should have been auto-sizing the precision of each conversion factor f by ln(f)/ln(10), but perhaps j was specified to allow tinkering of the precision, for each measurement. When Convert runs a conversion, via about 23 nested subtemplates, it seems to always perform the 2-logarithm sizing, as ln(x)/ln(10), so the concept has been central to the precision. I believe that the subtemplates should be combined, such as reducing the flow of 23 subtemplates to 20, then 15, then perhaps 9 to handle each measurement. The sprawling, extensive scope of the problem is why I focused only on tweaking j to get m-to-ft conversions to work better. -Wikid77 (talk) 19:07, 26 February 2010 (UTC)