Template talk:Convert/Archive April 2008

Conversion template needed

Can we have a template to convert from lb/in² to kg/cm² and vice versa. UK steam locomotives have their boiler pressures expressed in lb/in² wheras in Europe they use kg/cm². Mjroots (talk) 11:34, 28 March 2008 (UTC)

{{convert|100|psi|kg/cm2|lk=on}}-->100 pounds per square inch (7.0 kg/cm²)

{{convert|100|psi|kg/cm2|2|abbr=on}}-->100 psi (7.03 kg/cm²)

{{convert|7.0|kg/cm2|psi|lk=on}}-->7.0 kilograms per square centimetre (100 psi)

{{convert|7.0|kg/cm2|psi|2|abbr=on}}-->7.0 kg/cm² (99.56 psi)

Here's a start. It still needs some proof reading (Jimp, if you don't mind) so don't go crazy with it for a couple days. —MJCdetroit ^(yak) 15:00, 28 March 2008 (UTC)

Can we drop the f so that it reads kg/cm²? In fact it might be better if it could be arranged to read x lb/in² (y kg/cm²) Mjroots (talk) 08:31, 29 March 2008 (UTC)

I've made the "f" optional:

• kg/cm2 for "kg/cm²"

• kgf/cm2 for "kgf/cm²"
• kg-f/cm2 for "kg_f/cm²"

Do we need "lb/in²" as an alternative to "psi"? Jɪmp 03:58, 31 March 2008 (UTC)

Also, conversions to and from psi and kg_f/cm² are all well and good but we really should also include the SI unit. I've therefore introduced the following codes.

• kPa kg/cm2 for "kPa" and "kg/cm²"
• kPa kgf/cm2 for "kPa" and "kgf/cm²"
• kPa kg-f/cm2 for "kPa" and "kg_f/cm²"
• kPa psi for "kPa" and "psi"
• MPa kg/cm2 for "MPa" and "kg/cm²"
• MPa kgf/cm2 for "MPa" and "kgf/cm²"
• MPa kg-f/cm2 for "MPa" and "kg_f/cm²"
• MPa psi for "MPa" and "psi"

Jɪmp 06:22, 31 March 2008 (UTC)

Re the lb/in², I'd say we do need it. Is it possible to code it to use lb/in2 to prduce the desired effect and give an alternative to psi? Mjroots (talk) 07:24, 1 April 2008 (UTC)

It is possible. Is it desireable? Is this the forum to discuss whether to permit this alternative on WP. WP:MOSNUM states "squared US-unit abbreviations are rendered with ‘sq’, and cubic with ‘cu’," does that imply that it would be lb/sq in instead (that's pretty hard to read)? Does the policy need a rewrite? Is it not clearer to stick to one abbreviation/symbol across the encyclopædia? I don't mean to be obstructionist (is that a word?). I'd just like to see it discussed on WT:MOSNUM. If consensus there is to allow it, I'll code it. JЇѦρ 07:54, 1 April 2008 (UTC)

I'm happy to discuss it there. Most publications that talk about locomotive boiler pressures do use lb/in² or lb/in. One almost never sees psi although "lb/sq in" is used. I think it would look daft to say x lb/sq in (y kg/cm²), which is why I'm asking for lb/in². Mjroots (talk) 08:04, 1 April 2008 (UTC)

"lb/sq in" is awful (if you ask me) but a strict interpretation of MOSNUM would seem to favour that over the other. Of course, you could argue that "lb/sq in", though it involves a square, is a unit unto itself and not a squared unit ... if you want to get semantic you might say it's an imperial unit whereas the MOS talks of US ones ... but that's getting silly ... or actually it's pointing to a need for policy edit. The real problem is that the unit is not dealt with explicitely and probably should be. See you there. JЇѦρ 08:20, 1 April 2008 (UTC)

The jargon of steam locomotive enthusiasts should not be allowed in Wikipedia. Wikipedia is for everyone to read, and the internationally understood uint of pressure is the pascal. If someone wants to create articles that are only intended for steam locomotive enthusiasts, and not for general readers, let them go create their own wiki. --Gerry Ashton (talk) 16:39, 1 April 2008 (UTC)

This is not about steam locomotive enthusiasts. We are discussing boiler pressures, which means ships powered by steam engine, nuclear power stations, traction engines, steam rollers, steam lorries, fixed steam engines etc. etc. In the UK and USA we use lb/in², in Europe they use kg/cm². What I'm trying to achieve is to enable readers in Europe to be able to directly compare (and understand) different boiler pressures with something that they are familiar with. Similarly, I want to enable UK and US readers to be able to directly compare (and understand) articles about foreign locomotives etc. with our own, which they are familiar with. Mjroots (talk)

The above unsigned comment says "in Europe they use kg/cm²." Prove it. The correct unit is the pascal. It is the unit that the general reader can use to compare all uses of pressure in Wikipedia. --Gerry Ashton (talk) 18:20, 1 April 2008 (UTC)

Sorry, I forgot to sign that comment. Ok, proof:- see here, and here and here. Mjroots (talk) 19:07, 1 April 2008 (UTC)

Evaluation of Mjroots' proof.

• The first is an article from 1943, which hardly addresses which units modern Europeans use to express pressure.
• The second is about the law in the Philipines, and the date is not given.
• The third is from a magazine for locomotive enthusiasts.

I see nothing to convince me that modern Europeans generally express pressure in kilograms per square centimeter. --Gerry Ashton (talk) 19:35, 1 April 2008 (UTC)

(outdent) I never claimed that the unit was in modern usage, although #2 does seem to be a current document relating to the law in the Phillipines. As I said earlier, primarily we are talking about steam locomotives, but it would also cover ships, road vehicles, power stations etc. I fully agree that modern useage is the Pascal or Hectopascal, that is not the issue. Mjroots (talk) 20:06, 1 April 2008 (UTC)

Conversion to SI should be included. That's why the dual output templates were created. E.g. {{convert|12|psi|kPa kgf/cm2}} gives "12 pounds per square inch (83 kPa; 0.84 kgf/cm²)". JЇѦρ 20:44, 1 April 2008 (UTC)

In the past, pressure is a quantitity that has suffered from a vast array of different units, one or more for each field. To enable modern general readers to compare pressures from different fields, all pressures should be converted to pascals. I don't care about making it easy for people who are already familiar with old European steam equipment to compare it to old American or UK steam equipment, I care about the general reader. --Gerry Ashton (talk) 20:52, 1 April 2008 (UTC)

Gerry, I've no objection to a conversion showing X lb/in² (Y kg.cm², Z HPa) if that is what is needed to enable the general reader to understand pascals and the UK/US and European readers understand the value in "their language" as it were. Mjroots (talk) 21:00, 1 April 2008 (UTC)

Feature request: option for 'trillion', 'billion', 'million' etc

Can we have an option to provide 'trillion', 'billion', 'million' etc? Lightmouse (talk) 16:57, 28 March 2008 (UTC)

Second that. Look at what {{convert}} does to oil field units (see eg Ghawar):

"170 billion barrels" rendered using {{convert|170000000000|USoilbbl|m3}} becomes the horrible linefull "170,000,000,000 USoilbbl"

What we're looking for would be something like "170 billion barrels (27,000 GL)", or maybe "170 Gbbl (27 TL)". Prefer the first form.

We don't need "US barrel" or "US oil barrel", nor even "US bbl" - it's an oil field! --Gergyl (talk) 03:24, 29 March 2008 (UTC)

Further information: I have done a limited search of Wikipedia and it seems that the word barrel (when preceded by a number) is mostly used for oil. There are a few occasions when it is used for beer. I would welcome the input of anyone else that does a more detailed search. Lightmouse (talk) 09:28, 29 March 2008 (UTC)

Gigalitres and teralitres are both functional. JЇѦρ 06:16, 1 April 2008 (UTC)

My impression is that huge quantities of oil and gas are either in tonnes and or in cubic metres rather than litres. I have not done a google search though. You do see litres used for relatively small quantities (e.g. 50,000 L) of refined products. Lightmouse (talk) 09:04, 1 April 2008 (UTC)

Tonnes, no (though that does get used for fuel oil). Crude is nearly always bbl. Gas mostly cuft (as Bcf and Tcf), occasionally cum; or else it's measured by energy content as MBtu or (more often now) TJ/PJ. An odd hotchpotch. If the reason for converting is to give the SI, then litre is the correct base unit for fluid volume. For oil, it at least gives the non-specialist some scale (1 L light crude refines to abt 1 L of the gasoline they buy). For gas, litre sits kinda oddly beside cuft. Better cum there, but that leaves the "million" problem. Strictly, SI rules say Mm³ means 10¹⁸ m³, though usage would be almost exclusively as 10⁶ m³. Some try to get around that by writing M m³ or M.m³ (more rarely M(m³)).--Gergyl (talk) 11:51, 1 April 2008 (UTC)

Bring on the megastère. JЇѦρ 12:48, 1 April 2008 (UTC)

My previous comment was confined to metric values. I agree that non-metric values for crude oil are usually in barrels. I was just going on the many media reports quoting tonnes of oil in huge oil tankers. I know litres are are also in use. Metric values for oil products (domestic and vehicle fuel) are usually in litres when transported by road. Piped fuels such as domestic gas fuel and piped water bills are often in cubic metres. It is a shame that non-metric volume units (barrels) are sometimes paired with weight units (tonnes). The same problem exists in cooking recipes, non-metric volume units (cups, pints) in the North America are sometimes paired with weight units (grams) in metric countries. I do not know the proportion of each of the three metric units (tonnes, litres, cubic metres). A web search may be our friend.

As far as the SI is concerned, volume cannot have a base unit. There is a base unit of length (metre) and an SI unit of volume that is derived from it (cubic metre). See the official SI website. The litre is not an SI unit, nor is the tonne. Lightmouse (talk) 12:37, 3 April 2008 (UTC)

Capacities of oil pipelines are given in barrels/tonnes per day or per annum, and ususally not in cubic meters. Same applies to oil refineries, oil terminals etc. It is different with gas pipelines, which capacities are given in cubic meters/cubic feet per day or per annum (and not, for example, in cubic kilometers). The exception is LNG, which is measured also in tonnes. Also, the diameter of pipelines as a standard in inches or in millimeters, not in meters. After all these massive changes of units in pipeline articles, they are strange to read. Maybe it is possible to create suitable conversions for hydrocarbons industry before changing relevant articles.Beagel (talk) 10:36, 5 April 2008 (UTC)

The template conversions barrels->m³ can easily be edited to show barrels->t. We do not currently have a template for tonnes per day but a request for one can be made. Lightmouse (talk) 13:47, 5 April 2008 (UTC)

It could be tonne per day, but I think that more useful would be barrel per day converted to tonne per annum.Beagel (talk) 16:28, 5 April 2008 (UTC)

I absolutely agree, that metric values should be preferred, if possible. In case of water, it is logical convert barrels into cubic meters. In case of oil, the common unit is barrel, and oil is also measured in tonnes. Measuring oil in cubic meters may be correct from the point of view of the SI system, but has no sense in oil industry or in oil economics. It is not used in professional literature. Can you find any country, company etc measuring their oil (not gas) reserves or production in cubic meters? I think we should use common sense and avoid creation of absolutely correct and at the same time absolutely useless data.Beagel (talk) 16:24, 5 April 2008 (UTC)

Try {{bbl to t}} (it can't convert days to years though as yet, now it can). If cubic metres is useless for oil, why are barrels (another volume unit) not? JЇѦρ 16:39, 5 April 2008 (UTC)

Because all industries reports their data in barrels (and in some extend in tonnes, mainly in Europe), petrogeologists evalute reserves in barrels, and news agencies and newspapers write their oil stories using barrels or tonnes. Using cubic meters for oil may be correct for theoretical oint of view, but in pratice it makes relevant articles more confusing and less readable. Does Britannica really use cubic meters writing about oil reserves and production?Beagel (talk) 17:00, 5 April 2008 (UTC)

If you write {{convert|500|Moilbbl|t}}, you get: 500 million barrels () Lightmouse (talk) 19:14, 5 April 2008 (UTC)

You have something wrong. 500 million oil barrels is not 79,000 tonnes. According to the calculator at the EIA homepage it is a 68.185 million metric tonnes. Beagel (talk) 20:48, 5 April 2008 (UTC)

Jimp, can you work out what is happening here? Lightmouse (talk) 08:30, 6 April 2008 (UTC)

However, we're not writing for petrogeologists but for a general audience. Newspaper may not have room for conversions to SI, we do. Conversions to cubic metres may make articles a little more confusing and less readable for those who think in barrels but it seems to me that they make them significantly more comprehensible for those who, like me, don't.

If you try to convert volume to mass, the template will give you nonsense ... unless your density happens to be 1 kg/m³ ... oil is somewhat more dense. This is an issue that Gene has brought up. If you try to convert between different dimensions, the template will give you an answer. The answer will generally be nonsense (fuel consumption is an exception being expressible in volume per distance or distance per volume). I guess there are two possible solutions either put a note on the doc page or build dimensional analysis into the template. I sort of get the feeling that a note would suffice.

JЇѦρ 15:34, 6 April 2008 (UTC)

I really don't understand, what you mean by "the template will give you nonsense ... unless your density happens to be 1 kg/m³". Why the density should to be 1 kg/m³? You just need to put the right density into the conversion formula, notwithstanding what the density is. Of cause, densities of different crude oils vary little bit, but the average density will work fine.

Concerning writing for petrogeologists or a general audience, I think that we should write in the way that it is understandable for a general audience and at the same time makes a sense for professionals.Beagel (talk) 16:03, 6 April 2008 (UTC)

The template is not geared to convert between dimensions. Each input value is first converted to SI base units (or combinations thereof) and then from those to the output units. So when you attempt to convert from barrels to tonnes, first you convert to cubic metres, you send your cubic-metre number to the tonne subtemplate but that number is misinterpreted as being a kilogram number. Thus you get nonsense unless it so happens that your kilogram number and your cubic-metre number are the same, in which case the density is 1 kg/m³. Yes, it could be fixed simply by putting the right density into the formula ... what is the right density. It varies, right, so we'd be looking at adding another parameter but it won't stop there, next we'll be wanting to convert gallons of petrol to megajoules. It'll get messy. There is a different solution, though, use {{bbl to t}} which is geared to doing this. Of course, it could use another up-grade ... actually it's getting one. It now converts from bbl/d to t/a using the new parameter t_per.

{{bbl to t|100|per=d|t_per=a}} gives "100 barrels per day (~5,000 t/a)"

If the professionals don't understand cubic metres, they should take some evening classes. JЇѦρ 17:44, 6 April 2008 (UTC)

1 oil barrel equal to 0.136363 metric tonnes or 1 metric tonne of oil equal to 7.333333 barrels, as average, works fine. And yes, there is no problem to convert gallons into megajoules or toe etc. All these conversion tables available at the EIA, IEA, Rigzone etc websites. And I don't think there is problem with understanding cubic meters, it is just the issue of common use of units.

The IEA's Energy Statistics Manual says:

Beagel (talk) 18:39, 6 April 2008 (UTC)

There are common units within given fields and there are units common world-wide. Why not give both? It looks like the IEA at least recognises the cubic metre. Of course, gallon-to-megajoule conversions can be done but my feeling is that this type of thing belongs on a seperate template: the use of this one is complex enough as it is. JЇѦρ 18:53, 6 April 2008 (UTC)

Thank you for your clarification of how the template worked. I now understand how it got the numerical values. Lightmouse (talk) 21:48, 6 April 2008 (UTC)

oil barrels

Can we please have the following new units:

Million (oil) barrels: long unit "million barrels", abbrev "Mbbl" (preferred) [1] or "MMbbl" [2] (yes, confusing, but that's how it is.)

Billion (oil) barrels: long unit "billion barrels", abbrev "Gbbl" (preferred) or Bbbl [3]

Million (oil) barrels per day: long unit "million barrels per day", abbrev "Mbbl/d" (preferred) [4] or "MMbbl/d" [5]

The long unit for "oil barrel" does not need to specify either "oil" or "US". For oil, both are always implied by the context.--Gergyl (talk) 10:17, 29 March 2008 (UTC)

Just give up on the Fred Flintstone units and join the modern world, and you won't have any problems at all. Especially those weird Roman numeral prefixes--if there is one thing we damn sure can get along without, and which we need to clearly ban from Wikipedia, it is harder to think of any clearer example. Gene Nygaard (talk) 02:10, 31 March 2008 (UTC)

The really weird thing is that nobody has ever used a physical barrel holding 1⅓ Queen Anne's wine barrels, or one tierce (i.e., ⅓ of a butt rather than the ¼ of a butt for a wine barrel), to hold petroleum, at least not in the past century and a half or so. Maybe for a decade or two after the very first oil wells, but I have my doubts that they were used even then. Gene Nygaard (talk) 02:20, 31 March 2008 (UTC)

I had been working on adding million, billion, etc., got distracted, will pick it up from where I'd left off. Drop the US & you'll drop the "US".

{{convert|123|oilbbl|m3}} gives "123 barrels (19.6 m³)".

'Twould be nice if we could just drop the ancient units but if your source is quoting in barrels, what do you do? Jɪmp 04:08, 31 March 2008 (UTC)

Thanks, much appreciated. Realistically, for crude oil, barrel is the only unit in common use. So it's not at all "ancient", except etymologically. One could say that of metre. Actually that one is rather more ancient! --Gergyl (talk) 07:48, 31 March 2008 (UTC)

Interesting discussion. I had been adding 'USoilbbl' because the option made me think it is an American unit. From the conversation above, it seems that it is indeed an American unit but used throughout the world for oil. I have now tracked down a few of these and updated 'USoilbbl' to 'oilbbl' based on a google search. There might be some left. If there is only one oilbbl, can we delete variations of it to avoid confusing people like me? Lightmouse (talk) 08:49, 31 March 2008 (UTC)

Being defined as 42 US gal, it'd have to be an American unit but, I s'pose, the "US" is superfluous since there is no other oil barrell in use. There might be some left, yeah, about 140 of 'em. Of course, the subtemplate could be redirected but it would be better to move the transclusions to plain oilbbl and delete it. Jɪmp 09:04, 31 March 2008 (UTC)

Aha, 'What links here' is much better than a google search. I have gone through the article space in that list. Lightmouse (talk) 10:15, 31 March 2008 (UTC)

That was quick. How about unleasing your robot on km:h and mi:h? Jɪmp 11:44, 31 March 2008 (UTC)

You must have been reading my mind. I will do it. I looked for those but could not find them because the templates are not in alphabetical order. Lightmouse (talk) 12:26, 31 March 2008 (UTC)

←outdent←
The "US"/"U.S." are up for deletion. Jɪmp 16:33, 31 March 2008 (UTC)

I have eliminated all article space pages for mi:h. Lightmouse (talk) 16:38, 31 March 2008 (UTC)

Let's delete them. JЇѦρ 06:35, 1 April 2008 (UTC)

back on topic

I've introduced

• koilbbl for a thousand barrels abbreviated as "kbbl"
• Moilbbl for a million barrels abbreviated as "Mbbl"
• Goilbbl for a billion barrels abbreviated as "Gbbl"
• Toilbbl for a trillion barrels abbreviated as "Tbbl"

Note that I've gone with the "prefered" SI-based style rather than the Roman numeral-based. Note also that these use the short scale billion & trillion. JЇѦρ 20:38, 1 April 2008 (UTC)

Examples

{{convert|170|Goilbbl|GL}} gives "170 billion barrels (27,000 GL)"

{{convert|170|Goilbbl|TL|abbr=on}} gives "170 Gbbl (27 TL)"

JЇѦρ 06:47, 2 April 2008 (UTC)

Also kcuft to Tcuft are available. All of these default to converting tc cubic metres with display in scientific notation. JЇѦρ 09:23, 3 April 2008 (UTC)

Excellent. You are a star. Lightmouse (talk) 11:20, 3 April 2008 (UTC)

Exponent

This template should include proper HTML formatting for the exponent, not the Unicode precomposed superscripts (¹²³...). For example, km<sup>2</sup> (km²) instead of km² (km²). There are two reasons for this: use of precomposed characters is deprecated by the Unicode standard; and the precomposed characters do not match up with proper superscripts (as seen above). This can be distracting, as articles using measurements and units are somewhat likely to include math as well. —Werson (talk) 01:31, 29 March 2008 (UTC)

This is an issue to be taken up at WT:MOSNUM and WT:MOS. WP:MOSNUM does not proscribe precomposed superscripts. Whether or not "articles using measurements and units are somewhat likely to include math as well" is something we can't know a priori but in my experience, it doesn't seem to be the case. What, arguably, may be more distracting is the way that that rather large "proper" superscript pushes the line of text down (as seen above). Jɪmp 06:36, 31 March 2008 (UTC)

It's proscribed at WP:MSM. The superscript doesn't push down any lines on my browser; if it does on yours, you can fix that with CSS. On the other hand, having mixed formats in the same article is going to look terrible no matter what your settings are. Can you imagine something like 1 × 10⁹ m² happening? —Werson (talk) 07:17, 31 March 2008 (UTC)

Not "uncontroversial" it seems... Why then are ¹²³ right there in the character menu on the std edit screen? --Gergyl (talk) 07:55, 31 March 2008 (UTC)

The same reason ‘“’” are there, even though those marks are not supposed to be used: There is no reason, the characters were chosen rather arbitrarily. —Werson (talk) 18:02, 31 March 2008 (UTC)

WP:MSM pertains to mathematical formulae where the rule makes perfect sense. As for fixing it with CSS, I'd rather see what is seen by the average reader, the bulk of whom wouldn't be bothered fixing their CSS if they even know what it is. Jɪmp 08:11, 31 March 2008 (UTC)

The "average reader" sees what I see; I'm not using any special settings, and no lines are getting pushed down. km² is mathematical. If you square something, that's math. The fact that it's a unit doesn't create unique typographical rules for it; no published document makes a distinction. Using ² goes against Wikipedia policy, the Unicode standard (and by proxy, the HTML standard), hundreds of years of typographical tradition, and common sense, and looks terrible (IMHO); I don't see why it wouldn't be changed, it's a very quick fix. —Werson (talk) 18:02, 31 March 2008 (UTC)

I thought I was pretty average ... I'm using Internet Explorer ... that's pretty averge. If we want to get semantic I might stress the fact that the rule is under the heading Typesetting of mathematical formulas. Squaring might be maths but this template is not for use in formulae. But let's not get carried away. The policy which governs units is to be found at WP:UNITS. If they didn't have edit boxes with prefabricated exponents a hundred years ago, lucky us. Beauty is in the eye of the beholder. I'll grant you that the prefabs look terrible next to <sup>s but generally that's not where you find them. It's the <sup>s which look terrible to me in amongst text, which is where you mostly find this template. One byte verses eight is common sense enough for me. If MOSNUM policy changes, though, the template will change with it. But it's not all that quick a fix. JЇѦρ 18:59, 31 March 2008 (UTC)

…and even more correct would be to use the <math> formating for his $1\times 10^{9}$, but again lets not get carried away. Until ² is deprecated by wiki-policy, it is a legitimate character to use. Personally I hate the html formatting codes, which were a clear hack -- KelleyCook (talk) 15:50, 2 April 2008 (UTC)

That's exactly backwards. ² and ³ were a hack, put into ISO 8859-1 because there was no reliable, versatile way to display superscripts onscreen in 1985. There is now: HTML (and MathML, etc.). Unicode specifically says they shouldn't be used and were only included to process legacy documents. Using a character set flaw to cheat crappy browsers into displaying line-heights correctly is definitely a hack. —Werson (talk) 01:40, 3 April 2008 (UTC)

Computers are a hack. Not the MOS, not logic nor æsthetics give us cause to favour one over the other. Indeed which is best may depend on context. The best solution I can think of would be to make it optional whether to have one or the other. We've currently got two ways of specifying cubes and squares: either with "cu" and "sq" or with "3" and "2". How about this? Let cum, sqkm, etc. give "m³", "km²", etc. and let m3, km2, etc. give "m³", "km²", etc. JЇѦρ 04:46, 4 April 2008 (UTC)

That's even worse; it's inconsistent, which is the same reason I'm against ² and ³. Logic and aesthetics certainly favor consistency on this side of the pond. The actual best solution is to fix Wikipedia's stylesheet so superscripts don't screw things up in IE. I'm working on that. —Werson (talk) 05:01, 4 April 2008 (UTC)

That I can't do. Logic and æsthetics certainly favour consistency on the other side of the pond too I'm sure ... just the same as on this side of the other pond. However, consistency within an article comes before consistency across the project. If ²s and ³s are already there, we're best fitting in. If you want to get rid of all ²s and ³s, then this is not the place to discuss it. JЇѦρ 05:48, 4 April 2008 (UTC)

Foot (unit of length)

Next time someone makes an edit to the template it might be an idea to get rid of any redirects such as Foot (unit of length)) -> Foot (length). CambridgeBayWeather Have a gorilla 16:00, 29 March 2008 (UTC)

When this template was created, Foot (unit of length) was not a redirect— it was the article. It was moved in this edit [6]. Switching that around shouldn't be a problem. —MJCdetroit ^(yak) 21:34, 29 March 2008 (UTC)

Thanks. And it only took me 5 months to notice the article had been moved. CambridgeBayWeather Have a gorilla 00:36, 30 March 2008 (UTC)

The relevant discussion is at:

Article titles for units

Lightmouse (talk) 09:10, 30 March 2008 (UTC)

Round the original value

Is there a way to round the original value using this template?

Say for example that I have a source that specify the length of something to be 32,703 kilometers. I would rather present the length in whole units (more appropriate in the context), which would be 33 kilometers in this case. Using this template to add conversion to miles, I will have the following result: 33 kilometres (21 mi). But if I use the more precise value, the result is 32.703 kilometres (20.321 mi). Stating the "thing" is 21 miles does not seem to be correct, since 20.321 rounds to 20 miles. By rounding the original value, I loose necessary precision in order to perform an accurate rounding of the converted value. Instead of 33 kilometres (21 mi), I believe it would be more correct to write 33 kilometers (20 miles). Is it possible to achieve this result using this template? In other words, I would like to provide an input value with higher precison and have both the original and converted values rounded in the output. --Kildor (talk) 11:04, 1 April 2008 (UTC)

It's not currently possible with this template. JЇѦρ 06:40, 2 April 2008 (UTC)

But I think it would be an useful feature. Something like {{convert|32.703|km|mi|0|0}} -> 33 kilometers (20 mi) --Kildor (talk) 08:30, 2 April 2008 (UTC)

What's wrong with 32.7 kilometres (20.3 mi) ? --Random832 (contribs) 16:45, 2 April 2008 (UTC)

Nothing - it is just that I would like to show the length in whole numbers. More specifically: in the List of rapid transit systems, some systems have length specified with kilometer precision, others have it with more precision. For aestatical reasons, I would like to show the length for all systems with the same precision. But if I round the length to whole kilometers before converting to miles, I might get an incorrect value, as explained in the example above. --Kildor (talk) 23:07, 2 April 2008 (UTC)

moved from #In to Cm decimal problem

at the moment it is impossible to convert 612.2m to 2009ft, showing rounded 612m. the script needs to be updated to allow to show predefined figure for screen, but different for conversion. Elk Salmon (talk) 23:18, 17 April 2008 (UTC)

I have a similar problem that could be solved this way if the functionality existed. But for me it would be even handier to Preserve the original value. I have a list with meters values followed by feet values. But the sources that specify these figures sometimes use meters and sometimes feet. I my table I want to convert either m->ft or ft->m but the display should always be m(ft). (So the original value in the template should be specifyed with unit (e.g. "2009 ft").) This is because I do not want to destroy the original value, which could happen if the source uses feet.

Currently the precision is specified with numbers 1, 0, -1, -2 meaning 0.1, 1, 10, 100 etc. It is clear what unit it applies to, but if bothway conversion was allowed the precision probably have to be specified with unit (e.g. "0.1 ft" or "0.1 m"). If the precision is set to "0.1 m" it means the feet precision is about "0.33 ft", one third of a foot. But since 1/3 cannot be represented in decimal notation the template script have to select the somewhat better precision of "0.25 ft". Now: the meter figures all end with any of .0, .1, .2, ... .9 and the feet figures end with any of .0, .25, .5, .75.

Currently the precision granularity is maybe too rough, e.g. one can only select amongst 1, 10, 100 (meter) etc. Someone perhaps want the precision 5 m, so all numbers should be rounded so the last digit is either 0 or 5. Example 7, 9, 14, 17 are rounded to 5, 10, 15, 15. Or someone may want the precision 25. Examples: 17, 35, 60, 89 are rounded to 25, 50, 50, 100.

It has to be selectable if the original value should be preserved or rounded with the same precision as the converted value. Najro (talk) 16:37, 26 April 2008 (UTC)

A better solution to the table problem would be to swap the input and output units (so that the former comes second). A request for this has been made. No, it has not yet been implimented but it's not been forgotten either. JIMp _talk·cont 07:19, 30 April 2008 (UTC)

cubic miles

Well it turns out that the volume of a mountain formed by a volcano and the volume of lava produced is talked about in terms of cubic miles and cubic kilometres. Is this supported? --DRoll (talk) 07:10, 2 April 2008 (UTC)

Yeah. JЇѦρ 08:18, 2 April 2008 (UTC)

Works great. Thanks --DRoll (talk) 00:29, 3 April 2008 (UTC)

No worries, mate. JЇѦρ 00:34, 3 April 2008 (UTC)

volume/time

Can we have conversions for volume per unit time. For example barrels per day (bbl/d) into m³/d and m³/s? Lightmouse (talk) 15:46, 3 April 2008 (UTC)

Now you're reading my mind. JЇѦρ 22:26, 3 April 2008 (UTC)

Here are the numbers. Please check my maths.

1 in = 0.0254 m = 127⁄5000 m

1 cu in = 0.0254³ m³ = 127³×5⁻³×10⁻⁹ m³ = 2³×127³×10⁻¹² m³

1 US gal = 231 cu in = 2³×3×7×11×127³×10⁻¹² m³

1 bbl = 42 US gal = 2⁴×3²×7²×11×127³×10⁻¹² m³

1 bbl/h = 1⁄60×60 bbl/s = 2²×7²×11×127³×10⁻¹⁴ m³/s = 0.00004416313748 m³/s

1 bbl/d = 1⁄24 bbl/h = 3⁻¹×5×7²×11×127³×10⁻¹⁵ m³/s = 5.520392185⁄3000000 m³/s ≈ 1.840130728×10⁻⁸ m³/s

1 m³/h = 1⁄3600 m³/s

1 m³/h = 1⁄86400 m³/s

1 cu ft/s = 12×12×12 cu in/s = 2⁹×3³×127³×10⁻¹² m³ = 0.028316846592 m³/s

1 cu ft/h = 1⁄60×60 cu ft/s = 2⁷×3×127³×10⁻¹⁴ m³ = 0.00000786579072 m³/s

1 cu ft/d = 1⁄24 cu ft/h = 2⁴×127³×10⁻¹⁴ m³ = 0.00000032774128 m³/s

Cheers. JЇѦρ 00:18, 4 April 2008 (UTC)

If we make a practice of providing conversions for products and quotients of more basic units, the number of conversions could be enormous. I suggest that except for the very common quantity, speed, we don't provide conversions unless there are some single word units for the quantity. --Gerry Ashton (talk) 02:50, 4 April 2008 (UTC)

Whilst this is true, volume per unit time is a very useful quantity when you're dealing with river flow and natural gas and crude oil production and consumption. JЇѦρ 02:58, 4 April 2008 (UTC)

I've introduced a few new conversions.

Examples

{{convert|1000|m3/s}} gives "1,000 cubic metres per second (35,000 cu ft/s)"

{{convert|1000|ft3/s}} gives "1,000 cubic feet per second (28 m³/s)"

{{convert|1000|cuft/s}} gives "1,000 cubic feet per second (28 m³/s)"

{{convert|1000|kcuft/s}} gives "1,000 thousand cubic feet per second (28×10^³ m³/s)"

{{convert|1000|m3/h}} gives "1,000 cubic metres per hour (35,000 cu ft/h)"

{{convert|1000|ft3/h}} gives "1,000 cubic feet per hour (28 m³/h)"

{{convert|1000|cuft/h}} gives "1,000 cubic feet per hour (28 m³/h)"

{{convert|1000|m3/d}} gives "1,000 cubic metres per day (35,000 cu ft/d)"

{{convert|1000|ft3/d}} gives "1,000 cubic feet per day (28 m³/d)"

{{convert|1000|cuft/d}} gives "1,000 cubic feet per day (28 m³/d)"

{{convert|1000|kcuft/d}} gives "1,000 thousand cubic feet per day (28×10^³ m³/d)"

{{convert|1000|Mcuft/d}} gives "1,000 million cubic feet per day (28×10^⁶ m³/d)"

{{convert|1000|Gcuft/d}} gives "1,000 billion cubic feet per day (28×10^⁹ m³/d)"

{{convert|1000|oilbbl/d}} gives "1,000 barrels per day (160 m³/d)"

{{convert|1000|koilbbl/d}} gives "1,000 thousand barrels per day (160×10^³ m³/d)"

{{convert|1000|Moilbbl/d}} gives "1,000 million barrels per day (160×10^⁶ m³/d)"

JЇѦρ 04:33, 4 April 2008 (UTC)

The conversion from bbl/d to m3/d is out by two orders of magnitude. You should divide by approximately 6.29 to convert from bbl to m3. Thus, 1000.1 bbl/d should convert to 159 m3/d. However, the conversion results in a value 1/100 of that: 1,000.1 barrels per day (159.00 m³/d)}. RockyMtnGuy (talk) 18:40, 8 April 2008 (UTC)

Thanks. JЇѦρ 19:02, 8 April 2008 (UTC)

The template still seems to be wrong - I don't know how these templates are organised, and maybe it is working up someones list, but it seems pretty serious for dozens of oil related articles to be carrying the wrong information. We will be seeing it repeated in the media soon! Let me know if this is in hand please, so I can forget about it. Stainless316 (talk) 10:44, 18 April 2008 (UTC)

If you be more specific, the problem can be fixed. JЇѦρ 21:01, 18 April 2008 (UTC)

Thanks - here is a section copied from Peak oil: "Demand will hit 118 million barrels per day (18,800,000 m³/d) from 2006's 86 million barrels (13,700,000 m³)" The Moilbbl/d to m3/d converts differently from Moilbbl to m3. Another example with the same number Volume/time:100 million barrels per day (16,000,000 m³/d) Volume:100 million barrels (16,000,000 m³). Is this to do with the use of M to mean thousand in oil terminology? RockyMtnGuy had it right above, the m3/d is out by 2 orders of magnitude, I think. I made a few comments at Peak oil. Stainless316 (talk) 09:49, 21 April 2008 (UTC)

There is a two-order-of-magnitude error in all these bbl/d to m3/d conversions. The correct conversions (using engineering notation for SI units) should be:

• 1000 barrels per day = 160 m³/d
• 1000 thousand barrels per day = 160x10³ m³/d
• 1000 million barrels per day = 160x10⁶ m³/d
• 1000 billion barrels per day = 160x10⁹ m³/d

This is in some ways reminiscent of the saga of the Gimli Glider, an Air Canada Boeing 767 which made deadstick landing on a dragstrip at Gimli, Manitoba while a drag race was in progress due to a metric conversion error in calculating fuel volumes.RockyMtnGuy (talk) 00:15, 22 April 2008 (UTC)

Great! Thanks for sorting it. Stainless316 (talk) 17:39, 23 April 2008 (UTC)

If there's anything else odd going on, don't hesitate to make a note. JЇѦρ 18:26, 23 April 2008 (UTC)

Trillions of Cubic Feet

Can this template convert Trillions of Cubic Feet of Natural Gas into square metres? --Kevlar (talk • contribs) 16:50, 3 April 2008 (UTC)

I sure hope not, since cubic feet measure volume, and square metres measure area. --Gerry Ashton (talk) 17:25, 3 April 2008 (UTC)

This relates to Gene's dimentional-analysis point. JЇѦρ 22:30, 3 April 2008 (UTC)

For natural gas related articles (gas fields; pipelines), it should be necessary to have possibility convert trillion cubic feets into billion cubic meters. It is impossible to count all these digits if you convert this just into cubic meters, and right now all this articles a quite messy with lot of zeros. Also, all hydrocarbon's literature uses for billion cubic meter abbreviation bcm, I think it would be necessary to have a opportumity to have this abbreviation in this template. There is also need for convertion of cubic feet/cubic meter per day to cubic meter per annum.Beagel (talk) 10:22, 5 April 2008 (UTC)

It is possible: the code Tcuft gives you trillions (i.e. billions in real money) of cubic feet and for billions (i.e. thouands of millions) of cubic metres use km3. Yes, that's a cubic kilometre with the symbol "km³". If an industry wants to use some strange obscure abbreviation, should we follow suit? "km³" is the standard SI symbol, why not use it? We're writing for a general audience. Anyhow this is not the place to discuss whether to allow such things, go here for that. Alternatively you can convert to cubic metres with scientific notation by leaving the convert-to unit unspecified, e.g. {{convert|100|Tcuft}} gives "100 trillion cubic feet (2.8×10^¹² m³)". JЇѦρ 15:53, 6 April 2008 (UTC)

Cubic metres/feet per annum are up and running like the per day/hour ones. JЇѦρ 16:59, 7 April 2008 (UTC)

cubic kilometres (km3) are normally only used in geological terms (e.g. there are 100 cubic kilometres of rock in this mountain range). The normal production term would be billions of cubic metres (10^9 m3). In the real world, it would probably be billions of gigajoules (exajoules) since natural gas is usually sold by energy content. a trillion cubic feet (tcf) would be very close to a billion gigajoules (10^9 GJ) RockyMtnGuy (talk) 18:31, 7 April 2008 (UTC)

Good point. It does make more sense to convert cubic feet to cubic metres, though there be zillions of them. That's why the default conversion for trillions (i.e. billions) of cubic feet is cubic metres with scientific notation. All I'm saying is that standard SI symbols should be favoured over obsure non-standard abbreviations used is this or that industry. Thus "km³" is better than "bcm", of course, "10⁹ m³" is the best. JЇѦρ 23:41, 7 April 2008 (UTC)

In my experience, the standard abbreviations in the Imperial system for natural gas volumes are:

• scf - standard cubic feet
• Mcf - thousand cubic feet
• MMcf - million cubic feet
• Bcf - billion cubic feet
• Tcf - trillion cubic feet

The abbreviations of "M" for thousand" and "MM" for million are really Roman numerals. Things you may see in the popular press like "M" for "mega" and "G" for giga are just an attempt to bastardize an obsolete system to fit it into the 21st century. In the SI system you could use:

• dam³ - cubic decametres (1000 m³)
• hm³ - cubic hectometres (1,000,000 m³)
• km³ - cubic kilometres (1,000,000,000 m³)

... but in my experience these are never used. In the Canadian oil and gas industry, field operators often say "cubes" for cubic metres and "decks" for cubic decametres, but these are rather localized terms. In the global perspective, the best solution is to use exponential notation:

• 10³ m³ = 1000 m³
• 10⁶ m³ = 1,000,000 m³
• 10⁹ m³ = 1,000,000,000 m³

These are not really ideal, but in the absence in the SI system of secondary volume units like "litres" (cubic decimetres) for cubic decametres, cubic hectometres and cubic kilometres, this is the best you can do. (And of course I used Commonwealth spelling rather than American spelling because I felt like it.) RockyMtnGuy (talk) 17:05, 8 April 2008 (UTC)

You should feel like it if you're Canadian. I do think that exponential notation is our best bet when it comes to cubic metres (I feel like it too) but I don't know what to make of those Imperial/US unit abbreviations. They may be common in the industry but will the general public recognise them? "M" for thousand could easily be mistaken for "M" for mega-. "T" for trillion could easily be mistaken for tera-, it just so happens, though, that it's the same number but this is a double-edged sword for it might reinforce the aformentioned thousand-mega- confusion. of course, these trillions and billions are "short scale" ones which would indicate that they are probably of American origin and thus might never have been used much outside of North America. The pedant in me also just has to point out that "MM" is two thousand not one million so they are not really really Roman numerals. JЇѦρ 18:13, 8 April 2008 (UTC)

The American oil and gas industry uses units that nobody else in the world uses so naturally people outside the industry are unfamiliar with them. They express oil volumes in their own unique oil barrels (abbreviated bbl), densities in degrees of American Petroleum Industry gravity (abbreviated °API), gas volumes in thousands of standard cubic feet (abbreviated Mcf), and energy in several different versions of the British Thermal Unit (BTU). It would be a lot simpler if they expressed oil and gas volumes in cubic metres, densities in tonnes per cubic metre, and energy in gigajoules (GJ). If they did that you could easily compare their data to other industries and other countries, but it is a very staid industry with tremendous resistance to change.RockyMtnGuy (talk) 05:17, 11 April 2008 (UTC)

Fractional values like 1⅛ Inches

It seems like there's probably a clever way to handle situations like {{convert|11|ft|1⅛|in|m}}. Has anyone dealt with this yet? It comes up again and again in ship metrics. Cheers. Haus^Talk 12:49, 4 April 2008 (UTC)

There probably is a clever way of doing it. I've added the feature. Whether it's clever or not is another question. You have to enter the inches in the form x+y/z. For example:

{{convert|6|ft|5+1/2|in}} gives "6 feet 5+1⁄2 inches (1.969 m)"

{{convert|7|ft|5+1/3|in}} gives "7 feet 5+1⁄3 inches (2.269 m)"

{{convert|8|ft|5+5/8|in}} gives "8 feet 5+5⁄8 inches (2.581 m)"

If you want fractions less than one you have to enter the zero. For example:

{{convert|8|ft|0+2/3|in}} gives "8 feet 0+2⁄3 inch (2.455 m)" but

{{convert|8|ft|2/3|in}} gives "8 feet 2⁄3 inch (2.455 m)"

It can only handle halves, thirds, quarters and eights. For example:

{{convert|7|ft|2+1/5|in}} gives "7 feet 2+1⁄5 inches (2.189 m)"

It works with pounds and ounces, with stone and pounds as well as with foot (as opposed to feet) and inches also. For example:

{{convert|16|st|6+1/2|lb}} gives "16 stone 6+1⁄2 pounds (104.6 kg; 230.5 lb)"

{{convert|73|lb|12+1/3|oz}} gives "73 pounds 5+1⁄3 ounces (33.26 kg)"

{{convert|9|foot|5+3/4|in}} gives "9 foot 5+3⁄4 inches (2.889 m)"

The feature is new (added today) so if there are any bugs or inadequicies please report them here or on my talk page. JЇѦρ 07:53, 8 April 2008 (UTC)

Who da man? You da man, Jimp. Haus^Talk 11:40, 8 April 2008 (UTC)

A strange convert template issue, I think

I've been doing some tinkering with {{Infobox Ice Hockey Player}} and I've run into something odd that I think might be due to a weird interaction with this template. I put the documentation into a subpage (Template:Infobox Ice Hockey Player/doc) as per the common standards, and the included example looks fine. Template:Infobox Ice Hockey Player/doc#Example for Aleš Hemský. But when I go to Template:Infobox Ice Hockey Player#Example for Aleš Hemský, convert appears to display a major freakout over the weight. I'm having the same problem with my attempt to convert the template as a whole over to {{infobox}}, when I try previewing a test case using my prototype (User:Bryan Derksen/Template sandbox) the weight conversion throws a fit even though it's the exact same code as is used in the current template. Any ideas? Bryan Derksen (talk) 18:30, 4 April 2008 (UTC)

That is odd. It seems to happen only with the subtemplate Template:Convert/kg stlb and not with Template:Convert/kg st. —MJCdetroit ^(yak) 20:38, 4 April 2008 (UTC)

Though Template:Convert/kg stlb seems to work fine by itself. JЇѦρ 16:41, 5 April 2008 (UTC)

I still haven't been able to figure out what's going on. It is strange. JЇѦρ 16:37, 9 April 2008 (UTC)

Oil and gas pipelines

Comment moved to ongoing discussion of this issue in Feature request: option for 'trillion', 'billion', 'million' above. Lightmouse (talk) 13:49, 5 April 2008 (UTC)

SI units for petroleum and natural gas

It is not universally true that SI units are not used in the oil industry. While the American industry uses barrels while the Europeans use tonnes, the Canadian industry uses SI units to measure both petroleum and natural gas. They only convert them to barrels and cubic feet for export purposes (Canada is the largest supplier of oil and natural gas to the U.S.), and for reporting to investors since many Canadian companies are listed on the New York Stock Exchange. At the oil field level, workers talk of "cubes" (cubic metres of oil and cubic metres of gas).

The SI units used are:

• cubic metres (m³) for both petroleum and natural gas
• kilograms (kg) for weights
• kilograms per cubic metre (kg/m³) for densities

Litres (L) and tonnes (t) are depreciated non-SI units and not used for petroleum or natural gas measurement (although they are used for products like gasoline and commodities like coal.) Tonnes would be particularly misleading for measuring oil because a lot of Canadian production is much heavier than normal oil.

Metric (SI) versus U.S. Measurement Units

Measurement	SI Unit	US Unit
Oil volume	cubic metres (m3)	barrels (bbl)
Gas volume	cubic metres (m3)	standard cubic feet (scf)
Density	kilograms per cubic metre (kg/m3)	API gravity (°API)
Energy	gigajoules (GJ)	British Thermal Units (BTU)

There is a problem with volume units in that the increments are too large. Litres are too small to be practical for crude oil, and cubic kilometres (km³) are too large. So, exponential notation is used, but with the caveat that "engineering notation" is used, in which only multiples of three are used for the exponent, as below:

Petroleum and Gas Volumes

Acronym	Full Name	Abbreviation
m3	cubic metres	m3
e3m3	thousand cubic metres	103m3
e6m3	million cubic metres	106m3
e9m3	billion cubic metres	109m3
e12m3	trillion cubic metres	1012m3

Hope this helps to clarify things. RockyMtnGuy (talk) 04:11, 16 April 2008 (UTC)

It did help. I've changed the default conversions to engineering notation instead of scientific notation. I've also used the above acronyms as codes. JЇѦρ 18:28, 23 April 2008 (UTC)

Barrels per year / tonnes per annum

Is it possible to create a conversion of (oil) barrels per day to tonnes per year?Beagel (talk) 10:58, 5 April 2008 (UTC) It seems to be most suitable for the oil-related articles.Beagel (talk) 10:58, 5 April 2008 (UTC)

Done.

{{bbl to t|123|per=d|t_per=a}} gives "123 barrels per day (~6,130 t/a)"

JЇѦρ 04:20, 7 April 2008 (UTC)

Not to throw a monkey wrench into the gears, but the chemist in me must point out that crude oil varies in density depending on where the crude oil comes from. Alberta crude may actually weigh much more than say Texas crude per barrel. That's one reason that they have to be refined differently. Of course I don't have any references (at the moment) but I'll see if I can find some density tables to reinforce my terrible memory. —MJCdetroit ^(yak) 12:16, 7 April 2008 (UTC)

• click on the link to the "Table of API Gravity-Specific Gravity-weight per gallon or liter" link on the page
• Denisities of common liquids
• another table showing different crude densities

Here's a few to get an understanding of what I'm talking about. —MJCdetroit ^(yak) 13:50, 7 April 2008 (UTC)

Ezhiki thought of that when he made the template and so added the parameter API. He made it optional, though, defaulting to 33.4. The template could be changed to make it mandatory so discouraging people from using the thing without thinking about what they're doing. JЇѦρ 14:53, 7 April 2008 (UTC)

Crude oil varies widely in density, from about 0.800 tonnes/m3 to 1.000 tonnes/m3, although it can be higher or lower than that for some unusual crude oils. API gravity is a wacko inverted density scale invented by the American Petroleum Association based on the Baumé scale for wine invented in France in 1762 with a small error in the hydrometer calibration ... but I digress. API gravity = (141.5/density) - 131.5. The value of API = 33.4 is a global average of crude oil densities derived from the BP web site, equivalent to about 0.858 tonnes/m3. If you don't know what brand of crude oil you're dealing with (and there are about 160+ recognized varieties traded internationally), it's better than nothing, but not a lot better than nothing. The usual conversion is from barrels per day (bpd) to tonnes per annum (t/a). RockyMtnGuy (talk) 17:55, 7 April 2008 (UTC)

If only we could rid the world of wackiness ... we wouldn't need {{convert}}. What is to be done, though? Do we put a warning on {{bbl to t}} ... we probably need not go so far as deleting it (were it deleted it's probably be recreated sometime down the track but maybe not with the current functionality)? JЇѦρ 01:13, 8 April 2008 (UTC)

One of the reasons that the Canadian oil industry converted to the metric system was that Canada, being a former British colony that never had a revolution, was on the British Imperial system. The United States is on the American Imperial system, and none of the British Imperial measures of liquid volume are the same as the American Imperial measures. Let me repeat that, NONE of the British Imperial measures of liquid volume are the same as the American Imperial measures. Only the names are the same. There's even a British Imperial Barrel that is close to but not quite the same as the American Standard Oil Barrel. And then there's the fundamental difference that Americans used to ship oil in barrels on railway cars, whereas Europeans used to ship oil by weight on tankers. Hence, the Americans use barrels whereas the Europeans use tons. And then there's the inconsistency between the U.S., the U.K., and continental Europe between short tons, long tons, and metric tons (tonnes). So, the bills of ladings for ships that I have seen gave the amount of oil in short tons, long tons, tonnes. and barrels - just to cover all the bases. So, how do you resolve these inconstancies? Well, in Canada, the regulatory authorities just said, "You will report all amounts in SI units. There will be no exceptions. This means YOU!" It's simpler that way. RockyMtnGuy (talk) 16:12, 8 April 2008 (UTC)

Okay, to simplify, there are three things you need to know to calculate the amount of oil you have (where we are not really sure of what we mean by amount).

• Weight of oil in tonnes
• Density of oil in tonnes/cubic metre
• Volume of oil in cubic metres

If you know two of these things, you can calculate the third. In SI units, this is dead simple. If your weight is in long/short tons, your density is in degrees of API gravity, and your volume is in standard oil barrels, it's a much bigger challenge, but of course we all appreciate another challenge because we don't have nearly enough of them in our daily lives. RockyMtnGuy (talk) 17:30, 8 April 2008 (UTC)

Ranges?

Hello, is there away to convert ranges? I.e. 100-120 meters (xx-yy feet)? Thanks, Renata (talk) 01:58, 7 April 2008 (UTC)

Not yet, but this is, hopefully, something the future will hold. See Template talk:Convert/Archive February 2008#Support for ranges?. — Huntster (t • @ • c) 02:03, 7 April 2008 (UTC)

It's top of my to-do list. JЇѦρ 03:43, 7 April 2008 (UTC)

In to Cm decimal problem

At Four Freedoms (painting series), the {{convert}} template does not seem to be handling decimal input because it seems to thing 45.75 and 46 inches are a full inch different based on the conversions from what I can tell.--TonyTheTiger (t/c/bio/WP:CHICAGO/WP:LOTD) 20:36, 10 April 2008 (UTC)

I've gone ahead and fixed the page; the issue was that the template assumed (I believe) that you wanted the whole number "46" converted into another whole number with equal significant digits. Forcing it to use one decimal space (the {{convert|46|in|cm|1}}) fixes this. Still, I'm not sure this type of assumption should be left to the template to decide, though when it does work as intended, it is marvellous. — Huntster (t • @ • c) 01:47, 11 April 2008 (UTC)

Alternatively you could force the 45.75-inch conversion to round to the nearest centimetre: {{convert|45.75|in|cm|0}}. It rounds to a matching precision as the input, often this will be what you want, often it won't. Note also that you can specify the number of significant figures you want using sig fig. JЇѦρ 04:25, 11 April 2008 (UTC)

The 45.75 inch figure is likely expressed in somewhat misleading precision in the first place. It doesn't really have four significant digits. It is likely really 45¾ to the nearest quarter inch. I'd call that a little more than two decimal digit precision, a little less than three digit precision, for a number of this size. And if both numbers are to one-quarter inch precision, converting both to the nearest centimeter might be the most reasonable conversion. As in most conversions, the most logical choices are either one that is a little too precise, or the one that is a little too imprecise. But in knowing the dimensions of pictures, there is little reason for any of us to know them to the nearest millimeter. If they are originally measured in metric units, it is usually to the nearest centimeter (sometimes to the nearest half-centimeter), and not to the nearest millimeter. Especially for a picture of this size.

That's were people come in. It is difficult to devise any program to always make the best choice. In this case, either both results should be rounded to the nearest centimeter, or both to the nearest millimeter. Not one in centimeters with no digits after the decimal point, and the other in centimeters with one digit after the decimal place. That said, it really doesn't make a whole lot of different chich one is chosen. It only looks bad if your conversion results are expressed as "116.2 cm by 117 cm" or as "116.20 cm by 120 cm".

However, grouping the conversions would make them much easier to read:

• compare "The paintings are approximately equal in dimension with measurements of 45.75 inches (116.2 cm) × 35.5 inches (90 cm)"
• with ""The paintings are approximately equal in dimension with measurements of 45.75 inches × 35.5 inches (116.2 cm × 90 cm)"
• or better yet "The paintings are approximately equal in dimension with measurements of 45¾ inches × 35½ inches (116 cm × 90 cm)"
• or maybe best of all, ignore somebody's recent change to MoS and just say "The paintings are approximately equal in dimension with measurements of 45¾ × 35½ inches (116  × 90 cm)"

Isn't that a whole lot easier to read, no matter which set of measurements you choose to ignore? It is difficult to wade through that piecewise conversion nonsense.

Convert won't handle that, I don't think. And there's probably not a whole lot to be gained by ever trying to make it do so. Just remember, you can still add the conversions manually. Use {{convert}} to get the numbers if you like, then edit the results to make them more legible. Gene Nygaard (talk) 03:04, 15 April 2008 (UTC)

And it is not just easier to read in terms of the speed in which you can read it, but also in the likelyhood that you will retain what you read in your memory, when th conversions are grouped together. Gene Nygaard (talk) 03:07, 15 April 2008 (UTC)

Definitely group the conversions together as Gene suggests and, no, {{convert}} won't do that for you currently. Whether or not it will ever be able to is another question. No, not a lot to be gained by working it to handle "45¾ × 35½ inches (116 × 90 cm)" specifically but ... JЇѦρ 06:44, 15 April 2008 (UTC)

A comment from Elk Salmon has been moved to #Round the original value.

BCE/CE dates to BC/AD dates

For those among us who are offended by "Before Christian Era" and "Christian Era" because it presupposes a faith in the existence of Christians.--Zerothis (talk) 02:06, 22 April 2008 (UTC)

First off, unless I've missed something, this template doesn't convert dates (does it??), so I'm not sure why this is being asked here. Second, any modern dating system is going to have some references to Christianity, for better or worse. BC/AD has historically stood for "Before Christ"/"Anno Domini" (In the year of the/our Lord), so I don't see how that would be a better term to use. Modern usage calls BCE "Before Common Era" and CE just "Common Era". Unless we adopt a completely non-standard, non-offensive system, this situation is unavoidable. — Huntster (t • @ • c) 07:48, 22 April 2008 (UTC)

The solution, obviously, is to use the ISO 8601 standard date format (yyyy-mm-dd), in which today's date is 2008-04-22. The ISO date format starts at the year zero (the early Greeks, Romans and Christians didn't have the number zero, which created a huge problem in doing arithmetic that was only solved when the number zero was imported from India many centuries later.) Numbers after the year zero are positive, numbers before the year zero are negative, and it avoids the problem that Americans usually specify their dates in the order mm/dd/yy, whereas Europeans tend to use dd/mm/yy. It's mathematically foolproof,but people would prefer to argue over whether to use BC for Before Christ or BCE for Before Common Era rather than to use anything as radically new and unchristian as negative numbers. BTW, Christ was probably born in the year -0003 in the ISO system, although nobody recorded his birthday at the time, so nobody knows for sure. RockyMtnGuy (talk) 17:00, 22 April 2008 (UTC)

Nobody know for sure whether such a man even existed ... but we do digress. If this were implimented, you'd have {{convert|44|BCE}} producing "44 BCE (44 BC)", {{convert|1944|AD}} producing "1944 AD (1944 CE)", etc. Would there be any point? Surely we don't need both. If, on the other hand, you want to change BC to BCE, AD to CE, etc. just do so in raw text. Now, if you were after a template to convert between Julian and Gregorian dates, then you'd be talking sense. JЇѦρ 01:25, 23 April 2008 (UTC)

We are men of action, lies to not become us

The main sources of information regarding Jesus' life and teachings are the gospels. Most scholars in the fields of history and biblical studies agree that Jesus was a Galilean Jew, was regarded as a teacher and healer, was baptized by John the Baptist, and was crucified in Jerusalem on orders of Roman Governor Pontius Pilate, on the charge of sedition against the Roman Empire. Most critical scholars believe that ancient texts on Jesus' life are at least partially accurate.

Emphasis mine —Preceding unsigned comment added by Zerothis (talk • contribs) 17:30, 30 April 2008 (UTC)

What? First, how is this remotely relevant, and second, doesn't it contradict your first statement that BCE/CE shouldn't be used? In terms of this template, this is simply a non-issue. — Huntster (t • @ • c) 19:03, 30 April 2008 (UTC)

Sorry, it was in reply to Jimp's comments and I placed it wrong.--Zerothis (talk) 15:14, 1 May 2008 (UTC)

When you are talking about converting between Julian and Gregorian dates, are you talking about Julian years, Julian days, or the Julian calender? They are three different things. And I'm not really sure it's useful unless you are an astronomer, in the military, or want to celebrate a traditional Ukrainian new year. RockyMtnGuy (talk) 20:36, 23 April 2008 (UTC)

/me laughs. I cannot imagine a more inane use of a template than to handle your first examples. Converting between Gregorian and Julian would certainly be interesting, though I don't really see where it would get enough use to be worth the time (other than just to show off that the template can and will convert *everything*. :D

RockyMtnGuy, while strict ISO adherence would be fine, I'm afraid we'd still have the U.S. and European (aka everyone else) proclivities for having month-day and day-month, leading to even more confusion given that there are only numbers and no month names to draw inference from. — Huntster (t • @ • c) 11:08, 23 April 2008 (UTC)

True, but it's quite doable. JЇѦρ 18:39, 23 April 2008 (UTC)

Now, in a past life working as a consultant to giant international oil companies, I found that when you use a date like "01/02/03", nobody knows what you are talking about. It's either "1 February 03" or "January 2, 03". I took a survey and discovered that about 50% of Americans knew their date format was supposed to be "MM/DD/YY", and the other 50% weren't sure. About 75% of Brits knew that they were supposed to use "DD/MM/YY", but a lot of them weren't sure, either. Of course you could use "1 February 2003" but then the Americans got upset, or "February 1, 2008", but then the British got upset, and on both cases the French insisted it should be "1 Février 2003" and pretended they couldn't speak English. And that was even before we got into an argument about AD versus CE. So the easy way out was to use ISO format, "2003-02-01" which has the additional advantage that it sorts into ascending date format without any reformatting or translation. We made the concession of formatting it as "2003 February 1" on reports for the English-speakers, and translated it into "2003 Février 1" for the French (because we had to translate the headings anyway). RockyMtnGuy (talk) 20:08, 23 April 2008 (UTC)

Proposing new parameter: Orders of magnitude

I have often linked unit numbers to an appropriate orders of magnitude page. I haven't encountered this template before now, and editing the Sarnoff Corporation article, I was about to change "300 acres (1.2 km²)" into perhaps "300 acres (1.2 km²)" (or rather "300 acres (1.2 km²)") when I discovered that that wouldn't be possible without throwing out the {{convert}} code. Perhaps you who have been working on this template all along wouldn't mind incorporating this feature into the template? __meco (talk) 12:42, 26 April 2008 (UTC)

Of course, "300 acres (1.2 km²)" may be preferable but "300 acres (1.2 km²)" can be achieved with [[1 E+6 m²|{{convert|300|acre|km2}}]]. However, we come next to the question as to whether links from specific measurements to these orders of maginitude pages is appropriate ... not really a topic to be discussed on this page. JIMp _talk·cont 07:08, 30 April 2008 (UTC)

Perhaps I'm mistaken, but haven't I read somewhere that linking to orders of magnitude pages is inappropriate for conversions or measurements in general? — Huntster (t • @ • c) 19:03, 30 April 2008 (UTC)

If it's not written somewhere, I say it probably should be ... but that discussion for WT:MOSNUM (if you can get a word in edgeways these days). JIMp _talk·cont 23:48, 30 April 2008 (UTC)