Template talk:Convert

Template:Convert

... in conception

... and in reality

kWh/mi

Anybody know why these give slightly different abbreviated forms for the mile side? The first form displays "kWh/mi" but "kW⋅h/km" (notice the middot).
{{cvt|1.7|kWh/mile|kWh/km}} -> 1.7 kWh/mi (1.1 kW⋅h/km)
{{cvt|1.7|kW.h/mile|kWh/km}} -> 1.7 kW⋅h/mi (1.1 kW⋅h/km)  Stepho  talk  03:36, 16 March 2025 (UTC)

I haven't checked this particular unit but the general rule is that unit codes that include a dot (period) display a middot. I guess that years ago someone decided that kWh should display like that (no middot) because that is how it is commonly written. Johnuniq (talk) 04:16, 16 March 2025 (UTC)

When I was small, I only encountered the term "kWh" on the electricity meter in our house. I had heard of "kilowatts" when my parents were buying domestic appliances like heaters and kettles, and the box would sometimes show "1 kW" etc. which I knew to be an abbreviation for kilowatt. So I assumed that kWh was an alternative abbreviation for the same unit, until I was a teenager and a science teacher was explaining units like volts, amps, watts and joules - pointing out that the joule includes a time component and that 3,600 kJ could also be expressed as 1 kWh and that therefore, electricity meters should all be reconfigured to read out in either kJ or MJ. Forty-some years on, that's only just happening. So it would have been useful to me waaay back if there had been some kind of multiplication symbol. But of course, SI doesn't use a multiplication symbol for combined unit abbreviations, since the few two-letter unit abbreviations (like Hz and Pa) are usually chosen to avoid ambiguity (except lm (lumen) which might be mistaken for litre·meter). --Redrose64 🌹 (talk) 09:08, 16 March 2025 (UTC)

Johnuniq: Ah yes, I had forgotten about the kWh middot wars from a few years ago.

Found that {{cvt|1.7|kWh/100miles|kWh/100km}} correctly formats as 1.7 kWh/100 miles (1.1 kWh/100 km) . Any chance of removing the middot for |kWh/km= in the next general cleanup? No rush of course.  Stepho  talk  11:35, 16 March 2025 (UTC)

Sure, but someone has to sort out Module:Convert/documentation/conversion data#Fuel efficiency! Some points from that:

• kW.h is a unit with symbol kW⋅h and link Kilowatt-hour.
• -kW.h is an alias for kW.h with link Kilowatt hour (which is a redirect to the hyphenated name).
• kWh/km is a per unit (==) defined as -kW.h/km.

I do not recall why -kW.h was defined with that link as an exception but it was several months before the module went live in December 2013. Therefore, it is likely that I was just making the module compatible with the old templates. It might be better to remove -kW.h which would involve changing the definitions for kWh/km and kWh/mi. To remove the middot, use kWh in the two definitions. Can you see anything else in that section that should be cleaned up? Johnuniq (talk) 05:37, 17 March 2025 (UTC)

No problem, I can update the docs. Let me know when and I will update it to match the true output.  Stepho  talk  00:03, 18 March 2025 (UTC)

It's more magic than it might appear. First, the conversion doc page gets updated. Then the script mentioned at the top of the doc page gets run (to do that, view the associated talk page). I can use its output to update the convert data module. I'm hoping you will examine that section (or more if you feel inclined) and think about how everything should work together. If you do edit it, please bear in mind that it is read by a script so don't adjust the wikitext other than to edit the unit definitions. If wanted, you can examine the output at Module talk:Convert/makeunits (it says to purge and you might need to do that but MediaWiki has sped up in recent times and often it is not needed). Alternatively, just confirm that what I wrote above about what needs to be changed is correct, and that nothing else needs to be done. I have a simpler way to update the doc file using a script I run locally. Johnuniq (talk) 03:44, 18 March 2025 (UTC)

How about AWG-to-area and back?

Might come handy.82.154.174.148 (talk) 10:09, 22 March 2025 (UTC)

Convert applies conversion factors, and occasionally offsets, to continuous values expressed in different units of measurement. No such conversions exist for the discrete AWG designations, a series of nominal sizes which are not units of measurement. NebY (talk) 12:03, 22 March 2025 (UTC)

There was a related request (not on this page) a few months back, but concerning standard wire gauge. --Redrose64 🌹 (talk) 17:08, 22 March 2025 (UTC)

So what? There's formulae to interpolate between AWG numbers and optionally trunctate the result to the next lower integer. You sure this would need a separate template?2001:8A0:5E61:E900:E467:B8FA:3320:786A (talk) 17:36, 22 March 2025 (UTC)

Tmcft

Please add Tmcft to this template, it is used in Indian dam articles like Srisailam Dam. Commander Keane (talk) 11:17, 23 March 2025 (UTC)

Please don't. At least, not before agreeing whether the tmcft is needed it all. It is equal to one billion cubic feet and therefore (IMO) completely redundant. Dondervogel 2 (talk) 11:50, 23 March 2025 (UTC)

That's not equivalent, because both long and short scales are occasionally used in India, and it might not be quite clear what "billion" means. — Chrisahn (talk) 16:08, 23 March 2025 (UTC)

Agree. Many current WP:RS about Indian dams and related subjects use this unit. See e.g. Google news. Using a different unit in our articles would be confusing for our editors and readers. It's a trivial change. The list of volume units already contains Mcuft, Pcuft, Gcuft, kcuft, Mft3 (since 2013). It also contains dozens of US-specific volume units. — Chrisahn (talk) 16:06, 23 March 2025 (UTC)

The discussion at WT:Manual of Style/Dates and numbers#Tmcft does not seem to conclude that Tmcft is useful. Per WP:CALC, it is ok to say that something is 12.3 Tmcft (12.3 billion cubic feet or 350 million cubic metres). It would be better to have a footnote indicating what Tmcft is, although a link to the article should do. After that, don't mention it. Instead, use e9cuft or billion cubic feet. Johnuniq (talk) 01:49, 24 March 2025 (UTC)

That discussion is far from concluded. :-) "After that, don't mention it" – That's not going to work. Tmcft is currently used in 118 articles, often multiple times. Example quote: "...permitted Goa to use 24 tmcft (excluding the 9.395 tmcft prevailing uses), Karnataka to use 5.4 tmcft (including 3.9 tmcft for export outside the basin) and Maharashtra to use 1.33 tmcft..." Tmcft is the unit in the sources for these articles. Using a different unit on Wikipedia wouldn't make sense. — Chrisahn (talk) 02:08, 24 March 2025 (UTC)

is there an error converting LT -> t for values over 199,000?

I must be doing something wrong, but I can't see what it is. Converting long tons to tonnes works fine up thru 199,000 but at 200,000 it just returns the input value unchanged (220,000 LT => 220,000 t). Herostratus (talk) 02:19, 27 March 2025 (UTC)

That is the default rounding. 220,000 has two significant figures and that is applied to the output. You could use something like one of the following although the first is probably wrong because it shows false precision.

• {{convert|220,000|LT|t|0}} → 220,000 long tons (223,530 t)
• {{convert|220,000|LT|t|sigfig=3}} → 220,000 long tons (224,000 t)

Johnuniq (talk) 02:40, 27 March 2025 (UTC)

Ah, got it, thanks. Just a thought, but maybe the default should change for higher numbers? Herostratus (talk) 04:11, 28 March 2025 (UTC)

If I understand correctly, it is not large numbers that are affected vs small ones, but numbers starting with a 1 (or in this case a 2) vs numbers starting with an 8 or a 9. Can numbers starting with a 1 (or 2) be assigned one extra significant figure? Dondervogel 2 (talk) 07:16, 28 March 2025 (UTC)

Not quite, It's not the starting digit but how many zeroes are at the end.

• 218,000 has 3 significant digits and 3 rounded digits.
• 219,000 has 3 significant digits and 3 rounded digits.
• 220,000 has 2 significant digits and 4 rounded digits.
• 221,000 has 3 significant digits and 3 rounded digits.

...

• 899,000 has 3 significant digits and 3 rounded digits.
• 900,000 has 1 significant digit and 5 rounded digits.
• 901,000 has 3 significant digits and 3 rounded digits.

...

• 918,000 has 3 significant digits and 3 rounded digits.
• 919,000 has 3 significant digits and 3 rounded digits.
• 920,000 has 2 significant digits and 4 rounded digits.
• 921,000 has 3 significant digits and 3 rounded digits.

The default rounding of the output depends on how many zeroes it finds at the end of the input. This works good for generic large numbers in isolation (eg, Hoover Dam is 3,250,000 cu yd) but fails when listing through ranges like I just did. Use Johnuniq's solution to override the default.  Stepho  talk  09:00, 28 March 2025 (UTC)

• Math sure is complicated! EEng 12:22, 28 March 2025 (UTC)

Seems like a poor result

{{convert|0.2|sqmi|km2}} produces 0.2 square miles (0.52 km²). It makes little sense that 0.2 square miles should be converted to 0.52 km². Even 0.5 km² would be a higher precision than the input, so why increase the false precision even more? Player001eliminated (talk) 01:19, 1 April 2025 (UTC)

I don't see the problem. On the assumption the area is precisely 0.2 sq mi, the conversion is correct. If the area is rounded, your computer has no way of knowing this unless you specify that with {{convert|0.2|sqmi|km2|1}}, resulting in "0.2 square miles (0.5 km²)". Dondervogel 2 (talk) 05:35, 1 April 2025 (UTC)

But why would someone write 0.2 if the area was precisely 0.2? If the number had more precision, they should write 0.20 or 0.200 instead. In the real world, it is almost never assumed that data values have more precision than the number of decimal places. Player001eliminated (talk) 14:56, 1 April 2025 (UTC)

It occurs to me that neither the convert template nor typical technical writing has a standard way of communicating to the reader that a value is exact. Sometimes the reader has to figure this out from context, other times the publication invents a syntax and announces the syntax somewhere in the publication. Jc3s5h (talk) 16:36, 1 April 2025 (UTC)

Convert does default to giving at least 2 significant figures. Template:Convert/doc#Default rounding describes the basic algorithm thus:

By {{Convert}} default, the conversion result will be rounded either to precision comparable to that of the input value (the number of digits after the decimal point—or the negative of the number of non-significant zeroes before the point—is increased by one if the conversion is a multiplication by a number between 0.02 and 0.2, remains the same if the factor is between 0.2 and 2, is decreased by 1 if it is between 2 and 20, and so on) or to two significant digits, whichever is more precise. An exception to this is rounding temperatures (see below).

There's more below that and at Help:Convert#Rounding. Myself, I think it's a good general-purpose algorithm and defaulting to 1 sf could give very poor results. Convert's rounding can easily be adjusted if we're not satisfied (and as editors we're responsible for our tool use). NebY (talk) 18:04, 1 April 2025 (UTC)

It makes little sense to round it to 2 sig figs the input is 1 sig fig, when it's a decimal value. Especially with decimals, the last digit always gives the precision. Also rounding 0.9 mile to 1.4 km makes a bit of sense, because it's a similar relative level of precision, but increasing the precision by more than a factor of 10 (0.2 -> 0.52) makes no sense at all. Has there been any instance where this was useful? Player001eliminated (talk) 18:26, 1 April 2025 (UTC)

Consider {{convert|0.6|km2|sqmi}} -> 0.6 square kilometres (0.23 sq mi). NebY (talk) 18:43, 1 April 2025 (UTC)

So there's a bit more sense to that; even though it does increase the precision spuriously, the alternative would be to decrease it. Perhaps we could modify this to NOT increase the sig figs if keeping them the same would already increase precision. Player001eliminated (talk) 18:47, 1 April 2025 (UTC)

Would you like {{convert|0.6|km2|sqmi}} -> 0.6 square kilometres (0.2 sq mi) and {{convert|0.2|sqmi|km2}} -> 0.2 square miles (0.5 km2)? NebY (talk) 21:51, 1 April 2025 (UTC)

Remember that the algorithm has to handle hundreds of different cases (many different scales and units). What seems obvious for 0.2 sqmi is not obvious for 2000 sqmi.

0.2 sq mi (0.52 km²)

2 sq mi (5.2 km²)

2,000 sq mi (5,200 km²)

You can see that rounding 2000 sqmi to 5000 km² would not be right. The rounding algorithm chooses what works best in the majority of cases. If it doesn't work in your case then you override it.  Stepho  talk  23:11, 1 April 2025 (UTC)

In some cases, rounding 2000 sqmi to 5000 km² would be right. However, to avoid this, the function can be set to add an additional sig fig if the input is an integer, but not if the input is a decimal. I don't think increasing precision when the input is a decimal makes sense. One possibility is to also use the condition I described above: to NOT increase the sig figs if keeping them the same would ALREADY increase precision. Player001eliminated (talk) 23:18, 1 April 2025 (UTC)

But what about the case of converting sq inches to sq mm for computer chip dies. 0.02 sq in (13 mm²) In that case you do want to keep the precision. Which is why a generic algorithm cannot possibly cope with every situation. Which is why it makes a good estimate at rounding but allows for an override if the editor thinks the rounding isn't quite right.  Stepho  talk  23:29, 1 April 2025 (UTC)

A case where a single sig fig input is actually meant to be exact is very rare. THAT CASE should be accomplished by using the rounding parameter. Most of the time, the input is just an estimate that is accurate to its decimal precision. Player001eliminated (talk) 23:40, 1 April 2025 (UTC)

Your proposed change would result in 1.51 and 2.49 being rounded to 2 by default, for example. I would oppose that. Dondervogel 2 (talk) 07:40, 2 April 2025 (UTC)

@NebY: I do think that would be better than it is currently, but if someone this that 0.6 -> 0.2 is too imprecise, you could use the condition I described in my previous response to you: to NOT increase the sig figs if keeping them the same would ALREADY increase precision, but if keeping them the same would decrease precision (e.g. 0.6 -> 0.2) then set it to 2 sig figs. Player001eliminated (talk) 23:20, 1 April 2025 (UTC)

You think 0.6=0.5 and conversion factors lurching from 2.5 to 3 would be better than it is currently? Well, that's not something I could see as being good practice and I would expect it to cause far more objections than the current approach. NebY (talk) 08:00, 2 April 2025 (UTC)

@NebY What do you mean "You think 0.6=0.5 and conversion factors lurching from 2.5 to 3"? Player001eliminated (talk) 16:23, 2 April 2025 (UTC)

@NebY If all you mean is 0.6 square kilometres (0.23 sq mi) -> 0.6 square kilometres (0.2 sq mi) and 0.2 square miles (0.52 km²) -> 0.2 square miles (0.5 km2)

then that doesn't mean 0.6 = 0.5... That's just how calculations work. There's no reason to go back and forth, you just go one direction. Also, in which way is it helpful to round 0.47 or 0.60 to 0.52? It goes completely against the idea of significant figures. Player001eliminated (talk) 16:26, 2 April 2025 (UTC)

Of course reversibilty and consistency matter, especially in a tool that supports a wide variety of editors and readers variously fluent in one or the other system of units or both, employing a similar variety of sources (including with |order=flip). The default behaviour of the tool strikes a suitable balance beyond the mere "idea of significant figures". NebY (talk) 13:02, 3 April 2025 (UTC)

It really doesn't. I've had to use " |order=flip " specifically because doing it in the expected order would give the wrong result. Player001eliminated (talk) 21:51, 3 April 2025 (UTC)

Can you give some concrete examples where the order affected the precision?  Stepho  talk  22:14, 3 April 2025 (UTC)

Are you asking me? If so, no the order does not affect the precision. Rather, what I was saying is that I would put the second parameter first, and then use order=flip to make both numbers accurate when they otherwise would not be. Player001eliminated (talk) 23:49, 3 April 2025 (UTC)

I'm still not sure what you mean. Can you give a concrete example to explain what you mean?  Stepho  talk 

It may be hard to find one. I just think that the fact that people use order=flip is not a reason that the calculations should be exactly the same when reversed. My original point still stands; taking a single digit input and increasing precision by more than 10-fold is not useful. Player001eliminated (talk) 00:03, 4 April 2025 (UTC)

Here's some examples of rounding single digit input using the algorithm's choice of rounding:

• 100 km (62 mi)
• 200 km (120 mi)
• 300 km (190 mi)
• 400 km (250 mi)
• 500 km (310 mi)
• 600 km (370 mi)
• 700 km (430 mi)
• 800 km (500 mi)
• 900 km (560 mi)
• 1,000 km (620 mi)

And here it is with your proposal of single digit input rounding to single digit output

• 100 km (60 mi)
• 200 km (100 mi)
• 300 km (200 mi)
• 400 km (200 mi)
• 500 km (300 mi)
• 600 km (400 mi)
• 700 km (400 mi)
• 800 km (500 mi)
• 900 km (600 mi)
• 1,000 km (600 mi)

Many conflicts between adjacent values.  Stepho  talk  01:34, 4 April 2025 (UTC)

Then, this can only apply for decimal inputs like I said previously in this thread. Player001eliminated (talk) 01:36, 4 April 2025 (UTC)

Similar examples with algo's rounding:

• 0.1 km (0.062 mi)
• 0.2 km (0.12 mi)
• 0.3 km (0.19 mi)
• 0.4 km (0.25 mi)
• 0.5 km (0.31 mi)
• 0.6 km (0.37 mi)
• 0.7 km (0.43 mi)
• 0.8 km (0.50 mi)
• 0.9 km (0.56 mi)
• 1.0 km (0.62 mi)

And single digit rounding

• 0.1 km (0.06 mi)
• 0.2 km (0.1 mi)
• 0.3 km (0.2 mi)
• 0.4 km (0.2 mi)
• 0.5 km (0.3 mi)
• 0.6 km (0.4 mi)
• 0.7 km (0.4 mi)
• 0.8 km (0.5 mi)
• 0.9 km (0.6 mi)
• 1.0 km (0.6 mi)

Same conflicts.  Stepho  talk  01:56, 4 April 2025 (UTC)

Parameters abbr=~ & order=flip don't combine

Looks like the abbr=~ parameter with order=flip makes it so that the first parameter doesn't do anything. Here's an example:

{{convert|1|kW.h|abbr=~}} → 1 kilowatt-hour [kWh] (3.6 MJ) (Works in the non-flipped case.)

{{convert|1|kW.h|abbr=~|order=flip}} → 3.6 megajoules (1 kWh)

{{convert|1|kW.h|MJ|abbr=~|order=flip}} → 3.6 megajoules (1 kWh)

(Also, having a dot in the unit symbol doesn't produce the mid dot in the output, which is also wrong.) Tstcikhthys1 (talk) 02:18, 14 April 2025 (UTC)

kW.h is used in the visible converts above, but kWh (no dot) is used in the examples. That is why the mid dot is missing. I'll think about the other strangeness later. Meanwhile, adj=~ was added in recent times to handle cases where abbr was needed for something else. However, I don't think that helps here. Johnuniq (talk) 02:34, 14 April 2025 (UTC)

There was a March 2022 discussion where I acknowledged and ducked the issue. Again, that is all I can do at the moment. Johnuniq (talk) 09:29, 14 April 2025 (UTC)