Template talk:Convert/Archive July 2009

Volume conversion l × w × h
How would I go about doing a volume conversion of the form length × width × height? For example: 182.7 by 68.1 by 48.0 inches (4640 by 1730 by 1220 mm). The range conversions only seem to include 2-parameter conversions, is it possible to somehow do a three-parameter convert or would I have to do it by hand (like above)? --OldManInACoffeeCan (talk) 23:31, 13 June 2009 (UTC)


 * This is the same as the Template talk:Convert request above. It'd require the main Convert template to accommodate 8 rather than 6 parameters, and a whole Triple/ layer of sub-templates, though possibly only Length dimensions need be handled. —ClickRick (talk) 00:22, 14 June 2009 (UTC)
 * This is also usefull for dimensioning intermodal containers, etc. e.g. 8 ft by 8 ft by 20 ft. instead of 8 by by 20 ft. Peter Horn 02:21, 3 July 2009 (UTC)

Suggestions about default precision (ctd)
I'd like to support part of A. di M.'s suggestion at Template talk:Convert/Archive March 2009, namely that it would make more sense to put the boundaries for default rounding at 1/√10 ≈ 0.316 and = √10 ≈ 3.16 than at 0.2 and 2. I thought the same thing before checking back through the archives. The reason this makes sense mathematically is that if the conversion factor b to convert waldos to freds is between 0.316 and 3.16, so is the conversion factor 1/b to convert freds to waldos. By contrast, e.g. 0.4 is between 0.2 and 2 but 1/0.4 = 2.5 isn't. A couple of frequently-used conversion factors happen to be in the range 2 to 3.16: 1 inch = 2.54 cm, 1kg ≈ 2.20 lb. So default conversions from inches to cm (or metres, or mm ...) and kg to lb would gain an extra figure of precision. This would have avoided the problem in the section immediately above.

I'm less sure about abandoning the minimum of 2 significant figures though; there's a 1-in-10 chance that a two-digit number with 2 significant figures will end in zero and therefore appear to have only one significant figure. I'm not sure I want the default to be 20 kg (40 lb) rather than 20 kg (44 lb). In any case, probably wise to make one change at a time. Qwfp (talk) 17:48, 21 June 2009 (UTC)


 * I've stopped using default precision, and will always specify the precision I want until this nonsensical pedantry rounding people's heights to the nearest ten centimetres and people's weights to the nearest ten pounds gets fixed. (As for the latter, it could be fixed by changing the way significant figures in the input value are counted. You don't want "20 kg (40 lb)", but probably you don't want "15 km (9.3 mi)" either.) -- A. di M. (formerly Army1987) — Deeds, not words. 11:07, 5 July 2009 (UTC)

One works but the other don't.
I just noticed that 40 km/h works but 40 km/h does not. As per 40 km/h and 40 km/h. I would have thought the first would have been the more common usage. Enter CambridgeBayWeather, waits for audience applause, not a sausage 21:34, 29 June 2009 (UTC)


 * Okay, it has been created :) — Huntster (t • @ • c) 02:22, 30 June 2009 (UTC)


 * Thanks. Enter CambridgeBayWeather, waits for audience applause, not a sausage 05:14, 30 June 2009 (UTC)


 * Any chance a helpful passing admin could document the existence of both of these combinations at Template:Convert/list of units and Template:Convert/list of units/speed ? (PS: Is it really necessary to fully edit-protect such documentation pages?) Qwfp (talk) 10:20, 30 June 2009 (UTC)


 * ... or unprotect the lists since they are not meant to be transcluded onto the main space? J IM ptalk·cont 13:32, 30 June 2009 (UTC)


 * Changed both to semi-protection. Enter CambridgeBayWeather, waits for audience applause, not a sausage 17:45, 30 June 2009 (UTC)
 * Thanks, didn't realise you're an admin. I just tried editing it, however, and got the message, "This page is currently protected from editing because it is transcluded in the following page, which is protected with the "cascading" option: User:Nakon/cascade2". Huh?? Qwfp (talk) 11:14, 3 July 2009 (UTC)
 * I've left User:Nakon/cascade2|Nakon a comment. There appears to be a lot of protected material there and it might not be a good idea to change it until they reply. Enter CambridgeBayWeather, waits for audience applause, not a sausage 12:57, 3 July 2009 (UTC)


 * I just changed the protection on User:Nakon/cascade2 to semi. If someone would like to remove all the documentation pages from there and let me know so I change the protection back again. Enter CambridgeBayWeather, waits for audience applause, not a sausage 07:29, 4 July 2009 (UTC)
 * Thanks again. I've removed Convert/list of units and its subpages. I'm not sure if anything else might usefully be removed too while we have the opportunity, in particular perhaps the pages (where * is a wildcard) ? Qwfp (talk) 10:37, 4 July 2009 (UTC)
 * Aaaargh, seems its (even) more complicated than that. Template:Convert/list of units/speed just transcludes subpages such as Template:Convert/list of units/speed/impus that are still (conventionally) fully protected. Also there are many other subpages in Special:PrefixIndex/Template:Convert/list of units that are transcluded in User:Nakon/cascade3 (rather than cascade2), which still has cascading protection. I'm beginning to wish I'd never started this... I realise now why the documentation of this template isn't always entirely up-to-date! Qwfp (talk) 11:13, 4 July 2009 (UTC)

OK. So now User:Nakon/cascade3 is semi-protected. What's needed is a complete list of all the documentation pages. Enter CambridgeBayWeather, waits for audience applause, not a sausage 03:06, 5 July 2009 (UTC)
 * Thanks again. I've removed all the  entries from that page. Nearly all of them are still conventionally protected though. I believe all the documentation pages are subpages of Template:Convert/list of units, in which case a complete list of them is obtainable from Special:PrefixIndex/Template:Convert/list of units – something like 150 in all. If you can change all those to semi-protected, that would be great. Qwfp (talk) 11:21, 5 July 2009 (UTC)


 * Ah, changing to semi was easy using Twinkle but it turns out not all of them are documentation pages. Enter CambridgeBayWeather, waits for audience applause, not a sausage 12:10, 5 July 2009 (UTC)
 * Oh... I'd got the impression that, if not themselves documentation pages, then they were bits of documentation pages or templates that are transcluded only in the documentation pages. But there are too many for me to check, so I'll have to defer to their author, Jimp, on that one. Qwfp (talk) 12:26, 5 July 2009 (UTC)


 * I think you might be right. I just checked a couple of them and it appears that the only thing linking to some of the non-documentation pages are other documentation pages. Enter CambridgeBayWeather, waits for audience applause, not a sausage 12:32, 5 July 2009 (UTC)


 * Ok, good, I hope we've got the protection sorted out now. Many thank CambridgeBayWeather.
 * To return to where I came into this, namely to document the combinations "mph kn" and "kn mph", I've edited Template:Convert/list of units/speed/short list, which is transcluded into Template:Convert/list of units, the abridged list that appears in the Template:Convert page. The full list of speed units Template:Convert/list of units/speed defeated me though, as though it looks similar its construction is far more complex. I'll have to leave that to Jimp. Qwfp (talk) 17:43, 5 July 2009 (UTC)

Tricky oil consumption conversion
While working on Chevrolet Vega yesterday, I stumbled on an interesting and seemingly tricky conversion problem. I had to grapple with engine oil consumption expressed as "a quart every two hundred miles". After poring over the docs for this template, I couldn't figure out how to make it do everything I wanted, which is: That is, I didn't want to wind up with something that looked like 1 quart per 200 miles (0.946 litre per 322 km). I want something like 1 quart per 200 miles (1 litre per 340 km), or 200 miles per quart (340 km per litre).
 * Handle dual-unit input in X-per-Y format (1 quart / 200 mile)
 * Convert dual-unit X-per-Y input to dual-unit N-per-M output
 * Provide output pinned to one litre

Is this sort of conversion just too esoteric and knotted for the template? I can certainly do it out manually, but if the template can handle it, I'd just as soon use it. Thanks! —Scheinwerfermann T&middot;C 13:55, 4 July 2009 (UTC)


 * To handle that particular unit we could create a quarts per 200 miles subtemplate. To handle X-per-Y format would be trickier. J IM ptalk·cont 16:18, 4 July 2009 (UTC)


 * The difficulty is, the 200-mile value was specific to this particular case. The problem is coming up with a way to put in the number of miles per one quart, and have it spit out the number of kilometres per one litre (or input the number of kilometres per one litre, and output the number of miles per one quart). —Scheinwerfermann T&middot;C 16:30, 4 July 2009 (UTC)


 * Then it's a miles per quart subtemplate which we'd need. Normally the template would give "x miles per quart" as opposed to "1 quart per x miles" for such a thing.  Of course the latter would not be impossible but it's the former which is more usual in English anyway so we probably won't need to get into any of those convolutions.  We'll have to specify whether it's imperial or US quarts. J IM ptalk·cont 16:49, 4 July 2009 (UTC)
 * Yes to all: "x miles per quart" would indeed be better, we'd want provisions for input and output in US quarts, imperial quarts, and litres, as well as miles or kilometres. Is this feasible? I'm afraid I know little about template construction. —Scheinwerfermann T&middot;C 17:20, 4 July 2009 (UTC)

It's feasible but fuel consumption conversions are a little more complicated than others. J IM ptalk·cont 19:03, 4 July 2009 (UTC)


 * Okeh…how can I help get the process started? —Scheinwerfermann T&middot;C 19:14, 4 July 2009 (UTC)

If you've got the time, you could check through these.

J IM ptalk·cont 19:49, 4 July 2009 (UTC)


 * This doesn't actually do what's needed. This looks more like a fuel economy conversion. L/100km is not the needed output here, what's needed is n km per (1) litre. The idea is to fix the metric output upon one litre and let the kilometres float according to the miles-per-quart input. —Scheinwerfermann T&middot;C 21:59, 4 July 2009 (UTC)

Yeah, I was wondering about that. How's it look now? J IM ptalk·cont 22:32, 4 July 2009 (UTC)


 * Perfecto — thanks! —Scheinwerfermann T&middot;C 20:36, 5 July 2009 (UTC)

Hundred weight to kilogramme
For Campbeltown and Machrihanish Light Railway: 1 cwt etc. Peter Horn User talk 01:31, 13 July 2009 (UTC)


 * You'll have to specify whether you want a long or short one.
 * → "1 long cwt"
 * → "1 short cwt"
 * J IM ptalk·cont 07:31, 13 July 2009 (UTC)


 * P.S. I took the liberty to redo some of those conversions in the blockquote. J IM ptalk·cont 08:13, 13 July 2009 (UTC)

cwt supported?
We've got a convert/long cwt and convert/short cwt but no convert/cwt, and none of them are documented. Is this supported? Chris Cunningham (not at work) - talk 08:58, 23 June 2009 (UTC)
 * convert/long cwt and convert/short cwt are both documented in the full list of units of mass at Template:Convert/list of units/mass. Qwfp (talk) 09:54, 23 June 2009 (UTC)


 * Ah, thanks. Chris Cunningham (not at work) - talk 10:46, 23 June 2009 (UTC)
 * What about convert cwt/kg ??? Peter Horn User talk 01:06, 14 July 2009 (UTC)

Volume per minute or per second
Example: in Fireboat it talks about the water being spouted at 38,000 US gallons per minute (2 m³/s). How do we know that this conversion is reasonably accurate or correct? Would it be possible to construct 38000 usgalpmin 38000 usgal/min 38000 usgal/min etc etc or would that be altogether too difficult? Peter Horn 18:42, 8 July 2009 (UTC)

Some already exist but need fixing.

Here's the faulty code for

The conversion factor used here is 1 US gal = $1.57725491/25000$ m3/s. The rounding depends on the precision of the input ... but ...

editprotected

The templates are outputting two US/U.S.s.

They have an extra /.

Here's the correct code for

And here's the correct code for

J IM ptalk·cont 22:38, 8 July 2009 (UTC)
 * ✅ —Th e DJ (talk • contribs) 09:01, 9 July 2009 (UTC)

A couple more. J IM ptalk·cont 22:56, 8 July 2009 (UTC)
 * → 32000 impgal/min
 * → 38000 USgal/min
 * Can you explain these a bit better please ? —Th e DJ (talk • contribs) 09:01, 9 July 2009 (UTC)

Sorry, I meant here are a couple more codes to use. They don't need fixing. J IM ptalk·cont 13:10, 9 July 2009 (UTC)
 * What about 15000 USgal/min instead of 15000 USgal/min in Edward M. Cotter (fireboat) ??? Peter Horn User talk 01:19, 14 July 2009 (UTC)

Standard cubic feet
My inclination would be to convert to moles but ... J IM ptalk·cont 02:13, 15 July 2009 (UTC)

PS/kW conversion
Could somebody please check the calculation from PS to kW? It seems there's soemthing wrong. 700 PS are 514.85 kW (rounded to ~515) but I get 510 kW as result from the template. --Denniss (talk) 20:55, 17 July 2009 (UTC)
 * Probably it believes that the "700" has only one or two significant digits, and rounds accordingly. You must specify the precision with the fourth argument: rounds to the nearest 100 (i.e. 1), yielding "700 PS". -- A. di M. – 2009 Great Wikipedia Dramaout 23:30, 17 July 2009 (UTC)
 * BTW, I'd propose to prefix the conversion with "~" if it is padded with non-significant zeroes (corresponding to a negative value of the fourth parameter), i.e. "700 metric horsepower (~510 kW)", to make it less misleading. -- A. di M. – 2009 Great Wikipedia Dramaout 23:35, 17 July 2009 (UTC)

Formatting of ranges
WP:MOSNUM suggests that ranges should be "number [unit] nbsp ndash nbsp number unit". The template doesn't do the spaces (using the hyphen in the template instead of "to"). Would it be easy to change it to conform to MOSNUM? I can't see any real difficulty here, but I know you have to tramp through a lot of templates sometimes to do this. I could see it becoming maybe easier since "to" obviously uses spaces, but don't know exactly where you switch the output of the conjunction ("to" or ndash) in the codes.

One day I will learn to program templates (I am a programmer just not done this before) and either help with you all here, or maybe start a convert2 or something that takes a different approach to avoid this combinatorial explosion problem as more units/conversions get added. That being said, I am busy enough copy editing, and it seems people are forced to choose one or another: edit articles or templates or admin or whatever. A pity, but thanks for all your good works, this is a good template. SimonTrew (talk) 15:48, 19 July 2009 (UTC)

Sorry I should give an example:

gives:
 * 7–8 kg (15–18 lb) (this is hard written in this talk page)
 * 7 - 8 kg (this uses the template and so of course will change if template changes)

Best wishes SimonTrew (talk) 15:58, 19 July 2009 (UTC)


 * Where does WP:MOSNUM suggest that? The last but one bullet point of WP:MOSNUM reads: "Numerical range of values are formatted as lower value-en dash-higher value-non breaking space-unit symbol (e.g., 5.9–6.3 kg, not 5.9 kg – 6.3 kg or 5.9 – 6.3 kg)". --Qwfp (talk) 16:14, 19 July 2009 (UTC)


 * Exactly where you just said. I am sorry, I probably confused it in an attempt to get to the nub of the matter by not quoting the MoS exactly. The point is that it says to separate the dash each side with a non-breaking space; doesn't do that. I was erroneous in suggesting it was acceptable to put the unit after lower-value; it was getting late and I was probably a bit hasty in writing this, I just wanted to note it down before I forgot.


 * So my apologies for being technically wrong and not quoting verbatim; but the point stands, there should be non-breaking spaces around the dash. Best wishes 81.102.134.214 (talk) 07:57, 22 July 2009 (UTC)


 * Oh dear me I am still wrong. Rereading, I see the non-breaking space only comes between the higher-value and the unit. So stet, you are all right and so is the template.


 * That being said, usually with dashes one can space them or not but they have to be balanced (i.e. spaces both sides or neither) which I must admit in normal text I find odd, since I would generally tend not to space after a word but would space after the dash, but have been told this is "wrong". You are quite right in what you say, so either I misread it, or somewhere else is lurking the definition I gave, which I will post here if I ever come across it again.


 * Apologies again, but I am sure you can imagine, I was looking up MOSNUM for guidance and it surprised me too, I would not have posted it if it did not come as a surprise to me. But perhaps it is buried in a talk page or something, or has been superseded. Until I ever find it again (unless it was a figment of my imagination) we might as well stet, but leave this for the archive.


 * Best wishes 81.102.134.214 (talk) 08:02, 22 July 2009 (UTC)

Missing unit: hundredweight/centum weight (cwt)
While editing List of Holden vehicles by series, I needed to convert 10 and 14.5 cwt into both pounds and kilograms. This template does not allow for that, so I have for now left out the conversion. I only require the "cwt" conversion because this is the unit used by the cars' manufacturer Holden up until 1974. If it were not for that, I would just use pounds and convert into kilograms. OSX (talk • contributions) 04:22, 25 July 2009 (UTC)


 * Anyone?. OSX (talk • contributions) 08:30, 27 July 2009 (UTC)


 * There is cwt support but you've got to specify whether you want a long (112 lb) or a short (100 lb) one.


 * → "14.5 long cwt"
 * → "14.5 short cwt"


 * J IM ptalk·cont 09:04, 27 July 2009 (UTC)


 * Thank you very much for that. OSX (talk • contributions) 10:13, 27 July 2009 (UTC)


 * BTW, the cwt should probably be added to Template:Convert/list of units. OSX (talk • contributions) 10:18, 27 July 2009 (UTC) Never mind: Template:Convert/list of units/mass. OSX (talk • contributions) 10:19, 27 July 2009 (UTC)

Accuracy concern
In Harvard Bridge, the following text appears:

Given that Smoot was 5 feet 7 inches (1.7018 m) tall in 1958, the given measurement in smoots of 364.4 yields a "bridge length" of about 620 m. Published sources give the length of the bridge as approximately 660 m. The difference in length between the sidewalk markings and the published figure represents a 40 m discrepancy.

There seems to be a bit of a problem. The first two convert uses are 40m/200ft different, yet the third "convert" of 40m yields 130ft as the result. What's up with this, please? - Denimadept (talk) 20:44, 27 July 2009 (UTC)

See the FAQ at the top of this page and the Template:Convert section. I'd suggest:

Given that Smoot was 5 ft tall in 1958, the given measurement in smoots of 364.4 yields a "bridge length" of about 620 m. Published sources give the length of the bridge as approximately 660 m. The difference in length between the sidewalk markings and the published figure represents a 40 m discrepancy.

--Qwfp (talk) 21:36, 27 July 2009 (UTC)


 * Thank you, I think I'll just copy that right over! :-D - Denimadept (talk) 22:30, 27 July 2009 (UTC)