Template talk:Convert/Archive March 2009

more than two dimensions

Can the convert template handle 3 dimensions? I wanted to use it for the baggage size (like 45 cm × 35 cm × 16 cm) in 2006 transatlantic aircraft plot.  —Chris Capoccia ^T⁄_C 13:17, 19 February 2009 (UTC)

Not yet. JIMp _talk·cont 10:43, 9 March 2009 (UTC)

Megalitre

Can anyone help with Megalitres? A reference says Clatworthy Reservoir holds 5364 Megalitres. Is there any way for this template to handle them (or any advice on how to convert them into units it can handle)?— Rod ^talk 10:00, 6 March 2009 (UTC)

A megalitre is actually a nonstandard term for a cubic decametre (dam³) or 1000 cubic metres (10³m³). . The SI system discourages use of the litre and prohibits the use of prefixes with it. The Convert abbreviation for dam³ is dam3. Personally, I prefer to use engineering notation and cubic metres (e3m3 or e6m3) for things like reservoir volume, e.g. Clatworthy Reservoir holds 5.364 million cubic metres (5,364 dam³) RockyMtnGuy (talk) 04:16, 8 March 2009 (UTC)

Thanks I've edited the article as you recommend.— Rod ^talk 09:53, 8 March 2009 (UTC)

Or {{convert|5364|Ml}} → "5,364 megalitres (189.4×10^⁶ cu ft)". JIMp _talk·cont 10:43, 9 March 2009 (UTC)

Yikes. Can we have a list of all the units that use double output by default? Lightmouse (talk) 10:50, 9 March 2009 (UTC)

I don't know whether I could come up with such a list that easily. Multiples of the litre, knots, nautical miles ... maybe gallons, pints, etc. JIMp _talk·cont 11:14, 9 March 2009 (UTC)

A huge proportion (about half) of the instances of 'megalitre' are Australian. For example, I believe Australian water meters are in megalitres whereas other countries measure water in cubic metres. Lightmouse (talk) 15:42, 9 March 2009 (UTC)

In the United States, water reservoir volumes are usually measured in acre-feet rather than gallons. One acre-foot is the volume of water sufficient to cover an acre of land to a depth of 1 foot, equal to 43,560 cubic feet, approximately 325,851 U.S. gallons, approximately 1233.48 cubic meters. Not that the unit means anything to anybody except a rice farmer, but there it is. However, the question arises, "Should we cater to both Australians and Americans by converting to megalitres and acre-feet, or is that getting to be ridiculous?"RockyMtnGuy (talk) 17:00, 9 March 2009 (UTC)

What are we converting from? If the original unit is the cubic metre, cubic decametre, cubic hectometre, etc., then we surely need no conversion to megalitres. However, if we start with cubic feet or some kind of gallon, we'll need some sort of metric equivalent ... of course we won't need both a cubic metre, cubic kilometre, etc. and kilolitre, megalitre, gigalitre, etc. conversion (just one or the other ... preferably the first). How about cubic feet to acre feet or imp/US gallons to acre feet, should we bother with converting these? JIMp _talk·cont 19:37, 9 March 2009 (UTC)

I just mentioned that because I know that American engineers commonly measure reservoir volumes in acre feet, not gallons or cubic feet, and notwithstanding Australian preferences, most engineers in other countries use cubic metres. However, I just figured out how to do the conversion: Clatworthy Reservoir holds 5.364 million cubic metres (4,349 acre⋅ft) of water. I'm not sure there's any point in using other units.RockyMtnGuy (talk) 04:35, 10 March 2009 (UTC)

Move warning templates to /doc

{{editprotected}}

There's no reason to have the template's warnings split between <noinclude>s on the template itself and the documentation page. They should all be on /doc. I've updated the code in the sandbox; just needs synced. Once that's been done, I'll add {{intricate}} to the top of the /doc page. Chris Cunningham (not at work) - talk 12:01, 10 March 2009 (UTC)

 Done that. — Martin (MSGJ · talk) 13:32, 10 March 2009 (UTC)

Trouble on a transcluded page

1.0

Take a look at User:Droll/test where most of the content is transcluded from User:Droll/test/doc. On the User:Droll/test/doc page everything looks fine but on User:Droll/test there are errors shown. I'm thinking it might have something to do with all the noincludes and includeonly elements on these kind of pages but I'm stumped. --droll [chat] 06:59, 12 March 2009 (UTC)

I tested same code at Template:Infobox Mountain and Template:Infobox Mountain/doc with same bad result. I reverted the pages promptly. Convertion from feet to metres worked fine. See a similar example at Template:Infobox Protected area/sanbox which is a template update in progress. --droll [chat] 07:12, 12 March 2009 (UTC)

Never mind. I hunted down the solution. The problem was real and the solution is illogical. If you want to try it yourself I'll try to code up and example after a little sleep. It seems to be related to this template only. --droll [chat] 09:42, 12 March 2009 (UTC)

2.0

OK! Now I have two mysteries. See User:Droll/test. The first error I know how to work around but it shouldn't happen. The second error is a total mystery to me. Both should be fixed if possible in my opinion. If you need any help understanding the examples let me know. Basicly first look at the /doc page, User:Droll/test/doc, where everything works fine. Next look at User:Droll/test where the errors are evident. --droll [chat] 17:36, 12 March 2009 (UTC)

I've seen this kind of thing before and have to admit that I'm a little baffled. Things work fine on the doc page (and in articles) but go all mimsy when the doc is transcluded. It makes no sense ... but how we've got it working with some infoboxes and not others (on your test page) might end up being a key to solving the mystery ... maybe. Can I try Elevation_m=1234 on your mountain infobox? JIMp _talk·cont 18:39, 12 March 2009 (UTC)

Do whatever you wish. --droll [chat] 19:03, 12 March 2009 (UTC)

OK!!!!! See User:Droll/test1. The bug is a result of the output being evaluated as in {{#if: {{{area|}}} | {{{area}}} }}. If you edit User:Droll/test1 and comment out the conditional statement the problem goes way for the other two examples. Please revert after the experiment. As to why that happens I read something on mediawiki about evaluation having side effects but I really don't know.

The second bug at User:Droll/test still is unresolved. --droll [chat] 21:38, 12 March 2009 (UTC)

I had to edit some of the page names above after cleaning up my workspace. Sorry if it caused any confusion. --droll [chat] 20:19, 13 March 2009 (UTC)

3.0

See User:Droll/bug. It is a very simple example of the bug in {{convert}}. It needs attention. The error message seems to report an attempt to use {{rnd/c}} which does not exist. --droll [chat] 21:02, 13 March 2009 (UTC)

It's not trying to use {{rnd/c}}, all that bold red should be some number. JIMp _talk·cont 08:17, 14 March 2009 (UTC)

Discussion duplicated from Template talk:Documentation:

Bug
I have a problem that seems to be traceable to this template. See User:Droll/bug for an example. Notice that an error message appears. If you look at User:Droll/bug/doc you will see no error message. See User:Droll/bug/test where the doc page is transcluded and no error message appears. It seems that the bug is specific to {{Documentation}} I hope this can be resolved. I have spent many hours trying to figure this out. Find other examples of similar but not necessarily identical problems at User:Droll/test and User:Droll/test1. --droll [chat] 08:33, 14 March 2009 (UTC)

So that no one makes the same mistake I made at first, I dont think its a problem with the template {{convert}}. I jumped to that conclusion right off and started a thread on the discussion page there. The editors I talked with don't think its a problem with that template. I tend to agree with them although it might be an interaction between the two templates although I don't understand how that could happen. The interesting thing is that sometimes is happens and sometimes it doesn't but the conditions under which it occurs are consistent. If your are interested, and the examples don't help, I'll go into more detail as to what conditions seem be related. --droll [chat] 09:46, 14 March 2009 (UTC)

For a total shock go to User:Droll/bug and uncomment the <noinclude>{{User:Droll/bug/doc}}</noinclude> at the top of the page, save the page and purge. You should see the transclution and the rendering by the {{documentation}} template. The error message will have disappeared. It gets better. Restore the comment at the top of the page and then look at the bottom of the page and uncomment {{User:Droll/bug/doc}}, save and purge. Now the error will occur twice. Once in the Documentation version and once in the transcluded version. Please restore when done. This is mad house stuff. It probably means that the bug is at a lower level than this template. Maybe a metawiki bug. If I get a few people to agree I'll do the bugzilla thing unless someone with more influence wants to carry the ball. --droll [chat] 12:08, 14 March 2009 (UTC)

The error seems to start in {{Convert/round}}, as you can see by following the transclusion tree below. Notice that after the redirect, the template uses parameters that are not defined and have no defaults (bolded). These are then passed on to equations, which fail because "{" is not a valid operand or operator. These errors are wrapped in <span> tags, which in turn cause other equations to fail because "<" is not a valid operand or operator. Mayhem ensues.

1. {{convert|3080.73|km2|acre|abbr=on}}
2. {{convert/km2|3080.73||acre||||r=re|d=LoffAonDbSoff|s=}}
3. {{convert/LoffAonDbSoff|3080.73||acre||s=|r=re|u=km²|n=square kilometre|h=square-kilometre|t=square kilometre|o=sqmi|b=1000000|j=6-0}}
4. 3,080.73 km² ({{convert/acre|3080.73|3080.73*1000000|||r=re|j=6-0|d=LoffAonSoff}})
5. {{convert/LoffAonSoffNa|3080.73|3080.73*1000000|||s=|r=re}}
6. REDIRECT → Template:Convert/LoffAoffSoff
7. {{convert/out|{{convert/round|3080.73|3080.73*1000000/{{{b}}}|||{{{j}}}}}|{{{n}}}|{{{n}}}s}}
8. {{#ifexpr:3080.73*1000000/{{{b}}}=0|0|{{formatnum:{{rnd|3080.73*1000000/{{{b}}}|({{max/2|{{precision/+|13080.73}}+(-0.1989700043)round0|1-{{ordomag|3080.73*1000000/{{{b}}}'}}}})}}}}}}

The {{Convert}} structure is so tortuous, I'm not at all surprised it has weird effects.

—{admin} Pathoschild 12:42:52, 14 March 2009 (UTC)

{unindent}

1. Why does this happen in the context of documentation pages and nowhere else?
2. Should I go back to {{convert}} and shake that tree some more?
3. Should I wait and see what else people here can do?
4. Did anyone try the "uncomment trick" mentioned above and why should any of that happen.

--droll [chat] 19:34, 14 March 2009 (UTC)

Furthermore, when {{documentation}}'s code is used directly (by pasting its code and manually inserting parameter values), the {{convert}} call works perfectly (example). The erratic behaviour is probably due to quirks or caching in the parser. I don't think this is a problem with {{documentation}}, which is relatively straightforward: if the page exists, transclude it. Convert is the right place to discuss this.

—{admin} Pathoschild 22:21:17, 14 March 2009 (UTC)

—{admin} Pathoschild 22:24:30, 14 March 2009 (UTC)

Hear are two examples of the bug in the wild.

1. Template:Infobox Firearm Cartridge
2. Template:Ft to m

I've left messages with Jimp and MSGJ. Are there any other editors actively editing this template. Please let me know if there is anything I can do to help out. --droll [chat] 22:51, 15 March 2009 (UTC)

I think it is clear that the problem is that there is an attempt to call one of the {{rnd/c*}} subtemplates, see Subtemplates of Template Rnd, with an undefined template name. The template name is formed on the fly by {{rnd/b}} within {{rnd/a}}. All this is a bit esoteric. The only way this can be resolved is if someone who understands the machinations of these templates steps forward and takes responsibility. This can all be seen if the information given by Pathoschild is followed and a little research is done. I think this points out a serious flaw at the heart of wikipedia templates. Most templates lack documentation of flow and are not self documenting. Templates here in general tend to look like spaghetti code. I'm not blaming anyone specifically but it appears to be a systemic problem. We have a manual of style for articles but no guidance on programing style. It seems to me that this state has just sort of evolved.

Well so much for tonight's rant. I will figure out how to expand this discussion somewhere else as I am probably preaching to the choir here.--droll [chat] 11:35, 16 March 2009 (UTC)

Well I guess no-one understands {{rnd}} better than the creator. Okay, it seems like time to go and redesign it ... reredesign it. But as far as I'm aware the problem is only occurring when template doc pages are transcluded. JIMp _talk·cont 00:16, 17 March 2009 (UTC)

4.0

How's it looking now? JIMp _talk·cont 10:58, 17 March 2009 (UTC)

Things are looking good. Thanks Jimp. --droll [chat] 04:05, 19 March 2009 (UTC)

convert|0|kcal/g|kJ/g, etc

Someone care to attempt creating the following templates? 0 calories per gram (0 kJ/g) & 0 kilocalories per gram (0 kJ/g) as well as 0 calories per hour (0 kJ/h) & 0 kilocalories per hour (0 kJ/h) Peter Horn 00:49, 20 March 2009 (UTC)

Done. JIMp _talk·cont 09:11, 20 March 2009 (UTC)

abbr default state

{{editprotected}}

inasmuch as the greater percentage of conversions are (or after the first instance certainly should be) rendered as abbreviations, i'm wondering if it might make better sense for the default state to reflect the abbreviation. --emerson7 22:29, 23 March 2009 (UTC)

Sounds reasonable, but please get support for this and then re-add the editprotected. Thanks, — Martin (MSGJ · talk) 18:24, 24 March 2009 (UTC)

Fair enough if there is support and we can come up with a plan regarding those current transclusions which should remain spelt out in full. Also, before this is done we'd have to do something about the tables since abbr=on with disp=table makes the unit symbol/abbreviation appear—something you only occasionally want in a table. JIMp _talk·cont 07:18, 28 March 2009 (UTC)

Suggestions about default precision

Regarding the number of decimals remains the same if the conversion is a multiplication by a number between 0.2 and 2, is decreased by 1 if the factor is between 2 and 20, etc.:

• Wouldn't it make more sense to put the boundary at √10 = 3.162277... rather than at 2? I doubt many people would really round the conversion in "84 kilograms (185 lb)" to the nearest ten pounds, or that in "49 inches (120 cm)" to the nearest ten centimetres. With this proposal they would be converted to 185 pounds and 124 centimetres respectively.

Regarding or to two significant figures whichever is the most precise:

• Why? Writing "Aversa is a town about 15 kilometres (9.3 mi) north of Naples" looks somewhat quaint to me. (Maybe you could make an exception if the significand of the converted value is between 1.0 and 1.5 to avoid e.g. that 14 is rounded to 10, if technically feasible, if this was the concern why this exception was implemented in the first place.) --A. di M. (talk) 13:15, 22 March 2009 (UTC)

Strictly speaking it should be at one rather than two: anything over one involves false precision. However, if we want to bump it up to three or something it won't be too difficult to do. Yes, the at least two significant figures thing was to avoid introducing inaccuracy but in a relatively easy-to-understand way. I'd wanted to avoid confusing users with talk of significands and the like ... but if it's worth it ... JIMp _talk·cont 19:59, 23 March 2009 (UTC)

I think the default should be to match the significant figures. Thus "Blobington is 4 miles (6 km) from Peeton". Unfortunately, the template adds an extra significant figure producing "Blobington is 4 miles (6.4 km) from Peeton". That is not appropriate for town to town distances and many other routine uses. I love the template in general but I don't like this inconsistent feature of deliberate mismatching significant figures . Match the significant figures please, it will make the template simple and consistent. Lightmouse (talk) 10:38, 24 March 2009 (UTC)

Simply matching the number of sig. figs can produce excess precision when the source begins with 1 and the target begins with 9, as in the example above. The current algorithm (leaving the position of the last significant figure unchanged if the conversion factor is between 0.1x and x, shifting it one place to the left if it is between x and 10x, and so on) is better, although I think x should be larger than its current value of 2. (Assuming the source value has an error of about 0.5 units in the last place, by setting x to √10 the converted value can have an error of up to about 1.6 ulp; excess precision if you're excessively pedantic, but not very serious, and closer to what is done IRL: see the examples about kilograms to pounds and inches to centimetres; also the "approximate but not crappy value for g" is usually given as 32 ft/s² in America and 9.8 m/s² in Europe; but with x less than 3.048 32 ft would round to 10 m if the exception of "at least two significant figures" is removed.)--A. di M. (talk) 13:31, 24 March 2009 (UTC)

I see your example of "15 kilometres (9.3 mi)" and have some sympathy with it. But I can't get my head round your proposed rules. Can you give examples of how you think it should be for several cases? Lightmouse (talk) 13:40, 24 March 2009 (UTC)

As they are now, except that the exception of "at least two significant figures" should be removed, and the value of x should be increased to √10. --A. di M. (talk) 13:47, 24 March 2009 (UTC)

I can't translate the mathematical formula into real world examples. Forgive me for being unable to work it out. What difference would that make to:

• 0.1 miles (0.16 km)
• 0.2 miles (0.32 km)
• 0.3 miles (0.48 km)
• ...
• 14 miles (23 km)
• 15 miles (24 km)
• ...

and other common unit conversions? Lightmouse (talk) 18:10, 24 March 2009 (UTC)

0.1 miles (0.2 km), 0.2 miles (0.3 km), 0.3 miles (0.5 km), ..., 14 miles (23 km), 15 miles (24 km): since the mile and the kilometre are "roughly the same size", if the last significant digit of the source is the "tenths" digit, so be it in the conversion; if it is the "units" digit, so be it in the conversion, and so on. By "roughly the same size" I mean "no more than about 3.16 times larger and no less than 3.16 times smaller", so the inch is "roughly the same size" as the centimetre and the pound is "roughly the same size as" the kilogram: 84 kilograms would be converted to 185 lb (whereas both by the current rule and by "matching the number of significant figures" it would be rounded to 190 lb), 84.3 kg to 185.8 lb, and so on. One foot is more "roughly the same size" as 0.1 m than as 1 m, so 32 feet would be converted to 9.8 m and vice-versa, 32.2 ft would be converted to 9.81 m and vice-versa, and so on.

(Maybe rounding 0.1609334 km to 0.2 km can be a little too much and an exception could be made to keep at least two significant digits when the first significant digit of the exact conversion is 1; but on the other hand a length given as 0.1 miles rather than as 176 yards will probably be an eyeball estimate or something like that, so 0.2 km might be no less appropriate than 0.16 km.)

A. di M. (talk) 16:40, 27 March 2009 (UTC)

As I said above, I want the default to work out as:

• "Blobington is 4 miles (6 km) from Peeton" i.e. one sig fig for all mile values between 1 and 6
  

The template currently gives 2 sig fig i.e. '1.6 km', '3.2 km', or '4.8 km'. It is a common source of annoyance for me. If you can get the template to do 1sigfig for all mile values between 1 and 6, I would support your proposal. Lightmouse (talk) 17:53, 27 March 2009 (UTC)

Following my proposal, 4 miles / 5 miles / 6 miles / 7 miles / 8 miles would be converted to 6 km / 8 km / 10 km / 11 km / 13 km respectively. (I would not know how to implement it, but Jimp sounds like he said he could.) --A. di M. (talk) 18:01, 27 March 2009 (UTC)

I notice that you missed out 1, 2, and 3 miles. What would happen to them? Lightmouse (talk) 19:22, 27 March 2009 (UTC)

2 miles would be 3 km and 3 miles would be 5 km. I'm undecided about the exception for trailing 1s: with it 1 mile would be 2 km, without it that would be 1.6 km. --A. di M. (talk) 19:50, 27 March 2009 (UTC)

Thanks for the response. That sounds good. I see no reason for an exception at 1 mile. A travel guide in a non-metric country might say: "Blobington is 1 mile from Peeton" and a travel guide in a metric country would say "Blobington is 2 km from Peeton". Simples.
Lightmouse (talk) 20:00, 27 March 2009 (UTC)

Yes, I mostly like the idea of removing the two-significant-figure minimum for significands greater than or equal to two. "Three miles ≈ two kilometres" is good but I'm not so keen on "one inch ≈ thirty millimetres". As for the other thing, strictly speaking, two involves some degree of false precision, root ten would involve more, but if there's support, let's do it. JIMp _talk·cont 08:23, 28 March 2009 (UTC)

What do you exactly mean? 2.54 is "greater than or equal to two". If you're concerned about the fact that 30 mm looks more precise than it is, one could use 3 cm; but ultimately that's up to the users of the template. As for me, I would have no problem with 1 inch (3 cm), 1.0 inch (2.5 cm), 1.00 inch (2.54 cm) etc. if they are measurements. (For nominal values, I would not use the template in the first place, and I would give the exact value, e.g. "8+1⁄2 by 11 inches (215.9 mm × 279.4 mm exactly)", or explicitly note the approximation as such, e.g. "1 imperial pint (≈ 568 ml)".)

As for the other thing, if the boundary is kept at two some values are rounded more than most people would actually do, as in the 84 kg example above, and it would become even worse when the two-sigfig minimum is removed, e.g. 43 kg (≈ 94.8 lb) would be converted to 90 lb.

A. di M. (talk) 10:55, 28 March 2009 (UTC)

Another rounding bug at zero

I don't know whether this is related to the issue described above, but I just spotted another zero-related bug:

{{convert|1|-|10|m|ft|lk=off|abbr=on|sigfig=1}}

correctly expands as:

1–10 m (3–30 ft)

while

{{convert|0|-|10|m|ft|lk=off|abbr=on|sigfig=1}}

does not work:

0–10 m (0–30 ft)

GregorB (talk) 13:45, 30 March 2009 (UTC)

I'll look into this too. JIMp _talk·cont 12:33, 31 March 2009 (UTC)