Template talk:Convert#Some editors dislike conversion templates, part 2

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. [https://www.google.com/search?q=tmcft&tbm=nws 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 ({{convert|12.3|e9cuft|E6m3|disp=or}}). 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)

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}} → {{convert|220,000|LT|t|0}}

:*{{convert|220,000|LT|t|sigfig=3}} → {{convert|220,000|LT|t|sigfig=3}}

: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)

{{convert|0.2|sqmi|km2}} produces {{convert|0.2|sqmi|km2}}. 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 "{{convert|0.2|sqmi|km2|1}}". 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:

:::{{tq|By {{tl|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}} -> {{convert|0.6|km2|sqmi}}. 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.

::::::::{{cvt|0.2|sqmi|km2}}

::::::::{{cvt|2|sqmi|km2}}

::::::::{{cvt|2000|sqmi|km2}}

::::::::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. {{cvt|0.02|sqin|mm2}} 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)

::::::::{{ping|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 {{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)

:::::::::::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 {{para|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)

{{outdent}}

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

:*{{cvt|100|km|mi}}

:*{{cvt|200|km|mi}}

:*{{cvt|300|km|mi}}

:*{{cvt|400|km|mi}}

:*{{cvt|500|km|mi}}

:*{{cvt|600|km|mi}}

:*{{cvt|700|km|mi}}

:*{{cvt|800|km|mi}}

:*{{cvt|900|km|mi}}

:*{{cvt|1000|km|mi}}

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

:*{{cvt|100|km|mi|sigfig=1}}

:*{{cvt|200|km|mi|sigfig=1}}

:*{{cvt|300|km|mi|sigfig=1}}

:*{{cvt|400|km|mi|sigfig=1}}

:*{{cvt|500|km|mi|sigfig=1}}

:*{{cvt|600|km|mi|sigfig=1}}

:*{{cvt|700|km|mi|sigfig=1}}

:*{{cvt|800|km|mi|sigfig=1}}

:*{{cvt|900|km|mi|sigfig=1}}

:*{{cvt|1000|km|mi|sigfig=1}}

: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:

:*{{cvt|0.1|km|mi}}

:*{{cvt|0.2|km|mi}}

:*{{cvt|0.3|km|mi}}

:*{{cvt|0.4|km|mi}}

:*{{cvt|0.5|km|mi}}

:*{{cvt|0.6|km|mi}}

:*{{cvt|0.7|km|mi}}

:*{{cvt|0.8|km|mi}}

:*{{cvt|0.9|km|mi}}

:*{{cvt|1.0|km|mi}}

:And single digit rounding

:*{{cvt|0.1|km|mi|sigfig=1}}

:*{{cvt|0.2|km|mi|sigfig=1}}

:*{{cvt|0.3|km|mi|sigfig=1}}

:*{{cvt|0.4|km|mi|sigfig=1}}

:*{{cvt|0.5|km|mi|sigfig=1}}

:*{{cvt|0.6|km|mi|sigfig=1}}

:*{{cvt|0.7|km|mi|sigfig=1}}

:*{{cvt|0.8|km|mi|sigfig=1}}

:*{{cvt|0.9|km|mi|sigfig=1}}

:*{{cvt|1.0|km|mi|sigfig=1}}

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

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=~}} → {{convert|1|kWh|abbr=~}} (Works in the non-flipped case.)

{{convert|1|kW.h|abbr=~|order=flip}} → {{convert|1|kWh|abbr=~|order=flip}}

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

(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)

Template:Infobox firearm cartridge currently defaults to the default rounding behavior of Template:convert. With cartridge dimensions it behaves adequately when converting from mm to inches, but it has the bad habit of turning 3-sigfig inch dimensions (.300) into 2-sigfig mm dimensions (7.6), which is not exactly customary (7.62). I would like to have a switch to enable a modification of "comparable precision" rule that never allows a reduction in the number of sigfigs. Artoria2e5 🌉 13:40, 28 April 2025 (UTC)

Alright, I think I have a bit of an XY problem here. On second thought the issue might not be in the reduction of sig figs, but the threshold used for "comparable precision". Why was "2" picked? Why not something closer to the square root of 10, like "3"? That would avoid this particular problem. --Artoria2e5 🌉 13:49, 28 April 2025 (UTC)

Is it right?

{{cvt|0.8|mpgus}}

290 L/100 km?-- Carnby (talk) 09:11, 4 May 2025 (UTC)

:I can't easily investigate at the moment but this is likely to be a rounding problem. See the FAQ at the top of this page. Johnuniq (talk) 09:18, 4 May 2025 (UTC)

::{{cvt|0.8|mpgus|km/L L/km L/100km|3}} -> {{cvt|0.8|mpgus|km/L L/km L/100km|3}}

::It's approximately right. 0.8 mpg-imp is 0.340 km/L

::0.340 km/L is 2.940 L/km (on your calculator press the 1/n button)

::2.940 L/km is 294.018 L/100 km

::So, 290 L/100km is correct to 2 digits. Add |3 for 3 digit precision.  Stepho  talk  09:31, 4 May 2025 (UTC)

:::I see you got there before me. LoL Dondervogel 2 (talk) 09:33, 4 May 2025 (UTC)

:0.96 miles per gallon converts to 0.34 km/L or 2.94 L/km. That's 294 litres per 100 km, which is rounded to 290 L/(100 km). Where is the problem? Dondervogel 2 (talk) 09:32, 4 May 2025 (UTC)

::::Yep, I'm a fully paid up member of anoraks-R-us. ;)  Stepho  talk  09:38, 4 May 2025 (UTC)

::@Dondervogel 2 I probably asked it the wrong way. In daylight running lamp there's

::{{cvt|0.5|mpgus|L/100km mpgus mpgimp|order=out}}

::yielding:

::Fuel consumption reductions of up to 470 L/100 km (0.5 mpg_‑US; 0.60 mpg_‑imp).-- Carnby (talk) 11:54, 4 May 2025 (UTC)

:::The problem is quite simple: In the US, a length over volume metric is used, whereas in (most of) Europe, it's volume over length, i.e., the inverse. This means that the delta between two miles per gallon figures (say, we got 50 miles per gallon and 60 miles per gallon → Delta = 10 miles per gallon) cannot be converted into a L/100 km delta (and also not the other way around) using the template. The convert template works correctly – it's just that the source information is "dumb" and that whoever cited the source failed to understand it. The source assumes a typical fuel consumption in a certain range (e.g., 40–45 miles per gallon). Its information is only sensible if the average fuel consumption is within that range. It stops making sense as soon as cars become more (or less) fuel efficient. To illustrate the point, let's pretend a fuel consumption figure of 1 mile per gallon, i.e. 282.5 L/100 km. Increasing the "fuel efficiency" by .5 miles to 1.5 miles per gallon yields 188.3 L/100 km, a reduction of 94.2 L/100 km. Any 15-year old, low cdA large family passenger car can do 80 miles per gallon (3.53 L/100 km). Increasing this to 80.5 miles per gallon results in 3.51 L/100 km, which is negligible. Since the source dates back to 1998, prior to the advent of the passenger car CR Turbodiesel, I reckon it's safe to assume that its information is no longer valid, and that the claim should be removed from the article. Best, --Johannes (Talk) (Contribs) (Articles) 13:01, 4 May 2025 (UTC)

::::Looks like it would make more sense to find a reference that states a "xx percent increase in gas mileage".  Mr.choppers | ✎  16:19, 4 May 2025 (UTC)

:::::Perhaps also: {{cvt|0.5|mpgus|km/L mpgus mpgimp|order=out}}

:::::yielding:

:::::Fuel consumption reductions of up to 0.21 km/L (0.5 mpg_‑US; 0.60 mpg_‑imp--Carnby (talk) 03:43, 5 May 2025 (UTC)

::::::Like Johannes and Mr Choppers said, its really a proportional thing.

::::::0.5 mpg improvement out of 40 mpg is about 1.25%.
But 0.5 mpg improvement out of 20 mpg is about 2.5%.
And 0.5 mpg improvement out of 10 mpg is about 5%.

::::::Without knowing the original range then the 0.5 number is essentially meaningless.

::::::If we knew that the original vehicle was about 40 mpg then 0.5 improvement is 1.25% .
Applied to newer cars of about 5 mpg we get 5 mpg x (1.25/100) = 0.0625 mpg improvement.
Which is peanuts but still 1.25% improvement.  Stepho  talk  04:52, 5 May 2025 (UTC)

:::{{ping|Carnby}} What is the precise (verbatim) wording from the original source? Dondervogel 2 (talk) 07:29, 5 May 2025 (UTC)

::::I was not able to find it in the [https://web.archive.org/web/20041105101405/http://dmses.dot.gov/docimages/pdf29/41090_web.pdf linked document]. Johannes was right, the claim must be removed.-- Carnby (talk) 11:06, 5 May 2025 (UTC)

:::::On page 42357 I read "Additional, nonsafety benefits are that turn signal DRLs offer a fuel economy benefit of up to 0.5 m.p.g. compared to headlamp DRLs (according to 1990 test data), lower cost of replacement bulbs (compared with replacement costs for headlamps or headlamp bulbs), and lower costs than the reduced intensity lower beam headlamp according to the 1995 Economic Evaluation of DRLs performed by Transport Canada.". I think it's OK to convert 0.5 mpg to 0.2 km/L (though not to 500 L/(100 km)). Dondervogel 2 (talk) 11:37, 5 May 2025 (UTC)

::::::{{done}}-- Carnby (talk) 12:52, 5 May 2025 (UTC)