Template talk:Convert/Archive November 2007

←Previous archive

---

Could we pick one approach?

Jimp is working on a rewrite of {{Convert}} while MJCdetroit is working on {{ConvertVolume}} and {{ConvertWeight}} and I'm still maintaining the Category:Unit display templates e.g. {{Unit m}}. This is all good work but some of it must be redundant. Personally I would like to see us standardize on {{Convert}} if it could be rewritten address the scalability problems and with more modular code so more people can maintain the conversions independently of the format of the output. Since Jimp has created many sub-templates I assume that’s the direction he is going. -- PatLeahy (talk) 18:45, 18 October 2007 (UTC)

Like I said above somewhere, I am all in favor of a better mousetrap. I didn't invest a ton of time into {{ConvertVolume}} and {{ConvertWeight}} and would be glad to see something better come along. —MJCdetroit 20:33, 18 October 2007 (UTC)

I've put my mousetrap ... or what's there of it so far ... in the sandpit. At the moment it handles lengths, area, speed, mass and temperature. I'll be working on other conversions; i.e., volume, energy, pressure, ... etc. One advantage of using subtemplates is that you can just keep adding units without bloating the pre-expand size since the template only calls the unit subpages it needs. I seem to have cut the pre-expand size a fair bit. I've taken care of most of the issues mentioned on this talk page and a couple of issues which haven't been mentioned like:

{{convert|0.25|ha|acre|0}}'s	giving us	0.25 hectares (1 acre) but
{{convert/sandbox|0.25|ha|acre|0}}	gives	0.25 hectares (1 acre)

Another change I've made is to match the abbreviation vs. spelling out of unit names when using a slash. Thus if you spell out the first unit name, the names of the conversion unit(s) are also spelt out. Note that this is only done when disp=s, disp=slash or disp=/.

{{convert|10|ft|m|0|disp=s}}	gives	10 feet (3 m) but
{{convert/sandbox|10|ft|m|0|disp=s}}	gives	10 feet (3 m)

Trailing zeros are included. Set precision to 1 and you want that figure after the decimal point, right.

{{convert|10|ft|m|1}}	gives	10 feet (3.0 m) but
{{convert/sandbox|10|ft|m|1}}	gives	10 feet (3.0 m)

I've made it such that the hyphen is automatic when sing=on except when the unit is abbreviated per WP:HYPHEN. If this is undesireable, it could be removed but this's not the place for that discussion.

• At last! --Malleus Fatuarum 01:53, 19 October 2007 (UTC)

I've introduced three new types of rounding (i.e. in addition to the current rounding by specifying a precision ... let's call this prounding). So there are four types of rounding, let's lable them:

1. rounding
2. prounding
3. srounding
4. sprounding

Prounding is the same as what the current version does. Srounding is rounding to a given significant figure specified by attaching |sigfig={some interger}. Sprounding is a combination of the two—whichever gives the lowest degree of precision. Rounding is the default rounding type. Rounding matches the output precision to that of the input allowing a 10^0.3 (I've just pushed it up to two, which probably makes more sense—20Nov07) buffer but, to preserve a decent level of accuracy, never going below two significant figures. Temperature is dealt with slightly differently to other values. It's nonsense to say 20 °C has one significant figure and that 290 K has two. So for temperature rounding is based on the value in kelvin. It also defaults to three sigfig minimum (which generally looks like two in Celsius & Fahrenheit). I'll give a more detailed explanation later.

I've made the convert-to unit optional. Each unit has (a) default unit(s) to convert to. If no convert-to unit is specified, the conversion will go to the default. In this case the third unnamed parameter becomes precision i.e. the number of decimal places to round to (which is still optional).

I mentioned above that there were a couple of ways of allowing dual conversions. MJCdetroit introduces an extra parameter to specify the third unit. I did consider this but instead took a different approach. The way I went about it was to have both convert-to units specified in the third parameter, e.g. {{convert/sandbox|7|furlong|ft m}} which gives 7 furlongs (4,600 ft; 1,400 m). This has the advantages of being slimmer (with respect to pre-expand size) and of allowing more than two convert-to units e.g. {{convert/sandbox|500|R|K F C}} which gives 500 °R (278 K; 40 °F; 5 °C).

I've got quite a simple solution to the problem of feet when you want foot, e.g. "He was 6 foot tall." You just specify foot in place of ft in the input e.g. {{convert/sandbox|60|foot}} gives 60 foot (18 m).

Well, that's about all I've got so far. If this is the way we want to go, I'll give a more detailed explanation. The thing is still under construction ... but it probably will always be since there is no limit to the number of units which can be added ... no, not true ... better say "The sky's the limit ... or maybe the Oort cloud." I'll be adding units. Also, I've found a way to allow the use of the template in tables. I'll be adding this feature too (and maybe others e.g. split linking mentioned by Lightmouse above). These additions, though, will be additions & I don't forsee having to alter what's already in place. I believe the version I've got is good to go and can replace the current {{Convert}}. Jɪmp 01:49, 19 October 2007 (UTC)

It gets my seal of approval. We'll probably need a big explanation table —MJCdetroit 20:35, 19 October 2007 (UTC)

Fantastic. I am so pleased that the bloat problem is fixed. I also like the simple to remember and easy to use features like embedding 'foot' in the variable. Lightmouse 20:40, 19 October 2007 (UTC)

Major kudos to Jimp for his coding of this new code, the modular design will be extremely beneficial to adding new material. I especially like that more than a single conversion can now be displayed. I admit the code itself isn't quite unraveling itself in my brain, but that only impresses me more. So long as there are no dissenting voices, I suppose we'll need to get started on a new /doc page soon. -- Huntster ^{T • @ • C} 22:30, 19 October 2007 (UTC)

Thank you Jimp for all your work. Let me know if I can be any help adding unit types, writing documentation or tests, or anything else. -- PatLeahy (talk) 23:47, 19 October 2007 (UTC)

I'm glad people seem to approve of the new version. Yeah, new documentation & tests would be helpful. Of course, I've done a bunch of tests myself but others may find something I missed ... or thought was the right way to go but turns out not to look so great through other's eyes. I suppose the first thing to test is whether it can handle everything the current version does ... I'm pretty sure it can. New documentation, I suppose, would come in forms: what the new version does differently with the same input (e.g. rounding, hyphenation and abbreviation) and what new types of input it can handle. The first of these would have to be added pretty much at the same time as the new version is put in place. The second is still kind of in a state of flux ... what it does now might differ to what it does next week. I'll have to get together instructions on how to add units ... but this is also in a bit of a state of flux ... or at least I made two changes today (yeah, I wrote "I don't forsee having to alter what's already in place." ... so much for foresight, however, the template will be working in the midst of this flux so even if it were already replacing the current version this would do no harm). Jɪmp 06:33, 22 October 2007 (UTC)

I've added volumes (volumes of volumes), capacity for use in tables and split linking. For the cubes of units of lenght put either cu before or 3 after the unit (e.g. either cuin or in3 will give you cubic inches) ... to be continued ... Jɪmp 02:33, 26 October 2007 (UTC)

I had always thought that we were trying to avoid using numbers in the code i.e. (in3, m2, km2) even if the correct [SI] symbols displayed would be as m², km². I always thought there wasn't numbers in the code to avoid m2|22.2|2 or m|222.2|2 accidental typos. In anycase, it's something to think about. —MJCdetroit 02:51, 26 October 2007 (UTC)

Oh, I guess I wasn't here for that discussion but you've got a good point. They're there now though instead of deleting them perhaps we could just not mention this on the doc page. I've done the same for squares too. Anyhow, for imperial units add imp to the unit code (e.g. impgal) and for US customary units there are three options. Adding US will give you US, adding U.S. will give you U.S. and adding us links it to spell such that you'll get U.S. if spell=us and US otherwise. For us dry volumes you can leave out the us (e.g. drygal is equivalent to usdrygal). I thought this would be fair enough since there is not wet/dry distinction in the imperial system. For different barrels are covered impbbl gives you an imperial barrel (36 imp gal), usoilbbl (or just oilbbl for short) will give you a US oil barrel (42 US gal), usbeerbbl will give a US beer barrel (31 US gal) & usbbl will give a plain US barrel (31½ US gal). These figures are based on one of the refs at Barrel. If there is any error please say so (I'm from a metricated country so am not too familiar with this array of barrels). There is the option to use either l, cl, ml, etc. or L, cL, mL, etc., just type whichever you want in as code. Similarly, to abbreviate cubic centimetre as cc rather than cm³, use cc.

For tables set disp=table. The default is not to show the unit but if the unit is desired turn either abbreviations or linking on. Unless there is no abbreviation the name of the unit will not be spelt out in full when disp=table. For tables the template must start on a new line and be preceeded by a pipe. E.g.

{|class=wikitable
|-
|Volume/firkins||Volume/litres||Volume/imperial gallons||Volume/US gallons
|-
|{{convert/sandbox|256|firkin|disp=table|lk=on}}
|}

gives

Volume/firkins	Volume/litres	Volume/imperial gallons	Volume/US gallons
256 firkins	10,500 L	2,300 imp gal	2,770 US gal

Lightmouse suggestes lk=1 vs lk=2. I felt that this would be confusing since we're including more than one conversion. So I used lk=in (to link only the input unit) vs lk=out (to link only the output unit(s)). This also keep numbers out of the code. Jɪmp 03:55, 26 October 2007 (UTC)

Here are my comments:

• I agree with the idea of keeping numbers out of the code. I was not aware of the potential problem till now.
• I like the solution of 'lk=in' and 'lk=out'. Perhaps we will just have to live with the fact that it will not scale to multiple output units (km converted to mile and nautical mile).
• I like the option of typing 'cc' to get the non-SI format.
• I have never quite worked out what to do about US and imperial. I have been using 'USgal' i.e. no space and no parentheses. This makes it more compact We have to think about combinations such as USmpg, USgal/min.
• Is there somewhere that we can see what we have so far?

Great work! Lightmouse 16:00, 26 October 2007 (UTC)

←Agreed with the fantastic work, and the template-in-progress is visible at {{Convert/sandbox}} and the list of conversions is at Special:Prefixindex/Template:Convert (holy cow, what a list, and don't forget the 2nd page!), so you can test it anywhere. One thing I don't see a problem with is the keeping of numbers out of code. Even if a situation like {{Convert|m|222.2|2}} occurred, as MCJdetroit mentioned above, it should be immediately apparent that there is an error since the result should visibly display "metres" rather than "cubic metres". I think in this situation ease of use outweighs the potential for user error. -- Huntster ^{T • @ • C} 16:24, 26 October 2007 (UTC)

I'm ok with the cc and cm³ for cubic centimeter but I think when it comes to liter the abbreviation should always be L without the lowercase option. In my industry and in my science back ground, the only symbol you seen for liter anymore is 'L'. It seems like they (whoever 'they' are) phased out l and the lowercase cursive verision that you used to see long ago. —MJCdetroit 17:05, 26 October 2007 (UTC)

Thanks, Hunter, for the pointer to the list. The list includes template names containing 'kph' and 'km:h' in addition to the correct SI format 'km/h'. I presume that is being nice to users that do not know the correct SI format. I propose that we have a design concept of keeping the code as close to SI format as possible, unless there is a good reason otherwise. Reasons to permit non-SI formats in the code include:

• Avoiding typos is a good reason so I was running with 'keep numbers out of code' but now Hunter has made me uncertain about banning 'm3' etc.
• I think the 'cc' example is a good reason because 'cc' is a valid desired output.
• Permitting use of 'C' in the code is a good reason because the degree symbol is not easy on a keyboard. Similarly with superscript '2' and '3'.
• I do not think that 'km:h' and 'kph' should be permitted in the code because they are not valid desired outputs. The slash symbol '/' in 'km/h' is easy to type so there is no reason why a user should not be required to use it.

Lightmouse 09:32, 27 October 2007 (UTC)

I get that we should maintain an output that follows SI for standardisation purposes, but so long as it does output correctly, why should it be necessary to limit input? The way this template is designed, you can create almost unlimited conversion types without impacting size (as I understand it), so it doesn't make sense why multiple common inputs shouldn't be allowed. It will all render the same. I don't think that we should be forcing certain formats over others (even if "proper", they are no more "correct"), just as we shouldn't force metric over imperial and vice versa. -- Huntster ^{T • @ • C} 19:20, 27 October 2007 (UTC)

Imperial and metric are both valid choices. Writing 'MPH', 'mph', 'mi/h' are valid choices because there is no official source for what is *correct* with non-metric units. However, there *is* an official source of what is *correct* with metric units. The BIPM (official SI authority) does indeed mandate certain formats over others because it is required to do so by the member states. Users that are interested in units and learn how the template works are well capable of understanding the instructions.

People that use templates have always been required to learn the template code that they are given. None of the predecessor templates have supported 'kmph', 'kph', 'km/hr', 'Km/h', 'kmh' and all the bizarre *incorrect* combinations that some people use. I do not see why we should start now. This is a great piece of code! Lightmouse 08:49, 28 October 2007 (UTC)

The split linking could, of course, "scale to multiple output units" ... it would be a lot of work though (roughly about two and a half thousand subtemplates if we're accounting for triple outputs). You can see what we've got so far at the link mentioned above ... if that doesn't tell you much, well, I don't know of anywhere else to look (besides this talk page) ... I will be working on a fuller explanation but I'd rather do a little tidying up and make a few additions first. According to Litre the lower case l is still official and is used in Ireland and the UK. I didn't include the script version though because it seems that it's only used in non-English speaking countries. MOS:NUM makes no mention of the issue ... perhaps it should. I'm none too keen on having non-standard abbreviations for units either but there is another (and quite significant) reason for having them. That reason is compatibility. The current version uses ft:s and the like, if the new version didn't allow this, then we could have problems when replacing the old with the new. Whether we mention such alternatives on the doc page is another matter. Jɪmp 00:35, 29 October 2007 (UTC)

Regarding the non-standard abbreviations, I certainly did not mean that the non-standards should be documented, rather that they should simply be accounted for. Even if just for simplicity's sake, and be it SI or not, we should choose one input form to document for each measurement (and two if absolutely necessary) and stick with it. -- Huntster ^{T • @ • C} 01:39, 29 October 2007 (UTC)

• There are so many misunderstandings and false statements about metric units that it is always worth taking the simple step of looking at what the SI authority says on its website. The official SI website says that the symbol for litre is either L or l. The script version has no official status.
• The new version does not need to support colon versions (ft:s, m:s). The issue can be solved easily with a bot search&replace that changes 'ft:s' to 'ft/s' etc. My script already does this as it comes across them.
• A search of Wikipedia suggests that there are around 24,000 instances of 'km/h' and only 7 of 'kph'. It seems that the issue is rare. I don't care about non-metric units but supporting wrong SI formats (even if undocumented) reinforces an error. I would prefer it if we did not do that. Lightmouse 11:03, 31 October 2007 (UTC)

I'd be happy to throw the colon versions out after the bot has gone through and changed them to standard forms. The fewer options we give the easier it is to write this thing. Send a bot after kphs too because I don't know that they're as rare as we'd like them to be. Jɪmp 06:38, 5 November 2007 (UTC)

Not to throw a damper on anything, but is there any thought given to safeguarding against vandalism? With so many subtemplates being called, I somewhat worry that a single measurement being changed isn't going to be quickly, or easily, noticed. Perhaps semi- or full-protection should be considered for these once confirmed to be fully armed and operational? -- Huntster ^{T • @ • C} 09:47, 6 November 2007 (UTC)

Agree; full-protect 'em. We wouldn't want these weapons of mass measurement of to full into the hands of the vandals. —MJCdetroit 13:35, 6 November 2007 (UTC)

Response to Jimp, I have been through that search list and replaced 'kph' with 'km/h' using my monobook code. There are several editors that do this either with my code or somebody else's. I also caught and fixed some colon (km:h) versions of the convert template (we should probably still have a bot for that task).Lightmouse 09:59, 8 November 2007 (UTC)

Using a bot to replace instances of this template

Some time ago back in August, a bot was unleashed to replace the {{convert|...}} template with something like this:

<span style="white-space:nowrap">10&nbsp:miles&nbsp:(16&nbsp:km)</span>

The original actions of this bot were unpopular with some editors and the bot was quickly stopped (see the discussions here, and perhaps elsewhere too) - it's changes were quickly reverted on some of the affected articles. As I suggested during those earlier discussions, I believe a better solution would be for the bot to have replaced the convert template with other smaller conversion templates. For example, replacing {{convert|10|mi|km|0}} with {{mi to km|10|precision=0}} would transclude a whole lot less code but retain the functionality that us editors want (ie. to make it easy to update without having to get the calculator out to update the other unit as well).

I noticed there are now a lot more conversion templates, but has anyone considered modifying the bot like in my suggestion above?

Astronaut 19:17, 27 October 2007 (UTC)

If you will look at the section above, you will see a new "Convert" template is being designed to address the issues with code overhead while attempting work as an all-in-one template. If successful, there will be no need a'tall for any bot-assisted replacements to take place. Let's see how this turns out first, shall we? -- Huntster ^{T • @ • C} 19:24, 27 October 2007 (UTC)

Oh, I'm happy to wait. However, though I didn't read it all, it does seem most of the discussion above is about adding more complexity and more code to something that is already far too big. Astronaut 20:34, 27 October 2007 (UTC)

The way that Jimp is building/built the "new convert" it can expand to include almost anything without bloating the code. It's a little more complicated than that but you shouldn't have to worry about it.—MJCdetroit 00:56, 28 October 2007 (UTC)

Yep, that's about right, adding more complexity and more code to something that is already far too big ... heaps of extra complexity and gigatonnes more code but giving us something which is smaller (significantly smaller) that what we've got. Paradoxical? It's just a question of how you add the code. What counts is the pre-expand size. Only a small amount of the new code counts to the pre-expand size of any one transclusion since the with new design only that which is needed is included. Hence, as MJCdetroit writes, it can expand and expand without increasing the the size of any particular transclusion. And it is expanding hence it's both true that the thing is built and still under construction—like a cancer that just keeps growing but still can make you sick at any instant. Jɪmp 06:58, 6 November 2007 (UTC)

"like a cancer that just keeps growing but still can make you sick at any instant." ...Wow, that's such a cheery description of this pretty thing you've built. !! -- Huntster ^{T • @ • C} 09:47, 6 November 2007 (UTC)

...like a rose bush which keeps bringing forth new blossoms but those now in bloom still smell sweet. Jɪmp 23:42, 7 November 2007 (UTC)

Ready to go live yet?

Are we ready to go live yet? —MJCdetroit 15:24, 8 November 2007 (UTC)

Also, I'm having a bot go through the subtemplates and add them to this category: Category:Subtemplates of Template Convert. —MJCdetroit 16:01, 8 November 2007 (UTC)

Please go live. Lightmouse 18:19, 9 November 2007 (UTC)

We are ready. Jɪmp 04:02, 12 November 2007 (UTC)

LIVE!

I checked a few measurement heavy pages and everything seemed fine. —MJCdetroit 04:53, 12 November 2007 (UTC)

I've added a bit to the doc page about the new functionality. I think the list of units will have to be moved to its own page ... it's getting kind of long. Jɪmp 07:38, 12 November 2007 (UTC)

I've gone through & replaced {{convertW}} with this (except on user pages). So we should be able to delete {{ConvertWeight}} now along with {{ConvertVolume}} & the redirects to these. Jɪmp 09:16, 12 November 2007 (UTC)

Excellent work. Lightmouse 21:00, 12 November 2007 (UTC)

"put the source value first and the converted value second"

I noticed that many firearms related article (e.g. 5.56 × 45 mm NATO and 7.5 x 55 Schmidt Rubin) currently provide metric and non-metric values for all values except powder weight which is non-metric only. This is due to the design of a template. I mentioned this to the Firearms Project and I think that there is now general agreement to update the template to provide grams.

However, I am not sure if the template update will permit editors to "put the source value first and the converted value second". Perhaps I am just being paranoid but see for yourself at: WikiProject Firearms.
Lightmouse 18:33, 8 November 2007 (UTC)

Sample Sentence (but true): Next week I plan to put a 180-grain (12 g) bullet through a White-tailed Deer from my .30-06 Remington rifle from about 150 yards (137 m) away.

I'm not sure exactly what you mean, but the template seems to work just fine for me. —MJCdetroit 19:10, 8 November 2007 (UTC)

Oh, you meant {{Infobox Firearm Cartridge}}. Sorry. Grains for powder and bullet weight are an industry and military standard. So always listing them first shouldn't be a problem. —MJCdetroit 19:14, 8 November 2007 (UTC)

Always listing them first would be an exacerbation of the problem. Listing the originals first, in any instance, is what you need to be able to do. Gene Nygaard 21:26, 11 November 2007 (UTC)

carats and grains

Will the new template convert carats and grains into grams? Lightmouse 18:21, 9 November 2007 (UTC)

My sample sentence above (about the 180-grain bullet) was using the new template (Jimp's rebuild) which is at {{Convert/sandbox}}. —MJCdetroit 20:09, 9 November 2007 (UTC)

Excellent. Perhaps Template:Infobox Firearm Cartridge can be the first one to offer grains-to-grams and grams-to-grains. I think I understand the code in the template (it already has bidirectional conversions) but I am not confident enough to make the changes. Lightmouse 09:23, 10 November 2007 (UTC)

That "singular" terminology

It usually isn't really "singular" vs. "plural" that gives rise to the use of this parameter. Those are terms applicable to nouns. But where that parameter is used is generally in the case of adjectives. Maybe the reasons for using it should be explained somewhere. Gene Nygaard 12:18, 12 November 2007 (UTC)

Yes, adj would have been better. I don't know why sing was chosen in the first place. As for the new version's continued use of this, well, you work with what you've got. Jɪmp 23:38, 12 November 2007 (UTC)

However, its not something that can't be rectified. The code could easily be has been adjusted to allow for either adj or sing until a bot has gone through and replaced the sings with adjs. Can we get some bot expert on this one? Jɪmp 08:55, 13 November 2007 (UTC)

However, it isn't always because of adjectives. Sometimes it is because of singular nouns. Gene Nygaard 11:17, 13 November 2007 (UTC)

Just leave it with both terms. Removing |sing doesn't make sense. It would be like reinventing the wheel for some people. —MJCdetroit 13:13, 13 November 2007 (UTC)

Forgive me if I state the obvious, I don't mean to be making a fool of any one, just want to clarify what meaning is intended. Singular nouns are what you use with the number 1, e.g. 1 metre as opposed to 2 metres. The template takes care of this automatically. In the case of words such as stone where the plural form and the singular form are the same, e.g. 1 stone and 2 stone, the template takes care of this automatically also. In the case of the feet where there are two acceptable plural forms, e.g. 2 feet or 2 foot, you use either ft or foot in the code depending on what you want. Jɪmp 01:01, 14 November 2007 (UTC) If sing had been being used to produce 2 foot, this'll have to be fixed because it'll now be giving 2-foot. Jɪmp 05:40, 14 November 2007 (UTC)

That's the whole point. There are two different things involved, and "sing" should not be giving us "2-foot" with a hyphen. Of course, it would be an error for the user to tell it to use singular in that case, but if you tell it to use singular in converting 0.6 from meters to feet, it shouldn't be giving us "0.6-meter" with a hyphen either. Gene Nygaard 00:52, 16 November 2007 (UTC)

Furthermore, you give us one unit-specific example of using "ft" or "foot" as distinct parameters, certainly not an intuitive distinction. But does that exist for everything else, too? What's the intuitive rule we are supposed to devine here? What do I use if I want to get "0.25 pound"? to get "0.7 meter per second"? to get "0.035 kelvin"? Gene Nygaard 00:55, 16 November 2007 (UTC)

I very much agree with you sing, short for singular, should do just that: make things singular. Where the problem lies is in the fact that sing had in the past been used "for grammar" as past incarnations of the doc page (e.g.) will illustrate. Poorly named but that's what it had been intended for and if you look out there in the wild, you'll see that sing has indeed been used exactly this way. If we want it such that sing made things go singular without hyphens, it could be done. First you'd have to check all the current singss to see that that had been what was intended (I've checked a number & found this not to be the case) and change them over to adjs where appropriate (i.e. everywhere or at least almost everywhere). That done, the template could be adjusted to allow for sing to give singular without hyphens. That's one thing you could do if you "want to get '0.25 pound'? to get '0.7 meter per second'? to get '0.035 kelvin'?" Another thing you could do is just type them out ... My question is why you'd want such things in the first place, we use the singular form with adjectives and the number one and the plural form otherwise in English. Jɪmp 00:19, 20 November 2007 (UTC)

It should be singular for all numbers whose absolute value is greater than zero and less than or equal to one. Gene Nygaard (talk) 18:13, 20 November 2007 (UTC)

In that case it should be done automatically ... it didn't sound right to me, 0.5 metre, but on thinking about it I realised that I wouldn't say 0.5 metres either. I'd say 0.5 of a metre but that's not what you'd write in an encyclopædia. Jɪmp 09:27, 22 November 2007 (UTC)

General philosophy and implementation

I think we are overdue for more discussion of the general philosophy behind these "black boxes", and their overall implementation.

Some of it could take place here. But this is a hidden-away corner of Wikipedia, used primarily by maybe a handful of its advocates. The general discussion should take place in one or more forums with a broader audience. Suggestions include Wikipedia:Village pump (policy), Wikipedia:Village pump (technical), and Wikipedia:Manual of Style (dates and numbers).

I'll try to come up with some specific issued along those lines. One specific thing that sticks out was a use by User:Lightmouse which included the erasing of the identification of a specific, different nautical mile in Outer Continental Shelf (talk), and a number of cases in which existing conversions have been replaced by this template and give different, and much poorer quality, results. Sure, there are also cases which result in better quality results; the general discussion should include a balancing of the advantages and disadvantages of something that often makes them better, but also often makes them worse.

Maybe something along those lines already exists. If so, it would be good to point that out, at least here on this talk page and probably on the documentation page as well. Gene Nygaard 12:53, 12 November 2007 (UTC)

Just to mention one primary issue. The use of this template means that future corrections are beyond the capabilities of the average Wikipedian, and can only be accomplished by those who understand all the intricacies of a highly complex and non-intuitive black-box template. That includes things as simple as the ability to update numbers based on changed information, or based on a better source of old information. Gene Nygaard 12:58, 12 November 2007 (UTC)

If the wrong nautical mile was used, that's not hard to fix. Of course, we must first take account of the other nautical mile but that's not hard to do. By quality you mean accuracy, right? This can easily be adjusted as described on the doc page. At the moment the doc page doesn't fully describe the function of the new template but it will and it shouldn't be a black-box. Jɪmp 23:47, 12 November 2007 (UTC)

It will likely always be a black box. Especially to the average editor. But it's so complicated now that even I would have great difficulty figuring out exactly what it will do in a particular case, including the should-be-simple matter of figuring out the conversion factor being used. Gene Nygaard 03:04, 13 November 2007 (UTC)

I'll be working to shed as much light on the box as I can—including the conversion factor being used which I intend to make a very simple matter of looking it up in a table. It's a new box the lighting is still under construction. It is no harder to use than the old version though in that it handles to same input (yeah, except it flips out if you leave certain things blank). Jɪmp 03:51, 13 November 2007 (UTC)

I have included the old British & American nautical miles. See the doc page.Jɪmp 07:20, 13 November 2007 (UTC)

That's part of the problem; not part of the solution. Gene Nygaard 11:28, 13 November 2007 (UTC)

I am sympathetic to what Gene is saying. My inability to correct metric-hostile defects in the Firearms template is because it is too complicated. My pleading with the template owners (odd phrase on Wikipedia but that is what it feels like) at WikiProject Firearms is not having much luck.

I would prefer Wikipedia to have conversions in raw text. However my support for this template is because it is a net improvement to Wikipedia. It permits scripts to add conversions by searching for digits and moving them into a template. Furthermore, I think the template has resulted in more editors doing conversions. Of all the templates on Wikipedia, this one probably addresses the biggest issue. Many readers have benefitted.

It would be fine by me if somebody could do the same job using raw text. It would also be fine by me if somebody could take template conversions and turn them into raw text. Lightmouse 21:21, 13 November 2007 (UTC)

Forgive me Gene but you're saying that the inclusion of these different nautical miles is part of "the problem", right, how so, and not part of "the solution", what is the solution ... what exactly is the problem? Yes, it is perhaps a little complicated (non-intuitive? ... subjective that ... it's intuitive to me, of course) but I don't think it's much more complicated than it need be in order to achieve what it does. I do intend to give a full description of how it does what it does so that others can edit it but I think it's probably more useful to first describe simply what it does. Jɪmp 04:24, 14 November 2007 (UTC)

It is a problem with the general philosophy driving you.

I'm saying these are bordering on frivolity. They aren't going to be helpful in doing conversions; they are going to make the use of this template harder to learn, and unnecessarily so. Of course, those two seem quite reasonable compared to many of the other, totally frivolous and useless conversions which are supported now.

On the other hand, there are units whose conversions appear in thousands of Wikipedia articles, which are not supported by this template. No force conversions whatsoever, for example. Pressure? Why would anybody want to convert that? Torque? And those are the things that many editors could use help with when doing the conversions; we already have thousands and thousands of editors who can handle a conversion from meters to feet quite well, or even the much more difficult ones such as from degrees Fahrenheit to degrees Celsius, without using this conversion template. -- Gene Nygaard (talk) 20:59, 16 November 2007 (UTC)

Yes, I'm guilty of a little frivolity. If there are conversions which do more harm than good, I'm happy to let them be deleted. However, unless it's cluttering the documentation up, I don't see the harm in supporting the frivolous. Do I overlook something?

No force, no torque, no momentum ... I'm aware of this. The thing is still under construction. "Pressure? Why would anybody want to convert that?" Why, 'ay? Who knows? Whatever reason they've got, that's good enough for me. What the heck, include pressure too ... there's room, ain't there? Jɪmp 00:14, 19 November 2007 (UTC)

Broken template transcluded on many articles

Look at Mount St. Helens elevation data, it seems Template:Convert/LAonDbSoff is broken. It affects Template:Unit_ft. feydey 16:11, 12 November 2007 (UTC)

See also broken links in Category:Unit_display/tests. feydey 16:14, 12 November 2007 (UTC)

I reverted the change to the NEW version. It seems that we are going to have to get a bot to convert the Unit_display templates to use convert syntax. I'll see what I can come up with. —MJCdetroit 16:34, 12 November 2007 (UTC)

I've got a bot working to switch some of those Unit display templates over to the convert syntax. When that is done, we can update to the new version [again] and see if there are any more surprises. —MJCdetroit 21:23, 12 November 2007 (UTC)

There is no Template:Convert/LAonDbSoff. My guess is that someone left lk blank. Jɪmp 23:41, 12 November 2007 (UTC)

Those Unit display templates have |lk={{{lk|}}} in them. That's our problem. It's got to be changed to |lk={{{lk|off}}}. I've done a couple of them but I've got to go. Jɪmp 00:12, 13 November 2007 (UTC)

I've been through the Unit display template category & fixed those broken templates. We should be good to go. Jɪmp 03:03, 13 November 2007 (UTC)

Code error showing on the instruction page

The instruction page shows an error. It says:

• (Expression error: Missing operand for * )
  

Lightmouse 21:27, 12 November 2007 (UTC)

Because we had to revert to the old version until the Unit display templates (which are a wrapper for this template) can be switched over; see above. That error will fix itself when the New version is back online (in the next 10 hours). —MJCdetroit 21:30, 12 November 2007 (UTC)

Aha. Thanks for clarifying that. Lightmouse 21:41, 12 November 2007 (UTC)

Some display errors

See Special:Whatlinkshere/Template:Convert/LAoffDbSoff. I don't know whether this template should exist or the call is made incorrectly; in any case, something needs to be fixed (I just fixed something on Dead Sea by removing a lk=, but wanted to make sure the experts for this template know of the problem). Happy editing, Kusma (talk) 13:37, 13 November 2007 (UTC)

This subtemplate does not exist: {{Convert/LAoffDbSoff}}. Perhaps Jimp can create it. The problem happens when |lk= is present but left empty, e.g.: {{convert|640|acre|sqmi|lk=}} --> 640 acres (1.00 sq mi). —MJCdetroit 14:14, 13 November 2007 (UTC)

I've created it. Jɪmp 01:37, 15 November 2007 (UTC)

adj

Please can we change the 'adj' for something more direct like 'hyphen'. Here are some reasons why I ask:

• Command names should relate closely to what the user wants. The user is asking for a hyphen so let them ask for it.
• A hyphen is not a mandatory requirement of the adjectival forms. In fact it is expressly forbidden in some circumstances.
• The author might be thinking of disambiguation rather than grammar. This is the only purpose that I would use it for.
• Even clever people often do not know grammatical terms. More people know what a hyphen is than know what an adjective is.

Lightmouse 20:29, 13 November 2007 (UTC)

That's an unanticipated problem. The original change from "singular" to "adj" dealt with changes such as "feet" to "foot" and "kilometers" to "kilometer", as in "a 10-foot pole". Not with hyphens.

I would oppose any addition to hyphens when the unit symbols are used, neither between the number and the unit symbol nor between the symbols of a compound unit. The style guides such as NIST SP811 expressly say not to do that. Gene Nygaard 12:43, 14 November 2007 (UTC)

Aha. I misunderstood what 'adj' did. That reinforces my point. (I still think everyone is doing a great job on this). Lightmouse 19:50, 14 November 2007 (UTC)

MOS:NUM says not to do that & this template follows this advice. Jɪmp 04:24, 20 November 2007 (UTC)

Jimp, I do not understand your reply.

• If I want the output to be '10 gram' rather than '10 grams', I would prefer a command that is based on the term 'singular' rather than the term 'adjective'. The reasons in the bullets at the top of this section still apply and I will add one more: it seemed to me like the 'adj' command was created to get a hyphen.
• Two independent functions have been conflated (singular form, hyphen). I want one (singular form) without the other (hyphen). Please can this be possible for me.

Lightmouse (talk) 09:07, 22 November 2007 (UTC)

... not to put the hyphen in when you're abbreviating the unit name. One without the other ... anything's possible, 'ay. But do we want singular form without a hyphen? Sorry to be so breif but I'Ve got to run. When would we ever use that (except to match number)? Jɪmp 09:20, 22 November 2007 (UTC)

I cannot speak for others but I *always* use a space. Never a hyphen. Lightmouse (talk) 19:34, 22 November 2007 (UTC)

As for me, I always superscript the th, nd & rd when writing ordinal numerals ... except on Wikipedia where the MoS says not to. Now, according to the MoS, using a space instead of a hyphen is also "incorrect". Do we include the option to do something which is against the MoS? --Jɪmp 17:15, 25 November 2007 (UTC)

It is a shame that the MoS says that. I suppose I should join a lobby to get the guidance on the hyphen changed. You can only do what you think is best and you are doing a great job with huge effect on Wikipedia. I would like to reiterate my view that a good command name based on the term 'adjective' is not as good as one based on the term 'singular' if the effect is to turn 'feet' and 'metres' into 'foot' and 'metre'. Lightmouse (talk) 21:07, 25 November 2007 (UTC)

Join the lobby ... or start it. Well, sing still works but we're not just turning feet and metres into foot and metre but turning 2 feet and 3 metres into 2-foot and 3-metre. Of course, if the MoS allowed it, sing could give us unhyphenated singulars with adj giving the hyphenated versions. We could even have hyph to add hyphens (independant of pluarlisation), sing to use the singular (independant of hyphenation) and adj as a short-cut to do both ... but I don't know why we'd want to. Jɪmp 23:47, 25 November 2007 (UTC)

Excellent template thanks !

Just discovered this having previously wished for just such a feature without looking in to it any further. I don't know if theres a list of the most used/useful templates, but I seem to learn of them by actually seeing them in use. Would it be worth adding currency conversion ? Thanks -- John (Daytona2 · talk) 14:00, 16 November 2007 (UTC)

Currency exchange rates change minute to minute unlike the stuff converted here which almost never change. There will probably always be 12 inches in a foot, three feet in a yard, 100 cm in a meter, etc. —MJCdetroit 15:41, 16 November 2007 (UTC)

And 14⁷⁄₁₂ ounces in a pound (at least when Encyclopædia Britannica is talking about gold, and maybe Wikipedia too?) -- Gene Nygaard (talk) 20:14, 16 November 2007 (UTC)

How patronising. Where amounts in different minor currencies are converted, for instance to dollars to aid a larger audience, and point in time exchange rates are not required, it would be helpful to provide more up to date info. even if it's not at the milliseconds latest exchange rate. -- John (Daytona2 · talk) 20:22, 16 November 2007 (UTC)

First, how are MJCdetroit's words patronising?...he was simply laying an example. Second, currency cannot be properly converted using a static template...monetary values fluctuate significantly over any period of time. The only viable solution would be to use values from a fixed point in time, say, the year 2000. However, that isn't going to be hugely valuable to a given user since the value of currency from that year isn't going to be nearly the same as current value, both against itself and against other currencies. There are a terrific number of problems when dealing with this situation. We are far better off directing readers (where applicable) to an external site like finance.yahoo.com or similar site. -- Huntster ^{T • @ • C} 02:26, 17 November 2007 (UTC)

I found the second sentence patronising. I understand the issue between fixed and varying conversions, I simply thought that just about anything is better than the current situation. -- John (Daytona2 · talk) 16:05, 17 November 2007 (UTC)

It's not impossible. This template could even be adapted to handle this ... though writing a new one would probably make more sense. You'd just have to add a parameter to specify the date (& time) conversion is to be done. It wouldn't be easy though, so many currencies, so many dates ... I'm afraid you'll probably have to stick to tables. Jɪmp 04:32, 21 November 2007 (UTC)

The Template is Screwed Up

I was looking at the article I-35W Mississippi River bridge and noticed that the length of the bridge and stats to is are red linked and having Error Transclusions of this template. Can you guys fix the template or revert it until it gets fixed? Sawblade05 ^{(talk to me | my wiki life)} 05:11, 17 November 2007 (UTC)

Have you tried using "abbr=on", instead of "abbr=yes", as the documentation suggests? --Malleus Fatuarum (talk) 05:46, 17 November 2007 (UTC)

However, in correcting that, Malleus Fatuarum, you introduced a different error. You changed some of the input numbers.

you changed {{convert|456.0|ft|m|1|abbr=yes}} to {{convert|456|ft|m|1|abbr=on}}

1. Changing "yes" to "on" made it work without giving an error
2. But changing "456.0" to "456" changes the results
   • {{convert|456.0|ft|m|1|abbr=on}}  →  456.0 ft (139.0 m)
   • {{convert|456|ft|m|1|abbr=on}}  →  456 ft (139.0 m)

Granted, this problem might so far be undocumented. But it exists nonetheless.

Both problems serve to illustrate that the overwhelming complexity of this template will result in less than optimal results. Even problems whose solution is documented will be unfindable for most editors when the documentation is completed. Gene Nygaard (talk) 08:13, 17 November 2007 (UTC)

Furthermore, Malleus Fatuarum's change would have resulted in different changes in the display if the parameter to display one decimal place precision in the results hadn't been included:

• {{convert|456.0|ft|m|abbr=on}}  →  456.0 ft (139.0 m)
• {{convert|456|ft|m|abbr=on}}  →  456 ft (139 m)

In this case, the output number of meters changes as well as the display of the input number of feet.

Neither of these results are anything the average template user is ever going to be aware of, and both are the result of recent changes in the template. For someone who put these templates in a month ago, what is displayed now is different from what was displayed when the template was added. Gene Nygaard (talk) 08:23, 17 November 2007 (UTC)

• {{convert|456.0|ft|m|1|abbr=on}}  →  456.0 ft (139.0 m)
• {{convert|456|ft|m|1|abbr=on}}  →  456 ft (139.0 m)

Any surprises here? Should we add something to the documentation page to make it clear that the original value you input comes out as is? I'm grateful to you, Gene, for pointing out problems but is this one of them? Throw |456.0|ft at the template as input and it'll throw you 456.0 ft back as output. Throw |456|ft at the template as input and it'll throw you 456 ft back as output. Is this not what you'd expect?

• {{convert|456.0|ft|m|abbr=on}}  →  456.0 ft (139.0 m)
• {{convert|456|ft|m|abbr=on}}  →  456 ft (139 m)

Okay, now this is my doing. Don't specify the precision (and/or number of significant figures) to round to and the template defaults to rounding to a comparable precision as the input. How did the old version fair?

• {{convert, the old version|456.0|ft|m|abbr=on}}  →  456 ft (138.9888 m)
• {{convert, the old version|456|ft|m|abbr=on}}  →  456 ft (138.9888 m)

Don't specify the precision to round to (specifying the number of significant figures wasn't an option) and the template didn't round the results at all. Thus, if you look around at the pre-one-month-ago transclusions of the template, invariably you find that the precision was specified (I've never seen a counter-example). Thus given that the precision was specified, for someone who put these templates in a month ago, what is displayed now is no different from what was displayed when the template was added.

Was it a bad move to introduce precision-matching as the default rounding? I say it was not. Does it make the template harder to use? Yes and no. It takes some effort to figure out that if you don't specify precision or the number of significant figures you're after, then this is what's going to happen. However, once you have figured this out, you realise that you've got another option and an option which saves typing and actually makes sense: this is how conversions are generally done (the precision of the output is matched to that of the input).

Granted it's a somewhat complicated method by which this precision matching is carried out. Exactly how it's done will have to be fully explained—I do intend to do so. I don't expect that this method will make sense to those who don't get mathematics (base-ten logarithms in particular) but what can you do? So, it's a black box but let's let the box's magic speak a little for itself. With the default rounding you increase the input precision by a factor of ten from 456 ft to 456.0 ft and surprise, surprise the output precision increases by a factor of ten from 139 m to 139.0 m. Is this a bad thing? Is this worse than the absurdly false-precisioned 138.9888 m regardless of the input precision? Jɪmp 03:52, 20 November 2007 (UTC)

No surprise at all. "Any surprises here? Should we add something to the documentation page to make it clear that the original value you input comes out as is? I'm grateful to you, Gene, for pointing out problems but is this one of them? Throw |456.0|ft at the template as input and it'll throw you 456.0 ft back as output. Throw |456|ft at the template as input and it'll throw you 456 ft back as output. Is this not what you'd expect?"

The problem, of course, is that Malleus Fatuarum changed the precision of the input number, without realizing either:

1. That would change the display. It takes some pretty complex coding for you to accomplish that, as anyone who has tried to write simple arithmetic routines like this should realize.
2. That if this change were intentional, it should have been accompanied by a change in the precision of the output display as well.

So, no surprise at all. Just a template that is far too overwhelmingly complex for the average Wikipedian editor to use properly. Furthermore, all these nuances are something that if fully explained in the documentation, will not be read by most users anyway. Gene Nygaard (talk) 19:04, 20 November 2007 (UTC)

To write a template that would change display when you change the precision of the input number takes coding as complex as {{{1}}}. There's little more going on here. The main template takes the first unnamed parameter and passes it along to a unit subtemplate as the first unnamed parameter. This unit subtemplate passes it along to the next subtemplate which formats it using <code>{{formatnum:}}</code> and displays it. No arithmetic involved. You get back what you put in—standard fair for templates in the Conversion templates category. Malleus Fatuarum didn't realise this?

"That if this change were intentional, it should have been accompanied by a change in the precision of the output display as well." ... and would have been if the default rounding had been used ... a nuance I'm guilty of adding. But, yes, if you're using a different rounding it's up to you to adjust the precision of the output as appropriate.

A few months ago I bought a new camera. I haven't read the instructions yet—there's a whole book of them. Can I take pictures? The new version can still be used in the same way as the old version. I've added a few features, added a few units and reduced the pre-expand size but it still works like it used to. Sure the code is harder to understand, but that doesn't mean the template is harder to use (I reckon it's easier but, hey, I wrote it). Users who understood what it used to do can go on using it the way they're used to using it. The thousands of transclusions show that there are plenty of them.

So the question is how to document the new features without bewildering editors—I don't think this is impossible. Jɪmp 01:35, 21 November 2007 (UTC)

The 'auto' conversion templates

Is it the intention to include the functions of the many 'Auto' templates such as Template:Auto horsepower?
Lightmouse (talk) 10:19, 22 November 2007 (UTC)

I have got started on power (horsepower, watts, kilowatts, ... work). I intend to include the others as well.--Jɪmp 16:56, 25 November 2007 (UTC)

Thanks. Your work is much appreciated. Lightmouse (talk) 21:08, 25 November 2007 (UTC)

Default precision weirdness

The default precision function allows me to simplify my conversion script. It should be great. I have just started using it and spotted a weird outcome from my edit at Howell High School (Howell, Michigan). The form {{convert|3300000|sqft|sqm|abbr=on}} has two significant figures in the input but three in the output '(307,000 m²)'. It should only have two in the output '(310,000 m²)'. What happened? Lightmouse (talk) 10:47, 22 November 2007 (UTC)

That is strange ... I'll have a look at it. --Jɪmp 17:22, 25 November 2007 (UTC)

Good new & bad—I've found the problem but I don't have the solution. It's not a coding problem. It's Wikipedia problem.

{{#expr:13300000=13300000round-5}} should give 1 (since round-5 means "round to the nearest hundred thousand", 13300000 already is rounded to the nearest hundred thousand & expr is meant to give you 1 for true statements) but it gives us 0 (as we can see: 1). Where do we take this problem? --Jɪmp 18:06, 25 November 2007 (UTC)

Oh dear. I really do not know where to take it. Perhaps the people at the village pump (technical) will know. Lightmouse (talk) 21:13, 25 November 2007 (UTC)

Tweak

Is there a way to get the template to read "acre" instead of "acres", much the same way we have the option of "foot" or "feet"? Murderbike (talk) 19:57, 23 November 2007 (UTC)

Use acre-sing ... at least until someone comes up with a better code. --Jɪmp 17:20, 25 November 2007 (UTC)

Firearms template now using the convert template

I have been in discussion with User Tra about ongoing improvements to the Firearms template. It now uses this convert template for several different units. I am pleased that I found undocumented options for ft.lbf and J. However, I cannot find any options for pressure unit. Do these exist yet? Lightmouse (talk) 10:10, 25 November 2007 (UTC)

Yeah, I've added a number of engery conversions & got started on power but have not yet had the chance to add these to the doc page. I've not added pressure yet either but I'll be adding that soon. --Jɪmp 16:50, 25 November 2007 (UTC)

Thanks. Two requests:

• We currently have 'ftlbf', could I put in a small request for 'ft.lbf'. This would fit the design concept of having the command match closely to the unit. My instinct was to assume that you had coded for 'ft.lbf', but when that failed I guessed at 'ftlbf' and got lucky.
• You may wish to look at my monobook code to see which units I am converting frequently. Your work on this template has allowed me to simplify it because I do not need to handle precision in so much detail. However, my code still uses using conversion templates other than this one but I am hoping that your future work will let me migrate those to this template. I have coded for a range of power units that are found in car, train, and ship articles. Lightmouse (talk) 21:29, 25 November 2007 (UTC)

ft.lbf—done.

Looks like the conversions you're doing which haven't yet been covered or mentioned are torque & force. Have I missed anything? I'm not too familiar with how the monobook code works. Jɪmp 23:31, 25 November 2007 (UTC)

ft·lbf, in·lbf, in·ozf

[slightly off topic...sorry] Jimp, I work with ft•lbf (& in•lbf) everyday and when they're converted, they are always, always converted to newton metres and never ever to joules. The automotive and industrial specs that I see everyday always call for N•m. Having foot pounds converted to joules by default strikes me as very odd. In my [professional] opinion, it should be switched. —MJCdetroit (talk) 01:59, 26 November 2007 (UTC)

Actually, you are wrong, MJCdetroit. Those ft·lbf, in·lbf, in·ozf (use the &middot; · rather than the &bull; •) can be either units of energy (SI units: joules) or units of torque (SI units newton meters). (The dimensional analysis of the units is the same. Some people make a dot product vs. cross product distinction between these quantities.)

On the other hand, units of lbf·ft (pound-feet), unlike the foot-pounds order used above, are normally used only for torque, and not for energy. Some authors like to distinguish the two units in English units by the order used, others don't do so and use ft·lbf for either torque or energy.

With firearms, you are most often dealing with the energy units, usually energy at the muzzle, sometimes at the target. Joules are the proper choice there.

Furthermore, in the non-SI metric units, a common order for the torque units was meter-kilograms (m·kgf), etc., mass unit first rather than the force unit first in N·m in SI. Gene Nygaard (talk) 02:16, 26 November 2007 (UTC)

Note: This is just one of the many cases, where no matter how sophisticated the templates are, the users of them still need to do the basics outside the template:

• The units being converted from need to be properly identified
• The units being converted to need to be properly chosen

Gene Nygaard (talk) 02:19, 26 November 2007 (UTC)

This, however, is a problem:

{{convert|53|lbfft|J}}: 53 pound force-feet ()

{{convert|53|lbf·ft|J}}: 53 pound force-feet ()

{{convert|53|lbfft|Nm}}: 53 pound force-feet (72 N⋅m)

{{convert|53|lbf·ft|N·m}}: 53 pound force-feet (72 N⋅m)

{{convert|53|ft·lbf|N·m}}: 53 foot-pounds force (72 N⋅m)

{{convert|53|ft·lbf|J}}: 53 foot-pounds force (72 J)

{{convert|53|ftlbf|J}}: 53 foot-pounds force (72 J) Note the improper plural problem, too!

{{convert|53|ftlbf|Nm}}: 53 foot-pounds force (72 N⋅m)

{{convert|53|ftlbf|N·m}}: 53 foot-pounds force (72 N⋅m)

{{convert|53|ftlbf|inozf}}: 53 foot-pounds force (10,200 in⋅ozf) Note the forced formatting

{{convert|53|inozf|ftlbf}}: 53 inch-ounces force (0.28 ft⋅lbf) ditto to both above

Gene Nygaard (talk) 02:35, 26 November 2007 (UTC)

I've gone and filled in the holes and corrected the mistakes noted by Gene above except for the forced formatting issue. I believe you refer to the "f"'s getting subscripted automatically, Gene. That's not hard to change but what's the status of "lb_f" vs. "lbf" on WP? MOS:NUM doesn't seem to mention it. We might assume either are okay but wouldn't it be better to have consistancy accross the encyclopædia on this? Jɪmp 06:10, 26 November 2007 (UTC)

That attitude is part of the overall problem of the philosophy and implementation of this template, something that still needs discussing in some other more appropriate forum. Gene Nygaard (talk) 06:22, 26 November 2007 (UTC)

Which attitude? Filling in the holes or (sometimes) prefering consistancy? I've made the subcripting optional. If you start up a discussion about the overall problem of the philosophy and implementation of this template, be it here or elsewhere, I'd be happy to join. Jɪmp 06:55, 26 November 2007 (UTC)

Jimp, thanks for the continuing updates.

I prefer lbf without subscript. It is the easier format to write, so humans will use it. Template and manual versions of the unit look the same.

Any format that can be written easily on a keyboard has those advantages. So given a neutral choice, the non-superscript or non-subscript versions would be my preference for the house style. It is unfortunate that language dependent forms 'sq m', 'qm', 'mc', 'mq' are easier to type than m². It is similarly unfortunate that N.m is easer to type than N·m. Lightmouse (talk) 19:13, 26 November 2007 (UTC)

(outdented) On second thought, I retract what I was saying above; Gene's statements above do clear some things up. In automotive and [U.S.] military specs (e.g. Chrysler's PF-6616 & MIL-S-46163A), torque is most times stated in in·lbf (inch-pounds) or sometimes in ft·lbf (foot-pounds) for "English" units and are never stated as lbf·ft (pound-feet) etc; none that I've seen anyway. However, ASTM specs like ATSM D 5649 do call out for pound-feet. That being said and because as Gene stated, ft·lbf, in·lbf, in·ozf can be used either for units of energy or torque, I think that this maybe an instance where we should not let the template choose the default unit; force the user to do so and make note of this exception somewhere on the doc page. —MJCdetroit (talk) 19:26, 26 November 2007 (UTC)

It doesn't take any great genius to use a search engine to find zillions of instances of pound-feet (and about a zillion different abbreviations for it (libra-ft, lb.-ft., lbf.ft, lbs-feet, often looking like there is some division involved such as "LBS/FT" or whatever, for automobile torque--including a number of them on Wikipedia. Gene Nygaard (talk) 20:07, 26 November 2007 (UTC)

Here's SAE Technical Standards Board Standard TSB 003 (1999), Rules for SAE Use of SI (Metric) Units:

TABLE B1 APPLICATION OF SI UNITS

Quantity	Typical application	From Old Units	To Metric Units	Multiply by[1]
Moment of force, torque bending unit	General, engine torque, fasteners	lbf·in	N·m	0.112 984 8
		lbf·ft	N·m	1.355 818

Gene Nygaard (talk) 20:23, 26 November 2007 (UTC)

G.N., for someone who has been blocked before for incivility, you should mind your tone and not use statements like "doesn't take any great genius to use a search engine". The specs I was referring to above are direct publications of the manufacturer/government. They were sitting on my desk (along with a mountain of other similar torque specs) and did not require a search of the internet. My point was that we should not have default units for ft·lbf, in·lbf, in·ozf. We need to force the users to choose to convert them to N·m or joules. —MJCdetroit (talk) 21:31, 26 November 2007 (UTC)

Good grief. I merely pointed out that there is ample evidence of the use of pound-feet in the auto industry. False accusations of incivility are incivility themselves. Here is SAE Technical Standards Board Standard TSB 003 (1999), Rules for SAE Use of SI (Metric) Units:

TABLE B1 APPLICATION OF SI UNITS

Quantity	Typical application	From Old Units	To Metric Units	Multiply by[1]
Moment of force, torque bending unit	General, engine torque, fasteners	lbf·in	N·m	0.112 984 8
		lbf·ft	N·m	1.355 818

Here's some acura.com specs:[1]

• Torque   256 lbs-ft @ 5000 rpm

HMMWV specs at https://wrc.navair-rdte.navy.mil/warfighter_enc/landcrft/hmmwv.htm

• Torque 290 lb-ft (393 Nm) at 1,700 RPM

Saab saabusa.com[2]

• 5.3-LITER ACTIVE FUEL MANAGEMENT 8-CYLINDER (V8) ENGINE, 300 HP
• SAE peak torque–330 lb. ft. @ 4000 rpm

Need more? Gene Nygaard (talk) 23:03, 26 November 2007 (UTC)

Originally, I did not like the design concept of default units. It does not save much space or effort. I think I have seen people say it helps people that do not know what the converted unit should be. But that reason is just too weird for me to parse. Furthermore, I think that it reinforces a dangerous but popular misconception that there is a word-for-word translation between the systems. However, I am now resigned to this concept. If this concept is to be applied consistently, I suggest N·m as a default because it is more common as a target unit on Wikipedia. Lightmouse (talk) 19:40, 27 November 2007 (UTC)

I was just hoping to make the template easier to use. If you're converting kilometres, for example, it'll almost always be to miles ... no it doesn't have to be though. I suppose I overlooked the potential reinforcement of the dangerous but popular misconception you mention. If foot pounds and the like are more often used as torque units, then, sure, let's change it to N·m. Jɪmp 04:20, 3 December 2007 (UTC)

Grains of water?

Does anybody know how to convert 'grains of water'? The more I look at the Firearms template, the weirder it seems. Please see the conversation at: User Tra.
Lightmouse (talk) 19:46, 27 November 2007 (UTC)

Looking at the information I've been given on my talk page, it might be possible to use something like 123 gr (8.0 g) H2O. However, is this a standard way to express the units? If not, it would be nice to have gr H2O supported as a unit of volume. Tra (Talk) 21:48, 27 November 2007 (UTC)

It's just some arcane stuff known to the person who put it there, just like this {{convert}} is a black box full of arcane stuff known to the one person now capable of editing it. Let his conversions be your black box for this. It's already converted to milliliters everywhere it appears, isn't it—so there's no need for this template to handle it. Gene Nygaard (talk) 04:38, 28 November 2007 (UTC)

Here's a conversion factor for you:

• 1 imperial gallon = 70,000 gr H₂O (Weights and Measures Act 1824)

The firearms ones use slightly different conditions for the water, however. Gene Nygaard (talk) 05:57, 28 November 2007 (UTC)

I'm sure this "one person now capable of editing it" would be happy to explain the workings of the new version of the template to anyone who felt like editing it ... and has indeed said that this is what he intends to do. Yes, the template has become complicated but it wasn't made complicated for the sake of complication ... as noted above. And yes, it now contains some arcane stuff (known to the author ... no, he didn't fill it up with stuff he don't know) ... which could be put up for deletion if it's hurting anybody. Though if this ocean of frivolity isn't doing any harm, why not add a drop or two more?

So, 1 gr H₂O = 1⁄70,000 imp gal. This could be added to the template, seems well sourced and well defined but, alas, is not the grain of water we're after (as noted by Gene). Can we find a reliable definition for the other grain of water? Supposing we can, how do we distinguish them? Would it be appropriate to call one an "imperial grain of water" & the other a "US customary grain of water"?

The conversions are already done, so, no, there is no need for this template to do them ... but if you want to use this template, I'm not about to say "No." Why would you want to use this template instead of what's already there? One advantage would be that the conversion factor going from gr H₂O to cm³ will be the inverse of that going to other way—currently it's 0.065 cm³/gr H₂O one way and 15.432 gr H₂O/cm³ the other, 0.065 × 15.432 ≠ 1. Conversion factors on the current version of this template are exact not approximate (a future exception to this might be angles to radians—anavoidable π's irrational). Of course, still you don't need this template to address this issue, in fact that's easy to fix.

Not so easy, though, would be to deal with rounding. Currently the firearms template rounds to the nearest gr H₂O or mm³ regardless of input. Perhaps the editors of that template would prefer to use convert's black-box precision-matching default rounding. Yes, how it's done might as yet be all hocus-pocus ... and could ever be so, but what it does isn't too hard to fathom: the precision of the output is matched to that of the input. Perhaps they don't want zeros' vanishing from a decimal expansion upon rounding. Perhaps they just like convert. If something's useful, well defined & well sourced, why not add it?

Jɪmp 06:20, 29 November 2007 (UTC)

My comments are:

• The firearms template used to have inconsistent precision. It now uses the convert template with the default precision matching. This has been accepted. I assume default precision matching will continue to be acceptable.
• The quote given by MJCDetroit on the talk page of Tra gives instructions that produce a 'weight of water in measured in grains'. Web articles about firearms are consistent with those instructions. I searched the web for scales and they all used the normal grain (even specialist firearms scales).

Lightmouse (talk) 10:51, 29 November 2007 (UTC)

Yes, MJDetroit gave us a definition but that definition is dependant on the density of water. This density is dependant on temperature and pressure. So the grain of water definition given by Gene is not inconsistent with those intructions: the imperial gallon was originally based on the volume of 10 lb (70,000 gr) of water. The kilogram too was originally based on the density of water, however, a different temperature was used. So, which is the "normal" grain of water: the one which assumes 1 ml of water to have a mass of 1 g or the one which assumes 1 imp fl oz to have a mass of 1 av oz? Is the fact that the litre doesn't actually have a mass of exactly 1 kg accounted for? --Jɪmp 21:32, 29 November 2007 (UTC)

When I said 'normal' grain, I was referring to 0.06479891 gram. I hope that is what we have in the convert template.

A brief search of the web makes me suspect that many grain-of-water conversions into volume are unsophisticated. It would not surprise me if many of them used 1 g/cm³. Thus 1 grain would be 0.06479891 cm³.

The BIPM states that the litre-based-on-kilogram was 28 parts per million adrift from a cubic decimetre. Other references (including the Wikipedia litre article) make explicit statements that the litre of pure water was 1.000028 dm³ at 3.98 °C. If my arithmetic is correct, a grain of water would be 0.0648007244 cm³. However, I do not believe anyone does the measurements with those conditions.

If the Wikipedia water article is to be believed, water is 0.9982071 g/cm³ at 20 °C (room temperature). If my arithmetic is correct, a grain of water would be equal to 0.0649152966 cm³. Again, the conditions are not controlled with respect to temperature, pressure or purity. Water poured into the cartridge is not pure and then it picks up more impurities from the cartridge. The cartridge will, of course, retain some water when it is tipped out so the apparent volume will be reduced.

My conclusion is that the range is from 0.06479891 to 0.0649152966 g/cm³. I reiterate my doubts that any firearm reference has considered temperature, purity, water retention. I bet that they either use 0.06479891 or 0.0648007244 g/cm³. Lightmouse (talk) 11:23, 30 November 2007 (UTC)

The one used on Wikipedia assumes water at a temperature of 21 °C, without compensating for buoyancy due to the fact that the water-filled cartridge is weighed in air.

I've seen some indications in other sources of a use of water at 70 °F for this purpose (there were enough overprecise conversions originally to determine that what was used here wasn't 70 °F but rather had to be closer to the 69.8 °F (21.0 °C) value.

Note that this means that neither the imperial gallon comparison (originally based on water at 62 °F, weighed in air with brass weights), nor the not-quite-realized kilogram/liter of water equivalence, nor the 1901–1964 redefinition of a liter as something different from a cubic decimeter, equal to the volume of a kilogram of water at maximum density, will give a highly precise conversion value here. Gene Nygaard 14:55, 2 December 2007 (UTC)

So, I wonder, after all of this, what conversion factor(s) we're deciding on. Jɪmp 04:22, 3 December 2007 (UTC)

Some other funny conversion templates

I keep seeing funny conversion templates. I would be happy to update my monobook script to replace them on sight. It already replaces 'km:h' in the code with 'km/h'. Perhaps a bot could search and replace the many ad hoc templates with this one.

The use of 'mi to km|187|round' produces a fault at Willamette River. It also contains 'CubicFeetPerSecAndMeters|67800|round'/

What do people think? Lightmouse (talk) 20:37, 28 November 2007 (UTC)

I don't see anything wrong with {{mi to km}} in that article. {{Ft to m}} there fails because the parameter starts with a space. Could you, please, clarify?—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); 20:52, 28 November 2007 (UTC)

Power units

Please can this template be updated to handle 'horsepower', 'bhp', 'shp' and 'ihp'? These are very common. Thanks. Lightmouse (talk) 19:02, 29 November 2007 (UTC)

Horsepower works (use hp) as do the watt & its multiples. I get onto the others soon. Jɪmp 21:36, 29 November 2007 (UTC)

Am I right in interpreting 1 ihp and 1 shp both to be equivalent to 1 hp, the difference being where you're measuring? Boiler horsepower is more difficult. The definition goes - "The amount of energy needed to produce 34.5 pounds of steam, per hour, at a pressure and temperature of 0 Psig and 212 ºF, with feedwater at 0 Psig and 212 ºF." but what's this in watts? Here are some conversion factors I found:

• 33,475 BTU/Hr (but which Btu?)
• 33,446 Btu/hr
• 33,480 Btu/hr
• 9807.875 W
• 33,472 Btu/hr
• 33,475 Btu/h (9.8095 kW)
• ≈ 34.5 lb/h × 970.3 BTU_IT/lb ≈ 9.810 657×10³ W
• about 33,478.8 Btu per hour (about 9,809.5 watts)
• about 33,479 Btu per hour (about 9,810 watts ...
• 33,475 BTUH

Jɪmp 00:27, 30 November 2007 (UTC)

Here's what I get:

Enthalpy of vapourisation of water at 100°C [3]

≈ 40.657 kJ/mol

Molality of water (ibid.)

≈ 55.508472 mol/kg

Pound to grams conversion

≡ 453.59237 g/lb

Enthalpy of vapourisation of water at 100°C

≈ 40.657 × 55.508472 × 453.59237 kJ/mol × mol/kg × g/lb

≈ 1023670.865 J/lb

1 bhp

≈ 1023670.865 J/lb × 34.5 lb/h

≈ 35316644.84 J/h ÷ 3600 s/h

≈ 9810.179122 W

≈ 9810.2 W (rounding to five sig fig)

Note: I've not taken account of pressure.

Jɪmp 01:17, 30 November 2007 (UTC)

As you suggest, lot of the horsepower names indicate the method or location of measurement, not the conversion value. To date, I have converted 'bhp', 'shp' and 'ihp' as equivalent to 'hp'. I have always considered 'bhp' as 'brake horsepower' and not considered it as an abbreviation for 'boiler horsepower'. Frankly, the precision in Wikipedia articles is so low that I have not worried about it. Furthermore, there are many errors in Wikipedia articles (imported from incorrect sources or in-house errors). Even manufacturers are sloppy, a US website of a German manufacturer had two different 'horsepower' values for the same car. I believe one was the 'correct' American horsepower value after all the right people got involved, the other was the understandable (and therefore common) direct translation of PS from German into English as 1 hp, which was wrong for US readers.

Many Wikipedia articles about non-US cars quote an incorrect kW value because of this general confusion. I have corrected many of them by going to the home website and getting kW raw data. Unfortunately, this is not a problem that can be solved by the convert template. My inclination would be to start with the US value for 'bhp', 'shp', 'ihp', 'hp', 'horsepower' and then get more sophisticated later by addressing the varieties listed in the horsepower articles. Lightmouse (talk) 11:48, 30 November 2007 (UTC)

However, it is improper for you to use {{convert}} in a way that throws away that additional information and replaces it with 235 horsepower (175 kW) or the like. If you remove the information from the symbol, it is your responsibility to include it back again in some other way.

The identity of the horsepower used in various articles is a problem, of course. Basically, there are only two different units used; the English horsepower of 550 ft·lbf/s (745.700 W) and the metric horsepower (often PS in English, sometimes CV or ch or various other symbols) of 75 m·kgf/s (735.499 W), but a great many articles do not specifically identify the ones used.

How many of those various symbols for metric horsepower does this template support now? How many should it support? Gene Nygaard 14:36, 2 December 2007 (UTC)

I do not use the convert template to throw away 'bhp' and replace it with 'hp'. In fact, I am currently using auto templates ('auto bhp', auto shp' etc) that I created as variants of somebody else's 'auto hp'. I merely meant that I used the same conversion factor for them all. The only difference the reader will see is the addition of '(xx kW)'. Lightmouse 21:43, 3 December 2007 (UTC)

Note: "ihp", "shp" & "bhp" are now up and running (with the same conversion factor as "hp").

{{convert|123|ihp|lk=in}} → 123 indicated horsepower (92 kW)

{{convert|123|ihp|abbr=on}} → 123 ihp (92 kW)

{{convert|123|shp|lk=in}} → 123 shaft horsepower (92 kW)

{{convert|123|shp|abbr=on}} → 123 shp (92 kW)

{{convert|123|bhp|lk=in}} → 123 brake horsepower (92 kW)

{{convert|123|bhp|abbr=on}} → 123 bhp (92 kW)

Jɪmp 00:02, 4 December 2007 (UTC)

Thanks. I think that will let me eliminate the 'auto' templates from my monobook script. Lightmouse 19:14, 4 December 2007 (UTC)

It should do unless you've got km/l-mpg-l/100 km conversions in there. These are not supported yet ... they're in the works but a whole new subsystem has got to be put in place to handle the inversions and the imperial/US distinction (with the distinguishing terms after (or within if spelt out in full) the unit). Jɪmp 23:39, 4 December 2007 (UTC)

<out> Jimp, can you show me some Wikipedia articles using that "boiler horsepower"? Or are you just wasting a whole lot of time worrying about trivial, insignificant, obsolete usage that isn't likely to ever show up on Wikipedia, or if it does in one or two cases it should be explained in a more detailed manner than the convert template can handle, and can be better done manually in those cases without any template? Gene Nygaard 14:47, 2 December 2007 (UTC)

Gene,

No, I can't. Lightmouse mentioned bhp which is either an abbreviation for "brake horsepower" or "boiler horsepower" and said it was very common. I thought he had meant the second and preceeded to try and flesh out the difficulties of adding such a unit where no standardised conversion seems to exist. I suppose I was just wasting time. The template supports PS, CV & hk. You can also use hp-metric to get the unit spelt out as metric horsepower or the symbol hp. Should we add any more? --Jɪmp 15:31, 2 December 2007 (UTC)

You misunderstand me. I have never seen the term 'boiler horsepower' before you mentioned it at the top of this section. Lightmouse 16:56, 2 December 2007 (UTC)

Yes, I did misunderstand you but you did write "I have always considered 'bhp' as 'brake horsepower' and not considered it as an abbreviation for 'boiler horsepower'." When I read that I understood. Perhaps we can safely get by without boiler horsepower. --Jɪmp 18:29, 2 December 2007 (UTC)

I've added ihp, shp & bhp with the same conversion factor as hp. E.g.

• {{convert|1000|hp}} ==>> 1,000 horsepower (750 kW)
• {{convert|1000|ihp}} ==>> 1,000 indicated horsepower (750 kW)
• {{convert|1000|shp}} ==>> 1,000 shaft horsepower (750 kW)
• {{convert|1000|bhp}} ==>> 1,000 brake horsepower (750 kW)
• {{convert|1000|kW|hp}} ==>> 1,000 kilowatts (1,300 hp)
• {{convert|1000|kW|ihp}} ==>> 1,000 kilowatts (1,300 ihp)
• {{convert|1000|kW|shp}} ==>> 1,000 kilowatts (1,300 shp)
• {{convert|1000|kW|bhp}} ==>> 1,000 kilowatts (1,300 bhp)

Jɪmp 01:08, 3 December 2007 (UTC)

Hopefully I haven't missed this being mentioned elsewhere, but two sources use a different value for the above conversions: Google and Britannica. Both use a "1 hp = ~746 watts" (745.699872 to be more exact). Equalling all of the types of horsepower to each other seems acceptable, though if higher precision were desired, I'd simply apply a 10% subtraction from brake and shaft horsepower output to account for approximate friction-loss. -- Huntster ^{T • @ • C} 02:44, 3 December 2007 (UTC)

Those conversions above are automatically rounded to two significant figures. The conversion that this template is using is

1 hp = 745.69987158227022 W

as derived from the following definitions/standards

1 hp	≡ 33,000 ft·lbf/min
1 min	≡ 60 s
1 lbf	≡ 1 lb·g
g	≡ 9.80665 m/s²
1 lb	≡ 0.45359237 kg

So, yes, this template uses a different conversion factor. It uses the exact 17-significant-figure conversion factor whereas Google seems to use a factor rounded to nine significant figures. Jɪmp 03:43, 3 December 2007 (UTC)

Nine or 17 digits won't make a bit of difference in any actual measurement of power. In fact, I doubt that there are any measurements of power on Wikipedia, and not likely anywhere else at any time all throughout history, where 1 hp = 745.700 W (relative error 1 part in 6 million for most common current pound-force definition) and 1 PS = 735.499 W (relative error 1 part in 3 million) would not be more than sufficient for the precision of the measurement of power, especially for any measurement of power that would be expressed in either of these horsepower units. And the 17-digit one is only exact if you assume a particular definition of a pound-force; there is no generally established official definition of it, and even in that case, only post-1959 since the pound force always depends on the definition of the pound as a unit of mass. There is no requirement that we borrow the same acceleration which is official for defining kilograms-force; that is the way it is most often done today, but it doesn't have to be that way. Some have used, e.g., a standard acceleration of 32.16 ft/s² to define the pound force, others 32.2 ft/s².

And even without the acceleration choice, we still have the definitions of the pound and the foot varying over time and location. For example, even using the kilogram-force acceleration, a 1955 U.S. horsepower would be 745.7014578 W to 10 digits (based on a pound of 453.5924277 kg and a foot defined so 1 m = 39.37 inches), differing from the conversion factor Jimp is using in the sixth digit.

I'd still use Jimp's numbers; just pointing out that there is no need to worry about slight variants over time and location. A 283 hp 1957 Chevy will still be 211 kW, even though both feet and pounds were defined differently in the United States then from what they are now. Gene Nygaard 16:35, 3 December 2007 (UTC)

---

←Previous archive