Template talk:Convert/Archive October 2009

Haylp! Haylp!

Hello,

First I should say I am sure you are glad to hear Convert is now being given the test on Hungarian articles. (It seems I never can find an English girlfriend.)

Now this is not quite in the realm of Convert, or only obliquely. I have a template in embryo at User:SimonTrew/Hungarian settlement which, given an area per km squared and a population derives the population density using #eval. It's the first time I have written a template so am quite pleased it mostly works, and indeed this works, but too well. The kilometres come out to seventeen decimal places where two would suffice. (I do mean decimal places not sig figs here, at least I think I do.) Anyway I imagine the {{Infobox settlement}} which it invokes calls {{convert}} and nicely we have as the output/conversion sensibly in miles, but it is ridiculously over-specific in the input in kilometers. How to fix? Must be quite simple to you old hands but I am new to this. I don't have access to {{convert}} directly, I need to knock it down to 2 or 3 d.p. before it gets there. Needless to say I have looked up the relevant help but it goes into accuracy/precision as a parlay (not a parlay) on essentially ascii coded decimal not I WANT TO KNOCK THE BACK OFF OF IT, I DON'T REALLY CARE IF .5 GOES UP OR DOWN, COMPRENDE? ahem.

So a nice simple answer how to get it down (as I assume a string, used in #eval) to a reasonable level of precision, I should love to hear it. The answer no doubt is simple, but you know how WP is with actually trying to find a straight answer to a simple question.

My best wishes SimonTrew (talk) 02:52, 18 September 2009 (UTC)

Couldn't you just change:

|population_density_km2 = {{#if:{{{population_total|}}}
                              |{{#if:{{{area_total_km2|}}}
                                  |{{#expr:{{{population_total|}}}/{{{area_total_km2|}}} }}
                               }}
                         }}

so something like:

|population_density_km2 = {{#if:{{{population_total|}}}
                              |{{#if:{{{area_total_km2|}}}
                                  |{{#expr:{{{population_total|}}}/{{{area_total_km2|}}}
{{{populations_total|}}}/{{{{convert|{are_total_km2|}|km2|sqmi|lk=out|abbr=on}}}}}}
                               }}
                         }}

? 「ɠu¹ɖяy」¤ • ¢  03:14, 18 September 2009 (UTC)

Would {{pop density}} &/or {{convinfobox}} be of any use? JIMp _talk·cont 10:37, 19 September 2009 (UTC)

Unfortunately not. My difficulty is that {{Infobox settlement}} has fields for density_km2 and density_sqmi and performs the conversion itself (presumably using one of those templates you suggested; it's rather buried); it does not have a free-format field for population_density where I could use these templates (or if it does, it's undocumented).

Therefore I have to do the division myself using #eval. I don't mind doing this, but am not familiar enough with it to do the precision of it. I just need some help with the "round" thingy on "#eval", I just can't get it right. The other thing is, I don't know what I am doing wrong now, but it wants to submit the formatted value (with commas etc) instead of the plain value. These are all silly errors I know, but it's my last little struggle, everything else is working very nicely. SimonTrew (talk) 11:25, 20 September 2009 (UTC)

I don't know if this helps but the code used at Infobox Australian Place for converting km² to sqmi is : {{rnd|{{{area}}}/2.589988110336|1}} Orderinchaos 13:33, 20 September 2009 (UTC)

Thanks, I'll take a look at it. The problem is I have to cater both for places that have breakdowns for metro/urban (I think often wrongly; the Budapest infobox which I've taken a copy of for testing has urban and metro populations larger than the total, which surely is not the intent?) and the Infobox settlement template tries to be too clever when these are present, fabricating other fields.

I tried using population_density_blank (and population_density_blank_title) so that I could avoid the km2 thing, but it appears, looking at the sources, these are not actually used by the template though are in the documentation. I realised a stupid error it is not eval but expr. I think I have largely got it working now, but it took a while just to plod through the template. I do the division myself, round it myself, then throw it to population_density_km2 to handle the conversion. This is largely what I wanted in the first place, but could not get the rounding right. The example for the _population_density_blank fields, on the doc, is Windsor, Ontario, which does not actually use them. In short it is a bit of a mess.

Never mind, while not perfect, at least I only now have to change it in one place, and not fabricate stock fields for every article. It largely works for Budapest and for small villages, which gives me confidence somewhat, and I think I am ready to move it to Template: namespace fairly shortly, since of course one does not HAVE to use it!

My next step, probably, is to write documentation for it. Then I will wrap THAT template with another one mapping the Hungarian field names, so that, with a bit of luck, one can simply copy-paste from the Hungarian infobox into new/stub articles on the English wikipedia. Any advice as to whether that is found upon would be appreciated.

A bit of a struggle, which was kinda annoying as I got it up and running fairly quickly and the density thing took ages and ages to sort out. Thanks for everyone's help here. SimonTrew (talk) 14:39, 20 September 2009 (UTC)

This section can go. Thank you all for your help, but the struggle has moved elswehere. Best wishes SimonTrew (talk) 23:57, 1 October 2009 (UTC)

“abbreviation”

• I’m not going to change the column heading “abbreviation” because this page seems to be comprised of transcluded pages and I don’t have the time. Please understand though that unit symbols are not “abbreviations.”

  Here’s the proper terminology:

1. Measures are things like volume, length, temperature, and mass.
2. Units of measure are liter, meter, degree Celsius, the kelvin, ohm, pound, and kilogram
3. Unit symbols are l (or L) for the liter, m for meter, °C for degree Celsius, K for kelvin, Ω for ohm, lb for pound, and kg for kilogram.
4. The value of these two measures: “0.45359237 kg” and “1 lb” are different.
5. The magnitude of these two measures: “0.45359237 kg” and “1 lb”, are identical.

In the metrology world, unit symbols are not called “abbrevations” because they aren’t abbreviations; they are unit symbols. The symbol Ω is not an “abbreviation” for ohm, nor is “lb” an abbreviation for pound. Wheras “imp bbl” (for the Imperial barrel) might seem like it should rightly be called an abbreviation, it isn’t; all these symbols are just that: symbols. Even though the unit symbol °C has a “C” in it, it is not some sort of “ultra-abbreviation” for “Celsius.” Greg L (talk) 21:20, 24 September 2009 (UTC)

I think that is understood by those involved here, but it may make more visual sense to the laypersons who visit the template page than trying to get across the idea of "unit symbols". Don't worry about it too much. — Huntster (t @ c) 04:17, 25 September 2009 (UTC)

• An argument that amounts to “it’s incorrect terminology but everyone here knows that and accepts it and it’s easier to communicate improper terminology to laypersons” is not compelling, Hunster. I hope your answer is not a harbinger that there is some sort of group-think culture here that accepts *wrong* things because “that’s the way its always been done.”

  Perhaps it is understood by all the regulars here that the term “abbreviation” is incorrect terminology. But editors come and go on Wikipedia and newcomers (“laypeople” to use your parlance) who use our templates will understandably be mislead when improper terminology is employed in a centralized venue such as this. Then improper terminology can trickle into the body text of articlespace.

  If the objective is ease-of-understanding to laypeople, that can be just as easily accomplished (and less ambiguously too) with the following:

“ rendered
 symbol ”

Besides making it 110 percent clear that this column heading denotes what the reader will actually see in the rendered output, it has the virtue of using proper terminology.

Unless someone can advance a darn good reason to stick with improper terminology, I’ll get to it this weekend; that is, unless someone has an even clearer (and correct) column heading. Greg L (talk) 16:00, 25 September 2009 (UTC)

Greg, you are not entirely correct in your assertion that these are not abbreviations. Although many would properly be termed as symbols (including those for all SI units), others may now commonly be referred to as symbols, but are actually abbreviations, including your example of lb for pound (abbr. of libra). _wjemather^bigissue 18:17, 25 September 2009 (UTC)

• That wasn’t the “darn good reason to stick with improper terminology” I was soliciting, wjemather. They are “commonly referred to as symbols” because when used in this fashion in metrology—even if a unit symbol originated from an abbreviation of a latin word (like “lb” from “libra” for the pound)— they are still a unit symbol. The same goes for “nautical mile”, which has a variety of real-world unit symbols (M, NM, Nm or nmi); you might assert that some of these “sorta look more like an ‘abbreviation’ than the others.” Nevertheless, if they are being used like a unit symbol in metrology to represent a unit of measure, then are unit symbols.

  You’re quibbling now. Moreover, your acceding the point about how the SI unit symbols are indeed symbols (but some of the non-SI unit symbols are abbreviations), suggests two work-arounds: 1) label them all “abbreviations” because you think at least some are abbreviations, or 2) segregate what you think are abbreviations from what concede are truly unit symbols. Going with either option would be absurd. Greg L (talk) 20:45, 25 September 2009 (UTC)

I was not arguing against change, but your argument contained inaccuracies. I would say the symbol is definitely more appropriate than abbreviation as a general term, but it is still not entirely satisfactory. Is there anything wrong with a heading symbol or abbreviation? _wjemather^bigissue 08:09, 26 September 2009 (UTC)

Symbol/abbreviation is probably best. JIMp _talk·cont 14:24, 26 September 2009 (UTC)

• Then I propose…

“   rendered
  symbol or
abbreviation ”

…since words like “abbreviation” and “symbol” by themselves do not at all communicate the concept of “this is what you get.” Greg L (talk) 16:22, 26 September 2009 (UTC)

Right so how do you propose to change? Change thousands of articles that use abbr instead of your preferred symbol? But Convert works and it is bloody good. Everyone accepts it has its imperfections. But it works and does a good job, so if you insist to change abbr to symbol you break thousands of articles. I can't see that being useful. SimonTrew (talk) 00:03, 2 October 2009 (UTC)

In my haste I am mistaken again. I do not propose to change articles. If we can get consensus on how we put it in the doc, I am more than happy to improve the doc to make it better. Jimp does a great job on these templates and if I can help at all just gnoming on the doc, I am glad to do so. SimonTrew (talk) 00:09, 2 October 2009 (UTC)

This debate tends heavily toward hair splitting. Arguing the difference between an "abbreviation" and a "symbol" is like arguing the difference between a spade and a shovel. It's all a matter of semantics, which vary by region and cultural background. The terms basically mean the same thing, and calling a spade a "manually operated digging implement" doesn't help. You are better off to call it a frigging shovel. RockyMtnGuy (talk) 16:10, 5 October 2009 (UTC)

Torque problem

convert|38|Nm|lbf-ft|abbr=on

in template brackets gives this:

38 N⋅m (28 ft⋅lbf)

Using "ft-lb" instead of "lbf-ft" gives:

38 N⋅m ()

Why are both lbf-ft and ft-lb on the "units supported" list if they aren't?

No signature (talk) 01:01, 25 September 2009 (UTC)

Not sure why it is listed like that, because {{convert|38|Nm|ftlbf}} (38 newton-metres (28 ft⋅lbf)) and {{convert|38|Nm|ftlb}} (38 newton-metres (28 ft⋅lb)) seems to work. If these are what you are looking for, I'll change the documentation. — Huntster (t @ c) 04:23, 25 September 2009 (UTC)

Do not change the documentation. Torque is in the middle of standardization & will be fixed once there is a consensus. Wikipedia talk:Manual of Style (dates and numbers)#Torque measurement standardization 「ɠu¹ɖяy」¤ • ¢  06:26, 25 September 2009 (UTC)

Okay, well, if the currently-listed units don't actually work, some kind of change will need to be made quickly. — Huntster (t @ c) 23:10, 25 September 2009 (UTC)

Well the code is too complex for me to fully understand. I was under the impression Jimp would code it once we have a consensus, which we do have. 「ɠu¹ɖяy」¤ • ¢  17:32, 29 September 2009 (UTC)

I gave up at WP:MOSNUM talk because they constantly are changing it and having battles between themselves, whereas Jimp and others here actually make practical decisions that are helpful to real people, not just going round the houses. So if Jimp says that I believe him, and if I think it is wrong then I tell him, and you know what? If I am right and he is wrong he fixes it. And if I am wrong and he is right he tells me. That is good, all good, cos we all make a better encyclopaedia. SimonTrew (talk) 00:13, 2 October 2009 (UTC)

Yes, I too found that the signal to noise ratio at WP:MOSNUM is extremely poor. I would be inclined to let Jimp do whatever he wants because he appears to know a great deal more about the subject than most of the people attempting to make decisions for him. RockyMtnGuy (talk) 16:25, 5 October 2009 (UTC)

kmbot and htbot replace convert?

What is the purpose of Template:Kmbot and Template:Htbot? They are only used on about 20 or 30 pages, but it appears to be replacing this template for some odd reason. 76.227.79.204 (talk) 19:23, 5 October 2009 (UTC)

Update, I just saw Wikipedia:Templates_for_deletion/Log/2009_August_9, but now they live again? If you read the template source, it has comments referencing an "illegal deletion"? Was there a deletion review? 76.227.79.204 (talk) 19:32, 5 October 2009 (UTC)

This is simple circumvention of the deletion process. If the author feels so strongly about it, he can take it to WP:DRV. I'm in the process of changing the existing instances back to Convert. — Huntster (t @ c) 04:46, 6 October 2009 (UTC)

Some suggestions for changes to the default precision

• The current default method of choosing default precision ("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.") is fine, but I'd change the thresholds to 0.1√10, √10, 10√10 etc.: the current setting yields over-zealous rounding in some common conversions such as inches to centimetres or kilograms to pounds. You'd normally not want to round a value given as integer inches (or kilograms) to the nearest ten centimetres (or pounds). (The reason for this particular threshold of √10 is that the change of precision wouldn't depend on which unit is put first.)

Current behaviour

81 kilograms (179 lb), 82 kilograms (181 lb), 83 kilograms (183 lb), 84 kilograms (185 lb)

Suggested change

81 kilograms (179 lb), 82 kilograms (181 lb), 83 kilograms (183 lb), 84 kilograms (185 lb)

Current behaviour

6 feet 1 inch (185 cm), 6 feet 2 inches (188 cm), 6 feet 3 inches (191 cm), 6 feet 4 inches (193 cm)

Suggested change

6 feet 1 inch (185 cm), 6 feet 2 inches (188 cm), 6 feet 3 inches (191 cm), 6 feet 4 inches (193 cm)

• "Or to two significant figures whichever is the most precise": this rule does counter-balance the shortcomings of the previous one, but sometimes it yields excess precision for no useful purpose. Usually, if the input measure is a rough one, the conversion should be rough, too. Cases in which one significant figure would yield ridiculous low precision (1 mile (2 km)) would be somewhat rare and they could be overridden with the fourth parameter when they occur.

Current behaviour

13 kilometres (8.1 mi), 14 kilometres (8.7 mi), 15 kilometres (9.3 mi), 16 kilometres (9.9 mi)

Suggested change

13 kilometres (8 mi), 14 kilometres (9 mi), 15 kilometres (9 mi), 16 kilometres (10 mi)

Current behaviour

3 miles (4.8 km), 4 miles (6.4 km), 5 miles (8.0 km), 6 miles (9.7 km)

Suggested change

3 miles (5 km), 4 miles (6 km), 5 miles (8 km), 6 miles (10 km)

• "An exception to this is temperature wherein the conversion will be rounded either to precision comparable to that of the input value or to that which would give three significant figures when expressed in kelvin, whichever is the most precise." I can't see the point of this. It is usually fine, but is ridiculously precise for small temperature differences (as opposed to absolute temperatures) and for some particularly cold temperatures. I'd remove this exception, too.

Current behaviour

A 9 °C (16 °F) increase in temperature; −183 °C (−297.4 °F)

Suggested change

A 9 °C (16 °F) increase in temperature; −183 °C (−297 °F)

What do you think? I'm advertising this at WT:MOSNUM, WT:MOS, and to village pumps. --___A. di M. 20:59, 12 September 2009 (UTC)

• I read your examples in full and I agree with what you are proposing 110 percent (100 cU). Greg L (talk) 21:17, 12 September 2009 (UTC)
• Nice. Tony (talk) 01:45, 13 September 2009 (UTC)
• Excellent suggestion, superbly presented. I support this fully.—DCGeist (talk) 02:33, 13 September 2009 (UTC)
• Strongly support first suggested change, i.e. changing 0.2 and 2 to 1/√10 ≈ 0.316 and = √10 ≈ 3.16 — in fact that's what first brought me to this page back in July. Neutral on second. Support third, mainly on grounds of simplicity of comprehension and documentation. On first two, see also Template talk:Convert/Archive July 2009#Suggestions about default precision (ctd). Qwfp (talk) 09:49, 13 September 2009 (UTC)

• I think we need more examples with different scales (different dimensions does not really matter, I suppose). Really I think hainy just ft-and-in to and from cm, km to and from miles, and kg to lb, does not really give me an appreciation of how it would behave with, say, meters to inches, or nautical miles to metres. I'm not disagreeing with the proposal, but can we make the examples a bit more definitive when the source and destination units are on different scales? (I'm assuming that for whatever reason this may be reasonable in some articles, if in one system or another traditionally different scales are used. For example, "a {{convert|19|in|mm|adj=on}} rack" -> "a 19-inch (480 mm) rack". —Preceding unsigned comment added by SimonTrew (talk • contribs) 07:27, 13 September 2009

• Nautical miles to metres and metres to inches would behave the same way as today, as the significand of the conversion factor isn't between 2 and √10; except that there would not be the exception forbidding rounding to one sigfig. (But why would anyone want to convert nautical miles to metres rather than kilometres?) As for 19 inches to millimetres, integer inches would round to the nearest centimetres so it'd be 480 mm with the proposed default precision (incidentally, due to the at-least-two-sigfigs rules, this is also the current behaviour of the template for lengths between 100 and 1000 millimetres); but this is a measurement which is precise by design, so I would consider overriding the default precision by hand with the fourth parameter, so to have a more precise conversion, i.e. 19 inches (483 mm) or maybe even 19 inches (482.6 mm). (For measurements which are not precise by design, I would normally convert inches to centimetres, not millimetres.) --___A. di M. 12:46, 13 September 2009 (UTC)

Then (as far as the proposal goes) I think it should have said so explicitly. I took the fact that there were multiplications by factors of ten to be a subset of a continuing series.

I don't know why someone would want to convert nautical miles to metres, but was trying to come up with reasonably realistic examples. As you say (and I hope I implied but admit I did not make clear) where precision is important by design (or because e.g. millimetres are preferred in that field to centimetres, as is typically the case in engineering) it can be overridden. With the 19" rack example, I think in fact the measure is in millimetres and 19" is an approximation that is just used for convenience without any intention of it being taken as exact.

The 19-inch rack article provides interesting examples of a queasiness with conversions, for example some obviously metric measures such as 1000 mm are converted to quite precise Imperial/US Customary measures, whereas others such as 1 in are rather less precise (to 25 mm); a front-panel height of 44 mm is reduced by 1/32-inch [sic] (0.31  mm) to make it 43.7 mm, which is patently off by 0.01 mm and close enough in the text to be easily noticeable, so I'd argue either the conversion from 1/32 in is over-precise or that from 1.719 in to 43.7 mm not enough so. I would argue that changing the precision of conversions like this (leaving aside the somewhat erratic formatting) is quite likely to break this article. Now, it may not; I may have chosen an article where it happens to work by luck or judgment, but I am sure you see my point that there must be many other articles like this that could be easily broken.

So that is really my point, how changing defaults can break existing articles that rely on them. I think this has not been considered enough, both on this proposal and others. If a change breaks existing articles, that has to count against it (though not necessarily enough to vote it down). In my opinion there is simply sometimes too much tinkering without adequate consideration of the existing WP corpus. For example, I would prefer always to convert to mm rather than cm; there is no point arguing the whys and wherefores of that here, but the fact that your and my opinion differs I think shows that there is unsafe simply to assume consensus, and that if I rely on the default being one or another, changing it will break the article. If one accepts having defaults at all, they should be very stable. SimonTrew (talk) 22:08, 13 September 2009 (UTC)

Are there cases in which the current behaviour is OK and the proposed change will be highly undesirable? If so, we can fix them by hand before changing the template. (For example, we might request a watchlist notice advertising that "On October 1, the default precision of Template:Convert will be changed; see Template:Convert/New default precision for details. Consider manually specifying the desired precision for conversions which depend on the current default.") In any event, in a case where there's a particular reason to desire one particular precision no matter what, I'd always specify it by hand even if it happened to coincide with the default.

On the other hand, I think that's going to be far, far rarer than people just entering "John was 6 feet 1 inch (185 cm) tall", saving without checking, and getting a conversion which is off by almost five centimetres. --___A. di M. 09:50, 14 September 2009 (UTC)

Reject change. We might as well not have defaults at all if they change under editors' feet (or no editor is watching the article). I'd be more inclined to accept removing the defaults altogether (with a bot made first that runs through the WP corpus inserting the current defaults.) SimonTrew (talk) 08:06, 16 September 2009 (UTC)

• Support change so long as no significant counter examples to the benefits of the change can be produced. The height example is compelling. Nice work. Plastikspork _―Œ^(talk) 21:17, 14 September 2009 (UTC)

Comment I don't understand why you say the height example is compelling; since you support. You must be taking it a different way from me. I think the record will show, not just here but on actually editing articles, I am a great fan of this template, and it is used very inconsistently on that article, or indeed that many conversions are hard-coded rather than use {{convert}}. This points to the convert doc being somewhat lacking – and I am happy to take on improving it while the convertbunnies get on with the hard work of making it better, if they should wish – I do think Human height might serve as a good example of How Not To Do It and if the proposed change works with that, in statu, then I could be swung round to accepting it. It seems archetypal in tht it is specifically to do with units of measure (and fails in its duty there), we should not change the article arbitrarily inserting {{convert}}, but see if it makes sense after the proposed change. I think if that passes and makes sense, it's not a bad test. Some of the chemistry articles I have done e.g. caramel color or Coca-Cola formula might also be useful as a test of it not breaking existing articles. These both use {{convert}} rather heaily, my being rather a fan of it. 81.102.135.119 (talk) 07:20, 18 September 2009 (UTC) (It's SimonTrew I didn't log in but don't want to lose it after preview)

Maybe you've misread the proposal. 6 feet 1 inch (185 cm) is the current default behaviour; 6 feet 1 inch (185 cm) would be the default if the change were implemented. (Or do you think it is appropriate to round people's height that much? No-one in a metric country would do that, unless giving an eyeball estimate; they'd say "one metre eighty-five" even if it might be closer to eighty-four or to eighty-six.) --___A. di M. 11:06, 18 September 2009 (UTC)

Right, and this is part of the reason why may people just use {{height|ft=6|in=1}} which produces 6 ft 1 in (1.85 m). The other reason is that it's shorter than writing {{convert|6|ft|1|in|m|abbr=on}} which produces 6 ft 1 in (1.85 m) or {{convert|6|ft|1|in|m|2|abbr=on}} which produces 6 ft 1 in (1.85 m). Plastikspork _―Œ^(talk) 21:22, 18 September 2009 (UTC)

The higher we bump the bar up the more false precision we introduce. Currently the cut-off is two, the suggestion is to make it root three; the only way to eliminate false precision is to use one. Of course, avoiding false precision is only one issue; we have to consider introducing inaccuracy. This delicate balance is not done justice by flat rate such as two or root three. JIMp _talk·cont 10:55, 19 September 2009 (UTC)

Agree 'bout "delicate balance", and this is why the default can be overridden; but I think this proposed change would give a reasonable default in more cases than the present behaviour. Usually people in metric countries give their heights to within a centimetre, even if they don't really know it that precisely. (Matter of fact, it can't even be defined that precisely, because staying in bed or walking for a few hours will temporarily increase or decrease your height by more than 5 mm.) And I suspect that, similarly, people in imperial countries give their weight to within a pound (even if their weight varies more than that, as they drink and piss more than one pound of water every day). The only way to be rigorous w.r.t. precision and accuracy is to explicitly state the uncertainty, rather than relying on the number significant figures; but that is only practical in very advanced topics, and would be ridiculous for most everyday measurements. The false precision caused by converting inches to centimetres and not rounding to the nearest 0.1 metres is far, far less ridiculous than that caused by 6 miles (9.7 km). The former is an error of 1.27 units in the last place (assuming that the height in inches is actually accurate to within half a inch); the latter is more than 8 ulp. --___A. di M. 12:04, 19 September 2009 (UTC)

OK, there seems to be nearly unanimous consent. Now normally I'd use {{editrequested}}, but I have no idea of which particular edit should be made to implement this, and I guess that a random admin coming there from the list of requests wouldn't know, either. Who has a good grasp of how the template works? --___A. di M. 09:56, 23 September 2009 (UTC)

Is there anybody out there? --___A. di M. 12:13, 25 September 2009 (UTC)

Interesting discussion; I was just about to ask a similar question. Here are some metre–foot examples, surely one of the most common conversions:

• 36 metres (118 ft) 37 metres (121 ft) 38 metres (125 ft)

I think that is daft, especially where such values appear next to each other in a text. I do realise there is a manual fix, using the sigfig parameter:

• {{convert|36|m|ft|sigfig=3}} {{convert|37|m|ft|sigfig=3}} {{convert|38|m|ft|sigfig=3}} yields:
• 36 metres (118 ft) 37 metres (121 ft) 38 metres (125 ft)

but editors shouldn't have to do that. On the other hand, the template should not convert 1 mile into 2 km as a default. I like having a decimal in the conversion values for integer miles or kilometres. JN466 12:20, 5 October 2009 (UTC)

(edit conflict) The position of the last significant figure shifts back by one: it is the "units" place in the source value and the "tenths" place in the conversion. As for the second issue, a compromise would be allowing one sig. fig. unless that single sig. fig. would be (say) 1, 2 or 3. That way 1 mile would convert to 1.6 kilometres but 15 kilometres would convert to 9 miles. --___A. di M. 12:28, 5 October 2009 (UTC)

I think 2 miles should be rendered as 3.2 km. Could we say something like "the converted value should always be more precise than the original value by adding another decimal (or the next smaller power of ten) on the right, UNLESS this would lead to a figure with more than 3 significant digits"? I think this would fix the examples in your first group, as well as the ones I gave below. --JN466 12:41, 5 October 2009 (UTC)

With what I suggest, 2 miles would be 3.2 km, but 3 miles would be 5 km. If I understand your proposal correctly, 93 miles would convert to 57.8 km, which is excessive. (Replacing "more than 3" with "more than 2" would essentially be equivalent to the current behaviour, AFAICT.) ___A. di M. 12:50, 5 October 2009 (UTC)

93 miles would convert to 149 km. However, 33 miles, say, would convert to 53.1 km, which I agree is a bit daft.

I don't think I understood your "unless that single sig. fig. would be (say) 1, 2 or 3" correctly. --JN466 12:59, 5 October 2009 (UTC)

Current behaviour, I believe, is that there will always be at least 2 significant digits in the converted value. --JN466 13:01, 5 October 2009 (UTC)

All right. My proposal is that you round according to the proposed rule (like the current basic rule, except with 3.16 instead of 2), but then if you end up with one significant digit, and it's 1, 2, or 3 (i.e. you're rounding a number between 0.5 and 1.5 to 1, a number between 1.5 and 2.5 to 2, or a number between 2.5 to 3.5 to 3, or one of these multiplied by a power of ten), then you add another figure. Anyway, the mechanism of the basic rule works according to the position of the last significant figure, not the number of them, so 93 miles converts to 149 km anyway. (The conversion is not between 2 and 3.16 and the number of significant figures isn't less than three, so none of our proposals would change that.) ___A. di M. 13:11, 5 October 2009 (UTC)

Thanks, I understand what you mean now. This would mean abolishing the "at least 2 significant digits" rule for cases where the single significant digit is between 4 and 9, based on the rationale that 0.1 would be such a small percentage of a value between 4 and 9 as to make little difference. So 3 miles would be 5 km, which sounds okay; but likewise, 3 in would be 8 cm, rather than 3 inches (7.6 cm) as it is now. I think on the whole I prefer to keep the minimum two significant digits, but I really dislike the default setting that gives us fuzzy conversions like

• 81 kilograms (180 lb), 82 kilograms (180 lb), 83 kilograms (180 lb), 84 kilograms (190 lb)
• 6 feet 1 inch (190 cm), 6 feet 2 inches (190 cm), 6 feet 3 inches (190 cm), 6 feet 4 inches (190 cm)
• 36 metres (120 ft) 37 metres (120 ft) 38 metres (120 ft)

as default results of the template. --JN466 18:44, 5 October 2009 (UTC)

(ec) Also compare the following:

• 6 feet 1 inch (185 cm), 6 feet 2 inches (188 cm), 6 feet 3 inches (191 cm), 6 feet 4 inches (193 cm)
• 3 feet 1 inch (94 cm), 3 feet 2 inches (97 cm), 3 feet 3 inches (99 cm), 3 feet 4 inches (102 cm)
• 3 feet 5 inches (104 cm), 3 feet 6 inches (107 cm), 3 feet 7 inches (109 cm), 3 feet 8 inches (112 cm)

It does not make sense that as soon as we go beyond 100 cm, our conversion precision drops by a full order of magnitude. --JN466 12:31, 5 October 2009 (UTC)

Based on vast experience with automatic rounding algorithms, I would say that it is amazing that the Convert template works as well as it does. However, no rounding algorithm is perfect and all will produced unexpected results under certain circumstances. Editors should be warned to adjust the precision as necessary, because sometimes it will be misleading. Unfortunately, most people don't understand significant digits. For instance, many of you will remember the value usually given in the U.S. for human body temperature: 98.6 °F. In actual fact, that is an exact conversion of the metric value, 37 °C. If researchers had actually done the studies in °F, they probably would have come up with a value of 98 °F because 1) it only has two digits of precision, and 2) the average human body temperature is a bit less than 37 °C. However, 98.6 °F sounds so much more accurate and scientific. Remember, real scientists don't do Imperial units. RockyMtnGuy (talk) 16:56, 5 October 2009 (UTC)

I agree with that; that's why you can override the default. But, given that the default is most likely to be used for "ordinary" situations, what about one which makes sense in as many ordinary situations as possible? The perfect solution fallacy is no good reason not to try and improve something. ___A. di M. 10:04, 6 October 2009 (UTC)

Volume/second flow

In Rivière des Prairies generating station ~ 1,000 m³/s (1,308 cu yd/s) or ~ 1,000 m³/s (35,315 cu ft/s), would that be feasible or does it already exist? Or would this have to do ~ 1,000 m³ (1,308 cu yd)/sec. Peter Horn User talk 14:40, 25 September 2009 (UTC)

Whoopy, the second one already exists!! Peter Horn User talk 14:43, 25 September 2009 (UTC)

38,000 US gallons per minute (2 m³/s) What about any one of the following:

• 38,000 usgalpmin
• 38,000 US gallons per minute (2.4 m³/s)
• 38,000 US gallons per minute (2.4 m³/s; 32,000 imp gal/min)

• 38,000 USgalpmn
• 38,000 USgal/mn
• 38,000 USgal/mn

etcetera. Peter Horn User talk 23:37, 1 October 2009 (UTC)

Use USgal/min or U.S.gal/min

• 38,000 US gallons per minute (2.4 m³/s)
• 38,000 U.S. gallons per minute (2.4 m³/s)

JIMp _talk·cont 20:30, 6 October 2009 (UTC)

Template creep has km/miles using 13 to 26 templates

In analyzing the actual performance of T:Convert in hundreds of articles, I have noticed that the template-creep for converting km to miles has reached 13-to-26 templates invoked for each conversion, depending on rounding. It is possible to convert km/miles with rounding, abbreviations, slashes, and adjective-hyphen using only 1 template. Before it was deleted, Template:Kmbot demonstrated that the functionality of T:Convert for km/miles could be streamlined to be performed within just 1 template, while allowing other rare conversions to use the current 13-to-26 nested templates. I have restored that deleted template under User:Wikid77/Template:Kmbot for comparisons and proof-of-concept. The ability to handle km-to-mile conversions using a single template is not just a hypothesis, it was shown to be true all during 2009, by the workings of Kmbot. Naturally, because T:Convert performs a myriad of other conversions, plus the rare range-conversions, it could be expected to have several bugs and rounding problems, which are more difficult to fix, because it doesn't just use 1 streamlined template, but rather, {{Convert}} invokes 13-to-26 templates which might be the source of any of those bugs and more. As template-creep expands, it becomes more difficult to prove a complex template is reliable. -Wikid77 (talk) 08:54, 6 October 2009 (UTC)

convert cubic metres to barrels of petroleum, etc

Geography of Lithuania 1,600,000 m³ (56,503,467 cu ft) (10 million barrels) or 1,600,000 m³ (2,092,721 cu yd). Can some one construct the following 1,600,000 m³ () or tell me in what form it already exists? I'll be looking here. Peter Horn User talk 14:20, 6 October 2009 (UTC)

Use Moilbbl (million oil barrels).

{{convert|1600000|m3|Moilbbl}} → "1,600,000 cubic metres (10 Mbbl)"

JIMp _talk·cont 19:22, 6 October 2009 (UTC)

Any way to use open-ended ranges?

I'm working on a list of mountain peaks at Stuart Range#Partial list of peaks and my source only lists minimum elevations for some peaks (e.g. Dragontail Peak, 8840'+) I'm wondering if there is, or could be, a way for this template to take an open-ended range like this as a parameter. I'm no expert, but I tried to read the page carefully and couldn't figure out a way to do it, but I'm guessing it wouldn't be that hard to implement. Thanks! W.stanovsky (talk) 05:52, 6 October 2009 (UTC)

As in "8840 meters or higher"? No, the template doesn't allow open-ended ranges, but if that is what you are looking for, just use "{{convert|8840|m}} or higher". Though, I'm not entirely sure what you are looking for here. — Huntster (t @ c) 06:41, 6 October 2009 (UTC)

Yep, you understood me correctly. In sources and lists that I've looked at though, "8840+" seems to be pretty standard notation in this situation so it would be nice if there were a way to preserve it rather than writing out "or higher" each time. If it can't be done with though, I'll use one workaround or another. Thanks! W.stanovsky (talk) 02:41, 8 October 2009 (UTC)

Google converts to world-standard amounts

07-Oct-2009: A quick way to get real conversions (and hard-code numbers into an article) is to use Google Search as follows:

• enter: 6 ft 1 in in cm - (be sure to put both "in in" for "inch in")
• enter: 6 ft in m - (to get meters)
• enter: 200 m in ft - (to get feet)
• enter: 300 km in mi - (to get miles)

I know it might seem highly extravagant to use a 4-billion-webpage search to get a simple calculation, but it is a quick answer when very busy. The Google conversions are correct (duh), so they are the world-standard amounts that Convert should be showing when fixed: 300km will be 186 miles. -Wikid77 (talk) 14:19, 7 October 2009 (UTC)

Moving to smart-conversion templates

The reason that I had created Template:Kmbot was to simplify the entry, as just the kilometers, and automatically choose the output precision for kilometers (not lightyears). There should be many templates to handle the various special-subject conversions, such as speed-limits. Perhaps "Convert" should be renamed as "Astroconvert" since it focuses on the rounding of astronomical amounts, give or take a million. Formerly, Wikipedia had dozens of templates that accurately converted amounts for various measurements. However, as those other templates were stomped out and obliterated, there was no longer a choice as to which template to use for accurate results. Formerly, many people saw "32m as 105ft" but eventually Convert came to declare "32m is 100ft" (in wiki-math?) and by that time, the whole of Wikipedia was fatally wikied. Many American schools totally banned the use of Wikipedia, thank God. Who said, "Don't put all your eggs in one basket?" Consequently, now, thousands of articles have the bizarre rounding, where "32m is 100ft" (etc.), and there is no alternative. If you create a fantastic conversion template, it will be deleted quickly, so you must get some assurance that accuracy will be tolerated, even if as a variety of good conversion-templates, rather than all "32m=100ft" and other horrors. Wikipedia is incapable of doing any single thing "right" so there must be several alternatives to avoid a single point of failure. There must be several conversion templates to allow some, at least, to be correct. -Wikid77 (talk) 17:44, 7 October 2009 (UTC)

The rounding is based on mathematical principles which is about as smart as you should expect for a template. These are documented on the page along with ways to arrive at alternative levels of rounding. JIMp _talk·cont 19:14, 7 October 2009 (UTC)

• I do understand that there is a pattern being followed, but it defaults to results contrary to world-standard conversions. -Wikid77 (talk) 02:33, 8 October 2009 (UTC)

Convert is only as smart as the person using it. If you want more than the default precision, you have to ask for it - e.g. specifying "sigfig=3" gives 32 m (105 ft). The assumption it makes is that if you only put in 2 significant figures, that's all the significance there is in the number. If that's an incorrect assumption, you have to change it. It can't read your mind. RockyMtnGuy (talk) 20:40, 7 October 2009 (UTC)

• There is the current ongoing discussion to make Convert "smarter": that the output amounts must reflect not only the conversion of amounts, but also the conversion of precision, thus a 2-digit "32m" becomes a 3-digit "105ft". The method for implementing converted-precision is not obvious to a 6th grader, so that's why the extended discussion above: we want to make Wikipedia easy for a teenager to use, not just "rocket scientists".

Wikid77, the whole reason Convert was created as it was, is because there used to be a huge variety of templates that each provided calculations for their individual types...ft to m, m to ft, mi to km, etc etc. Typically one per conversion or conversion set. This caused significant problems in lists and long complex articles as the transclusion size quickly rose above server limits and after a certain point in an article, templates simply broke. The way Jimp set up Convert's current incarnation solves this problem by maintaining a very minimal footprint. If we went with your setup, given that the templates are significantly larger than the old ones that were used, the problem would become even worse. Also, given what you wrote above, you seem to have some deep distaste or even hatred for Wikipedia...perhaps you'd be more happy at a place with (admittedly) higher standards for inclusion, like Citizendium? To clarify, I intend absolutely no malice in this...it is just an observation. — Huntster (t @ c) 01:15, 8 October 2009 (UTC)

• Hunster, Thank you also for taking the time to respond: I've been here the whole time, and I realize there were "too many" templates before, but having just 1, now, seems to be too few. The current MediaWiki software can now handle hundreds of templates per page, as noted below. -Wikid77 (talk) 02:33, 8 October 2009 (UTC)

OK, we get it. Your template got deleted. You're not happy. If you can't be constructive, don't waste your time or that of others. (And RockyMtnGuy and Huntster are spot on.) Orderinchaos 01:47, 8 October 2009 (UTC)

• Please be patient: the world is laughing at Wikipedia, and chasing users away just sends the message that academic experts are not welcome in this playpen. -Wikid77 02:33, 8 October 2009

What does this have to do with academic users? I learned significant figures in Year 11 Physics, some 15 years ago. The concept is generally well understood amongst academics. Orderinchaos 06:11, 8 October 2009 (UTC)

Recapitulating my suggestions

• Replacing "Default rounding" with:

  If neither the desired precision nor the desired number of significant figures are specified, the conversion will be rounded either to a comparable precision as the input value (the number of decimals remains the same if the conversion is a multiplication by a number between √10/10 and √10, is decreased by 1 if the factor is between √10 and 10√10, etc.), except when this would cause the conversion to be given with one significant figure equal to 1, 2, or 3, in which case an additional significant figure is used. An exception to this is conversion from metres to feet and vice versa: a value given to within 0.1 metres is converted to within 0.1 feet and vice versa, a value given to within 1 metre is converted to within 1 foot and vice versa, and so on.

• Modifying the count of significant digits in the input so that in numbers such as 30,000 it assumes that the first zero is significant.
• Adding "approx." or "~" before conversions ending with a non-significant zero (so that {{convert|40000|km|mi|-1}} would yield "40,000 kilometres (~24,850 mi)". With the current setup, the reader would be very likely to assume that the conversion was rounded to one mile and not to ten miles.

___A. di M. 15:04, 7 October 2009 (UTC)

• I agree the current "fuzzy-math" conversions should be tilde-branded as "~250 mi". I think "~" looks more professional than saying "wikifuzz 100ft" or "wiki-so-so 250 mi" -hehe). But we need to alert people about these bizarre conversions. Meanwhile, precision will still be wrong because the magnitude of the number must be assumed to be important: a value of 200 would be 3-digits, not 2 hundreds rounded. If you want one significant digit, make the writer enter "2" hundreds, because "200" would be 3-digit precision for mid-level magnitude. If someone "puts 2,000 meters is 2 kilometers" then count all 2000 of those meters. Make people specify 5,000 as unusually rounded with sigfig=1 or such. When the dust settles, it will be amazing how many correct conversions will be made because 99.999% of Wikipedia text uses precise measurements for the mid-level numbers. The current astro-rounding could be allowed to resume after, perhaps, 10_000, based on the magnitude. Otherwise, every town that happens to have altitude x,x00 will get rounded to some other hilltop height. The abstract-math idea that zeroes are always estimated (as non-precise) denies the fact that most Wikipedia articles are based on real measurements, not people saying that all towns over 151km are roughly 200km away. Why does magnitude-based rounding work so well? ...because most of the mid-level numbers are precise, down to the last zero. Rounding must be based on the context, and for Wikipedia that context is real measurements, not abstract estimates. -Wikid77 (talk) 17:58, 7 October 2009 (UTC)

If the trailing zeros are significant, you have to adjust the significance to reflect that. As an example, when they first measured the height of Mount Everest in 1865, they found it was 29,000 feet, exactly. Since people would assume that they had rounded it to the nearest 1,000 feet, they changed the number to 29,002 feet to give an indication of the actual precision (commonly, the last digit is meaningless noise). More recent measurements put the height at 8,848 metres (29,029 ft) - and still rising. The last digit is still meaningless noise. RockyMtnGuy (talk) 21:05, 7 October 2009 (UTC)

Hey, that might be an idea, although it might be difficult to implement. Assume that "40000" has five significant digits, "40 thousand" has two, "40.0 thousand" has three and "0.04 million" has one. (Same with "hundred" and "billion".) This matches what is done in real world: "Japan has a population of 128 million" has three sigfigs, "the grant is 10,000,000 Swedish kronor" has seven. ___A. di M. 09:51, 8 October 2009 (UTC)

It's very rash to assume assume that "40,000" has five significant figures, or only one. If you investigate the value of 40,000 that people here mistakenly took as the exact value for the circumference of the equator, you find that the actual value is 40,075.16 kilometres (24,901.55 mi). If you are editing an article, you should know how many significant figures there are, and put it in the template - e.g. 40,000 kilometres (24,900 mi) versus 40,000 kilometres (24,855 mi) or 40,000 kilometres (25,000 mi). The problem here is that many people don't understand the subject matter and assume that there is far more accuracy in the numbers they are quoting than there really is. RockyMtnGuy (talk) 16:45, 8 October 2009 (UTC)

The current WIKIPEDIA-2 can handle 600 templates

08-Oct-2009: Prior to 2008, Wikipedia articles had to avoid using too many large templates, due to the fact that all documentation, comments & sections were expanded into the formatted article, for each (and every!) time a template was used. My complex 3-D, polar mapping templates (for putting lat/longitude on a conic projection) completely exceeded the old MediaWiki parser, for the transclusion expansion limit, but those days are over. As of January 2008, we have been running "WIKIPEDIA-2 (The Next Generation)" with the recursive-descent parser & true sections: now, all HTML comments are really bypassed and false-branches in templates are really omitted when generating a formatted article page. No longer should people be afraid to use 600 templates (on a rarely read page): the current MediaWiki software is beginning to have the sophistication of 1970s professional software, so we can start "thinking big" about having smart, multi-conditional templates, with dozens of logical branches. It is possible, now, to have smart templates which consider numerous possibilities. -Wikid77 02:33, 8 October 2009

• On Oct. 23 (2009), I used a text editor to stack a page with 640 temperature-range conversions, and the entire page formatted ok during edit-preview. There were 640 variations of {{convert|33|to|66|F|C|1}}: 33 to 66 °F (0.6 to 18.9 °C). -Wikid77 08:26, 23 October 2009

How exactly does having to know the niceties of 600 templates assist usability, which is identified as possibly the single biggest entry/growth barrier for Wikipedia? Orderinchaos 06:12, 8 October 2009 (UTC)

• People were listing conversions in rarely-read tables, of several hundred rows. The tables were excellent for those rare, special viewings. Plus, it was easy to create them by just using some home-made conversion templates for each entry in the table (rather than hard-code conversions), but the Wikipedia parser could only handle, perhaps, 200 streamlined templates on a page (perhaps 20 medium-size templates). A novice user could have coded 300 entries, showing km-to-miles, but it was too big. They experienced "bad usability": having to hand-edit some of the rows to literally list km/miles and not use so many templates, plus time to experiment as to how many rows could remain with km-to-miles templates. Now novice users can code hundreds of templates into a table, plus those templates could be made smarter to report when a novice user had made a mistake: "Row 184 has 2 decimal points in a number". We are able to look through user input & report dozens of invalid codings, without fear that all those error messages will exceed the article-formatting space. How usable? Now, we can validate hundreds of option-values to report coding errors to novice users. In 2007, that would have exceeded the space allowed for formatting an article, but now we can validate hundreds of option-values on hundreds of rows: more than a thousand times greater capacity. -Wikid77 (talk) 09:35, 8 October 2009 (UTC)

It doesn't have anything to do with the number of templates transcluded. JIMp _talk·cont 20:46, 8 October 2009 (UTC)

Yet another 3 way conversion

Geography of England 24 mi or 38.6 km or 20.9 nmi instead of 24-statute mile (52 km or 28.1 nmi). 28.1 nmi or 52.0 km or 32.3 mi is already possible. Peter Horn User talk 15:05, 8 October 2009 (UTC)

Interesting, I just noticed that there is a 1.7-mile discrepancy! Peter Horn User talk 15:09, 8 October 2009 (UTC)

In Metolius River#Headwaters, Any way to handle these?

• 190 m³/min (6,700 ft³/min or 50,000 gallons per minute)
• 2,300 m³/min (80,000 ft³/min or 600,000 gallons per minute)

Peter Horn User talk 17:21, 8 October 2009 (UTC)

More oddball flow rates

In Totley Tunnel

• 2,250,000 gallons per day (7,100 L/min)
• 5,000 gallons an hour (380 L/min).

Peter Horn User talk 19:10, 8 October 2009 (UTC)

More conversions requested

For Woodhead Tunnel#Woodhead 1 & 2 3 miles 13 yards (4,840 m),does not quite work yet, instead of 3 miles 13 yards (4,840 m) (5,293 yards (4,840 m)). Sample 3 feet 3 inches (0.99 m) Peter Horn User talk 22:05, 8 October 2009 (UTC)

For Fire sprinkler system#Operation

• 0.015 m³/s (0.53 cu ft/s), 0.015 m³/s (240 US gal/min), 900 litres per minute (200 imp gal/min; 240 US gal/min) or 900 litres per minute (240 US gal/min) instead of 900 liters/min (250 US gallons/min)
• 100 US gallons per minute (380 L/min) or 100 US gallons per minute (0.0063 m³/s)

Peter Horn User talk 23:27, 8 October 2009 (UTC)

Installing fix and new FAQ rounding text

The amounts displayed by Convert will no longer seem unusual, with the upcoming change to Template:Convert/round to use world-standard amounts (the updated Convert would show "32 m (105 ft)" [not 100 ft] or "84 kg (185 lb)" [not 190 lb]. The newly inserted coding will be similar to:

• +{{#ifexpr:{{{2}}}/{{{1}}} > 2.2|<!--then-->1|0}}

That adjustment in precision will fix the default rounding.

So, now the problem is: What wording to display at the top of this talk-page for the FAQ issue. I suggest the following new wording:

Q: When using {{convert}} why does the answer not seem right sometimes?

A: Try again. Formerly, Convert had rounded some values by 10-unit increments, but has been changed to display world-standard results, as the default values. However, if you need to change from the default output precision, see the "Rounding" section of the template documentation.

Alternatively, should the wording state, "why did the answer not seem right"? With that wording, we wouldn't say, "Try again" which might seem rude to some users. As a 3rd alternative, should the FAQ just be some totally different issue? ...because most results from Convert will seem normal, compared to the world-standard results. Rather than dwell on the "answer not seem right", should we just focus on some other FAQ as the top text of the talk-page? Any other suggestions? -Wikid77 (talk) 22:43, 8 October 2009 (UTC)

Yeah, I'm not sure that the change should even be addressed. I'd say keep it in the same tone it already is, and address why some people may still not see exactly what they expect, rather than what peopled used to see. Does that make sense? And if there is something else that needs to be addressed in the FAQ, there's no reason for it to not be included as well. (we're not limited to one issue there ;) — Huntster (t @ c) 02:58, 9 October 2009 (UTC)

• That sounds good. I was thinking to include "Q: What are all the valid units, like: kg, lb, km, mi?" which seems like a common question where people didn't find the list of units. -Wikid77 (talk) 10:15, 9 October 2009 (UTC)

• Very much agreed. With the short list at the bottom of the main page, I'd imagine many folks don't know it's there. I would actually suggest doing away with the short list, and prominently linking directly from the top of the documentation page. I have half a mind to try and completely rewrite the doc page to make it more reader-friendly, but that's something I'll have to find time to work on. — Huntster (t @ c) 23:05, 9 October 2009 (UTC)

How is the code supposed to work exactly? My wild guess is that it increases the precision by one digit if the conversion factor is more than 2.2. This would leave conversions with factors between 2 and 2.2 (if there are any) with a lower precision. Also, I'm not sure one would want to increase the precision all the way up to ten (as a consequence, converting e.g. 123 yards would yield a conversion rounded to 0.1 metres, or converting 123 pounds would be rounded to 0.1 kilograms. A saner threshold would be something like 3.3 (just high enough to convert integer metres to integer feet). Anyway, your proposed way to do that looks too much like a kludge to me; better is finding the place where the threshold of 2 is coded (wherever it is) and increase it to 3.3. ___A. di M. 08:50, 9 October 2009 (UTC)

• Okay, I will check increasing that 2 to 3.3, so that conversions 10x times higher would not be changed. -Wikid77 (talk) 10:15, 9 October 2009 (UTC)

Width by Height with ranges

Is it possible to convert something like (189.2–190.5) cm x (137.2–148.2) cm using this template? I have a set of paintings with varying widths (from 189.2 to 190.5 cm) and heights (from 137.2 to 148.2 cm) which I'd like to have automatically converted. bamse (talk) 18:53, 8 October 2009 (UTC)

Exactly what you are wanting is not currently possible. You might try something like "{{convert|189.2|-|190.5|cm|abbr=on}} by {{convert|137.2|-|148.2|cm|abbr=on}}", which would render as "189.2–190.5 cm (74.5–75.0 in) by 137.2–148.2 cm (54.0–58.3 in)". — Huntster (t @ c) 03:02, 9 October 2009 (UTC)

Thanks. I was hoping for a rendering like: (74.5–75.0 in) by (54.0–58.3 in) using a syntax like "{{convert|189.2|-|190.5|x|137.2|-|148.2|cm|abbr=on}}"". It seems I'll have to convert manually. bamse (talk) 08:57, 9 October 2009 (UTC)

Fathoms could allow abbreviation: fath

I noticed that "fathoms" keeps the full word "fathom" rather than using abbreviation "fath". Was that to avoid problems with alternate abbreviations, such as "fthm"? I realize each abbreviation requires adding another subtemplate to handle each conversion. Is anyone aware of the decisions about fathoms? -Wikid77 (talk) 13:56, 9 October 2009 (UTC)

Fix for rounding - rationale

This section explains the reasoning behind the proposal to alter the default rounding of the output amounts displayed by Template:Convert. The consensus forum for collecting comments, is below, under section: "#Comments on proposed rounding". The rationale is presented here, in detail, for the record, although most of the reasoning has already been discussed as prior talk-page topics. The plan is to increase precision by +1, for conversion factors greater than 2, as shown in the sample tests below.

Rationale

Numerous people over the past months have noted that the default rounding was producing unusual numbers. However, the concerns of 10 or 20 people must also be backed by strong evidence, to justify making a change. Consequently, to show the rounding will give better results, there are 3 sanity tests being used (reconvert-test, references-test, and bounds-test):

1. Convert-Reconvert test - A simple test, of the converted results, is to convert an amount, then reconvert back to the precision of the original units: the final result should be the same number (or close) to the original amount converted:

	Proposed rounding: 32 m (105 ft) ==> 105 ft (32 m),	33 m (108 ft) ==> 108 ft (33 m)
	Current rounding:     32 m (100 ft) ==> 100 ft (30 m),	33 m (110 ft) ==> 110 ft (34 m)
	Proposed rounding: 83 kg (183 lb) ==> 183 lb (83 kg),	84 kg (185 lb) ==> 185 lb (84 kg)
	Current rounding:     83 kg (180 lb) ==> 180 lb (82 kg),	84 kg (190 lb) ==> 190 lb (86 kg)

Because of the eroded precision, where 32 m has been reconverting back as 30 m (6.25% less), there have been concerns about the current rounding, whereas the new rounding typically will reconvert to match the 1st amount identically.

2. References test - The from-and-to amounts should match what reliable sources use, in the world at large. For 32 m-to-ft:

• "105[ft] 32[m]" from "Conversion Table" in book British Isles, English Channel, and North Sea by Griffes (web: Books.Google-8C).
• "9.1 meters (30 feet) by 32 meters (105 feet)" from "DOE/EA-1211" conversions by Hanford.gov (web: Hgov-ea1211).
• "32[m] 104.99[ft] 17.50[fathoms]" from "TABLE 8. Conversion Table for Meters, Feet, and Fathoms" (diving) by NGA.mil (web: NGA-T8-PDF).

All those sources consider 32 m as 105 feet (or 104.99 ft).

3. Bounds test - The resulting conversion, in most cases, should be within a 1-unit margin of error, as bounded by half-unit limits for a particular unit "n": n-0.5 to n+0.5. For the value 32 m, the bounds are:
           Bounds 31.5-to-32.5 giving converted bounds as 103.3-to-106.6 feet.
Hence, the converted value as 105 ft fits within those bounds. The current rounding, as 100 ft, is far below the lower bound of 103.3 ft: while the value should be between the lower number and 106.6, so 105 ft passes the test.

Related documentation changes

The doc subpage will be changed to help explain the extra precision as +1 for conversion factors greater than 2.0. The precision will be explained, as the last digit being rounded to the mid-point. For example, a mountain height, such as for Mount Everest, would become 8,848 metres (29,029 ft), with the "029" as the mid-point between "028-030". A more precise display would be "29,029±1". For that reason, 29,028 ft also reconverts back to the same 8,848 m, which has a margin of error of 1m or a 3.3-ft span. A novice user would need documentation to clarify that 29,029 is the midpoint between 29,028 or 29,030 feet, and for that reason 29,029 is customarily displayed. The ending "9" is not exact, but it is "semi-significant" as being close to 28, 29, and 30, with all three being within the 1-metre precision of 8,848 m: 29,029±1. If a height were exactly 8,848.00 (to within a hundredth of a metre), then the new rounding would show: 8,848.00 metres (29,028.87 ft), with the former ending of "029" now closer to 028.87 ft. That level of precision assumes a mountain doesn't shift with the movement of the Earth or the Moon's tidal forces. Anyway, the documentation will be changed to reflect the new precision.

Questions about proposed rounding

There are several common questions:

• Q: Will the change fix all rounding problems?

A: No, the focus is to shift some of the common measurements, so the change will improve: heights ft/in to cm, weights kg-to-lb, and metres-to-ft, but other units might remain the same.

• Q: Will the change become the mandated standard?

A: No, this is just a first step to improving the rounding for general-purpose measurements. Some adjustments, to the rounding, could be added in the future.

• Q: Why has the rounding been controversial?

A: The problem stems from 2 different meanings of an ending-zero. For engineering work, an end-zero typically means "the last 2 digits are rounded", whereas for the general public, an end-zero typically means "closer to a 0 than 9 or 1". So, for the number "150", an engineer often considers the value as rounded between "145-155", while the general public sees "150" as between 149-151. An engineer could treat "10" as the range 5-15, while when a child says "age 10" that does not mean "5-15 years" old. These 2 meanings are completely, utterly incompatible; there should be 2 entirely different Convert-templates: an engineer's conversion as Template:Engconv, versus the general public's Template:Genconv for general conversions. The numeral "10" cannot mean both "exactly 10" and "5-15" in the same template. The proposed rounding is to shift common measurements, such as height or weight to display as the general public would expect, not consider height as rounded up/down 2 inches. For engineering articles, then any heights or weights would need to be checked to include a round parameter (typically "1").

• Q: Why has the problem persisted?

A: As noted directly above, the meaning of "10" or "100" has been endlessly debated. The engineering measurements use 10 as 5-15, or 100 as 50-149, while the general public uses 10 between numbers 9-11, or 100 between 99-101. The 2 views are hopelessly deadlocked, and when Template:Convert has been changed, one side or the other always loses.

• Q: Why aren't there 2 templates: Engconv & Genconv?

A: Clearly, at least 2 different templates are needed, for engineering versus general use. However, during the past 2 years, all attempts to create new conversion templates have been met with hostility and suppression, to the extent that WP admins felt the issue no longer warranted any discussion, so new templates were AfD-deleted without any real debate. There had not even been enough time to clarify the issue of "exactly 10" versus "10 means 5-15". So the one template has become now, "One size fails all": engineers are disgruntled about too much dropping of decimals "xx.x" and general users dislike the vague end-zeros.

Those are the main questions, so far. Other major questions that arise will be explained here later. -Wikid77 (talk) 21:07, 10 October 2009 (UTC)

Impact of proposed rounding

Only numbers that convert to higher amounts will change: conversions to lower counts will not change, and miles-to-kilometers will not change, due to 1.61 km being below a scale factor of 2.0. However, for the other amounts, the improvement to Wikipedia is almost incalculable. Thousands of articles will be reformatted to show the new amounts, which will be adjusted, by up to 5%. The impact exceeds, for example, correcting the value of pi, from being off as 3.3 or 2.99 (back to 3.141592...), because Convert is used much more than pi in Wikipedia. The impact will rank with some of the most important bot-edits ever done in Wikipedia. It will likely exceed the impact of correcting 5 million spelling errors. The result will be similar to correcting the meaning (not just spelling) of 1-5 sentences in thousands of articles. It will be similar to correcting the date of discovery or date-of-birth, by 1 to 4 years, in thousands of articles. Again, the impact is difficult to assess, but likely to be far greater than correcting values of pi if ranging in extremes from 3.3 to 2.99.

The consensus forum is below, with comments entered under section: "#Comments on proposed rounding".   -Wikid77 13:56, 9 October 2009 (UTC)

Issues noticed for km/miles in actual articles

06-Oct-2009: There are numerous issues which surfaced while running the quick-deleted Template:Kmbot versus {{Convert}}. Templates which explore alternate conversion tactics are quickly deleted in Wikipedia, so there has been little comparison with better methods. Because of the diversity of ideas, between T:Kmbot and T:Convert, it was easy to see many issues to resolve:

• {{Convert}} converts 20 km as "12 mi" rather than 12.4 miles. The default rounding seems too severe for a low distance such as 20 km. Focus: consider including tenths of miles for low distances.
• {{Convert}} displays "20 kilometres (12 mi)" as the default, when "km" is the known measurement, and the "12 mi" is displayed as the foreign amount. The more logical display, considering an article's focus, would be "20 km (12 miles)" because the "km" is well-known for the article's subject (and avoids the "metre/meter" bias), while the term "mi" is the foreign measurement better explained with the full word "miles" which is foreign to most articles about "kilometres". The choice to abbreviate "mi" but not "km" is logically backward for the culture of most articles using km. Focus: consider "km" as a typical, default item to display.
• {{Convert}} insists on putting commas in a 4-digit amount, although it can be confusing for decimal-point versus decimal-comma numeric displays. It would be much better to follow the input format (if no commas, don't force them): so 4125 m would remain "4125 m" rather than be forced to "4,125 m" which might be a decimal-comma typo for 4.125 (4+1/8) meters. Remember: numerous multi-lingual readers work on the English Wikipedia, so it would be better to avoid excessive commas in numeric amounts, when those commas are not even needed. Amounts with zeroes are obviously large, such as "4,100" seems over 4 thousand, but most elevations do not have zeroes: "9,125" might be mistaken for "9+" metres. The forcing of commas makes it harder to detect actual typos from the decimal-comma cultures. Focus: avoid forcing commas everywhere, for numbers within 9999.
• {{Convert}} still chokes on commas in the input number, such as converting a vast distance of 12 million km to miles: {{Convert|12,000,000|km}} has been dying all during 2008-2009. Currently, the live result of using commas as input for {{Convert|12,000,000 |km}} is as follows:12,000,000 kilometres (7,500,000 mi)

     Focus: make allowing commas a priority change in Convert.

• {{Convert}} does not really handle number sense, whereas Template:Kmbot was designed to round logically, depending on distance, as the main design goal. Focus: consider if {{Convert}} could even handle number sense, or would it be too complex for a single template like that.

Of course, the simplest solution to those issues is: don't use {{Convert}}, and just use {{Kmbot}}, if only it weren't constantly deleted! So, instead, skip the 13-to-26 templates, and, just hard-code the "20 km (12.4 miles)" or other measurements with wording more logical for each article's culture. By hard-coding the digits, there will no rounding of 12.4 as 12, and no forcing of extra commas to clutter the page. -Wikid77 (talk) 08:54, 6 October 2009 (UTC)

Agreed with some of your points, although at least two (long-form kilometres vs km, and the commas in longer numbers) are beyond the scope of this particular group of editors to fix as they're simply convert's implementation of Wikipedia's Manual of Style (see Numbers, and Units of measurement). With default precision I think it has got it right - I always specify the precision (is 20km literally 20km as in 20.0, or is it approximately 20km, within 20km etc in which case the default is entirely reasonable.) When using a conversion in-template I tend to code it manually unless there's a real need to do otherwise. Agree re commas. However, I think having a multiplicity of templates would be inefficient - better to fix the one we have so that changes are both centralised, and shared with all relevant conversions. Orderinchaos 09:25, 6 October 2009 (UTC)

Huh? What's wrong with 20 km (12 mi)? A distance which might by given as 20 km by a guide for metric readers might be given as 12 mi by a guide for imperial readers. No-one would measure the distance between two settlements to within 0.1 miles (even because that'd depend on which point of each settlement you take, unless they are less than 80 metres across each). On the other hand, you might be measuring the position of a motel along a road, where more precision would be appropriated, but then you'd say 19.5 km, or 19.6 km, ..., or 20.0 km, ..., or 20.5 km, whichever is appropriate. And if for some reason you still want to have the conversion more precise than the original, you can use {{convert|20|km|mi|1}}, where the 1 at the ends tells the template to convert to one decimal place after the point: 20 kilometres (12.4 mi). (On the other hand, I agree that it shouldn't give commas in numbers less than 10000 unless asked to do so.) ___A. di M. 09:58, 6 October 2009 (UTC)

Yeah personally I wouldn't mind seeing the MOS change such that numbers < 10000 are handled that way. A table I did for Barcaldine Region#Population today is an ample demonstration as to why. Orderinchaos 10:35, 6 October 2009 (UTC)

Huh? The MoS already allows to use both 2345 and 2,345 for numbers between 1000 and 10,000 which are not years or page numbers. --___A. di M. 11:30, 6 October 2009 (UTC)

This is what I get for consulting the summary version. :| Orderinchaos 11:54, 6 October 2009 (UTC)

• Perhaps the 20-km / 12.4-mile example was too weak. Compare extending a building from 200 to 201 meters: the October-2009 Convert shows the building increased from 660ft to 660ft (same?):
    · {{Convert|200|m}} gives: 200 metres (660 ft) & {{Convert|201|m}} gives: 201 metres (659 ft).
  
  Yes, Convert shows both 200 and 201 m as 660ft. That proof of the issue is called "reductio ad absurdum" - the results of a logical test show an absurd result, and hence, Template:Convert is, in fact, rounding incorrectly. It's not a matter of personal preference: the default rounding in Convert yields illogical results. -Wikid77 (talk) 12:29, 6 October 2009 (UTC)

There is something seriously wrong if convert is giving 660ft for both 200 and 201, when {{convert|200|m|ft|0}} is giving 200 metres (656 ft) and {{convert|201|m|ft|0}} is giving 201 metres (659 ft) --Red King (talk) 12:48, 6 October 2009 (UTC)

Every default will result in illogical results in some cases. Or do you think the following is better: "The length of the equator is approximately 40,000 kilometres (24,855 mi)"? That's what we would get from a rule "all printed digits are significant, even trailing zeros". Currently Convert is guessing the number of significant digits based on the theory that trailing zeros that come before the decimal point are not significant, and it correctly produces 40,000 kilometres (25,000 mi). Hans Adler 12:52, 6 October 2009 (UTC)

It's also why the default is so easily able to be overridden. One thing Wiki is missing is a true scripting language, convert makes do with the best of what parserfunctions can offer. The rest is down to us humans and our common sense. Orderinchaos 13:15, 6 October 2009 (UTC)

Indeed. It's killing me that people expect a dumb template to do everything for them in every situation by default. Whatever happened to the editor having ultimate responsibility for correctly using the template? The usage instructions are clear enough, in my opinion, for anyone who cares to read them. — Huntster (t @ c) 19:14, 6 October 2009 (UTC)

Reducing illogical default conversions

Without having a template to compare the tactics for rounding of everyday numbers, it might seem as though there is no coherent strategy to make conversions logical. However, during the first 9 months of 2009, Template:Kmbot (see: Kmbot) was available to consider: how would a computer be taught to round distances in a logical manner (could a template actually round distances like humans would do)? Since the 1980s, schools have been teaching "number sense" which includes how numbers are rounded in everyday affairs. Hence, the common-sense rounding of amounts is not "original research" which might make Wikipedia more intelligent than the general populace. Instead, it's been almost 30 years that people have been studying number sense. So "yes, Virginia" there is intelligent rounding:

• {{Convert|100|km}} ==> 100 kilometres (62 mi) while {{Kmbot|100}} ==> 100 km (62 mi).
• {{Convert|200|km}} ==> 200 kilometres (120 mi) while {{Kmbot|200}} ==> 200 km (124 mi).
• {{Convert|201|km}} ==> 201 kilometres (125 mi) while {{Kmbot|201}} ==> 201 km (125 mi).

So, while Convert thinks going 1 extra kilometer means "going another 5 miles" the Template:Kmbot keeps the increase to within 1 more mile: 200 km is nearly 124 miles (not 120).

The secret to intelligent rounding is that it depends on the general culture, plus the magnitude of the amount, rather than just the number of non-zero digits in a number.

• {{Convert|40000|km}} ==> 40,000 kilometres (25,000 mi) while {{Kmbot|40,000}} ==> 40,000 km (24,850 mi).

The reason that the rounding problems in Convert were discovered (even years later) is because another template existed to allow easy comparisons. In a volunteer effort, normal people have only a few hours to analyze problems: it's not like everyone sleeps on Wikipedia and wakes to edit-again. We don't have time to sit and cross-check calculations: it is only because Template:Kmbot existed that the conversion problems in Convert were easily spotted. -Wikid77 (talk) 17:48, 6 October 2009 (UTC)

Are you sure you have understood the problem? How can a computer distinguish between the following two situations?

• "The metre was originally defined as 1/40,000,000 the length of the equator, but this definition was given up later in favour of a more precise one. Nevertheless, the length of the equator is still roughly 40,000 km."
• "For the two satellites to work properly it is crucial that they keep a distance of 40,000 km from each other, with a tolerance of only about 1 km. In other words, the distance must remain between 39,999 km and 40,001 km."
• "For the two satellites to work properly it is crucial that they keep a distance of 40,000 km from each other, with a tolerance of only about 10 km. In other words, the distance must remain between 39,990 km and 40,010 km."

The "secret to intelligent rounding" is to understand the surrounding text. This is something our templates can't do. The respective correct conversions in the three examples are, roughly, 40,000 kilometres (25,000 mi), 40,000 kilometres (24,855 mi) and 40,000 kilometres (24,850 mi). Hans Adler 18:14, 6 October 2009 (UTC)

It's interesting that you give us 40,000 km → 24,850 mi to support your argument. If I tell you that an asteroid is 40,000 km away, you shouldn't think that I mean to the nearest ten miles. Even 200 km → 124 mi introduces false precision. The best general approach, what they've actually been teaching in schools since the 1980s (and some time before), when the context is unknown is to match the precision of the output to that of the input (making some allowances for the sake of accuracy). JIMp _talk·cont 19:54, 6 October 2009 (UTC)

It's clear from your response that you understand the "secret to intelligent rounding", which, as I said, is to understand the surrounding text, but that you have trouble applying it in practice. I said the conversion 40,000 km → 24,850 mi is correct in the third example, which was carefully set up for a precision of ±10 km (± 6.25 mi). The distance of an asteroid has nothing to do with the third example and in fact requires even less precision than the first, in which I used the conversion 40,000 km → 25,000 mi. Hans Adler 14:08, 7 October 2009 (UTC)

I guess Jimp intended to answer Wikid77, not you. ___A. di M. 14:36, 7 October 2009 (UTC)

I did. JIMp _talk·cont 21:41, 7 October 2009 (UTC)

I got that from the content of your post, but you should have indented it with one fewer colon or it looks like you were replying to Adler. ___A. di M. 09:55, 8 October 2009 (UTC)

Sorry for having allowed the formatting to confuse me. There is so much silliness on this page that I wouldn't have been surprised even by this kind of response to my post... Hans Adler 11:09, 11 October 2009 (UTC)

• I see they have been caught in their own trap of "imagined inaccuracy": please understand that, by definition, the equator is almost exactly 40,000 km, so the number is very close to 40,000.0 exactly, and hence almost exactly 24,850 mi (nowhere even near 25,000, hello?). This idea of rounding to the "nearest 1,000 miles" is, what's the term? (...wait for it...) over-rounding. Just because a number has a bunch of zeroes "000" doesn't mean it is an estimate to the nearest thousand, give or take a million. In the reality of Wikipedia articles, very few measurements are meant to the nearest thousand. That's why rounding many kilometers to the nearest mile will work 99.999% of the time. Otherwise, just specify the round-parameter as "-3" to round as full thousands. -Wikid77 (talk) 16:38, 7 October 2009 (UTC)

Ah, but if understood in terms of significant digits, it is most definitely not over-rounding. 20,000 would not be acceptable, but 25,000 is fine. If the value *is* known to a level of specificity, then specify the specificity :) i.e. |0, |-1, whatever is appropriate. Orderinchaos 16:45, 7 October 2009 (UTC)

The circumference of the earth at the equator is NOT 40,000 km. It is 40,075.16 km. If you round it to three significant figures, you get 40,100, so 40,000 is only accurate to three significant figures with a bit of fuzz in the third. The earth is not a sphere it is an oblate spheroid, and the original definition of the metre was based on a line from the pole to the equator passing through Paris (it's a lumpy oblate spheroid). The average distance from the pole to the equator is about 10,002 km depending on where you measure it.RockyMtnGuy (talk) 21:39, 7 October 2009 (UTC)

More unhelpful default conversions

These are further examples of currently less-than-perfect default conversions from a thread above; I'll repeat them here just so they don't get lost:

• 81 kilograms (179 lb), 82 kilograms (181 lb), 83 kilograms (183 lb), 84 kilograms (185 lb)
• 6 feet 1 inch (185 cm), 6 feet 2 inches (188 cm), 6 feet 3 inches (191 cm), 6 feet 4 inches (193 cm)
• 36 metres (118 ft), 37 metres (121 ft), 38 metres (125 ft)

At the time of writing, these display as follows:

• 81 kilograms (180 lb), 82 kilograms (180 lb), 83 kilograms (180 lb), 84 kilograms (190 lb)
• 6 feet 1 inch (190 cm), 6 feet 2 inches (190 cm), 6 feet 3 inches (190 cm), 6 feet 4 inches (190 cm)
• 36 metres (120 ft), 37 metres (120 ft), 38 metres (120 ft) JN466 18:12, 6 October 2009 (UTC)

• WOW! Those rounding problems are frightening. I had no idea the errors were that massive. Let's find solutions, see below: #Damage control to fix Convert errors. -Wikid77 (talk) 22:20, 6 October 2009 (UTC)

It is impossible to write a template that gets these things right without a level of artificial intelligence that simply hasn't been developed yet. As in: A computer scientist would get extremely famous if he was able to do it. If you want to compare several measures that are close to each other, then in most cases you must use the optional parameter. There is no way around this, and there will not be one for at least the next 10 years for the reason I have given. (Unless you want an extremely complicated template where you must enter not just the measure you want to display but also all the others that you want to compare to it. That could be correct more often, but nobody would use it. It's much easier to use the existing optional parameter.) Hans Adler 18:35, 6 October 2009 (UTC)

I must correct myself, as you have a valid point: In each of your examples the precision in percent of the converted measure is considerably lower than the precision in percent of the original measure, because the precision measured in number of significant digits is the same. This effect occurs each time the first digit of the converted measure is significantly smaller than the first digit of the original measure. This could in principle be handled more intelligently, although I am certainly not qualified to fix it. Hans Adler 18:47, 6 October 2009 (UTC)

Perhaps it might be possible to tell the program counting the significant digits to ignore a leading 1, 2 or 3 in a converted value that's numerically greater than the original value: so it would think of 125 ft, for example, converted from 38 m, as having only two significant digits (2 and 5), ignoring the 1. Then we'd get this as a default:

• 36 metres (118 ft), 37 metres (121 ft), 38 metres (125 ft) --JN466 19:02, 6 October 2009 (UTC)

Again. The template doesn't work in terms of the number of significant digits, but of their position: for example, in 1,234 kilometres (767 mi), the last significant digit of the source is the "units" place, and since the conversion factor is between 0.2 and 2 this is preserved in the target. Ditto for 7,891 miles (12,699 km). In other words, values given to within one kilometre are converted to within one mile and vice versa, values given to within 0.1 kilometres are converted to within 0.1 miles and vice versa (1,234.5 kilometres (767.1 mi), 7,890.1 miles (12,697.9 km)), and so on. (Exceptions are made when this rule would yield only one significant figure in the target.) This makes perfectly sense, except that I'd increase the thresholds from 0.2 and 2 to √10/10 and √10, to solve ridiculous imprecise conversions in inches-to-centimetres and kilograms-to-pounds, for example. Nowadays a value given to within one inch would be converted to within 10 centimetres (73 inches (190 cm)), one given to within 0.1 inches would be converted to within 1 centimetre (73.1 inches (186 cm)), and so on, because the conversion factor (2.54) is greater than 2. With my proposal, the factor would have to be larger than √10 = 3.16... for the conversion rounding to be shifted right one digit; 2.54 isn't, so values given within one inch would be converted to within one centimetre and vice versa (73 inches (185 cm)), values given to within 0.1 inches would be converted to within 0.1 cm and vice versa (73.1 inches (185.7 cm)), and so on. (Then there's the problem of deciding how many significant digits are in "40,000", but that's another issue. A reasonable default would be assuming that at least the first zero is significant. Today the template assumes that none of the zeroes is significant, which is usually wrong. Often the "at least two figures" exception comes to rescue, but sometimes it doesn't, and sometimes it does when it shouldn't. If possible, I'd have a parameter telling the template that, for example, the first two zeroes are significant and to round accordingly (40,000 kilometres (24,900 mi), converted to the same precision as 39,900 kilometres (24,800 mi) and 40,100 kilometres (24,900 mi)) rather than directly specifying the desired rounding.) And I'm fed up with this perfect solution fallacy: the fact that there is no default which will be reasonable in 100% of cases doesn't mean that it's pointless to replace one which is reasonable in 70% of cases with one which is in 95% of cases. Anyone who's understood my proposal is OK with it. ___A. di M. 19:33, 6 October 2009 (UTC)

Thanks. I had been misled by an earlier discussion elsewhere as to how this worked. Once you have the wrong idea in your head, it is pretty hard to get it out of there. ;) --JN466 20:53, 6 October 2009 (UTC)

Then there is the feet/metres problem. The conversion factor from metres to feet is 3.281 and the one from feet to metres is 0.3048. So, if we set the threshold below 3.281, 1234 feet would be converted to 376.1 m, and if we set it above 3.048, 1234 metres would be converted to 4050 ft. There's no way to have integer feet converted to integer metres and vice versa with a system based on the same idea as the current one. Maybe we should make an exception for one of these. Or maybe we may just use yards for values not intended to be precise to within a foot. ___A. di M. 20:10, 6 October 2009 (UTC)

How about using 0.3 and 3.33 then? Any particular conversions that would screw up? --JN466 20:53, 6 October 2009 (UTC)

In principle, it'd be OK, but it wouldn't be obvious how to scale it to larger or smaller powers. In the current version the thresholds are ..., 0.02, 0.2, 2, 20, ..., and in my original proposal they were ..., √10/100, √10/10, √10, 10√10, ...; an idea could be using ..., 0.03, 0.3, 3.33, 33.3, .... Is there any other conversion factor between 3×10ⁿ and 3.33×10ⁿ? If not, that'd be equivalent to implementing my original proposal but special-casing feet-to-metres and metres-to-feet (including decimal multiples and submultiples of the metre). ___A. di M. 22:54, 6 October 2009 (UTC)

Yes, 0.03, 0.3 etc. and then 3.33, 33.33 etc. had occurred to me too. I guess somewhere in the workings of the template there must be a list of the conversion factors that is uses. --JN466 23:08, 6 October 2009 (UTC)

I dunno, normally a programmer would give a value such as 2 and scale it by the appropriate power of ten as needed. But trying to wade through the forest of transclusions I got the impression that each single conversion has a precision rule hard-coded in it—but I could easily be wrong: this template is one of the most complicated pieces of code I've ever seen. ___A. di M. 10:13, 7 October 2009 (UTC)

Increasing the threshold to $\scriptstyle {\sqrt {3}}$ will, of course, increase the degree of false precision in the output. This is not necessarily a bad thing for the level of precision typically input into the template but could be a problem for input which is already highly precise. For low-precision we'll still need the two-sig-fig rule (or something), the increased threshold won't cover all. Ideally we'd want some sort of sliding scale to kill three birds with one stone (i.e. reduce false precision where the input is already precise (threshold → 1 as precision → ∞), bump up cut-off for normal numbers (threshold ≈ $\scriptstyle {\sqrt {3}}$ for typical precision range) and replace the two-sig-fig rule (threshold → 10 as precision → 0)). JIMp _talk·cont 14:15, 7 October 2009 (UTC)

Values so precise that an error of 1.5 ulp would be a serious matter are normally only found in scientific articles, where they usually have the uncertainty explicitly stated and they aren't often converted to imperial units; so that'd generally not be an issue. As for the two-sig-fig rule, I think it should be applied to the input (i.e. not assuming that 600 has one significant figure in 600 inches (15 m)—one would use "50 feet" if it had), not to the output (the 15 kilometres (9.3 mi) silliness). ___A. di M. 14:35, 7 October 2009 (UTC)

Damage control to fix Convert errors

Okay, I think the severe rounding problems (noted directly above) can be handled, once we earnestly look for solutions. Step 1: Don't Panic. Don't conclude that all rounding is hopelessly doomed. For most mid-level amounts, the workaround for damage control will be to "always" use rounding parameter "0". So, in the case of multiple kilograms-to-pounds, use:

• {{Convert|81|kg|0}} to get: 81 kilograms (179 lb) and {{Convert|83|kg|0}} to get: 83 kilograms (183 lb)
• {{Convert|82|kg|0}} to get: 82 kilograms (181 lb) and {{Convert|84|kg|0}} to get: 84 kilograms (185 lb).

I think the fear of the 5-pound errors will go away, when adding round-parameter "0". The same will fix the fear of 5-mile errors in kilometer-to-miles. Thank you, to all the people above, who have confirmed that, yes, Convert has severe rounding problems, by default, but in most mid-level cases just force rounding as "0". Yes, Convert mis-rounds the weights by 5-pound errors, and distances by 5-mile errors. Note that for small numbers, the use of round "0" would be just as bad (only put "0" on amounts of many kg or km):

• {{Convert|8.1|kg|0}} will give: 8.1 kilograms (18 lb)
• {{Convert|8.2|kg|0}} will give: 8.2 kilograms (18 lb)
• {{Convert|8.3|kg|0}} will give: 8.3 kilograms (18 lb) (all the same)

Instead, for small amounts, put round as "2" as with 2-kg or 2-kilometer amounts (less than 10):

• {{Convert|1.81|kg|2}} as: 1.81 kg (3.99 lb) & {{Convert|1.83|2|kg}} as: 1.83 kg (4.03 lb)
• {{Convert|1.82|kg|2}} as: 1.82 kg (4.01 lb) & {{Convert|1.84|kg|2}} as: 1.84 kg (4.06 lb)

Again, thanks to all above who confirmed the shocking level of rounding errors in the Convert template. But don't panic, Convert can't "scar Wikipedia's reputation": Wikipedia has had a bad reputation for years: many articles are hacked stubs, articles of famous people are outdated, and vandalism remains months or years in many articles (at least 2 years). The recognition of Convert errors is just one more step along the way, toward making improvements. Let this be another lesson: the R.M.S. Convertanic has sunk, but let's move to the lifeboats and keep going, until we build the R.M.S. Convert II. -Wikid77 (talk) 22:20, 6 October 2009 (UTC)

It's not as much a matter of largeness or smallness as a matter of precision. 1.84 kg suggests that something was weighed to within not much more than 0.01 kg or better, and so you should convert to a similar precision. On the other hand, 84 kg suggests that it was weighed to within not much more than 1 kg or better, and so you should convert to a similar precision. On the other hand, if you were weighing something such large with more precision (e.g. 84.235 kg), you should convert to 84.235 kilograms (185.706 lb), whereas a rough weight measurement of 8 kg with an uncertainty of not much less than 1 kg should be 8 kilograms (18 lb). But it is the case that many measurement of weight are made to within about 1%. ___A. di M. 22:52, 6 October 2009 (UTC)

Well said. :) JN466 23:11, 6 October 2009 (UTC)

Wikid77, you are displaying a rather high level of bad faith towards this template and those who have been involved in its creation and operation. Please stop using hyperbole such as "shocking" errors, "don't panic" and "scar Wikipedia's reputation". You are overreacting and throwing around wild statements. There is obviously a lack of understanding of how and why the template works the way it does, but the fact is, with the exception of some isolated cases that can easily be fixed, there are no rounding errors present. The current level of precision used by default is that way for a reason, and can easily be modified as laid out in the instructions. — Huntster (t @ c) 23:13, 6 October 2009 (UTC)

• Hello User:Huntster, there is no need to claim "hyperbole": I am one of those who have worked, for years, to modify Template:Convert. The errors we noted are caused by over-rounding; see below: #Convert is over-rounding common measurements. -Wikid77 (talk) 01:22, 7 October 2009 (UTC)

I'm sure there were no hard feelings intended by Wikid77. The conversions given above under #More unhelpful default conversions are worth looking at though, and fixing if at all possible without harming something else. Values like 6 ft 1 in e.g. are often used to give someone's height. If our conversion does not by default differentiate between someone who is 6'1" and someone who is 6'4", that is not good, especially as editors more familiar with inches may not have a feel for the difference between someone who is 185 cm and someone who is 193 cm. Vice versa, readers only familiar with the cm measurement may not stop to question the 190 cm value. And I'd wager that the percentage of template users who know the parameters, and what they do, is small. --JN466 01:14, 7 October 2009 (UTC)

Wikid77, you say you have worked for years to modify {{convert}}. Can you back that statement up? Some minor tweeks in the rounding might be worthwhile but all in all the template follows correct mathematical procedure i.e. it bases conversions on precision (not magnitude). JIMp _talk·cont 13:44, 7 October 2009 (UTC)

Replying to Huntster: "some isolated cases" what? It overrounds practically all conversions of people's heights from imperial to metric and all conversion of people's weights from metric to imperial. ___A. di M. 14:51, 7 October 2009 (UTC)

Convert is over-rounding common measurements

Several people have noted, above, that there are rounding errors based on common notions of measurement. Of course, anyone could invent broad-rounding rules, such as: "1 km = 10 miles (to nearest 10 miles) because rounding to 0 miles is no distance at all". However, when considering common measurements, it is not logical to say that 200 m is 660ft, and increasing the length of a warehouse to 201 m results in a new length of 660ft (the same). Bottom line: Convert is defaulting to some shocking notions of rounding for common measurements. When did the Pope decree, "Round meters to 10ft"? Instead, treat 200m as 656ft and let the longer warehouse of 201m be 659ft, as the default. When people want to round to the nearest-10-ft (or 100-ft), then let them override the default higher precision. A distance of 300 km should be 186 miles (or rounded by 5 as "185 mi" not Convert's value of 190). Again, Convert rounds 300 km to the nearest 10 miles. The fundamental problem is that Convert is "over-rounding" the measurements, beyond what is logical for most Wikipedia articles. If you re-read above, in all the examples that other people have discussed, then it is pretty obvious that Convert has rounding errors, when judged relative to common notions of accuracy and precision. That is what we have all been saying, for months now. -Wikid77 (talk) 01:22, 7 October 2009 (UTC)

The problem is that by reading "300 km" you cannot know whether it's a ballpark estimate, a rough value, or a value precise to within one kilometre; in these cases, you'd convert to "about 200 miles", ""about 190 miles", or "186 miles". (This is another idea I once had, although I acknowledge it might be difficult to implement: when the conversion ends with a place-holder, non-significant zero, we should add "approx." or "≈" before it so that one wouldn't assume that "190 miles" is to within a mile.) Nowadays the template, on seeing "200", will assume that only the 2 is significant, which is very likely to be wrong, and this is even truer with units which have close multiples in very common use (e.g., nobody would use "500 mm" for a rough measurement or a guesstimate: they'd use 50 cm for the former and 0.5 m for the latter). ___A. di M. 10:00, 7 October 2009 (UTC)

I'm not sure that nobody would use "500 mm" for a rough measurement or a guesstimate (whether or not to use centimetres often depends on context). The template is not overrounding. The claimed "errors" are based on assumptions which are mathematically false. Mathematically speaking the correct approach is to count only the "2" in "200" as significant and convert accordingly. Only context can tell you whether the zeros are meant to be significant. Where context tells you so you can adjust the output precision. JIMp _talk·cont 13:34, 7 October 2009 (UTC)

Huh? At least in Italy (but I guess the situation isn't very different elsewhere), centimetres are much more widely used than millimetres in non-technical usage, so normally a measurement given in millimetres (for something larger than about one centimetre or so) would look like a quite technical one. Assuming that only the 2 is significant is often silly (200±50, that'd be a 25% error!). A more realistic assumption would be that at least the first zero is significant (maybe, except when the first digit is, say, 7, 8 or 9). Also, roughly approximated values are normally stated as such, so having one more digit in the conversion is usually going to be less bad than having one less. ___A. di M. 14:11, 7 October 2009 (UTC)

I can confirm the usage of centimetres is very similar in Australia - it's probably the main unit of small measurement in common use. Orderinchaos 16:22, 7 October 2009 (UTC)

Re "the template is not overrounding": yes, it is (even if I'm not talking about that). No-one in Metricland would round the height of a person to the nearest ten centimetres in any situation in which someone in Imperialland would give it to within an inch, and I guess that no-one in Imperialland would round his weight to the nearest ten pounds in any situation in which someone in Metricland would give it to within one kilo. One would rather risk missing someone's height by one centimetre (e.g. using 5 feet 5 inches (165 cm) for someone whose height is actually closer to 164 cm) than be sure of missing it by five centimetres (i.e. 5 feet 5 inches (165 cm)). You and SimonTrew appear to be the only ones thinking otherwise (see § Some suggestions for changes to the default precision above).___A. di M. 14:20, 7 October 2009 (UTC)

• Yes, for the general public, most people handle "300 km" as 1 more than "299 km" so that's why the default conversion should be 186 miles. However, when the situation is "3 hundred km" then higher rounding could be specified, by the writer, rather than the default for Convert. -Wikid77 (talk) 14:19, 7 October 2009 (UTC)

My apologies for not noticing rounding errors

07-Oct-2009: I certainly want to apologize to those people who have kept trying to say, for months (or years), that Template:Convert was rounding incorrectly. I fully realize that the world does not treat 32 meters as 100 ft, when the world-standard result is 105 ft. I'm not slow, pig-headed, nor a total idiot: I'm just busy. I wish I could spend more time fixing these massive problems. However, I have just been so busy on other "priorities" that I didn't see the "elephant in the room": yes, I noticed "32 m ~ 100ft" but it didn't register as bizarre. Yes, I do feel like a fool to have assumed, for years, that Convert was "converting". I just didn't like Convert, so I was writing (& using) other conversion templates (which gave highly accurate results; I didn't intend that to sound so mean). Of course, my better conversion templates were quickly deleted without discussion, totally exterminated. But anyway, yes, I understand:  the numerous rounding errors from Convert are appallingly horrific; they are progated into thousands of Wikipedia pages; and God only knows all the people, cursing under their breath, at the monumental screw-up to report 32m as 100ft when the entire world knows it is 105ft. I promise to work with you to help resolve this terrible fiasco. Meanwhile, remember to append round-parameter "0" to mid-level amounts (or to feet/inches), append "2" to small liters/km, and append "1" to fix the small feet-to-meters conversions (less than 30m?). -Wikid77 (talk) 14:19, 7 October 2009 (UTC)

I'm not sure whether you intended to be sarcastic, or what. But I always force convert at a rounding parameter so it says what I mean and not simply the default option (which is decent for most purposes though definitely not for all.) I usually force it at the same level of decimal places to which my original figure is accurate (and for bigger numbers, this will sometimes be a negative number.) This avoids the entire issue of "rounding errors". Orderinchaos 16:32, 7 October 2009 (UTC)

A 3-part strategy for future improvements

We are ready for a three-part approach to moving forward:

1. emphasizing the current use of rounding levels & sigfig=3;
2. developing formulas for converted-precision 2==>3; and
3. experimenting with smart templates, using number sense.

These are described, in detail, within the subtopics below. -Wikid77 02:33, 8 October 2009

Default rounding is nearest 10 units

Several users have kept noting that Convert is rounding numbers far off the world-standard amounts, where Convert tends to over-round by 10s-of-units: kilometers rounded by 10 miles, kilograms by 10 pounds, or feet-inches by 10 cm (a person's height could be off by 2 inches). As a workaround, the Convert template allows specifying a count for rounding the converted amount. For example:

• For feet/inches-to-cm, append 0: {{Convert|6|ft|2|in|cm|0}}
• For feet-to-meters, append 1:       {{Convert|6|ft|m|1}}
• For large km-to-miles, append 0:     {{Convert|6|km|mi|0}}
• For small km-to-miles, append 2:     {{Convert|2|km|mi|2}}
• For liters-to-gallons, append 2:   {{Convert|7|L|2}}

Unless rounding is specified, then Convert has generated some very unusual conversions. For example:

• {{Convert|32|m|ft}}       for: 32 metres (100 ft)          - standard is 105 ft
• {{Convert|300|km|mi}} for: 300 kilometres (190 mi)   - standard is 186 miles

Numerous people had noticed the problems, but there were not enough people available to get the template changed to display the standard conversion amounts. Clearly, the idea of equating 32 meters to 100 feet, was highly unusual, because no reliable source would support the result as "100 ft" rather than the standard of 105 ft. Currently, those 2 conversions give the following results:

• {{Convert|32|m|ft}}      today gives: 32 metres (105 ft)           - standard is 105 ft
• {{Convert|300|km|mi}} today gives: 300 kilometres (190 mi)   - standard is 186 miles.

Because of the complexity of Template:Convert, improvements have taken weeks or months to fully implement for all cases. Please understand, there are hundreds of details which must be considered, and volunteers have only limited amounts of time. -Wikid77 (talk) 02:33, 8 October 2009 (UTC)

I don't know what you're referring to with "improvements have taken weeks or months to fully implement for all cases". The type of conversions you label as "standard" are by no means correct by mathematical standards. The standard mathematical approach is to regard "300 km" as 300 ± 50 km convert this and you get 186 ± 30 mi. The result, 190 mi, given by convert already implies more precision than we're really justified giving. JIMp _talk·cont 20:18, 8 October 2009 (UTC)

Actually, 300 is often understood to have three significant digits and 3×10² (or "three hundred" outside nerd-land) to have one. Another approach is to say that 300. with a trailing point has three sigfigs, 3×10² has one, and 300 has an unspecified number of sigfigs between one and three. The use of "300" to unambiguously mean (3.0±0.5) hundred is not that common. BTW, an idea would have to have the template understand 300 as having one sigfig and 300. as having one. (I've tried that, but now it considers 300. as having four, equivalent to 300.0.) ___A. di M. 14:46, 11 October 2009 (UTC)

Converting precision while converting amounts

The October-2009 version of Template:Convert has been treating precision as if within a calculation where all units are the same, but discussions (above) have indicated that precision must change, depending on the convert-output units: a 2-digit "32m" is treated by the world as being the 3-digit "105ft". Because Convert is stuck at the 2-digit precision, it chops the answer to "100ft", while that is far out of range:

• The actual 32 m is between: 31.5 m (103.3 ft) & 32.5 m (106.6ft)

There is no way to justify "100 ft" as a valid amount based on 32 being a rough value between 31.5-32.5. The bounds would be between 103.3-106.6 ft, and thus the world-standard is 105ft. I think the easiest solution is to alter the precision on a case-by-case basis, for each and every combination of units: m-to-ft, ft-to-m, in-to-cm, etc. For simplicity, start with the most-used units, such as: for meters-to-ft, shift the output precision +1 from 2 to 3 significant figures; for decimal meters 123.321m, shift 6 to 7, and see if that works. Because the shift would only be made on a case-by-case basis, only the units being shifted would be affected during the revisions to the Convert-family of templates. Eventually, there might be some "elegant" formula, but that can wait. Focus on matching the basic world-standard amounts of the most-common conversions. -Wikid77 (talk) 03:24, 8 October 2009 (UTC)

There really is no elegant solution to this problem - all automatic rounding algorithms give unexpected results at times. Converting 32 m gives 104.98687 ft, and rounding that to 2 sig figs gives 100 ft. To avoid losing precision people often use the rule of thumb to add one significant figure on the conversion, thus giving the 3-sig-fig result 105 ft. However, this can have its own problems. As I mentioned before, it results in the commonly quoted figure of 98.6 °F for normal body temperature. The body averages closer to 98 °F than 98.6 °F. They got 98.6 °F by converting 37 °C, which was only accurate to two sig figs, and gaining a meaningless sig fig.RockyMtnGuy (talk) 05:53, 8 October 2009 (UTC)

• I guess they had rounded 36.8 to 37 C? -Wikid77 09:35, 8 October 2009

I'm getting tired of repeating the same thing over and over again. The template doesn't count the number of significant digits, but their position. In 788 miles (1,268 km), the last significant figure in the input is in the "units" place, and the conversion factor is between 0.2 and 2, so the output is rounded so that the last significant figure is in the "units" place, too. Ditto for 1,023 kilometres (636 mi), 789.1 miles (1,269.9 km), 1,023.4 kilometres (635.9 mi), yadda yadda yadda. This makes perfectly sense, except that the thresholds should be increased to avoid over-rounding by one place in inches-to-centimetres, kilograms-to-pounds, etc. just because the conversion factor happens to exceed 2. ___A. di M. 10:08, 8 October 2009 (UTC)

• Okay, I deciphered the Template:Precision/a and I agree: a very simple solution is to increase precision (by 1) when the conversion-factor exceeds 2.2 (as in kg-to-lb); see below: #Shifting precision in Template:Convert/round. -Wikid77 (talk) 21:37, 8 October 2009 (UTC)

BTW, Wikid77, would you convert 346 foot to 105.5 m? Because [345.5 ft, 346.5 ft] equals [105.3084 m, 105.6132 m], with 105 m falling outside that range. ___A. di M. 10:15, 8 October 2009 (UTC)

• Yes, of course, because feet are fractions of a meter, even though rounding to 105 seems tempting. You already know my hunch about 20 km as "12.4 mi" not 12 miles; again, because kilometers are fractions of a mile, and 0.4mi is a long stretch to walk, plus often too far to see past trees: I'm thinking Marathon, Greece as 26 miles. This concern is where "number sense" comes in, so let's move to the 3rd part of the future, below: #Part 3: templates with number sense.

Shifting precision in Template:Convert/round

08-Oct-2009: The top-level rounding templates, such as Template:Convert/round can be altered to accept a precision-shift amount "pshift", such as to increase meter-to-ft conversions by +1 significant digits. A value of "65 m" would then default to yield 213 ft.

In Template:Convert/round - append "+{{{pshift|0}}}"

{{#ifexpr:{{{2}}}=0|0|{{formatnum:{{rnd|{{{2}}}|({{max/2|{{#expr:({{precision|1{{{1}}}}}+{{{5}}}-0.5+(ln2/ln10))round0}}|{{#expr:1-{{ordomag|{{{2}}}}}}}}}+{{{pshift|0}}})}}}}}}

(The coding has no spaces due to old 2007 template-size limits).
The pshift=1 would fix "32m" to give "32m (105 ft)" as matching the world-standard with 105ft, between rounding limits of 103.3-106.6ft. The typical (teenage) user would just request {{Convert|32|m}} without needing to designate an appropriate sigfig=3 (or more for more digits). To re-program the templates and pass pshift, some other subtemplates would need to be changed to set the value of pshift, depending on larger units, but other templates/conversions would not be changed, and just use the default pshift=0. Also, we can add explanatory HTML comments into those templates now. A value of pshift=1 would be too large for other conversions, such as 196km to miles. Hence, pshift would only be set for larger-scale units, NOT for all conversions. As a more elegant solution (in the future), I think, in general, if the scale factor is greater than 1, then set pshift=1. -Wikid77 09:35, 8 October 2009

Raise precision by 1 for factor over 2.2

A simpler solution would be to raise the precision (or pshift number) by +1 when the scale factor is over 2.2. That tactic will correct the default rounding for m-to-ft, kg-to-pounds, ft/inches-to-cm. I think, rather than pass "pshift" the new coding would insert the following expression:

• +{{#ifexpr:{{{2}}}/{{{1}}} > 2.2|<!--then-->1|0}}

That new calculation would be inserted into each of the top-level rounding templates. -Wikid77 (talk) 21:37, 8 October 2009 (UTC)

Part 3: templates with number sense

Because Template:Convert already has over 2,375 subtemplates, it is somewhat "unfair" to expect this same template to also convert American speed limits, hurricane windspeeds, jogger's "fun runs", and other cultural measurements. There is already so much clutter among the 2,375, that new templates are clearly the logical future. We can develop a great new template within 2 hours, whereas it might take 2 weeks to modify/test/fear similar changes in Convert. However, we don't want 500 bizarre new templates. The goal is reasonable diversity, but not chaos. If we set some guidelines, such as new templates must support the major Convert parameters (abbr=on, sp=us, adj=on), then we can slow the growth of wild, bizarre templates being touted as smart templates with "number sense" savvy.

There have been debates about the km-to-miles conversions, with the idea to round whole miles. I prefer 20km as 12.4 miles, but others would round exactly 12 miles. The dead Template:Kmbot had preset levels where decimal miles xxx.x rose to be whole miles. There's nothing like having an experimental template to edit, to try new ideas, so I've created another smart template "{{Lenbot}}" to focus on smart length conversions. You know such templates are verboten and get instantly deleted (so don't tell anyone it's there!!). No, in fact, I've created Lenbot as a talk-page subpage (a template doesn't even need a title as "template"), where the name "Lenbot" is a mere redirect. If they exterminate the redirect, we just create a different one, such as Lenbot2 (etc.). However, now anyone can edit Lenbot and try different rounding levels, just to see what impact the various forms of rounding look like.
Anyway, when someone says their town is the highest in the region, they do NOT want you to round them down to the nearest 10ft: be precise with official town/mountain elevations: an "Elevbot" would be very precise about all official elevations. Meanwhile, the figure "12.4 miles" is an example of more precision. However, in American road maps, we never see a tiny line-segment of "12.4" miles, nor would an Interstate sign read "Next Rest Area 12.4 miles" (never). Even though walking a half-mile can be difficult (in bad weather with no sidewalks), for travel information, whole miles are the rule. So, a "Travbot" would have some very explicit rules about rounding distances related to motor traffic, totally opposite the concept of precise town elevations.
American speedlimits are by 5-mile levels: 25mph, 30mph, 35, 45, 55, 65, 70. A "Speedbot" would need to avoid saying the "speed limit was 62". For hurricane windspeeds, a "Windbot" would need to round the typical wind-speeds into the standard 5-mph increments (based on knots), except 74mph is the minimum speed (1-minute sustained winds?) for a hurricane. That's the idea behind number sense. -Wikid77 12:30, 8 October 2009

I've never understood American speed limits, but I guess that's because I've carefully avoided living there. Canadian speed limits are by 10-km/h levels: 30 km/h, 40 km/h, 50 km/h, etc. I suppose that means we need the "CanadianSpeedBot" to handle Canadian speed limits, and of course the "LeftHandedAlbanianMidgetSpeedBot" for indicating the speed of left-handed Albanian midgets. I try to avoid sarcasm but sometimes I fail miserably. RockyMtnGuy (talk) 17:00, 8 October 2009 (UTC)

• That's why the stipulation to force creation of the parameter "abbr=on": because they wouldn't have an abbreviation (or unit symbol) for "LeftHandedAlbanianMidgetSpeed" !! Hence, no template for them. -Wikid77 (talk) 21:37, 8 October 2009 (UTC)

How will creating more of them "slow the growth of wild, bizarre templates being touted as smart templates with 'number sense' savvy"? JIMp _talk·cont 20:31, 8 October 2009 (UTC)

• People with extreme, wild, bizarre ideas tend to lack the patience to implement parameters such as: abbr=on, sp=en, disp=or, and adj=on (in fact I doubt they would ever hyphenate a multi-word adjective!). It is an easy way to control quality, without being overly judgmental. -Wikid77 (talk) 21:37, 8 October 2009 (UTC)

Expanding to smarter Convert(s)

The numerous discussions about the defaults, for rounding a converted amount, have revealed at least 3 different (and conflicting) interpretations of numbers:

• Engineer's view of "150" - In the use of engineering measurements, an ending zero has special meaning, not used by the general public. For the number 150, the end-zero means a measurement "rounded to the nearest two digits": a range of variation between 145-155, because of the special meaning held by an end-zero in engineering.
• General public's view of "150" - For the public at large, in everyday affairs, an end-zero typically means "closer to 0 than to 9 or 1". The number 150, to the public, is typically just between 149-151. If a woman weighted less than 130 lb, she is likely to report 129 lb, rather than round up! While an engineer might consider "20" as rounded between 15-24.99, someone of "age 20" would not be considered as "15-24 years old" in general.
• Banker's view of "150" - For a banker, every single penny counts: scams have been caught that rounded paychecks to drop pennies and collected $thousands by numerous pennies transferred to a round-down-account. That was not considered an "engineering measurement", but rather larceny. For a banker, "150" doesn't mean deposit $146 and withdraw $154 same-difference. That "$150" means $150.00 exactly, not one penny more/less.

Unfortunately, Template:Convert is used by people in many professions: it can't read people's minds. There need to be multiple versions of Convert to preset the rounding levels, for each profession:

• Engconv or Econvert: A version of Convert would use the end-zero "00" rounding for typical engineering measurements. A value of "200m" would be a rough measurement near "660ft"; otherwise an engineer would know to enter "200.0" for more precision, as 656ft.
• Bankconv or Bconvert: A version of Convert would preset rounding to very exact levels. When a banker says "10ft" in inches, that means "10*12 inches" exactly, to the penny (!). When converting 10,000 feet to inches, they don't mean to the nearest mile. A new interface, allowing "4.5 million" or "12 billion per month" would treat those values as exact.
• Genconv or Gconvert: A version of Convert would use the everyday rounding that most people want as the default-rounding. For them, 200 m becomes 656 ft (not the engineer's "660 ft"). A new option "plusminus=on" could show Mount Everest as "8,848 m (29,029 ±1 ft)" to reveal that 29,028 is also the height. Perhaps, internally, Convert would keep a "user-mode" value to let all subtemplates know that general-user conversions were in effect. That same mode-switch would be reset for bankers or engineers (from the template names "Bconvert" or "Econvert"). A novice user would find {{Gconvert}} easy to use, because of the default rounding and fewer concerns. -Wikid77 05:47, 13 October 2009

As several have noted in earlier discussions, "Convert is only as smart as the user" (although it does make some internal decisions about customary units). A novice user or young teenager is unlikely to know significant digits or metric precision, so the default Convert would be for the general public, and would be the one most seen in articles. As might be expected, engineers, very busy with technical details, would be relieved to know, with Econvert, that finally, all the technical-rounding was automatic for them, following formulae in accordance with well-established engineering standards. No longer would Convert be twisted and contorted with conflicting notions of numeric precision: there would be multiple templates that, internally to each, set the appropriate calculations for each type of user. Every subtemplate could alter its operation based on the user-mode. -Wikid77 01:25 (revised 9:09), 11 October 2009

No. This makes no sense. Could you please read and make a serious attempt to understand what other people have written on this page, before you continue to put your own badly conceived ideas on it? Thank you.

For your convenience I try to repeat the most important points and explain them with detailed exaxmples. Please make sure that you understand all the following points. If you disagree with one of them, explain why:

• A measurement is almost never exact. Measurements come with various levels of precision, depending on a) the precision of the method used for measuring, b) the precision with which the used unit is defined, and b) the conventions of the context in which the measurement is given.
• The level of precision is almost never given explicitly. Up to a certain point it can be inferred from the number. Some examples:
  • "7.387 metres." Inferred precision: ±0.001 metres.
  • "7387 metres." Inferred precision: ±1 metre.
  • "73870 metres." Inferred precision: anything between ±1 metre and ±10 metres.
  • "73865 metres." Inferred precision: anything between ±1 metre and ±5 metres.
  • "73875 metres." Inferred precision: anything between ±1 metre and ±25 metres.
  • "73850 metres." Inferred precision: anything between ±1 metre and ±50 metres.
  • "74000 metres." Inferred precision: anything between ±1 metre and ±1000 metres, but most likely between ±100 metres and ±1000 metres.
• If several similar measurements are given in a row, we get additional information since they are usually given to the same level of precision:
  • "73870 metres and 73875 metres," Inferred precision: anything between ±1 metre and ±5 metres; probably ±5 metres. (Compare this to the separate values above.)
  • "100 metres and 100.5 metres." Inferred precision: ±0.5 metres.
• When converting to a different unit, we must a) make an exact conversion, b) make an assumption about the level of precision in the original measurement, c) convert the level of precision, and d) round the converted measurement in accordance with the converted precision. Detailed examples:
  • "7.387 miles." a) Exact conversion: 11.888224128 kilometres. b) Assumption about precision of original measurement: ±0.001 mile. c) Converted precision: ±0.0016 kilometres. d) Appropriate conversions would be "11.888 kilometres" (implied precision: 0.001 kilometres), "11.89 kilometres" (implied precision: 0.01 kilometres). The first option gives a more exactly converted number but may claim greater precision than is present in the original value. (Technically this is a lie about the level of precision, making us unreliable.) The second option loses a bit of the precision but makes sure not to lie.
  • "100 miles." a) Exact conversion: 160.9344 kilometres. b) Assumption about precision of original measurement: Impossible to say without context, but since we have to take a decision, ±10 miles seems reasonable. c) Converted precision: ±16 kilometres. d) Appropriate conversions would be "160 kilometres" (implied precision: ±1 kilometres to ±10 kilometres, lying a bit) or "150 kilometres" (implied precision ±1 kilometres to ±50 kilometres).
• The template is forced to guess the level of precision. It follows the following principles:
  • For simplicity it assumes that the level of precision is always of the form ..., 100, 10, 1, 0.1, 0.01, ....
  • When there are several possibilities, the templates assumes less precision, not more. E.g. with "74000 metres" it assumes ±1000 metres not ±1 metre, ±10 metres or ±100 metres. (There is some correction for extreme cases such as "100 miles", which would otherwise be converted into "200 kilometres". Not sure about the details, but it seems reasonable.)
• The level of precision is then converted following simplistic rules such as ±1 mile → ± 1 kilometre, and the result of the exact conversion is rounded accordingly.
• For cases where the template guesses wrong, we have an optional parameter that tells it which digit should be the last significant one in the converted measurement. Hans Adler 12:00, 11 October 2009 (UTC)

Yeah, you are correct on almost everything. Few people would understand 73875 to be rounded to the nearest 25 unless explicitly stated, anyway. As for 100 miles, it does assume that it has one sigfig, but then there's an exception which forces at least two sigfigs in the output, yielding the over-precise 15 kilometres (9.3 mi) which first triggered me to question the default rounding, months ago.

So there are several issues:

1. We agree that 123 miles is to be understood to be ±1 mile (or ±0.5 miles, depending on how you define "±", but that's immaterial for the rest). But, short of having explicitly stated uncertainty in the output, we can't have an output understood to be ±1.6 kilometres (or ±0.8 kilometres according to that other interpretation); so we have to choose between ±1 km and ±10 km (±0.5 km and ±5 km). So to speak, we have to choose between a "precision scaling" of 0.62 and one of 6.2; now the template works so that the precision scaling is always between 0.5 and 5, which has the effect of giving unusually rounded conversions for inches-to-centimetres and kilograms-to-pounds; precision scalings between 0.3 and 3 would yield more typical roundings. A good idea from a mathematical POV would be imposing precision scalings between 1/√10 and √10, but then we'd need an exception for metres-to-feet to avoid ±1 m to convert to ±10 ft. In any event I don't think there will be many other conversion factors between 3×10ⁿ and 3.33×10ⁿ, for which these last three proposals would differ.
2. We have to decide whether 40,000 is ±1, ±10, ±100, ±1000 or ±10000 in absence of indications to the contrary. Now the template assumes the last, but I think that the penultimate is usually more likely. Where we are at it, we could implement a way to specify that directly in the input: for example, 40000. with a trailing point could be assumed to be ±1, 40. thousand could be assumed to be ±1000, 0.04 million to be ±10000, and so on with "hundred", "billion" and "trillion".
3. We have to decide whether there must be a minimum precision in the output. Now the template uses the rule of "at least two sigfigs in the output", which in some cases is overkill (see the 15-kilometre example above). My proposal would have to avoid having (1 ± 1)×10ⁿ, (2 ± 1)×10ⁿ, and maybe (3 ± 1)×10ⁿ by using one more significant figure in the output in these case, but IMO there's nothing wrong in (9 ± 1)×10ⁿ (e.g. 15 kilometres (9 mi). (Also, I don't get the point of the exception for temperatures. It is a pointless complication in most cases and a harmful one in a few ones.)
4. Maybe, having a ~ in front of conversions ending with a non-significant zero (e.g "~23,460" if it means 23,460±10 so that the reader won't be misled into thinking that "23,460" means 23,460±1) could be an idea. What do you think?

___A. di M. 15:21, 11 October 2009 (UTC)

I think the ~ suggestion has merit. Orderinchaos 05:51, 12 October 2009 (UTC)

• To User:Hans Adler: I'm sorry you're upset, but my ideas are not "badly conceived" - I've been working on Template:Convert & the 2,410 subtemplates for 2 years (convert 2 as to 2*365 days, not 18 months rounded). The concerns listed above, about measurement precision, are only for engineering measurements. I think a source should be quoted, as some engineering standard, that considers 100 to be ±10 and 1,000 to be an engineering measurement of ±100 (not ±500). Meanwhile, when a banker says "$4,000" then that is not ±1000; it is NOT even ±1 dollar, but rather exactly $4,000.00 to the penny. I'm sorry, but taking an attitude which questions my understanding of the above discussions, after working on Template:Convert for 2 years, only further confirms my conclusion: the use of Convert as an engineering tool is totally at odds with the use for general-purpose conversions. I would ask, in return, how many years of experience do others have in working with banking calculations, such as calculating the monthly payment for credit life insurance on a consumer loan? I am not a novice or some computer hack. -Wikid77 (talk) 02:56, 12 October 2009 (UTC)

To be honest a large part of the opposition you're encountering here is because of the way you're going about it. Pretty much I've just seen pages and pages (much of it repetitive) of attacks and sarcastic comments on the template and its operation. In general people want to cooperate in good faith and take umbrage at those who don't appear to share that desire. I can't speak for your motives, only for how it looks from the other side of the computer screen. Orderinchaos 05:51, 12 October 2009 (UTC)

• I've seen several different reasons for opposition, not because of sarcasm. I have proposed several changes which are a "shock to the system", so that's a major reason for opposition: for example, changing 1,000 to mean 999+1 (4 significant digits, by default). It might seem like sarcasm, but bankers really do have a totally different view about the numbers: to a banker, the number "200" is not just 1 significant digit, but rather 5: $200.00 (Many bankers even dislike writing "200" without the ".00"). Meanwhile, internally to Template:Convert, there are 2,410 subtemplates, and the many thousands of articles that use them. There are numerous reasons for opposition to major changes. -Wikid77 (talk) 05:46, 13 October 2009 (UTC)

I think you are totally wrong about this having anything to do with different fields. Especially the banking example is not convincing at all. Yes, a banker must convert currencies (not lengths etc., which he/she has nothing to do with) according to a precise conversion rate. However, for any pair of currencies there are several such conversion rates for different purposes, and they change every day, some even every minute. (There are very rare exceptions such as the Bulgarian lev, whose relation to the Euro doesn't change because it is legally defined as precisely one Deutsche Mark, which in turn is legally defined as precisely 1/1.95583 €. But I assume you are not talking about that.) For almost all intents and purposes that occur in an encyclopedia, 100 $ is roughly 70 €, not precisely 67.7966 € on last Friday, 67.7369 € on last Thursday, 69.8617 € on 1 September, 75.3874 € on 1 May, etc.

There is a tendency at this encyclopedia (and not just this one, but also some printed ones) to lie by making absurd statements such as "The population of Norway in 2009 has been estimated as 4,839,008". Really? Does this mean that for every person who enters/entered the country during the year 2009 someone else has to leave on the same day? If they are that good at regulating their population it's not surprising that they can estimate their population as 4,839,008 as opposed to, say 4,839,007 or 4,839,009. Or even 4,840,000 – the kind of number you would expect as an estimate from less omniscient statisticians. Now let's get serious again. If you look at what is supposed to be the source for this strangely exact number, you will find a serious website that doesn't seem to make any such absurd claims of precision, although it does claim to give us the population number right now. It's not clear (to me) whether this is just a silly projected number or the official number right from the government computers. In any case it seems to be increasing every few minutes. My guess is that an editor simply copied this number and felt that changing 4,839,007 to 4,840,000 would have been "original research". No, rounding is not original research, but not rounding in such a case is misrepresentation of the source. Hans Adler 08:52, 12 October 2009 (UTC)

• When bankers handle currency conversion, they do in fact, demand precision to the daily (or hourly) rate. They might estimate that $100 is roughly 70 €, put when the conversion is actually made, then the $100 is $100.00 (to the penny) and the exchange rate is also used exactly (to the last decimal). A customer cannot say, "Convert the currency using yesterday's rate, which was better, but consider it as a matter of rounding if your manager asks about it" (that is totally unacceptable). It might seem like excessive sarcasm, but please note: rounding of measurements to an engineer is considered the crime of larceny to a banker. Every calculation is determined as exact, to the penny. The number 200 does not have just 1 significant digit; it has 5 ($200.00). When insurance premiums are calculated, the amount must be exact to the penny, and it must match what the insurance company charges; even though the formula is a company-confidential secret, the amount must be calculated, in some equivalent manner, to match exactly. -Wikid77 (talk) 05:46, 13 October 2009 (UTC)

  But we're talking of what we should do on Wikipedia, not what bankers do. Saying that 10,000,000 Swedish kronors is 1,435,543.23 US dollars is excess precision unless we specify "as of 10:47, 14 September 2009 (UTC)", which is something completely pointless for a reader who just want to know roughly how much the money prize for the Nobel Prize in Physics is. ___A. di M. 10:22, 13 October 2009 (UTC)

  Indeed, also noting that currency is very variable. For example the Australian dollar has been valued at everywhere between 60.2 and 97.8 US cents, and between 41 and 54 57 UK pence since just the middle of last year. (I give my own only because I know the figures off the top of my head - any non-pegged currencies would have similar interchange issues.) Orderinchaos 11:22, 13 October 2009 (UTC)

Indeed I tend to round currencies much more roughly than other measurements: see the last paragraph of Nobel Prize in Physics#The Award. But maybe Wikid77 was thinking of conversions such as from dollars per square foot to dollars per square metre. (As for the population of Norway, I agree, but I'd write 4.84 million so that it's more obvious that it's approximate. Using zeroes as placeholders when there's a obvious way of avoiding that is one of my pet peeves.) ___A. di M. 09:21, 12 October 2009 (UTC)

• I agree that the general public also rounds the currency amounts (perhaps not as much as in engineering), but the level of precision required by a banker exceeds the level typically used by the general public. -Wikid77 (talk) 05:46, 13 October 2009 (UTC)

• Could you please give a specific example of a specific number in a specific article, where "the level of precision required by a banker" is appropriate. There may be plenty of such examples in the parts of Wikipedia where you are editing, but I don't think I have ever seen one and I am having difficulty imagining it. Hans Adler 14:21, 13 October 2009 (UTC)

  In principle, "the speed of light is 299,792,458 m/s" has infinitely many significant figures, so "299,792,458 m/s (1,079,252,848.8 km/h, ~670,616,629.384 mph)" isn't incorrect. It's just totally pointless (pronounced "silly"). ___A. di M. 14:49, 13 October 2009 (UTC)

• Bankers' calculations aren't actually very accurate, they're just consistent. They have rules and they follow them whether it makes any sense or not. Case in point: One fellow I knew in Australia got a bill for 3 cents. After some argument (and warning notices that they would sue if he didn't pay), he went to the bank to pay it. Since Australia had discontinued minting the 1 cent coin, he handed them a 5 cent coin. The bank now owed him 2 cents, but Australia had also discontinuted minting the 2 cent coin. The bank had a policy of always rounding in the customer's favor, so they handed him back his 5 cent coin, stamped his bill PAID, and thanked him very much for his business.RockyMtnGuy (talk) 16:43, 14 October 2009 (UTC)

  In Italy we have a €1.10 tax on cash payments of bills, so here he would have had to pay €1.10 anyway. ___A. di M. 18:28, 14 October 2009 (UTC)

Gconvert

{{Gconvert}} is up and running. Wikid77 has already created the rival convert. He has even introduced to an article replacing this template and providing us with a number a prime examples of how "number sense" in the absence of any solid mathematical basis leads directly to nonsense. Lerma River is currently a show case for false precision with such wonderful examples as "over 3,000 metres (9,843 ft)", "about 560 kilometres (348 mi)", "400-kilometre (249 mi)" and "more than 2,600 metres (8,530 ft)". Yep, we often tend to use words like "over", "about" and "more than" to introduce an approximate measure. Context is important and can't simply be divided into general, engineering and banking. This idea of writing several versions of the template to fit each context is ill-conceived. It's hard to imagine a better illustration of the fact that alternative conversion templates make it harder rather than easier to get it right than when the creator of such a thing fails to use it correctly ... especially when he's spent "2*365 days" working on this one. JIMp _talk·cont 21:50, 13 October 2009 (UTC)

• The new template Gconvert is still being expanded, as I compare results to the operation of Convert. It is not a "rival" template, but rather a variation, with different defaults for rounding:

Convert: 6 feet 2 inches (188 cm)   Gconvert: 6 feet 2 inches ()

Convert: 6 feet 2 inches (1.88 m)     Gconvert: 6 feet 2 inches ()

I'm comparing to get results similar to what other users have requested above. -Wikid77 (talk) 22:56, 14 October 2009 (UTC)

Jimp, you're more than welcome to take the new template to TfD as a duplication of effort of Convert. I won't because I've previously deleted similar templates he's created. And if Wikid77 is watching, stop using terms like "illegal AfD" and "legal AfD" when discussing the discussion processes. Legalities are completely a non-issue with discussing meta topics like templates. — Huntster (t @ c) 23:43, 13 October 2009 (UTC)

Once I was tempted to round the conversion in "There are 18 peaks over 3000 metres (9843 ft) in the South Island" to 10,000 feet, but since I was (and am) unaware of whether there's any peak between 9843 and 1000 feet, I refrained to do that. But that doesn't apply to the Lerma River article. The conversion of the length of Rio Grande is particularly misleading, since the reader might think that it's 400 km to within 1 km, whereas it is 433 km according to its article. But having 433 km in the Lerma River article too is a better solution than rounding the conversion to 200 miles. ___A. di M. 00:39, 14 October 2009 (UTC)

Artificial intelligence is no substitute for the real thing, and it's always useful to check the results of a conversion for bloopers before clicking on the "Save page" button. I keep a metric conversion calculator handy for this purpose. However, the Lerma River article does demonstrate that the Gconvert macro produces more misleading and weird-looking results than the Convert macro:

• more than 2,600 metres (8,530 ft) vs. more than 2,600 metres (8,500 ft)
• about 560 kilometres (348 mi) vs. about 560 kilometres (350 mi)
• a length of 750 kilometres (466 mi) vs. a length of 750 kilometres (470 mi)
• at 1,510 metres (4,954 ft) above sea level vs. at 1,510 metres (5,000 ft) above sea level
• the 400-kilometre (249 mi) long Río Grande vs. the 400-kilometre (250 mi) long Río Grande

I think it demonstrates the lack of utility of Gconvert. Convert works well in most cases. If you don't like what Convert does, just adjust the precision using the parameters. As far as the 18 peaks over 3000 metres (9843 ft) example is concerned, convert produces over 3,000 metres (9,800 ft), which is just fine - people don't normally measure the height of peaks to the nearest metre or foot, and often a change in the weather throws their altimeters off quite badly. Even GPS units can get it wrong by a few hundred feet if the satellites are badly located when you take the reading.RockyMtnGuy (talk) 16:02, 14 October 2009 (UTC)

Ordinary people don't, but at least here, most maps give peak heights to within one metre, and different maps normally agree on the height of the same peak, so I'm not entirely sure that "1,510 metres" was rounded to the nearest ten. (In the train station in my town there's a stone slab with an horizontal line marked as "392.11 metres above sea level" or something, and I agree that that is excess precision.) ___A. di M. 18:28, 14 October 2009 (UTC)

• As he noted above, the words "over" or "roughly" work for most whole-number measurements: "over 3000 m" or "over 9843 ft", the meaning is still an approximation. That's why it is not nonsense but rather, true. -Wikid77 (talk) 22:56, 14 October 2009 (UTC)

just wanted to say thanks

I've been following the long discussions here lately with interest, but there is nothing much I can add beyond what has already been said. I just wanted to say in my personal experience practical problems with the templates, be they technical or, er, user error, are handled promptly, politely, and accurately, and I thank all the regs here for that.

I do think the docs could do with some restructuring and am happy to contribute to the leg-work of sub-editing that in any way I can. That is not just to fire up another load of parallel discussions, and I think if there is any major rewrite of it, it should almost be stated at the outset that the talk about the docs specifically excludes talk of the operation of the template itself, just documents what it actually does.

My best wishes to you all. SimonTrew (talk) 16:24, 14 October 2009 (UTC)

Yeah, I've recently re-worded the explanation of the default precision, as many people seemed to misunderstand it. ___A. di M. 18:28, 14 October 2009 (UTC)

Simon, if you find anything in the /doc page worth updating, my suggestion would be to work on something in your userspace and then link here for review. That type of thing is always welcome. And I agree with you regarding your last point...discuss how to use it, not how it operates. That can be discussed on a subpage...no need to clutter the main documentation. — Huntster (t @ c) 03:44, 15 October 2009 (UTC)

Annotating quotations with: disp=output only

14-Oct-2009: Some users have expressed an interest in using conversions inside the bracket-editorial comments, within a quotation: using just the converted amount. Note that excessive comments inside a quotation could clutter the original wording; however, for some numbers, it could be better to insert them (as "[252 ft]"), rather than repeat all the measurements outside the quotation. Consider a possible quotation:

"During the expedition of 1907, our team estimated the mountain's height at 6700 total metres [22,000 ft]. However, years later, the elevation was revised to 6,841 met. [22,510 ft], after another voyage."

Within the brackets, the conversions use "disp=output only". Because of the lack of commas (and the word "total"), the exact text cannot be re-generated from Convert, so only the data in brackets "[ ]" is inserted using Convert, but suppresses the original amounts by using the option "disp=output only". That option allows Convert to be used inside a quotation, without altering any of the original wording as quoted. -Wikid77 (talk) 22:56, 14 October 2009 (UTC)

Rounding to 2 fewer significant digits

15-Oct-2009: One of the problems of the default rounding, in Template:Convert, is when rounding upward past a "9" such as 3951, 4957 or 5953, so that the result becomes 4000, 5000, or 6000 (etc.). Because rounding past a 9 will carry +1 to the next digit, the number of significant figures drops to 1 (as in "4" of 4000). This problem could be avoided by rounding to 1 less, to chop 1 less digit, as r-1. Hence, a rounding of 3951 for 3 digits (as 4000) would be reversed to become "3950" (by rounding just the first digit). However, a number such as 4957 would be reverse-rounded to 4950+10 (the 10 comes from rounding digit 7 to 10), so the amount would be 4960. A change to the default rounding in Convert would then prevent the current case of:

Convert: 1,510 metres (4,950 ft) → reverse-rounded: 1,510 metres (4,950 ft)

Because of the default rounding, the value as 5,000 has only one significant digit, and it is far from the original amount of 1510 m. When re-converting 5,000 ft, the result becomes 1524, which is 14 metres off the original amount. The current rounding is causing severe problems. I think that such problems could be detected by a sight-check: if Convert returns a value that has "many zeroes" (such as "5,000"), then the user should know the result is likely to be incorrect. Thanks to all, above, who spotted this issue with the default rounding. -Wikid77 (talk) 01:39, 15 October 2009 (UTC)

Interesting claims by Wikid77

Is Wikid77 attempting to pass himself off as a contributor to this template? He claims "I am one of those who have worked, for years, to modify Template:Convert." He also says "Because of the complexity of Template:Convert, improvements have taken weeks or months to fully implement for all cases. Please understand, there are hundreds of details which must be considered, and volunteers have only limited amounts of time." And he writes "I've been working on Template:Convert & the 2,410 subtemplates for 2 years". No, Wikid77, a few edits to the doc page doesn't quite cut it. I'm not sure what the purpose of these claims are but I put it to you, Wikid77, that they aren't particularly helpful. JIMp _talk·cont 21:50, 13 October 2009 (UTC)

Indeed. I had wondered about that myself as I'd never seen his name before this debacle. On looking I note that before the last two weeks, some documentation changes in September and 3 edits (again to documentation) in late 2007 (with none in between) are his only contributions to the templates, yet he talks like he is one of its developers. It can be checked quite easily by looking at contributions -> template mode -> 500 at a time view. Orderinchaos 13:25, 14 October 2009 (UTC)

• My work on the template, over the past 2 years wasn't in wiki-edits, but rather in long-term detailed analysis, plus some changes to documentation. However, now I am focusing on changes to the subtemplates. -Wikid77 (talk) 22:56, 14 October 2009 (UTC)

• 7 edits to documentation. Even I have made more changes to convert, and that's actually saying something (I'm most definitely not a developer). There is a huge perception gap between "Convert needs changing!" and "I am a developer of Convert and I think Convert needs changing!". Orderinchaos 04:04, 15 October 2009 (UTC)

• I'm sorry if I gave the impression that I wasn't actually willing to help with the work; see below: #Working to make improvements. -Wikid77 14:53, 15 Oct 2009

Wikid77 really needs to start taking his medication again - this flurry of pointless activity is getting really annoying.RockyMtnGuy (talk) 17:01, 15 October 2009 (UTC)

• That's what the nurses tell me at the front desk (just kidding). No, since I was already analyzing the performance, I figured I would develop those 70 subtemplates, while I was familiar with the formats. Plus, when a guy in the mountains of Andorra wants to use Convert with "disp=comma", then that's a sign to get it finished. I know those templates might seem like "pointless" work, but they form complete sets, and I followed a pattern that helped me focus on each of the 70 different subtemplates. -Wikid77 (talk) 00:16, 16 October 2009 (UTC)

Working to make improvements

A number of people have wondered if I really intended to help improve Convert, or just came to the talk-page, raising several issues, as empty promises, and would then leave to work on a "rival template" without actually staying to help. I understand that Template:Convert requires a lot of detailed testing to make careful changes, and I do intend to help with the work, more than just talk. Today, I have been working to finish the implemention of "disp=comma" after User:ClickRick had stopped making changes back in February 2009. The reason it has taken several days, to affect the live Convert, is because I have been making user-space copies of the subtemplates to try the various suggestions that others have proposed in the topics above. I didn't want to insist on making a change to Convert, when that idea hadn't been carefully tested beforehand. Meanwhile, someone from Andorra (writing above #Bug due to recent change?) again noted that "disp=comma" was not working, so that's why I shifted to fixing that issue next. -Wikid77 (talk) 14:48, 15 October 2009 (UTC)

Kilogram force not working

When using following:

convert|15.9|kg-m|Nm lbft||abbr=on

A red error message is shown instead of converting 15.9 kilogram metre to Newton-metre and pound foot. -- Jacob Poon (talk) 04:00, 9 October 2009 (UTC)

• Use units as "kgm" and let the output default by {{convert|15.9|kgm|abbr=on}} to get: 15.9 kg⋅m (156 N⋅m; 115 lbf⋅ft). -Wikid77 (talk) 10:15, 9 October 2009 (UTC)

• Your suggestion worked as intended, except as soon as more parameters are added, eg: {{convert|15.9|kgm|Nm lbft|abbr=on}}, the error message appears again. Anyway, {{convert|15.9|kg-m|abbr=on}} simply does not work. -- Jacob Poon (talk) 19:42, 16 October 2009 (UTC)

We are still waiting on Jimp to correct the code to reflect to what is on the table for torque conversions.... 「ɠu¹ɖяy」¤ • ¢  19:06, 10 October 2009 (UTC)

Finishing subtemplates for: abbr=none

17-Oct-2009: I have finished creating about 40 (of 60? total) subtemplates to allow the display option "abbr=none" which shows all unit-names as full names (not the unit symbols), where applicable. It is intended primarily for situations such as "32.0 metres (105.0 feet)" where neither unit is abbreviated. -Wikid77 (talk) 14:05, 17 October 2009 (UTC)

Bug due to recent change?

{{convert|2865|m|ft|abbr=on|disp=comma}} is generating an error because it requires a non-existent subtemplate Template:Convert/LoffAonDcommaSoff. 85.94.166.161 (talk) 01:21, 15 October 2009 (UTC)

• Any unknown value for "disp=" will display a similar message, such as "disp=aardvark": {{convert|2865|m|ft|abbr=on|disp=aardvark}} looks for: Template:Convert/LoffAonDaardvarkSoff. Thanks for reporting that issue; it will help others to fix the problems sooner. -Wikid77 (talk) 01:39, 15 October 2009 (UTC)

Fixed. Okay, I have created the missing subtemplate. Again, thanks for letting us know. It was easy to fix, but had been overlooked. The result now is: {{convert|2865|m|ft|abbr=on|disp=comma}} - 2,865 m, 9,400 ft. -Wikid77 (talk) 01:56, 15 October 2009 (UTC)

It's working well. Thank you. 85.94.166.161 (talk) 18:13, 18 October 2009 (UTC)

Please add this pressure unit

I would like to add centimetre of water (cmAq) and inch of water (inAq), two units of pressure. They are not uncommon units, and their conversion factor are 1 cmAq = 98.0638 Pa and 1 inAq = 249.0889 Pa --Quest for Truth (talk) 22:38, 22 September 2009 (UTC)

"cmAq" or "cmH₂O"? 98.0638 Pa or 98.0665 Pa? The centimetre of water article says 98.0638 Pa but the pascal (unit) article says 98.0665 Pa. This website agrees that it's 98.0638 Pa. These say otherwise i.e. 98.0665 Pa. Which is the true value? Both it seems. Two versions of the same unit. So what do we go with? JIMp _talk·cont 08:09, 23 September 2009 (UTC)

What do you do for mmH
₂O? Surely cmH
₂O would simply be ten times that (or a tenth of that, depending on which way you're counting)? I've seen mmH
₂O (and ^mm
Hg) a lot but never cm.

I suppose that gives you a get-out clause in that you could have cmH
₂O and cmAq with different factors! SimonTrew (talk) 19:06, 23 September 2009 (UTC)

Yes, not only should 1 mmH
₂O equal 0.1 cmH
₂O but I'd argue 1 inH
₂O should equal 2.54 cmH
₂O. The idea of having cmH
₂O for one value & cmAq for the other ran through my head but which would be which, either way, though, it'd be a convention made up by us. JIMp _talk·cont 20:06, 23 September 2009 (UTC)

I am not sure if I would go so far as it being a convention made up by us, since nobody is obliged to use it (though I suppose that is true of SI and whatever also, except where mandated by law). But I understand your queasiness both in maintenance ("it says 0.9999w36q87e6987q346 instead of 1") and in seeming, unnecessarily, to have invented a unit. I searched my Science Data Book (Ł1,66 when published in the 13th impression of 1989) and found nothing on it, though it is rather good on log tables and I must be one of the few here who can genuinely do it quicker on a slide rule than a calculator, to about 3 or 4 sig fig. But it is silent on the matter as far as I can tell, though gets a kick on the permittivity of free space, which is literally all Greek to me.

I think the itinerant Greg L misses the point a little. Jimp as usual has done his research and found three different numbers all claiming the same thing. Which one to take? The best recourse is quietism, i.e. after consideration do not provide it, since inevitably convert will (because of how good it is) be taken as a de facto standard and that is exactly what he wants to avoid. However, I come here as the originator did for practical answers to practical questions, not because we get on our high horse and ride off to Sévres. SimonTrew (talk) 22:42, 24 September 2009 (UTC)

• I didn’t miss anything. If you want to call Wikipedia’s article on the unit, which isn’t even cited, a “number” (as if it’s worth paying attention to or worth getting confused over) knock yourself out. Like I wrote below, the value there is the result of Original Research by someone who doesn’t know what he or she was doing. That simple. Greg L (talk) 22:49, 24 September 2009 (UTC)

  P.S. Quoting you: itinerant Greg L?!? Why, I resemble that statement. Greg L (talk) 23:17, 24 September 2009 (UTC)

Greg L, I hope it was taken as it was given. An itinerant is one who passes through. It was certainly not my intention to offend. Well at least, not much... :) SimonTrew (talk) 23:35, 24 September 2009 (UTC)

• Not at all. Joke. I wrote “I resemble that statement,” not “I resent that statement.” No worries. Greg L (talk) 23:40, 24 September 2009 (UTC)

Good. I can spell, too. I just know written that sometimes things said in jest do not carry as they would face to face. Let's leave us both be happy and get back to the matter in had. Full disclosure: I have asked for Jimp's help with some conversion templates I have from Hungarian to English. These are not at all related to this, as far as I can tell, but to disclose. SimonTrew (talk) 00:25, 25 September 2009 (UTC)

• Passing through. The conversions for water column at 4 °C assume water at precisely 1 kg per cubic decimeter under precisely on standard gravity and ignore the vapor pressure over the column. Thus, one centimeter of water (4 °C) is precisely 98.0665 pascal. One inch of water is precisely 249.08891 Pa.

  These slightly lesser values (like 98.0638) are home-brewed (read: WP:OR) things by people who do stuff like looking towards the latest experimentally derived values for VSMOW water at 3.984 °C. That value is 25.05 ppm less than precisely one kg per liter. None of these nuances changes anything since, in real life, the vapor pressure over water would screw things up many orders of magnitude more than the small density difference (an effect with which most home-brewers are unaware).

  There is simply no point to adjusting values to account for real-world differences like a 25 ppm shortfall in density if one is going to turn right around and not compensate for vapor pressure over the column. Accordingly, the pressure-measuring world just takes the value for kgf/cm² and multiplies it by 1000 to obtain “cm H₂O (4 °C)”

  Believe me, I could write a book on this stuff, including ultra-low pressure (high vacuum) work with mercury McLeod gauges. In fact, my first patent was on an electronic pressure/temperature-measuring instrument. Any time you want the definitive conversion value for a pressure, contact me on my talk page. As for water columns at some other temperature, like 60 °F, I’d have to research it to see what convention is typically used; never bothered to look into those before. I personally wouldn’t bother. Greg L (talk) 22:49, 24 September 2009 (UTC)

If I were in charge of standards, I'd make it 98.0665 Pa and that would be that ... no hang on, I'd abolish the unit altogether ... 98.0665 Pa makes more sense the other seems to be some fiddly adjustment to make it better fit a real water column ... but who measures pressure with a water column anyhow? 98.0665 Pa seems to be the most usual definition, can we settle on this or are we likely to run into strife with people trying to convert the wrong cmH
₂O? Whilst we're at it, according to WP 1 Torr and 1 mmHg are slightly different; absurd but is it true? JIMp _talk·cont 14:36, 26 September 2009 (UTC)

The U.S. NIST gives two different factors for centimeters of water:

• centimeter of water (4 °C) 98.0638
• centimeter of water, conventional (cmH2O) 98.0665

The best choice for this application is probably 98.0665 Pa.

The NIST notes that additional digits are not justified because the definitions of the units do not take into account the compressibility or change in density caused by the temperature scale.

It actually gives three factors for inches of water:

• inch of water (39.2 °F) 249.082
• inch of water (60 °F) 248.84
• inch of water, conventional (inH2O) 249.0889

And of course you can't convert directly from inches to centimeters because the standard conditions are different. This is the problem with basing standards on water. The properties of water are highly variable depending not only on temperature, but also on the purity of the water and the atmospheric pressure and vapor pressure of the air above it.RockyMtnGuy (talk) 15:59, 26 September 2009 (UTC)

If the conventional value & the 39.2 °F value were 249.08891 Pa and 249.082052 Pa, you could convert directly to one of the centimetres of water values. JIMp _talk·cont 20:19, 6 October 2009 (UTC)

I agree to use the conventional one as it seems to be more commonly used. --Quest for Truth (talk) 06:50, 17 October 2009 (UTC)

I think the most important question is about the "standard". A centimetre of water is defined as the pressure exerted by a column of water of 1 cm in height at 4 °C (temperature of maximum density) at the standard acceleration of gravity. But inch of water can be at different temperature. Perhaps we should select some commonly used temperatures instead of one for inch of water. --Quest for Truth (talk) 12:47, 19 October 2009 (UTC)

Suppressing output of input value?

Is there a way to tell the template to only output the converted value, not the input value? I have a situation where one measurement is being converted into a few different units and thus don't want the original unit value repeated multiple timed. --Cybercobra (talk) 04:19, 19 October 2009 (UTC)

use disp=output only. This is not well documented, as far as I can tell. For example

I'd walk {{convert|1609000|km|mi|disp=output only}}

produces:

I'd walk 1,000,000 mi

I am not sure if this is available for all conversions. I have asked before. SimonTrew (talk) 08:26, 19 October 2009 (UTC)

disp= parameter poorly documented

The disp= named parameter is, in my opinion, poorly documented.

First, the documentation is kinda the wrong way round (though that's very much open to debate I guess); the parameter value should be specified first, its behaviour/effect afterwards.

Second, some values such as the output formats are really not documented at all (e.g. output only), as far as I can tell. Since I do not know much about these, or whether they apply to all conversions, I am not qualified to improve the documentation here, though am more than willing to help. This seems to catch people (including me) a lot.

Best wishes SimonTrew (talk) 08:31, 19 October 2009 (UTC)

• Thanks for helping. Currently, "disp=output only" works for all single units (output unit must be specified) & some double-units, but only a few options beyond lk=off & abbr=on. So far, this happens:

{{Convert|2|m|ft|disp=output only}}              gives: 6.6 ft

{{Convert|2|m|ft|disp=output only|abbr=on}}   gives: 6.6 ft

{{Convert|2|m|ft|disp=output only|adj=on}}     gives: 6.6 ft

{{Convert|6|ft|2|in|cm|disp=output only}}               gives: 188 cm

{{Convert|6|ft|4|in|cm|disp=output only|abbr=on}}   gives: 193 cm

I will try to add the most likely options. As currently designed, Template:Convert would require 3 full-time developers to implement all options, so there are major stress and burnout issues for people helping on this task. -Wikid7715:45, 19 Oct 2009 (revised at 17:18)

Terameters

Ok, I tried to add terameters (Template:Convert/Tm) by naively copying & adjusting the gigameters template (Template:Convert/Gm), but it's not quite working with the options I need.

{{convert|110.66|AU|Tm|lk=on|disp=output only}} gives: "16.555 Tm" with the right link but the wrong name.

However, without the lk=on it works okay: "16.555 Tm"

How would I go about trying to make this work? --Cybercobra (talk) 18:12, 19 October 2009 (UTC)

{{convert|110.66|AU|Tm|lk=on|disp=output only|sp=us}} gives: "16.555 Tm" with the right link and the right name.

Best wishes Si Trew (talk) 23:30, 19 October 2009 (UTC)

Temperatures ranges working for logical options

21-Oct-2009: I have fixed the temperature-range conversions of °C, °F & Kelvin by adding many subtemplates to handle all the major ranges & options, such as "{{convert|30|to|70|F|C|lk=in}}" to give: 30 to 70 °F (−1 to 21 °C). Options include:

• dual ranges: 10|to|20, 10|and|20, 10|-|20 (perhaps more?)
• options: lk=off, lk=on, lk=in, lk=out, adj=off, adj=on, abbr=off, sigfig=n & round "1" (2, 3, etc.)
• display: disp=comma, disp=or, disp=s (slash), disp=b (parentheses), disp=output only & disp=output number only.

Because there are over 5,148 possible options and parameters, I only implemented the most-logical 260 combinations, in less than 65 subtemplates, rather than the potential of 590 subtemplates to handle all possible combinations of options. -Wikid77 (talk) 23:50, 21 October 2009 (UTC)

Thank you. Seems like there is inspiration to simplify the template hierarchy to make this kind of thing less complex to maintain. —EncMstr (talk) 18:44, 22 October 2009 (UTC)

• Yes, I have found some ways to eliminate over 2,100 subtemplates; see essay-page "WP:A plan to reduce Convert subtemplates". -Wikid77 06:30, 31 October 2009

Density

I might be being dense, but I can't see anything for kg/m^3 into lbs/ft^3 etc...--Jaymax (talk) 05:45, 22 October 2009 (UTC)

• I created Template:Convert/lb/cuyd (for pounds per cubic yd), so if the conversion factor is inaccurate, then edit that template and adjust "b=0.5932789".

{{convert|5|kg/m3|1}}:            5 kilograms per cubic metre (8.4 lb/cu yd)

{{convert|5|kg/m3|1|abbr=on}}: 5 kg/m³ (8.4 lb/cu yd)

The older, related conversions are:

{{convert|1000|kg/m|1}}: 1,000 kilograms per metre (2,015.9 lb/yd)

{{convert|5|kg/m|1}}: 5 kilograms per metre (10.1 lb/yd)

{{convert|1|cuyd|6}}: 1 cubic yard (0.764555 m³)

{{convert|1|kg|lb|6}}: 1 kilogram (2.204623 lb)

Again, because Template:Convert/lb/cuyd is new, you can adjust the scale factor "b". -Wikid77 (talk) 10:02, 23 October 2009 (UTC)

Aviation conversions

1. lb/ft² to kg/m² and vice versa.
2. Under Fuel efficiency: lb/mi and kg/km

Are there way's to do this? I don't see it. Maybe 100 lb/sq ft (490 kg/m²) and 11 lb/mi (). Thanks - Trevor MacInnis ^contribs 17:52, 24 October 2009 (UTC)

Finishing subtemplates for: disp=comma

15-Oct-2009: I have finished creating the remainder of 24 90 (of 288? total) subtemplates to allow the display option "disp=comma" which shows conversions separated by a comma (","). It can be used in a series of adjectives for a description:

"The newer, 21-metre, 69 ft, high-level tower..."

That tower-text uses: {{Convert|21|m|ft|disp=comma|adj=on}} to generate the text "21-metre, 69 ft". I am still double-checking to ensure that the options for lk=on, abbr=on, adj=on will display using the comma-format. -Wikid77 (talk) 14:48, 15 October 2009 (UTC)

• Each separator (such as comma, and "or") seems to require over 285 subtemplates to handle all options for single-unit, 2-unit ("6ft 2in"), and dual-unit (n-by-m) conversions, plus imperial/US units (such as "imperial gallon"). -Wikid77 (talk) 19:46, 26 October 2009 (UTC)

Imperial pints to litres

For some reason, the template isn't working when I want to convert imperial pints to litres using the "disp=or" option. As in: 2.5 imperial pints or 1.4 litres.

Does anyone know what's gone wrong? Wcp07 (talk) 08:44, 25 October 2009 (UTC)

• 26-Oct-2009: Okay, I created another 24 missing subtemplates for imperial-unit results with "or" and that fixed it. -Wikid77 (talk) 19:20, 26 October 2009 (UTC)

Guide to creating a new subtemplate

Is there one? I wanted to create Template:Convert/lb/nmi, and after much trolling around, I can't find any guide to how the sub-templates are formatted. I ended up copying the lb/mi template, but I dont understand what the t, b and j parameters do.

• 10 pounds per nautical mile ()
• 10 pounds per nautical mile ()
• 10 pounds per nautical mile ()

- Trevor MacInnis ^contribs 03:39, 26 October 2009 (UTC)

• Several people have requested a "Guide to creating Convert subtemplates", so a guide is being prepared. Meanwhile, inside each unit-conversion subtemplate (such as {{Convert/ft}}), the template parameters are:

u = unit symbol, n = unit name, l = plural unit name (lowercase L),

h = hyphenated name (singular, such as: mile-per-gallon)

t = text linked (such as article "Miles per gallon" for "mpg")

b = conversion factor relative to base units

j = 2nd conversion-precision (put "5" to show result as 5 digits)

s = combined rounding for sigfig=x plus end-parameter "0" etc.

r = end-spelling as either r=er (American) or r=re

y = unit-code for 4-part unit names

I will try to get more details about parameters b & j. -Wikid77 (talk) 19:38, 26 October 2009 (UTC)

That would be great. And any links to current or old attempts to make a guide would be good. I could help. A few things: "conversion factor relative to base units" what are the base units here? 1 lb, and 1 nmi? And what is "unit-code for 4-part unit names"? - Trevor MacInnis ^contribs 02:53, 27 October 2009 (UTC)

I too look forward to this guide. Thanks for working on it Wikid77. — Huntster (t @ c) 07:04, 27 October 2009 (UTC)

• To write guide-details, I have created "WP:Advanced Convert coding" (an essay page, with shortcut WP:ACONVERT), which also explains the importance of "disp=output only" for customizing output. That essay is only a first draft, with the basics for defining a new subtemplate. However, there are over 12 different styles (or unit-groups) of subtemplates, so the parameters vary for the 12 groups: regular, ranges, 2-unit (ft&in), imperial, US-unit, multi2, etc. -Wikid77 (talk) 05:37, 29 October 2009 (UTC)

New abbreviation options: abbr=in or abbr=out

29-Oct-09: I have begun implementing options to control the input versus the output-abbreviations (similar to linking as options lk=in or lk=out). There are now 5 settings for abbreviation:

• abbr=off, abbr=on, abbr=in, abbr=out & abbr=none.

This is the first time it has been possible to abbreviate just the input units, using abbr=in, and leave full-word form as the output: such as "xx km (xx miles)":

{{convert|16|cm|in|abbr=in}}   gives: 16 cm (6.3 inches)

{{convert|4|kg|lb|abbr=in}}       gives: 4 kg (8.8 pounds)

{{convert|6|ft|3|in|cm}}                 gives: 6 feet 3 inches (191 cm)

{{convert|6|ft|7|in|cm|abbr=in}}      gives: 6 ft 7 in (201 centimetres)

For many conversions, the default has been "abbr=out" so that the km/mi conversions have stated "xx kilometres (xx mi)". I added the options (in/out) for completeness, to allow anything: in, out, both or none. However, I see the logical preference as abbr=in, because for most articles where the culture is metric, then "km" would be obvious, but other readers might wonder about "mi". The use of abbr=in gives "xx km (xx miles)" and also avoids the end-spelling of -metre/meter which has been irritating to some readers. Anyway, this is the first time for users to have a choice of abbreviating just the input unit-names. -Wikid77 (talk) 12:53, 29 October 2009 (UTC)

Fix for rounding - consensus forum

09-Oct-2009: Many people above have already expressed support for changing the default rounding, and others already append a round parameter "0" or "2" when using Convert. This forum here is just to log any concerns people have, before changing the default rounding. Note that this change would not be "set in stone" as the final change ever made to Template:Convert. Other changes will come in the future.

Proposal: Change the default rounding to increase precision by +1 for conversions over 2.0 times greater. This affects numbers that increase, such as: 32 m (105 ft) [from 100ft], 84 kg (185 lb) [from 190] or 16 ft 2 in (188 cm) [from 190], where the 2nd number is larger, but not 10-to-5 or other smaller conversions. Also, it does not affect miles-to-km because miles are only 1.61 km (or "1.609344"), below the factor of 2.0.

Consensus status 2009-10-30: By the end of October (3 weeks), there had been no formal oppose comments; however, the exact impact of the change was questioned by multiple people, and there was only one support comment.

Comments on proposed rounding

Add comments, about the above proposal, in the subsections below. The reasoning, behind changing the default rounding, is presented in the section above: "#Fix for rounding - rationale".

Support the proposed rounding

Strong support. Many people are concerned, and the fix will match world-standard amounts. Novice users or young teenagers will be able to just code "{{convert|32|m}}" or height "{{convert|6|ft|2|in}}" without concern for significant digits or metric precision. Meanwhile, any alternative rounding-tactics could be considered for future updates. This would not be mandated as somehow the final change for rounding in Template:Convert. -Wikid77 (talk) 13:56, 9 October 2009 (UTC)

Oppose the proposed rounding

Log any objections or major concerns in this section:

Oppose. (...followed by reason why...)

Other comments

I'm not 100% sure I understand the proposal. Now the template specification says:

If neither the desired precision nor the desired number of significant figures are specified, the conversion will be rounded either to a comparable precision as the input value (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.) or to two significant figures whichever is the most precise.

Is this a proposal to change “between 0.2 and 2” to between 1 and 10, “between 0.2 and 2” to between 10 and 100 and so on? And what would become of the two-significant-figure exception? And what about the exception for temperatures, whose purpose I've never understood? --___A. di M. 14:19, 9 October 2009 (UTC)

• The proposed change would stop the "decrease by 1" for factors over 2, of conversions going to higher counts. For example, the 3-digit "105ft" would still decrease to the 2-digit precision "32m" (not as a 3-digit "32.0m"). As you can see, there are some "man-made" shifts being made to avoid decimal-point "32.0", but the goal is to present rounded numbers as customary in general use, without 32 becoming "31". I will check the affect on temperatures, such as boiling point 100C as 212F (scale factor: 2.12). Thanks for the input & for adding the "Other comments" section. -Wikid77 (talk) 16:12, 9 October 2009 (UTC)

• Temperatures would be unaffected - The proposed change would only alter the subtemplate {{Convert/round}}, which is not used for temperature conversions, which instead use templates: Convert/roundT and Convert/roundT0 (plus Convert/proundT or Convert/proundT0) to handle either the default or user-specified rounding for more/less temperature precision. -Wikid77 17:15, 9 October 2009

We need more clarification. It is not at all clear what is being proposed. I would support a change to something like:

... the conversion will be rounded to one more significant figure than the input value ...

because that is a standard rule-of-thumb for doing unit conversions where the objective is not to lose any precision, and as a consequence produces results that people are familiar with (e.g. the conversion of 37°C to 96.8°F for human body temperature, or 8848 m to 29,029 ft for the height of Mount Everest). (BTW, if you use the ...one more significant figure... rule, the ...or to two significant figures whichever is the most precise clause is redundant.) RockyMtnGuy (talk) 16:29, 9 October 2009 (UTC)

• Okay, I think that wording is what would occur. However, temperatures are a separate rounding issue, which we could discuss as a major topic at bottom. -Wikid77 17:15, 9 October 2009

As of now, the template works in terms of the position of the significant digits, not in terms of their number, which is entirely reasonable: for example, there's no obvious reason to suppose that 98.7 is any more or any less precise than 101.2; now they convert to 98.7 kilometres (61.3 mi) and 101.2 kilometres (62.9 mi), which is entirely reasonable. You two want to make it work in terms of the number of significant digits instead, but I don't see the point of this change. Also, you draw a distinction between "conversions going to higher counts" and "conversions going to lower counts" whose point I don't get. If 2.34 yards (214 cm) rounds to the nearest centimetre, 2.34 yards (2.14 m) should (and does) round to the nearest centimetre, too; I don't see the point to make this distinction. (However, I'm not 100% sure I understand your proposal completely correctly.) In other words, I think that the general idea of the template as it works now is fine, only that the thresholds should be increased. FYI, the scale factor between Celsius and Fahrenheit is 1.8 not 2.12, because the difference between 100.0 °C and 101.0 °C equals that between 212.0 °F and 213.8 °F; so a value given to within ±1.0 °C corresponds to one given to within ±1.8 °F. The obvious way to deal with temperatures would be to drop the current exception, so that values given to within a tenth of a degree Celsius convert to within a tenth of a degree Fahrenheit and vice versa, those given to within one degree Celsius convert to within one degree Fahrenheit and vice versa, and so on. ___A. di M. 19:32, 9 October 2009 (UTC)

• Look. [192.5 yd, 193.5 yd] equals [176.022 m 176.9364 m], and 176 m isn't contained in this interval. Do you seriously suggest that "193 yards" should convert to "176.5 m", even if it's very unlikely that the precision of the original measurement was anywhere near 10 centimetres, making the final "5" essentially a random digit? --___A. di M. 18:55, 10 October 2009 (UTC)

I agree there needs to be a clarification of wording, perhaps: "The displayed amount needs to be within the bound limits when similarly rounded: if the bounds are 176.2-176.3, then the only rounded choice would be 176." -Wikid77 (talk) 21:18, 10 October 2009 (UTC)

You'd need to more precisely explain what you mean by "similarly rounded"; I think the current system is generally fine except that the thresholds should be increased so that 185 lb is considered to have "comparable precision" to 84 kg rather than to 80 kg. ___A. di M. 14:40, 11 October 2009 (UTC)

• By the end of October 2009, the proposal-consensus was still uncertain; see "Consensus status" above at: #Fix for rounding - consensus forum. -Wikid77 (talk) 15:02, 30 October 2009 (UTC)

New conversion available

I'm not sure if you folks usually announce new templates, but per my question above (Template talk:Convert#Guide to creating a new subtemplate) I created two new sub-templates: Template:Convert/lb/sqft and Template:Convert/kg/m2. - Trevor MacInnis ^contribs 01:00, 31 October 2009 (UTC)

• Thanks. So far, this talk-page had been our only notice. Using a separate category, then we could list it, to see new subtemplates. I have created "Category:2009 Convert unit subtemplates", so insert that category-link at the bottom of new templates. -Wikid77 (talk) 06:31, 31 October 2009 (UTC)

New Template:Convert/wrench

31-Oct-2009: I have created another smart-conversion template, as {{Convert/wrench}} and {{Convert/spanner}} to display the related wrench (spanner) sizes. For sizes that don't quite fit, I have used the term "(loose 3/4)" or "(loose 1/8)" (etc.) because sometimes, bolts have odd sizes (or outer deposits) that allow a loose wrench to fit. Some examples:

{{convert|3/4|wrench|mm}}              gives:   3⁄4 wrench

{{convert|1/8|wrench|mm}}              gives:   1⁄8 wrench

{{convert|17|wrench|inch}}              gives:   17 wrench

{{convert|22|wrench|inch|sp=us}}    gives:   22 wrench

If anyone has some extra time, please proofread that template, and add other metric sizes. I have listed from 1-26mm so far, in #switch-blocks, so just add the other official sizes. (When the size is 1mm less, I put "loose 17/16" etc.) I just guessed at most sizes, putting 26mm as a "1-inch" size. Anyway, Template:Convert/wrench is another example of the next-generation smart templates. Thanks, to everyone, for suggesting these new templates and docpages. -Wikid77 (talk) 06:31, 31 October 2009 (UTC)