Template Talk:convert
{{User:MiszaBot/config
|maxarchivesize = 950K
|minthreadsleft = 2
|counter = 3
|algo = old(42d)
|archive = Template talk:Convert/Archive %(counter)d
|archiveheader = {{Automatic archive navigator}}
}}
{{FAQ|collapsed=no}}
{{permanently protected}}
{{Archives}}
{{Lua sidebar}}
__TOC__
{{Multiple image
| direction = vertical
| header = :Template:Convert
| width = 300
| image1 = Rube Goldbergian music machine at COSI Toledo.JPG
| image2 = Rube goldberg machine.jpg
| caption1 = ... in conception
| caption2 = ... and in reality
}}
Feature request: Default rounding, but never reduce sigfigs
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)
mpg-us
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}}
::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
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
::
::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:
:::::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)
Visual editor: "precision OR suffix"?
When you are doing a conversion, what if you need to specify precision AND have a suffix (due to adj=mid
)?
If there's a way to do it, the visual editor doesn't make it obvious, and I'm not sure how to do it in wikitext, either. I don't know why these options should be mutually exclusive.
Thanks! 1980fast (talk) 20:47, 20 May 2025 (UTC)
:I don't use the visual editor, so I won't comment on that. But in wikitext the precision and adj forms are not linked in any way.
:Eg: use the {{para||3|}} option for 3 digit precision
displays as {{convert|10|mi|km|adj=on|3}} Stepho talk 23:59, 20 May 2025 (UTC)
::Or, for adj=mid
:
::*
→ {{convert|10|mi|km|long|3|adj=mid}}
::*
→ {{convert|10|mi||long|3|adj=mid}}
::You can even use this (not recommended):
::*
→ {{convert|10|mi|3|long|adj=mid}}
''Mu'', or 'Chinese acres'
File:Cow (Fleckvieh breed) Oeschinensee Slaunger 2009-07-07.jpg
File:പൂച്ചക്കുഞ്ഞുങ്ങൾ (17 ദിവസം പ്രായം).JPG
{{clear}}
File:Muses sarcophagus Louvre MR880.jpg
{{clear}}
For this conversion, see provisional template {{t|Convert mu}}. Thanks, Mathglot (talk) 06:47, 26 May 2025 (UTC)
:From Mu (land), "One mu equals 666.67 square meters in mainland China, 761.4 square meters in Hong Kong and Macau, and 99.17 square meters in Taiwan and Japan." So there needs to be something to choose between the 3 values. Or at least to be very clear in the documentation that only a specific one is supported - although I see endless issues with people doing a conversion with the wrong one in mind. Stepho talk 06:57, 26 May 2025 (UTC)
:: Thank you, already handled in the doc. I am [https://en.wikipedia.org/w/index.php?search=mu+insource%3A%2F%5B0-9%5D+mu+%2F+-insource%3A%22%7B%7Bconvert+mu%22+-insource%3A%22%7B%7Bcvt+mu%22+-insource%3A%2FMU+of%2F+-insource%3A%22%3Cmath%3E%22+-syllabary+-Myanmar+-constellation+-Macaria+-CMOS&title=Special%3ASearch&profile=advanced&fulltext=1&ns0=1 examining the usage] in articles here, and have not so far encountered any cases of the non-Chinese version, but haven't looked at all of them. As the provisional template is slated to disappear when the module is updated, I don't currently see a reason to update the template to add variants which are edge cases (or non-existent cases) that may never be used. If someone turns up some actual cases of them, then I will. The variants could (and probably should) be added to the module when the template function is merged, with the Chinese one being the default, and maybe different unit specifiers for the others, e.g., {{pval|hkmu}}, {{pval|twmu}}, {{pval|jpmu}}, etc. Thanks, Mathglot (talk) 19:11, 26 May 2025 (UTC)
::: Or better the other way round, i.e.: {{pval|muzh}}, {{pval|mutw}}, {{pval|mujp}}, and {{pval|mu}}, the last being an alias of {{pval|muzh}}. Mathglot (talk) 23:56, 27 May 2025 (UTC)
Redaction notice: At this point in the discussion (see this edit of 23:10, 27 May 2025) several images were removed from this section which may have been encumbering the discussion. (It is easier to follow the flow, now.) As the removed content had already been responded to below, this left the discussion in an incoherent state (see TPO). Adding this redaction notice on behalf of User:Chrisahn to restore a coherent narrative. Thanks, Mathglot (talk) 00:36, 28 May 2025 (UTC) {{ec}}
::::Maybe with a separator, e.g. "mu-zh" or "mu_zh"? Or even "mu (zh)"? I first read "muzh" as a single word. — Chrisahn (talk) 00:21, 28 May 2025 (UTC)
::::: Those are details that the module writer regulars can work out to remain consistent with existing usage. Mathglot (talk) 00:38, 28 May 2025 (UTC)
{{cot|bg=khaki|indent=1.6em|Off-topic discussion regarding redaction}}
:I feel that this redaction notice only adds to the confusion. Can we delete it? Your note at the end is fine and sufficient, isn't it? When I deleted the images, I just wanted to keep the discussion on topic and easily readable, but now it's gone meta and off topic again... — Chrisahn (talk) 00:55, 28 May 2025 (UTC)
:: It is meta and it is off-topic, so I am collapsing this, per TPO. I would have had no problem with the image removal had it been accompanied by an explanation despite the TPO issue involved, and it all would have been fine with no follow-up comment necessary by me or anyone else if you had explained your original image removal edit in the discussion itself, instead of only in the edit summary. I realize you were only trying to help, but the way it was left after your edit made it worse for third-party readers of this discussion due to follow-up already in the discussion referring to things higher up that were not there. The redaction notice was an attempt to remedy that, and imho should not be removed to avoid reintroducing the confusion.
:: This is kind of why the WP:TPO guideline exists in the first place, to avoid getting into a confusing situation like this. Asking for removal of the images would have avoided the confusion, and even removing it yourself contra TPO and saying why you were doing it inline in the text would have also avoided it, but you chose silent removal, which unfortunately kicked off the confusion. So at this point, sorry, no, I don't think the redaction notice should be removed.
:: As far as where to at this point, I'm happy with the status quo and don't really have anything else to add, but as you said, this side-discussion is meta and it is off-topic, so if you want to discuss further, may I suggest we pick a different venue? Mathglot (talk) 01:30, 28 May 2025 (UTC)
{{cob}}
{{clear}}Circling back: just to be clear to any and all users, despite an occasional digression into sanity-protecting hilarity or what to some will perhaps see as a mysterious sidetrack or editors having lost their senses, there is a serious core here about adopting a new land area unit into the module, and your feedback is welcome.
Regarding the provisional template {{t|convert mu}}, it was designed to mimic param names and behavior of {{t|convert}}, so that after the new unit is added to the module, conversion of articles using the new template is trivial, by simply dropping the 'mu' in the name. That is: currently, we have:
- {{tlg|convert mu|47,531|mu|ha|lk{{=}}in|sf{{=}}3|code=y|_show_result=y}}
with equivalent positional params, and three available equivalent named params (two shown in the example). To convert it after the module is updated, just change {{kbd|{{((}}convert mu{{!}}}} to {{kbd|{{((}}convert{{!}}}} and it will just work. Mathglot (talk) 18:41, 27 May 2025 (UTC)
: Note: redacted a portion of my previous comment which no longer makes sense after images previously present in this section were removed. Mathglot (talk) 00:47, 28 May 2025 (UTC)