Template talk:Convert/Archive January 2008

False Precision Issues

It has been a long time since the occasion when i raised somewhere (on WP:VP?) the issue of manual perpetration of false precision. There was, AFAI remember, consensus at least that people who don't have a deep mathematical grasp of precision should stop going around looking for manual conversions to do.
I think this template addresses a real need, and i admire the design work and overall implementation. My concern, tho, is that it presently encourages inaccurate use of it by anyone who becomes aware of it, whether with or without reading of the instructions.

1. All the examples in the "Purpose" section, and in the first third of the "Examples" section, are fundamentally false assertions of precision of measurements, that should never be used in typical WP articles, and probably not (given the rarity of articles presenting legitimate exceptions in WP and the template's reduced utility in those case) be supported via any automated scheme.

   Taking the first example,

   32 metres (105.0 ft)

   is legitimate only if it describes an exact specification, e.g.

   The length of a khlaumbodge pitch is 32 meters (105.0 ft).

   More typical occasions for unit conversions are measurements, where the implicit infinite precision of specifications doesn't apply. In cases of a measurement of 32 meters, writing "32" means uncertainty covering a range of 1 part in 32, while "105.0" claims the imprecision is no more than one part in 1050. An automated scheme usable by any IP user, or for that matter by any "experienced" user (unless we contemplate an enforceable editor-training program), should not permit such apparent greater precision in the derived number except in a mode where it also provides some qualifying word(s), e.g., giving the user the choice between

   by definition, 5,280 feet (1,609.3 m)

   and

   exactly 5,280 feet (1,609.3 m)

2. BTW, the spelling "metre" is AFAIK specified by an ISO standard but rarely complied with in American English (and i wonder about British English) in any context that isn't reviewed by some kind of ISO-compliance authority. Editors who want "metre" will know the distinction, and are more likely to look for how to get it; those who don't (perhaps, as is usually the case with me, having learned to use the template by examples) are more likely to be intimidated into abandoning what they thought was right (and still is right in the dominant, American dialect). The slow switchover to metric is more a social than an educational process, and asking WP to favor the sensible SI approach is PoV. Hollywood and the 'Net seem to make Yankish the default standard (tho i assume the 'Net is also moving us twd a hybridized standard), and sp=SI and sp=US should both exist, probably with sp=US as default, for the foreseeable future.

   In the same vein, the abbreviation of units of measure without periods is peculiar to SI. I don't think its oddness (to at least Americans) is serious, but if the coding of the template is so quirky that it won't accommodate periods on non-metric abbrevs along with period-omission on metric, then solution is for the metric abbrevs to get periods as well.

3. As to the design of the default -- examples:

   {{subst:convert|1|m|ft}} 1 metre ()

   and

   {{subst:convert|9|ft|m}} 9 feet ()

   it indicates a perceived unsuitability of a conversion with accurate precision in some situations (whose particulars i won't conjecture about). The default must be to show the precision that is as strictly accurate as feasible. And any need to show "extra" precision should be met by hand-coding it -- though editors are free to avoid hand-calculating it, by using the template with the extra precision applied to the input values. E.g., those desiring the results above can (without ever saving that version) code, respectively, in the edit pane, in the first case, either

   {{subst:convert|1.0|m|ft}} 1.0 metre () or {{subst:convert|1.00|m|ft}} 1.00 metre ()

   (and correspondingly in the second case), and paste the converted portion into the edit pane to replace the markup that used the template. (And the template call whose rendering won't appear in the rendering of the article can, for the benefit of future editors of the page, can be saved inside a comment.)

4. Similar techniques apply to requests, via the "round_to" param, for increased or apparently increased precision in the converted value: if the "exactly", "by definition", etc. options won't do, automate your calculation but cut and paste to get the saved markup.
5. It would be a valuable enhancement if the user had control over whether the original or converted value is mentioned first: which is original reflects the source of the number, but which appears first should, i think by policy, reflect the subject matter, e.g. articles abt American places or highways should state their areas or lengths in acres and miles, followed by hectares or km, and those in most of the rest of the world should reverse those roles. Often the sources force those choices, but not always.
6. The specification of precision in terms of "significant digits" is a good initial pedagogical technique, but it is fundamentally flawed: keeping the same number of sig-figs is almost always adequate caution, but if you measure g= 32 ft/sec² and convert to metric, you are lucky in getting the correct figure of 9.8 m/sec², because that equal number of significant digits amounts to asserting a factor-of-three precision improvement, from 1 part in 32 to 1 part in 98, just by changing units. (Gee, metric is a great idea! [wink]) In theory, programs can in effect use fractional numbers of sig figs to avoid this kind of false precision. My guess is that our template-programming resources could in theory support that, and looking at feasibility would be called for -- except perhaps in light of my final point.
7. Imprecision derives from two sources: accurate measurements of phenomena that are partially masked by "noise", and quantization error.
   1. Briefly, the first of these is treated by accompanying the value with the standard deviation of the measurements (or maybe it's a more conservative but similar statistical construct). That is interestingly different for the second source, bcz it implies that doing arithmetic among such numbers calls for propagation-of-error rules that use rms techniques. But this kind of imprecision seldom is relevant in WP numerical writing.
   2. Quantization error is an important and very technical electronic and cybernetic matter, but it underlies in simple form the sig-fig issues relevant re this template. I dare say "simple", bcz i mean that the math is simple when, as here, we consider only in passing traditional measurements in inches: as i understand, WP requires converting 6⅝ inches to 6.875 inches (even tho 6.9 would much better represent the precision). Oh, well.

   Even when a vernier or visual interpolation pushes a measurement beyond the actual marks on, say, your meter-stick or odometer, you end up with a small number of digits. If that measurement is 5.43 metres (214 in), what it really means is that the real size is guaranteed to be no less than 5.4250 metres (213.58 in) and no more than 5.4350 metres (213.98 in), so the 214 in. conversion is excellent.

   In contrast, the measurement 5.42 metres (213 in) means no less than 5.4150 metres (213.19 in) and no more than 5.4250 metres (213.58 in), and (even tho "213 in." already reflects an increase in imprecision, the most precise conversion that doesn't need to have a +/- indication after it, or the word "or" in it, is "210 in." (Note the decimal point must be omitted.)

   Such cases are not even rare: i picked "5.43 m" at random, without getting one, but trying the next lower number of the same precision (or, i think, the next higher) produces a case of what i was looking for. It will probably take substantial reanalysis and recoding to deal with these quantization cases, but i don't think the template should be retained if it is not going to be undertaken. The problem it addresses is real, not just because manual conversions are laborious and invitations to arithmetic errors, and i feel sure only the effort of checking existing conversions prevents its extent being recognized.

--Jerzy•t 06:15, 20 December 2007 (UTC)

1. I don't believe that the examples given had been intended as assertions of anything. Just poorly thought-out examples. This has been addressed with better examples given.
2. It is Wikipedia policy to accept any and all dialects of English. Neither metre nor meter is favoured. The template started out with the default being Commonwealth spellings, it should stay that way. Who's up for checking some ten thousand odd transclusions to see whether a change in the default spelling effected the article?
3. The default rounding must not only give appropriate conversions but also follow a simple-to-comprehend set of rules. To avoid inaccuracy the default rounding will not give less than two significant figures. Where this miminum two-significant-figure requirement is satisfied it gives a conversion with a similar precision as the original value (within a range of 2 to 0.2). It's as simple as that. It's as complex as that. I'd wanted something sophisticated enough to give appropriate conversions most of the time but not so complicated as to baffle users. Where the default is inappropriate there are other options for rounding.
4. If you want to use the template for exact conversions, I'd suggest you figure out how many decimal places or significant figures that would entail. Take care, though, since the WP software won't go beyond a dozen or so significant figures.
5. Reversal of order is discussed below.
6. Yes, the use of significant figures for rounding has its drawbacks. The sigfig parameter should be used only by those who know what they're doing. Note: the default rounding uses precision not significant figures (and does indeed use fractional numbers of decimal places).
7. Two way of getting imprecision—the question is whether we're dealing with the imprecision appropriately. By the way, I don't know of any WP requirement to rewrite fractions as decimals.

Jɪmp 09:31, 1 January 2008 (UTC)

Thanks for your attention, and i'll look more carefully at the doc'n, and say more here, before considering sounding alarms at VP.
--Jerzy•t 04:58, 4 January 2008 (UTC)

With regard to part 2 of point 2. It would have been quite simple to have accomodated full stops in the abbreviations of non-metric units or even to make this optional. It could have been done without adding full stops to metric abbreviations—a completely unacceptable "solution". However, the abbreviation of units of measure without full stops is peculiar to not only to SI but also to WP. No quirk on the part of the template, the ommission of these dots is in accordance with the Wikipedia Manual of Style which states as follows.

Standard abbreviations and symbols for units are undotted. For example, m for meter and kg for kilogram (not m. or kg.), in for inch (not in., " or ″), ft for foot (not ft., ' or ′) and lb for pound (not lb. or #).

Jɪmp 02:03, 8 January 2008 (UTC)

Please eliminate mandatory conflation of 'hyphen' and 'singular'.

I am delighted with the way that the template has been updated to handle feet and inches. I have updated my script to use it. I have just added the template AKS Continental using my script. The singular form "7 foot 6 inch" was in the article. It now has "7-foot-6-inch (2.3 m)".

I am disappointed that 'sing=on' is not just confined to singular. You can see that this has meant that my edit to that article has not just added the metric value, it has added hyphens. I did not want it to do that.

The error with date autoformatting was the conflating of independent functions. By conflating singular and hyphens, we are making the same error with the convert template. Please confine 'sing=on' to be a switch for the singular form only.

Rant over. It is a great template otherwise. Lightmouse (talk) 11:57, 28 December 2007 (UTC)

The hyphenation is what the Manual of Style recommends for compound adjectives; 7-foot-6-inch is what should be used in the above article. TomTheHand (talk) 15:33, 28 December 2007 (UTC)

I looked in wp:mosnum and could not see anything relevant. Can you give me a reference please? Lightmouse (talk) 15:48, 28 December 2007 (UTC)

Sure. See Wikipedia:HYPHEN. TomTheHand (talk) 16:44, 28 December 2007 (UTC)

Tom's right, the hyphens should be there. The problem is the original poor choice of parameter name. sing was always intended for adjectives but adjectives need more than simply singularising the noun. Jɪmp 17:05, 28 December 2007 (UTC)

I understand that it follows the MoS guidance. I think the MoS is wrong to mandate a hyphen. I have made a proposal for new MoS guidance (following Tom's reference). The root problem for me is semantic rather than lexical i.e. even if we changed the parameter name, I would still object to being forced to use hyphens. Lightmouse (talk) 17:52, 28 December 2007 (UTC)

I think the MoS as it is currently correctly reflects standard English grammar. Jɪmp 19:17, 28 December 2007 (UTC)

I do not think it does. Lightmouse (talk) 10:47, 29 December 2007 (UTC)

Time units

It seems that this template doesn't provide for units of time. It's sometimes useful to convert between s (the only SI unit of time) and minutes, hours, days, weeks, months, years, centuries, millennia, and millions of years (Ma). Clearly, for any given month or year, the conversion may differ, but the template could use the number of seconds in an average month or year.--Curtis Clark (talk) 16:14, 28 December 2007 (UTC)

No, time is something which has yet to be added. Months, years, decades, etc. are tricky even if you go for an "average" year ... what, Gregorian, Julian, tropical, sidereal ...? I think I'll go for Gregorian but this will have to be noted. Jɪmp 16:59, 28 December 2007 (UTC)

Okay, seconds (s), kiloseconds (ks), megaseconds (Ms), minutes (min), hours (h), days (d), weeks and fortnights are all up and running (the input codes/abbreviations are in brackets). Not sure what to do with years etc. though ... Julian might be better than Gregorian ... maybe. Jɪmp 19:15, 28 December 2007 (UTC)

Thanks, that was quick! I think the Julian is best for what I'm thinking of, which is long spans of time ("The Cretaceous-Tertiary extinction even was around 65 Ma (2.1 Ps) ago.") I suppose if you wanted to get fancy, you could do as you have with US and Imperial gallons and allow for several years: "annum" or "a" for the Julian year, "year" for the average Gregorian year, and other abbreviations for other years. --Curtis Clark (talk) 22:35, 28 December 2007 (UTC)

I've added nano- to milli- and giga- to exaseconds (use standard abbr). I've also added months, years, decades, centuries, millenia and millions, thousands of millions and billions (i.e. millions of millions) of years (spell the unit out in full singular form and use long or short to distinguish between different meanings of billion, trillion, ... e.g. short billion year) assuming the average Julian year for all.

If anyone has a use for getting fancy and adding other years, I'm all ears. However, it might be less confusing if, instead of using completely different terminology we just stick Gregorian in front of the unit name (what would we call an average Julian month otherwise ... a duodeciannum?).

Writing the names out in full seemed a bit tedious so I made the following alternative codes. Note the use of yr instead of a, this is to avoid confusion with ares, hetares, etc. However, although the codes contain yrs it's "a"s which will be displayed. Note also that the words long and short are not displayed either.

short code		full code
tryr	‎ →	short trillion year
long byr	‎ →	long billion year
kmyr	‎ →	thousand million year
kMyr‎	‎ →
Gyr	‎ →
tmyr	‎ →
byr	‎ →	short billion year
Myr	‎ →	million year
myr	‎ →
kyr	‎ →	millennium
tyr‎	‎ →
yr	‎ →	year
mth‎	‎ →	month
wk‎	‎ →	week

Jɪmp 21:18, 29 December 2007 (UTC)

Excellent!--Curtis Clark (talk) 00:47, 30 December 2007 (UTC)

Yet another request

Let's say that my reference has all the information in inches and feet, but I want the lengths in the article to be given first in cm and m. It would be nice to have a |reverse parameter to achieve this.--Curtis Clark (talk) 01:05, 30 December 2007 (UTC)

I have tried but failed to imagine a good reason for this. Can you give an example? Lightmouse (talk) 12:15, 30 December 2007 (UTC)

I thought I had explained it; let me be more explicit. Let's say I wanted to add to the article about California Black Oak the height of the largest known specimen. Because I found this in a book published in the US in perhaps the first half of the 20th C., the measurement is given in feet, let's say 137 ft. But the rest of the article is appropriately written with SI units, leaving English units to parentheses. If I write {{convert|137|ft|m}} I get 137 feet (42 m), which is backward to what I want. I could then go in and manually edit to 42 m (137 feet), but that has two unfortunate effects. First, it negates some of the convenience of {{convert}}. Second, and more important, it removes forever from the article a clear indication of the original measurement from the source reference (was it the m or the feet?). Of course in that specific article, {{convert}} isn't used, so it's already impossible to tell whether the original references gave measurements in SI or English without consulting them. But if an article had been written from the get-go using {{convert}}, the cited measurements are there in the page source for all to see. {{convert|137|ft|m|reverse}} would solve this.--Curtis Clark (talk) 16:29, 30 December 2007 (UTC)

That actually does seem a reasonable request - I've had occasion to want for it too at times. Basically all this parameter would do is display 9.6 kilometres (6 mi) instead of 6 miles (9.6 km) when 6 and mi is entered with an appropriate command to switch the display order. On an unrelated note, those working on this template set have done a fantastic job reducing the template overhead! I was looking at some outputs with subst yesterday and it's much tighter than it was. Orderinchaos 17:43, 30 December 2007 (UTC)

Aha. Your explanation is helpful, I understand now. It is an interesting debating point. Lightmouse (talk) 17:09, 31 December 2007 (UTC)

It would be done using the disp parameter e.g. <code>{{convert|137|ft|m|disp=reverse}}</code>, however, I wonder whether it would be appropriate. The source units should generally come first with the converstions in brackets, though, let's assume that there may be some instances where their reversal is warrented. In such a case the reversal should be noted. There must be that "clear indication of the original measurement from the source reference", not just in the article's source code but as a footnote (i.e. we should not expect people to have to open an edit box and go searching for reverse). Unfortunately it seems impossible to add footnotes via templates. Jɪmp 08:40, 1 January 2008 (UTC)

Although I see your point, this is exceedingly problematic in practice, since for plant and animal species in the US, different references often use different systems of measurement. As in the hypothetical example I gave above, heights of largest specimens of trees were often measured in feet, but floras and monographs most often report general measurements in SI. Putting the source units first would mean that the article would use mixed measurements. My suspicion is that editors who do manual conversions almost never do this; they arrange their conversions to fit with the rest of the article. Perhaps there needs to be a way to typographically indicate the source measurement, but I suppose this would be a discussion for WP:MOS or even the Village Pump. But it seems clear to me that conflicts between "source measurement first" and "consistent units across an article" have never been resolved in a consistent manner.--Curtis Clark (talk) 17:04, 1 January 2008 (UTC)

Yeah it comes up as a problem in Australian geography articles as until 1972 most State governments still used imperial units in urban planning, and from then onwards used metric. The switch was so comprehensive (unlike Canada and the UK) that pretty much noone 35-40 or younger understands imperial units and many older people are out of practice with using them. So you could have source documents about a place built in the early 1970s that randomly flips between units depending on source document. Orderinchaos 21:00, 1 January 2008 (UTC)

← outdent
There being no strong arguements not to allow this reversal, I reckon it's motion-carried. My point that any such reversal should be noted in plain view, which would generally best be done using footnotes, which cannot be added using templates, is not really an arguement against allowing this. As long as it's noted, I see no problem in switching the order. Of course, it's open to abuse, i.e., editors using the reversal option to switch the order but not bothering to make a note of this. However, someone bent on order switching will do it anyway, perhaps by copying, switching and pasting the values manually. I s'pose a hidden clue as to what's going on is better than none at all. And the clue is to be called |reverse ... I'm after something more obvious, something that won't eat too much pre-expand size whilst still remaining flexible. The coding I've got in mind is along the lines of |disp=conv(orig). This is good on the pre-expand size front because it uses an existant parameter. The parameter it uses is |disp, which makes sense since this is a question of how the conversions are to be displayed. I hope it gives an obvious hint as to what's going on with the conv (for conversion) and the orig (for original) reflecting the intended positions of the values, if not, we could go for |disp=conversion (original value) ... or even |disp=conversion first original value in brackets. It's flexible in that something along the lines of |disp=conv/orig and |disp=table!conv!orig respectively could be used to produce slashes and used in tables. Jɪmp 07:12, 9 January 2008 (UTC)

Temperature in the 70s °F and 50-60 °F

I'd like to be able to use {{convert}} on hybrid expressions such as

1. Numbers with an alphabetic suffix, e.g. "70s" as in "temperatures in the 70s °F" → "temperatures in the 70s °F (20s °C), or
2. Number ranges with punctuation such as a dash as separator, e.g. "50-60" as in "temperature is 50-60 °F" → "temperature is 50-60 °F (10-15 °C)".

This seems to be beyond the current capabilities of {{convert}}. How easy would it be to make it to handle these two cases? Support for syntax like {{convert|70s|°F|°C|sigfig=1}} or {{convert|50-60|°F|°C|sigfig=1}} would be handy. - Neparis (talk) 02:18, 2 January 2008 (UTC)

I'm not convinced that 70s °F and 20s °C are equivalent. The 20s extend from 68 °F to nearly 86 °F, a range from "cool" to "warm" in my estimation.--Curtis Clark (talk) 03:40, 2 January 2008 (UTC)

I agree they are not strictly equivalent and I was not trying to suggest that they are. Of course, "the temperature is in the 70s °F" is more precise than "the temperature is in the 20s °C", but in the kind of deliberately vague uses that are typical for such expressions, is the difference in precision practically important? If it is, the conversion could use the words "low", "mid", or "high" as a modifying prefix, e.g. "70s °F" → "low 20s °C", "90s °F" → "mid 30s °C", and "150s °F" → "high 60s °C" which all have similar precision. It should be easy to implement that in code. However, I wonder if we need to be worrying about any of this. In any situation where precision was important, a vague expression like "70s °F" would simply not be used and an exact temperature like "73.2 °F" would be given instead. I think that having even an extremely approximate automatic conversion would be better than having absolutely none at all. - Neparis (talk) 04:44, 2 January 2008 (UTC)

Edit conflict ... here's what I'd written:

The syntax would have to be more like {{convert|70|s°F|s°C|sigfig=1}} but, like Curtis notes, 70s °F and 20s °C are quite different, of course, "low 20s °C" might be plausible. Ranges are a different issue under discussion above archived (again the syntax will be different, the software would consider that hyphen to be a minus sign).

i.e. a similar solution. No, the coding would not be too hard. Gota go. Jɪmp 04:52, 2 January 2008 (UTC)

That's a pity because the semantics is that the "s" modifies the number (70), not the unit of measurement (°F). - Neparis (talk) 05:00, 2 January 2008 (UTC)

True but the software won't recognise "70s" as a number ... though it's not completely impossible to work around this. Jɪmp 11:58, 2 January 2008 (UTC)

... The work-around would actually use the non-recognition-as-numbers of "70s" and the like to distinguish it from the regular conversions. One drawback would be that there'd be a limit to the ranges over which the conversions would be possible. This, however, might not be such a drawback after all: the likes of 750s °F (for example) would be made unconvertible but do we want such absurdity? Another drawback would be a slight increase in pre-expand size for regular temperature conversions ... but only slight. Perhaps this is the better way. Jɪmp 12:50, 2 January 2008 (UTC)

I've never seen the expression used for extreme temperatures such as 750 °F; isn't it used exclusively for temperatures in the approximate range -50 to +150 °F? - Neparis (talk) 13:22, 2 January 2008 (UTC)

No, nor have I, and we probably shouldn't see it here. Therefore an incapability to handle such things might actually be a good thing. Jɪmp 13:50, 2 January 2008 (UTC)

Ok, thanks for your input. I look forward to being able to use an extended {{convert}}. - Neparis (talk) 23:19, 4 January 2008 (UTC)

First we've got to figure out exactly what we're after. Here's one possibliity.

°F	°C	Notes
50	10.000	Ranges are in bold. Conversions of single temperatures have been included for comparison. This pattern would continue like this in both directions.
50s	low 10s
60	15.556
60s	high 10s
70	21.111
70s	low 20s
80	26.667
80s	high 20s to low 30s
90	32.222
90s	mid 30s
100	37.778
100s	high 30s to low 40s
110	43.333
110s	high 40s
120	48.889
120s	low 50s
130	54.444
130s	high 50s
140	60.000

Are high 30s to low 40s and high 20s to low 30s a bit too wordy? Can the 2+2⁄9 of a degree overlap into the 30s be ignored like the 1+1⁄9 of a degree overlap into 20s and 40s were. On the other hand, was the latter too inaccurate? Are we going to run into strife with the 100s' being interpreted as 100 ≤ T < 200? Of course, this is only one-way for now, we'd also want conversions from Celsius. Jɪmp 19:59, 5 January 2008 (UTC)

← outdent
Done ... or at least partially.

I've covered conversions from −50s to 150s °F using the pattern above. For negative temperatures I've taken low and high to mean low & high temperatures respectively (as opposed to low and high absolute values of the number of degrees). Thus low −20s would imply the approximate range of −30 < T < −25. This seems the most logical & I'm sure the usual interpretation (coorect me if I'm wrong). Note also the distinction between 0s (i.e. 0≤ T < 10) and −0s (i.e. −10< T ≤ 0).

Negative values are entered with a hyphen as a minus sign (as with ordinary numerical input) but this is converted to a proper minus sign on display, e.g. {{convert|-40s|F}} gives you "". Note that precision and sigfig rounding specifications are (currently) ignored, if need be, this could be changed, however, since these type of expressions are generally vague, I doubt that there'll be such a need ... indeed more precise conversions would usually be stated as a range (which will be dealt with differently).

Next I'll be adding Celsius to Farenheit. As yet I've ignored Kelvin & Rankine, there is probably no need for these either, but if the need should arise, I've left room for them to be added.

Jɪmp 03:37, 7 January 2008 (UTC)

It seems to be working well. Re your question about verbosity of certain conversions, e.g. 80s °F, perhaps editors would want to ignore the 2+2⁄9 of a degree overlap into the 30s °C in some but not all cases. It might be useful if the style could be set on a case-by-case basis in different articles by making it possible to disable verbose-mode with an option, e.g. {{convert|...|concise? - Neparis (talk) 04:37, 7 January 2008 (UTC)

My initial inclination was to ignore the 2+2⁄9 degree overlap into the 30s °C but weighed against the 3+3⁄9 degrees of the 20s °C which it occupies 40% seemed significant enough. Yeah, {{convert|...|concise sounds like a nice option. Jɪmp 04:55, 7 January 2008 (UTC)

Okay, that's done. Use concise to ignore 2+2⁄9 degree overlap. Put it in the usual precision position, i.e. the last unnamed parameter, e.g. {{convert|80s|F|concise}} (or {{convert|80s|F|C|concise}}) will give you "" as opposed to the "" which you'll get from {{convert|80s|F}}. Jɪmp 06:47, 7 January 2008 (UTC)

Of course, this opens the door to the creation of the option to go the other way; i.e. add more accuracy e.g. convert 50s °F, 60s °F, 70s °F, etc. to low to mid 10s °C, high 10s to low 20s °C, low to mid 20s °C, etc., respectively; or even convert to the exact ranges, i.e. 10 to 15+5⁄9 °C, 15+5⁄9 to 21+1⁄9 °C, 21+1⁄9 to 26+6⁄9 °C, etc, respectively; but let's not get carried away without good cause. ... On second thoughts, whilst all of that may be rather a bit over-the-top, conversions to simple ranges such as 10 to 16 °C, 16 to 21 °C, 21 to 27 °C, &c. might well be worth allowing for. Jɪmp 07:14, 7 January 2008 (UTC)

← outdent
To conversions from Celsius: the following pattern might be the way to go here. Note that I've included a plain & concise version already.

°C	°F	°F plain	°F concise
10	50.000
10s		50s to 60s	50s to 60s
20	68.000
20s		70s to mid 80s	70s to 80s
30	86.000
30s		mid 80s to mid 100s	90s
40	104.000
40s		mid 100s to 110s	100s to 110s
50	122.000
50s		120s to 130s	120s to 130s
60	140.000

Conversions would cover a similar range, i.e. −50s to 60 °C. Do we need conversions from the more precise expressions such as low, high and mid 10s, 20s, 30s, etc.? Jɪmp 08:10, 7 January 2008 (UTC)

Since these "s" phrases are in use, it probably would be useful if they were convertible too. - Neparis (talk) 01:44, 10 January 2008 (UTC)

Phrases like 120s to 130s, you mean? Yeah, I'm contemplating how best to to this. What I have in mind at the moment is to have these ranges fall out as a natural consequence of the use of their end points (e.g., 120s and 130s) in some {{ConvertRange}} (which has yet to be written ... and might end up being called something different ... could even simply end up here). Jɪmp 08:19, 10 January 2008 (UTC)

(sub-thread moved to where it was meant to appear) I was referring to the more precise conversions involving low, mid, and high. I think it would be very neat if there was only one {{Convert}} template with overloading that could handle ranges as well, e.g. something along the lines of {{Convert|60 to 70|F|C}}. - Neparis (talk) 15:19, 10 January 2008 (UTC)

Conversions from low ..., mid ..., and high ... could be done, yes. I've been thinking about how to add ranges into {{Convert}} itself as opposed to creating a new {{ConvertRange}}. I think I could get {{Convert|60|to|70|F|C}} working. However, if we're to handle the likes of {{Convert|6|ft|3|in|to|7|ft|5|in}}, we'd have to add extra pre-expand size to non-range conversions (48 bytes). Jɪmp 23:31, 10 January 2008 (UTC)

Do you think this might be a real problem in practice in terms of available template resources in the current MediaWiki? - Neparis (talk) 16:51, 11 January 2008 (UTC)

Conversions from Celsius to Fahrenheit are now covered following the pattern given above. I've extended the ranges to −80s °C to 100s °C and −120s °F to 220s °F. Jɪmp 06:34, 9 January 2008 (UTC)

Many thanks. - Neparis (talk) 17:27, 19 January 2008 (UTC)

Value range

See also Template talk:Convert/Archive December 2007#Ranges

Two questions were posed in the preceding section. Only one of them was addressed. Would is be possible to get output in the formats "(4.5 - 9 cm)" or "(4.5 to 9 cm)". I am thinking in particular of a parameter that sets the separation character/text. An example would be from the Greatsword article, where I had to use the template twice a got this text: 6.5 inches (17 cm) to 9 inches (23 cm). I feel it would look a lot better thus: 6.5 to 9 inches (17 cm to 23 cm) or 6.5 to 9 inches (17 cm-23 cm). Regards TINYMark (Talk) 21:26, 9 January 2008 (UTC)

While this capability is unavailable in {{convert}}, you can use {{in to cm}}. That template does not allow selection of your own separation character, but it does output the values in the format you need. Just an FYI.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); 22:19, 9 January 2008 (UTC)

Thanks a lot. That helps me for now. There seem to be a lot of different conversion templates and, it seems to me, they require some sort of organisation. Taking Infobox (actor, musician, film etc.) as an example, {{convert area}}, {{convert area range}}, {{convert length}}, {{convert length range}}, {{convert temp}} ....... would seem sensible. Trying to remember all these different templates is pretty head-wrecking! But then again, organising them all will also be head-wrecking for the person doing it! TINYMark (Talk) 22:50, 9 January 2008 (UTC)

Yes, ranges are currently unavailable on this template. I do intend to get to work on this. It will probably take the form of {{ConvertRange}}. But, yes, in the meantime, many of the other (single purpose) templates in the category do handle ranges. By "organisation" perhaps you mean dividing the category into subcategories based on length, area, volume, etc. This would seem sensible. (Note that the syntax you've used above seems to suggest adding new templates rather than sorting the current ones). Jɪmp 01:37, 10 January 2008 (UTC)

Or perhaps just renaiming them. We don't have to reinvent the wheel ;-) TINYMARK 14:17, 14 January 2008 (UTC)

Some could do with renaming, others, deletion. The whole category could do with a clean up. Jɪmp 03:32, 15 January 2008 (UTC)

Sub-unit conversion

== Incorrect converting ==

{{editprotected}} This template is incorrectly converting kg into stones. ie. errors are occuring.

For example: 100 kg = 220 lb = 15 st 10. This template is saying that 100 kg = 220 lb = 16 st . This is an error. Could this be fixed asap.?? --Bob (talk) 15:42, 11 January 2008 (UTC)

100 kilograms is 16 stone ... after rounding to two significant figures. To get greater (or lesser) precision specify

1. the number of decimal places you want e.g. {{convert|100|kg|st|2}} will give "100 kilograms (15.75 st)" or
2. the number of significant figures you want e.g. {{convert|100|kg|st|sigfig=5}} will give "100 kilograms (15.747 st)".

Jɪmp 16:13, 11 January 2008 (UTC)

One doesn't talk about being 15.7 st, one states 15st 10lbs. Can this be altered? If not, it useless for kg to st conversions. --Bob (talk) 16:23, 11 January 2008 (UTC)

I have disabled the "editprotected" template above for now because this is too complex, but I will work on this. —Random832 16:28, 11 January 2008 (UTC)

While we are at it, metres to feet is also badly formatted. We don't talk about being 6.5 ft tall, we say 6' 6" or 6ft 6in. It will be easily misinterpreted... Thanks for taking a look at this. (Copied to yor talk so you can see this last post quickly.)--Bob (talk) 16:33, 11 January 2008 (UTC)

Someone said above that there is handling for feet and inches - I'll try to figure out how this is done. —Random832 16:34, 11 January 2008 (UTC)

I can't make heads or tails of this, I've flagged down User:Jimp, he seems to have done some work on this template. —Random832 16:40, 11 January 2008 (UTC)

The ideal method to do this seems to be to convert metres to inches, then inches to feet. That being said though, if something was 421.5 metres, you wouldn't want it to spit out feet and inches - decimal is probably more useful. Orderinchaos 16:42, 11 January 2008 (UTC)

Based on Jimp's talk page, he appears to have been working on this capability (output in feet/inches, stones/pounds, pounds/ounces, etc) for quite some time. —Random832 16:44, 11 January 2008 (UTC)

Currently the template only does conversions from feet & inches, stone & pounds and pounds & ounces. Yes, conversions the other way have been a feature I've indended to add for some time ... since I started on this thing actually. Jɪmp 17:05, 11 January 2008 (UTC)

I've made a start on it. I've introduced five new codes:

1)	ftin	e.g. {{convert|2|m|ftin|disp=s}}	which gives "2 metres (6 ft 7 in)"
2)	footin	e.g. {{convert|2|m|footin|disp=s}}	which gives "2 metres (6 ft 7 in)"
3)	lboz	e.g. {{convert|2|kg|lboz}}	which gives "2 kilograms (4 lb 7 oz)"
4)	stlb	e.g. {{convert|70|kg|stlb}}	which gives "70 kilograms (11 st 0 lb)"
5)	lb stlb	e.g. {{convert|100|kg|lb stlb|abbr=onlk=on}}	which gives "100 kilograms (220 lb; 15 st 10 lb)"

Jɪmp 22:27, 12 January 2008 (UTC)

Thank you, merci beaucoup, Grassy-ass,. I found out the hard way that the Aussies and Brits get all bend out of shape over decimal stones (16.4 st). Hopefully you've made (or will soon) a "kg stlb" sub template too. I'll be needing it. —— MJCdetroit ^(yak) 00:06, 13 January 2008 (UTC)

Funny that ... making kg stlb was exactly what I was about to do when I saw that there's been a reply here. Jɪmp 00:25, 13 January 2008 (UTC)

Done but needs tweeking before it'll link properly. Jɪmp 00:31, 13 January 2008 (UTC) ... tweect Jɪmp 01:08, 13 January 2008 (UTC)

As we don't use stones/pounds in Aus, it really doesn't matter one way or the other. It's all metric (as is the UK but apparently there is still a lag in some quarters). What we do do is measure height in centimetres, not metres. The old template put cm into decimal feet and inches, will cm still put it into feet and inches? •Florrie•leave a note• 05:20, 13 January 2008 (UTC)

ETA, yes, it does, just tried it. {{convert|200|cm|ftin|abbr=on}} = 200 cm (6 ft 7 in) - Except, of course, that it is supposed to be 6 ft 7 in, not 7 ft 7 in. Ta. •Florrie•leave a note• 05:32, 13 January 2008 (UTC)

Odd, I'll have a look at it. Jɪmp 11:57, 13 January 2008 (UTC)

Many thanks, it seems to be working now. Though it was good for a while, I was a good six inches taller. •Florrie•leave a note• 13:36, 13 January 2008 (UTC)

How do you use a source that has "8 lb 6 oz" and "6 ft 6 in"? {{convert|6 6|ftin|m}} and {{convert|8 6|lboz|kg}} gives errors. The other way works {{convert|3.8|kg|lboz|abbr=on}} gives 3.8 kg (8 lb 6 oz) and {{convert|1.98|m|ftin|abbr=on}} gives 1.98 m (6 ft 6 in), but I want to use what the source said and convert that.-- Jeandré, 2008-01-13t11:15z

Use {{convert|6|ft|6|in|m}} and {{convert|8|lb|6|oz|kg}}. Yeah the doc page is lagging behind the template. Jɪmp 11:57, 13 January 2008 (UTC)

Many thanks. -- Jeandré, 2008-01-13t12:51z

Small glitch today with {{convert|182|cm|ftin|abbr=on}} showing up as 182 cm (5 ft 12 in) instead of 6 ft 0 in. •Florrie•leave a note• 12:35, 14 January 2008 (UTC)

Yeah, I know, it'll be fixed soon. Jɪmp 13:28, 14 January 2008 (UTC)

Fixed. Jɪmp 17:34, 14 January 2008 (UTC)

Thank you. •Florrie•leave a note• 22:14, 14 January 2008 (UTC)

Roods & Perches

How do you convert roods and perches to sqyd or sqm? Yes, I know you can multiply to get sqyd, but what is 2a.2r.15p in sqm?Mjroots (talk) 11:35, 13 January 2008 (UTC)

1 acre	= 1 chain × 1 furlong
	= 4 rods × 40 rods
	= 160 square rods
2 acres	= 320 square rods
1 rood	= 1 chain × 1 rod
	= 4 rods × 1 rod
	= 4 square rods
2 roods	= 8 square rods
1 perch	= 1 square rod
15 perches	= 15 square rods
1 yard	= 0.9144 metres (the international definition of the yard)
1 rod	= 5½ yards
	= 5.0292 metres
1 square rod	= 30¼ square yards
	= 25.29285264 square metres
2 a 2 r 15 p	= 320 + 8 + 15 square rods
	= 343 × 25.29285264 square metres
	= 8675.44845552 square metres

Hope this helps. Note that this template does not currently support roods, perches (the area) or square rods but they could be added if there be the need. Jɪmp 04:22, 16 January 2008 (UTC)

Conversion error

{{convert|1.5|m|ft}} gives 1.5 metres (4.9 ft), but when you try to convert to ft and in {{convert|1.5|m|ftin}} gives 1.5 metres (4 ft 11 in)! the correct figure should be 4ft 11 in.Mjroots (talk) 12:16, 13 January 2008 (UTC)

This is the problem noted above (200 cm ==>> 7 ft 7 in). Fixed ... I believe. Jɪmp 13:21, 13 January 2008 (UTC)

Errors: m to ftin.

There seems to be a problem with m to ftin when comparing to the calculations by Google, CSG, and Simetric:

code	answer	Google/CSG/Simetric
{{convert|2.18|m|ftin|abbr=on}}	2.18 m (7 ft 2 in)	7 ft 2 in = 2.1844 meters (they all agree)
{{convert|2.40|m|ftin|abbr=on}}	2.40 m (7 ft 10 in)	8 ft 10 in = 2.6924 meters (?)
{{convert|2.41|m|ftin|abbr=on}}	2.41 m (7 ft 11 in)	8 ft 11 in = 2.7178 meters (?)
{{convert|2.66|m|ftin|abbr=on}}	2.66 m (8 ft 9 in)	9 ft 9 in = 2.9718 meters (?)
{{convert|2.72|m|ftin|abbr=on}}	2.72 m (8 ft 11 in)	9 feet 11 inches = 3.0226 meters (?)

-- Jeandré, 2008-01-13t12:24z

Same problem. I think I've fixed it (was rounding rather than truncating). Jɪmp 13:26, 13 January 2008 (UTC)

Template to be substituted

Is this template to be substituted? I found some edits from a bot (MetsBot) back in August 2007 [1] converting uses of this templates and filling infoboxes with (unneeded) <span>-tags. -- User:Docu

It looks like the bot was stopped in the meantime User_talk:Mets501/Archive_20#Convert_template. I guess I just have to fix the conversions. -- User:Docu

Yeah, but as for substing this template, I wouldn't advise it. Each transclusion involves a rather long string of subtemplates and can involve outside templates also. You'd be substing all afternoon. There are smaller single-conversion templates in the Conversion templates category which are good for substing. Jɪmp 01:08, 16 January 2008 (UTC)

Actually, those are not so good for substing either. You'll get a bunch (and I mean a bunch) of conditionals if you subst most of those.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); 01:45, 16 January 2008 (UTC)

True, most of them, yes. What I had in mind were the likes of the dist templates (not sure how many other such simple templates are out there) but there's still no escaping the {{#expr:}}s. Jɪmp 03:32, 16 January 2008 (UTC)

Looks like the auto templates are simple too. Of course, another advantage with this simplicity is that it minimises pre-expand size. Jɪmp 04:37, 16 January 2008 (UTC)

To "subst" a complex template in one shot, if it really is necessary, use Special:Expandtemplates. —Random832 17:34, 17 January 2008 (UTC)

Template with defaults for infoboxes [Was: Should we keep this parallel template?]

Is there any advantage for keeping this: {{converta}}? Note: the "a" at the end. It looks like it was created just to save a few key strokes in {{convert}} by always having units abbreviated. —MJCdetroit ^(yak) 17:16, 17 January 2008 (UTC)

My personal opinion - probably no advantage. Keystrokes aside, it's slower to have one more process in the cycle. Is it substantially used? Orderinchaos 17:23, 17 January 2008 (UTC)

No, not really, less than 500 pages. It can be replaced in about an hour by a bot. —MJCdetroit ^(yak) 17:32, 17 January 2008 (UTC)

I don't see any use in having it. Jɪmp 18:44, 17 January 2008 (UTC)

When only the abbreviated version of units are needed (such as for value in infoboxes), there is an advantage in having a template with corresponding defaults. If there was a way to provide such default easily for cases when convert is used within infoboxes, we could do away with it. -- User:Docu

There is: add |abbr=on to the code. Adding |abbr=on also makes it very clear that the symbols have been abbreviated; converta doesn't. I thought converta was a typo graphical error when I first saw it. —MJCdetroit ^(yak) 13:38, 18 January 2008 (UTC)

The template has two other defaults that make it more suitable for infoboxes. Maybe there is a better name we could use for it? {{convert_ib}}? -- User:Docu

TfD nomination of Template:Converta

Template:Converta has been nominated for deletion. You are invited to comment on the discussion at the template's entry on the Templates for Deletion page. Thank you. —MJCdetroit ^(yak) 02:26, 2 February 2008 (UTC)

Need referral to proper discussion page

I had a thought about including currency figures in a document, having a user declare what his currency was in user preferences and therefore reading budget figures (or whatever) in his/her own currency. This would not be the much overworked "convert" but something similar perhaps. Can you refer me to a proper page where I might raise this idea? Thanks. Student7 (talk) 13:22, 19 January 2008 (UTC)

Currecy conversion templates have been discussed before.

• Template talk:Convert/Archive November 2007#Excellent template thanks !
• Category talk:Conversion templates#Currency conversion templates

There even is one in existance.

• {{INRConvert}}

It not so much a question of overworking {{convert}} (this template could handle currency). It's more a question of overworking editors. An inch is an inch and has been 25.4 mm since 1959. How many yen is a euro worth? That will probably have changed since your post. Even if we avgeraged exchange rates over a month ... or even a year, that'd be a lot of work.

You mention user preferences, though, as far as I'm aware templates cannot read your preferences. To have a feature like this you'd probably need to talk to the developers. Have a look at these pages.

• Wikipedia:Bugzilla
• Wikipedia:Village pump (technical)

Hope this helps. Jɪmp 23:56, 20 January 2008 (UTC)

Thanks for your thorough answer. You have talked me out of it! Student7 (talk) 01:12, 21 January 2008 (UTC)

sqft to acre and sqm

I am having problem with the dual conversion feature of Template:Convert at Lucien Lagrange.--TonyTheTiger (t/c/bio/WP:CHICAGO/WP:LOTD) 20:49, 21 January 2008 (UTC)

That particular sub template didn't exist—it does now. —MJCdetroit ^(yak) 21:36, 21 January 2008 (UTC)

exponentials

Is there a way to convert numbers with exponentials, such as 2.3 × 10¹⁶ liters? Or things like 24.3 million pounds? Thanks, kwami (talk) 09:32, 29 January 2008 (UTC)

Not at the moment (except for British thermal units) but it's food for thought. Jɪmp 07:02, 31 January 2008 (UTC)

Rounding

When using km to mi/mi to km or m to ft/ft m and the last digit of the input number is zero it rounds the number. Some examples,

• 600 kilometres (370 mi) (actual 373)
• 600 miles (970 km) (actual 966)
• 601 metres (1,972 ft) (actual 1969)
• 600 feet (180 m) (actual 183).

Yet when the last digit is not a zero it doesn't always do that. Such as,

• 601 kilometres (373 mi) (actual 373)
• 601 miles (967 km) (actual 967)
• 601 feet (183 m) (actual 183).

However, 601 metres (1,972 ft) (actual 1972) Why? CambridgeBayWeather Have a gorilla 05:09, 30 January 2008 (UTC)

I believe it is trying to interpret the second zero in the source as a non-precise measurement, thus it outputs a non-precise since MOS calls for such action. It's just a matter of it trying to be intelligent and failing in this specific instance. Just specify how many digits to round to ({{convert|601|m|ft|0}} would yield 1972 ft, {{convert|601|m|ft|1}} would yield 1971.8 ft). However, I cannot figure out why it would be interpreting the 601 m measurement as it is, though again, specifying the "round to" field will fix it. Jimp may be able to shed further light on this. — Huntster (t • @ • c) 07:26, 30 January 2008 (UTC)

Thanks. CambridgeBayWeather Have a gorilla 14:14, 30 January 2008 (UTC)

From m to ft the number of zeros is increased by 1, because the factor 3.3 is between 2 and 20.--Patrick (talk) 14:23, 30 January 2008 (UTC)

So it uses the conversion factor to decide whether to round or not? I cannot begin to wrap my brain around that one. — Huntster (t • @ • c) 20:16, 30 January 2008 (UTC)

E.g. 100,100 feet (30,500 m), 100,100 feet (3,050,000 cm); with a larger conversion factor more digits are rounded to zero. The assumption is that in the given value 100100 the zeros are from rounding; if not, as you say, specify how many digits to round to.--Patrick (talk) 23:34, 30 January 2008 (UTC)

Yep, Patrick hit the nail on the head. For a given conversion factor, f, the precision of the numerical conversion is decreased (the number of zeros is increased) by n where 2×10ⁿ < f < 2×10^{n − 1} to account for the increase in precision of the unit. However, to maintain accuracy, it won't round to one significant figure unless you tell it to. Jɪmp 07:26, 31 January 2008 (UTC)

Actually: 2×10^{n − 1} < f < 2×10ⁿ.--Patrick (talk) 08:38, 4 February 2008 (UTC)

Ahem. All output values are accurate regardless of the precision. Lightmouse (talk) 08:59, 31 January 2008 (UTC)

Thanks for the explanation Patrick and Jimp, makes sense now. Lightmouse, not sure what you mean...the output figures are accurate if you are intending them to be non-precise, but if you are meaning exactly 600 km, then no, it isn't accurate (the converted figure is off by three). ...unless you are meaning something else? — Huntster (t • @ • c) 13:58, 31 January 2008 (UTC)

The terms 'exactly' (as in your comment) and 'actual' (as in the original comment by CambridgeBayWeather) are not clear to me. Let us set those terms aside for a moment. The terms 'accurate' and 'precise' are clear to me. I hope they are to you. You can choose to convert 600 km as: 500 miles, 400 miles, 370 miles, 373 miles, 372.8 miles, 372.82 miles, etc. Each conversion is accurate. Each conversion has a different precision. Lightmouse (talk) 22:58, 31 January 2008 (UTC)

← I understand what you are saying, but the problem is whether or not the output is accurate for a given situation. If the 600 km input is a non-precise figure, then a non-precise output of 400 or 370 mi is acceptable; if 600 km input is a precise figure (as in, 600.0 km), then those outputs become imprecise and thus unacceptable. So your original statement cannot be fully correct: dependent on (not regardless of) the intended precision, the above output may or may not be "accurate". It's not that big a deal for most purposes here, but it is a distinction that must be accounted for. The template, though, is doing the best it can to accommodate the widest number of situations, and as noted above, there are easy workarounds to gain the correct output. — Huntster (t • @ • c) 01:34, 1 February 2008 (UTC)

True, true, those are all accurate & the difference is in the precision. As for the workings of the template, give it 600 km and it'll assume you mean 600 ± 50 km, i.e. it'll take the 600 as being precise to one significant figure ... nor can a human correctly assume otherwise without context. So {{convert|600|km}} gives "600 kilometres (370 mi)" (since the default rounding gives a minimum of two significant figures). Now, give it 600.0 km and it'll assume you mean 600 ± 50 m (four significant figures). So {{convert|600.0|km}} gives "600.0 kilometres (372.8 mi)". With the default rounding I've attempted to accommodate as general a set of conversions as possible but where context may call for greater or less precision this can done by specifying the number of significant figures and/or precision you want directly. Only context will tell you whether this would be necessary. Jimp 05:39, 1 February 2008 (UTC)