Template talk:Convert/Archive February 2009

Manual of style bans format used by convert template

It was recently brought to my attention that the Manual of style bans a format used by the template:

• {{convert|70|to|90|cm}} --> 70 to 90 centimetres (28 to 35 in)

I think the template is right and the guideline should be changed. Please comment at: Proposal: Delete guideline that bans "70 x 90 cm" and mandates "70 cm x 90 cm". Regards Lightmouse (talk) 11:41, 27 January 2009 (UTC)

First of all, the Manual of Style can't ban anything, since it is a guideline. With that said, thanks for bringing that discussion to attention here, Lightmouse. — Bellhalla (talk) 12:55, 27 January 2009 (UTC)

I note your comment about ban versus guidance. Thanks for pointing that out. Lightmouse (talk) 15:31, 27 January 2009 (UTC)

Also, the real reason the MoS discourages "70 x 90 cm" is because it could be interpreted to be a mathematical calculation yielding 6300 cm rather than 6300 cm². In contrast, "70 to 90 cm" is obviously not a calculation like " 70 - 90 cm", and cannot be interpreted to equal -20 cm.RockyMtnGuy (talk) 04:09, 30 January 2009 (UTC)

Please can we confine the debate to Proposal: Delete guideline that bans "70 x 90 cm" and mandates "70 cm x 90 cm". Otherwise we will have the same debate in two places. Thanks. Lightmouse (talk) 10:23, 30 January 2009 (UTC)

No, I won't go there. There are limits to the amount of inane nitpicking I can cope with reading.RockyMtnGuy (talk) 23:17, 31 January 2009 (UTC)

I sympathise with you. A huge proportion of it is ad hominem that isn't constructive to the project. Lightmouse (talk) 11:57, 1 February 2009 (UTC)

Bell weights

Please see discussions at User_talk:Oosoom#Bell_weights. Lightmouse (talk) 12:43, 6 February 2009 (UTC)

Round to the nearest 0.5, 5, 50, etc.

In some cases it's desireable to round to the nearest 5 instead of 10. For example: "about 40 mi (65 km)". With the current rounding options my only integer choices are "40 mi (60 km)" or "40 mi (64 mi)"; one is too coarse and the other is too fine. —Tonyle (talk • contribs) 11:06, 23 January 2009 (UTC)

In what circumstances, exactly? Chris Cunningham (not at work) - talk 10:55, 30 January 2009 (UTC)

If an approximate figure is mentioned that is rounded to the nearest 5, it makes sense to do a conversion to the nearest 5 (if the units are roughly the same order of magnitude). For example, in the first paragraph of 1900 Galveston hurricane:

It had estimated winds of 135 mph (215 km/h) at landfall, making it a Category 4 storm on the Saffir-Simpson Hurricane Scale.

This sentence does not use the Convert template unlike other sections of the article, possibly because Convert can only give either 217 km/h (which doesn't read as an estimate) or 220 km/h (which doesn't have the same intended precision of the original). —Tonyle (talk • contribs) 20:12, 30 January 2009 (UTC)

I disagree with the premise. The estimate was not made in km/h; it is therefore inappropriate to speculate as to what it would have been estimated at, had it been made in km/h. The only appropriate conversion is from what it was measured in; the purpose of providing a converted measurement is not to supplant the original, it is to provide a frame of reference for readers who may be unfamiliar with the original units. That line should be read as "estimated at 135 mph (which is 217km/h)", not "estimated at 217 km/h". Chris Cunningham (not at work) - talk 20:41, 30 January 2009 (UTC)

Saying "estimated at 135 mph (215 km/h)" does provide a frame of reference without supplanting the original, just as "135 mph (217 km/h)" does. One is simply more precise than the other. By your argument, "about 135 mph (220 km/h)" is also inappropriate, even though the Convert template allows it. By that same argument, should a phrase such as "weekly mileages of over 100 miles (160 kilometres)" (Marathon#Training) thus be rendered as "... over 100 miles (161[.09344] kilometers)"? My vote is for the former case which, it turns out, still satisfies your criterion for an appropriate conversion from what it was measured in: tens of miles, rather than single miles. —Tonyle (talk • contribs) 00:20, 31 January 2009 (UTC)

Providing a comparison to an appropriate number of significant figures (as your 100km example does) is a perfectly normal practice. I don't buy that there is a compelling need to go further and round to halves. Chris Cunningham (not at work) - talk 00:47, 31 January 2009 (UTC)

In the U.S. customary system if somebody says something is 10½ feet tall, that can be taken to imply less precision that when somebody says the object is 10 feet 6 inches tall. I'm not sure that sort of use justifies a major change to the template, but it is an example of when it might be useful. — Bellhalla (talk) 18:28, 10 February 2009 (UTC)

Error in conversion of carat

If I convert 33.19 carats using 200 mg/carat, I get 6.638 grams but if I use the template, it gives me 6.64 grams. Can somebody correct the error? Lightmouse (talk) 20:19, 8 February 2009 (UTC)

What is there to correct? It is converting correctly, just rounding to two decimal places, as the input uses. If you use {{convert|33.19|carat|g|3}} it will show 33.19 carats (6.638 g). — Huntster (t • @ • c) 21:05, 8 February 2009 (UTC)

I thought rounding was to significant figures, not decimal places. Lightmouse (talk) 21:28, 8 February 2009 (UTC)

Rounding like that is to the specified number of decimal places. You can round to yeah-many significant figures: "|sigfig={some non-negative integer}."

{{convert|33.19|ft|3}}	→	33.19 feet (10.116 m)
{{convert|33.19|ft|sigfig=3}}:	→	33.19 feet (10.1 m)
{{convert|33190|ft|3}}:	→	33,190 feet (10,116.312 m)
{{convert|33190|ft|sigfig=3}}:	→	33,190 feet (10,100 m)

—WWoods (talk) 02:39, 9 February 2009 (UTC)

I am aware of the sigfig option, I just thought that the template used sigfig matching by default. I looked at the template instructions in the Default rounding section and I see it is complicated. I had trouble working out what the text meant so I looked at the Wikipedia article Arithmetic precision:

• Arithmetic precision divides precision into two types: rounding to sigfig (precision of 5 = 5 sigfig); and rounding to decimal places (precision of 5 = 5 decimal places). Thus sigfig rounding is a type of 'precision'.
• the template instructions uses the top level term 'rounding' and puts 'precision' as an alternative to sigfig. It implies that sigfig rounding is not a type of 'precision'.

They can't both be right. Lightmouse (talk) 09:59, 9 February 2009 (UTC)

I think we might have to look at the use of vocabulary on the doc page. You're right sigfigs is a kind of precision but the doc uses precision to mean only decimal-place precision. The default rounding is not quite significant-figure based but precision based (in the broader sense). In this sense I mean the precision of the input number, the input unit and the output unit are all accounted for. Note that "6.638 grams" i.e. "6.638±0.0005 grams" in inherently more precise than "33.19 carats" i.e. "33.19±0.005 carats" i.e "33.19 carats ±0.01 grams". Such in increase in precision the template deems unacceptable (border-like actually: only just unacceptable e.g. 33.19 knots it converts to 61.47 km/h) so rounds up. Now, in this case, you might argue that it's not unacceptable for this reason or that but, alas, 'tis only a dumb template so you have to fix it by hand. No error, though, the template is handling this as it was designed to do. JIMp _talk·cont 20:16, 9 February 2009 (UTC)

I was convinced that it simply matched sigfigs, so it looked like an inconsistency (i.e. a bug). I had no objection to that particular conversion format. As you say, the ratio between the unit sizes may be a ratio between implied precision. I sometimes become aware of this ratio in conversions but had never thought it through. I do think the doc page could be improved, the Arithmetic precision article seems to have useful stuff which we can link to. I think part of the problem is that I can give a numerical value to the default precision but I can't name it. It does seem similar to what the 'Arithmetic precision' article calls 'decimal precision', but it doesn't require decimals. I agree with your conclusion of 'not a bug'.
Incidentally, I note the 'Arithmetic precision' article doesn't refer to integer precision which is a common form. For example, mountain heights (integer ft <-> integer m) and floor areas (integer sqft <-> integer m²). I am not proposing anything for the template, I am just remarking on an insufficiency in the article. Lightmouse (talk) 09:53, 10 February 2009 (UTC)

Problem

Can someone figure out what changed to trigger CNO cycle to call the non-existant Template:Convert/ScientificValue/LoffAonSoffT? Best I can tell, it is coming from the embedded call to {{val/units|K}} = {{val/units|K}} Dragons flight (talk) 03:36, 11 February 2009 (UTC)

Abbreviations cwt

Could I please request that an abbreviation for output of long cwt (and, perhaps short cwt) be added as cwt. I am not aware that long cwt, or even long ton are in common use. The actual units intended will usually be easily found from context. Thanks. Oosoom ^Talk 16:13, 6 February 2009 (UTC)

Long ton and short ton were used in British planning documents in World War II (probably only after Dec 1941). The reason for using long ton instead of ton was to avoid ambiguity with US short tons.

I have never seen long cwt in any document.--Toddy1 (talk) 16:18, 6 February 2009 (UTC)

The long ton of 2240 pounds is still used in international shipping, along with the short ton of 2000 pounds and the metric ton of 1000 kilograms. This sometimes causes errors in international shipments when buyers, sellers, and ports use the same name for different units, and ships carry cargoes measured in a mix of different tons. As far as I know, the long hundredweight of 112 pounds isn't in common use any more, since it is very close to the metric hundredweight (50 kilograms), but I could be wrong.RockyMtnGuy (talk) 16:58, 6 February 2009 (UTC)

Cwt [of 112 lbs] are used in reference books - I have never seen the term long cwt--Toddy1 (talk) 17:37, 6 February 2009 (UTC)

The underlying issue is that the Americans and Brits can never agree on the exact value of units. It has something to do with that unfortunate misunderstanding in the 1776 time frame. I assume that you identify more closely with the British since you think a hundredweight is 112 pounds. The American version is 100 pounds, which (for want of a better phrase) we call the short hundredweight, and the British version is 112 pounds, which we call the long hundredweight (to differentiate it from the American hundredweight). We here in the colonies try to avoid using either.RockyMtnGuy (talk) 19:09, 10 February 2009 (UTC)

Yes I was brought up with 112 lbs in a cwt, but as with probably most British people had never come across long cwt before, and was rather amazed that this new unit was going to appear in a any article which used {{convert}} on cwt. In an article on, for example, a historic British topic it seems grotesque to see unfamiliar units which would need looking up to see what they mean. Since {{convert}} is being used there can be no ambiguity about the real meaning of the weight. Oosoom ^Talk 09:33, 11 February 2009 (UTC)

Both the UK and US use cwt as an abbreviation for their favourite (or favorite) version. The trouble with it is that it is ambiguous in the international context:

1. British a unit of weight equal to 112 pounds or 50.802kg
2. US & Canada a unit of weight equal to 100 pounds or 45.359kg
3. A metric unit of weight equal to 50 kilograms
4. A metric unit of weight equal to 100 kilograms

None of this is very helpful if you are trying to editing an article for an international readership.RockyMtnGuy (talk) 00:56, 12 February 2009 (UTC)

Excessive use of double output

If you use the default template, you get a value in grains. The template usually has one output unit by default. In exceptional cases we have two output units. I think this one is not worthy of the exception.

• The gem weighs 33.19 carats (6.638 g; 102.4 gr) stone

Do Americans find it difficult to use the carat value plus the gram value and then get an 'aha moment' when they see the grain value? Lightmouse (talk) 20:25, 8 February 2009 (UTC)

You may be right. I s'pose few people are likely to be more familiar with the grain than either the gram or carat in the first place. I don't oppose changing it. JIMp _talk·cont 20:32, 9 February 2009 (UTC)

I don't understand how the template works. Can somebody tell me, or just do it, please? Lightmouse (talk) 17:42, 10 February 2009 (UTC)

Done. JIMp _talk·cont 19:47, 10 February 2009 (UTC)

In your example, I could instantly compare that grain weight to ammunition that I've dealt with in the past such as the .243 Winchester (that was my "aha moment") or I could multiply my wife's diamond by 33, but the grams mean little. Therefore, I oppose the change.

While the grain weight being there may annoy Lightmouse, he would be clearly annoyed if grams were removed; oh wait he already stated his displeasure in not including grams over at the MOSNUM's talk page even through the MOSNUM is clearly in favor of conversions. Which then spiraled into giant waste of MOSNUM page space. —MJCdetroit ^(yak) 00:04, 11 February 2009 (UTC)

Added the grains back in. I don't want to be the judge especially since I'm from a metric country so haven't much idea how useful grains are. JIMp _talk·cont 01:06, 11 February 2009 (UTC)

Every country is a metric country, including the United States, and, trust me, most Americans do not even know that a grain is a unit of mass. More of them are familiar with the gram.RockyMtnGuy (talk) 02:00, 11 February 2009 (UTC)

MJCdetroit, I asked a question about an exception to the norm and American usage. Answers from Americans such as yourself are particularly welcome. I mean you no harm. Please can you respond to the question rather than suggesting I am a bad person for asking it. Lightmouse (talk) 09:03, 11 February 2009 (UTC)

LM, don't get me totally wrong, I really do like that you make a great effort at adding metric values when they are not there; I do the same thing. What I don't like is that sometimes you let your admitted bias against anything not metric show itself in instances like this.

As for the MOSNUM comment, you've been around long enough to know that if metric units are being removed, that the MOSNUM guideline is completely backing you and you don't have to instantly come to the MOSNUM's talk page to protest about it as you have several times in the past. The Bean Cars discussion is one that comes to mind; which I defended you in. Start the discussion on the article in question's talk page first instead of coming to the MOSNUM. If you can't convince the opposing editors on the article in question's talk page, then leave link on the MOSNUM, or here. I'll gladly defend your editing actions as I have in the past. If you want to discuss this aspect further, shoot me an email or leave a message on my talk page. Regards,—MJCdetroit ^(yak) 15:06, 11 February 2009 (UTC)

Parenthetical phrases are always less legible; the question in any given case is whether the information is worth the cost in readability. In this case, another sentence giving the weight in a variety of more familiar units would be both more readable and more useful.

MOSNUM is a worthless product of rival edit-warring bullies; it is neither English nor consensus, and may be ignored on either ground. Septentrionalis PMAnderson 04:14, 13 February 2009 (UTC)

Change the default automatic conversion unit for metres

Currently, {{convert|2|m}} returns "6.6 ft". If no output unit is specified, input of metres should return feet and inches (ftin, as opposed to ft), as decimal fractions of feet are rather strange. Chris Cunningham (not at work) - talk 20:09, 12 February 2009 (UTC)

Not if it's the height of a mountain we're talking about ... but how about this? For more than three (ten, thirty ...) metres the default could stay as feet but for less it could go to feet & inches. JIMp _talk·cont 21:19, 13 February 2009 (UTC)

2 meters should convert to 6 ft anyway; the decimal point is spurious precision to begin with. No reason a mountain can't have a height in feet and inches if it's known to the nearest inch, which implies we are converting a metric measurement accurate to the centimeter. How many mountains are known to the centimeter? We give Mount Everest's height to the foot and to the meter, and that appears to be the available precision. (Anything much more precise would probably be temporary anyway, given the motion of the Indian Plate.) Septentrionalis PMAnderson 22:01, 13 February 2009 (UTC)

JimP's idea is fine by me. —MJCdetroit ^(yak) 23:01, 13 February 2009 (UTC)

"No reason a mountain can't have a height in feet and inches if it's known to the nearest inch," absolutely but it's unlikely that we will know the height to such precision. To get it working as described above here's the new code for {{Convert/m}}.

{{convert/{{{d}}}|{{{1}}}|{{{2|}}}|{{{3|}}}|{{{4|}}}|s={{{s|}}}|r={{{r}}}
|u=m
|n=met{{{r}}}
|t=metre
|o=ft{{#ifexpr:{{{1}}}<3|in}}
|b=1
|j=0-{{{j|0}}}}}<noinclude>{{pp-template|small=yes}}
[[Category:Subtemplates of Template Convert]]
</noinclude>

JIMp _talk·cont 00:01, 14 February 2009 (UTC)

 Done. Seems to be working okay, but the code page is showing an odd error. Is this normal? — Huntster (t • @ • c) 04:05, 14 February 2009 (UTC)

Normal. JIMp _talk·cont 12:08, 14 February 2009 (UTC)

Thanks! Out of interest, would it be possible simply to adjust the precision of the output in the >30m case rather than going back to decimal feet? Chris Cunningham (not at work) - talk 10:54, 14 February 2009 (UTC)

The template is set up to match the output precision with the input precision, however, ftin overrides this—it assumes that you want the output at least to the nearest inch. Drop this assumption and we might be in business but that'd take quite a bit of tweaking ... JIMp _talk·cont 12:08, 14 February 2009 (UTC)

Just so you know - surveyors do not use feet and inches, they use decimal feet, usually to the nearest 0.01 feet, but sometimes 0.001 feet. So the height of a mountain would not be measured in feet and inches, no matter how accurate it was.RockyMtnGuy (talk) 04:15, 15 February 2009 (UTC)

Glitch with abbreviation

If I utilize this template as such

{{convert|10|to(-)|15|cm|in|abbr=on}}

, it does not use the word "to" in the cm section like it should. If I take the abbr=on out, it then works. speednat (talk) 03:05, 15 February 2009 (UTC)

I'm afraid that's pretty much how it was designed. to(-) means to with spelt-out units & an en dash with abbreviations or symbols. How about using {{convert|10|to|15|cm|in|abbr=on}}? That'll give you "10 to 15 cm (3.9 to 5.9 in)" (with the to in the inch section too). Is that any use? JIMp _talk·cont 12:18, 17 February 2009 (UTC)

I sweat, that at one point, it would give me the desire result, 10 to 15 cm (3.9—6.0 in), but it seemed to have been changed, if that is possible. speednat (talk) 15:24, 17 February 2009 (UTC)

You've got an em dash there, you'd want an en dash, right? The thing is that the subtemplates which put the dashes/words/symbols in place don't know whether the number are in brackets or not. This was the simpler way of putting the thin together ("simpler"≠"simple"). I'll look in to how that can be changed but it might take a while. JIMp _talk·cont 23:19, 17 February 2009 (UTC)

Major error with this template?

What has happened? Look up this page or at Nanisivik Airport. Enter CambridgeBayWeather, waits for audience applause, not a sausage 05:16, 18 February 2009 (UTC)

See also, USS Connecticut (BB-18) and Japanese battleship Haruna —Ed 17 ^{(Talk / Contribs)} 05:34, 18 February 2009 (UTC)

Yeah, this needs to be fixed pronto. It seems to be affecting thousands of articles. Brianreading (talk) 05:37, 18 February 2009 (UTC)

Whoever made this change to the template, please change back ASAP. This is a total mess affecting thousands of articles.Beagel (talk) 05:45, 18 February 2009 (UTC)

It's not *this* template, it's actually the MediaWiki software. Note that Hamersley, Western Australia, which doesn't even use this template but uses one of its calculations manually, exhibits the same issues. Orderinchaos 05:47, 18 February 2009 (UTC)

All appears to be working now. If you're seeing broken feedback, purge the page in your cache so you can see the latest version of it. Orderinchaos 05:52, 18 February 2009 (UTC)

Problem with the template

{{convert|50|ft}}

gives the following error:

50 feet (15 m)

Does anyone know what is going on? WTucker (talk) 05:44, 18 February 2009 (UTC)

Wiki-wide problem with a whole heap of templates following a MediaWiki upgrade. They're working on it. Orderinchaos 05:46, 18 February 2009 (UTC)

(Always helps to subst, but it looked like: 50 ft ({{rnd/cExpression error: Missing operand for <dec0|9|0}} m) Orderinchaos 05:53, 18 February 2009 (UTC)

You are right, I should have substed to avoid the problem fixing itself in my comment. Thanks for you efforts -- all is right with the world and this template. WTucker (talk) 06:02, 18 February 2009 (UTC)

Range conversion

Range conversion has some other problems. Compare

• {{convert|0.80|-|0.85|m}}
• {{convert|0.80|-|0.85|m|ft}}
• {{convert|0.80|-|0.85|km}}

which produce (live)

• 0.80–0.85 metres (2 ft 7 in – 2 ft 9 in)
• 0.80–0.85 metres (2.6–2.8 ft)
• 0.80–0.85 kilometres (0.50–0.53 mi)

or substed (so this comment makes sense after the glitch is repaired)

• 0.80–0.85 metres (error in the use of {{convert}})
• 0.80–0.85 metres (2.6–2.8 ft)
• 0.80–0.85 kilometres (0.50–0.53 mi)

Somehow {{Convert/Dual/LoffAnd}} is called in the first case, so I put an error message there. --Rumping (talk) 14:28, 16 February 2009 (UTC)

I know what went wrong. I'll try fixing it when I get the chance. If it's causing enough strife, revert the most recent change to {{convert/m}} for now. (It doesn't seem to be. 6:51 pm GMT) JIMp _talk·cont 18:34, 16 February 2009 (UTC)

Looks better now. --Rumping (talk) 22:07, 17 February 2009 (UTC)

Keep us updated on any other such holes (there are a few left) urgently needing to be filled. JIMp _talk·cont 23:23, 17 February 2009 (UTC)

Range functionality broken in SM U-66. When will this be fixed? — Bellhalla (talk) 05:33, 18 February 2009 (UTC)

I didn't see anything. I thing it must have been the WikiMedia-wide problem mentioned below. JIMp _talk·cont 13:47, 18 February 2009 (UTC)

Ranges for basic temperature conversions?

Could anyone be a saint and add basic range support for Celsius -> Fahrenheit and back? I've seen a few articles which could really do with this. Chris Cunningham (not at work) - talk 16:07, 18 February 2009 (UTC)