Template talk:Convert/Archive September 2015

Micron

Can we please have micron added as a length unit, as a synonym of the existing micrometre. This would be useful for dealing with engineering sources, in some disciplines of which (electroplating being one), the micron refuses to go away. Andy Dingley (talk) 12:25, 31 August 2015 (UTC)

Just an alias? I've done that, but I guess you are aware that micron will behave exactly like um which is accepted for µm:

• {{convert|1|um}} → 1 micrometre (3.9×10⁻⁵ in)
• {{convert|1|micron}} → 1 micrometre (3.9×10⁻⁵ in)
• {{convert|1|micron|uin|abbr=on}} → 1 μm (39 μin)
• {{convert|1|micron|uin|abbr=off|sp=us}} → 1 micrometer (39 microinches)

I tried to define microinch as a default for micron but ran into a glitch because µm is defined to have inch as its default in an exceptions table. I'll think about that later. When convert is updated some time in the future, the micron can be moved into the main set of units if it is used in articles. Johnuniq (talk) 02:46, 1 September 2015 (UTC)

Possible inconsistencies in 'Mass' table, column 3

Hi, I feel there may be a few inconsistencies in Template:Convert/list of units/mass/short list as presented in Template:Convert/list of units. The alternative forms for long ton, short ton and drachm are listed in their own boxes in column 3, rather in parentheses in the same cell. This is probably deliberate, but I wondered if anyone could enlighten me. NB I'm probably not capable of disentangling the intricate web of tables myself, even if anyone thought it needed changing. >MinorProphet (talk) 15:55, 30 August 2015 (UTC)

I see that your two links Template:Convert/list of units/mass/short list and Template:Convert/list of units are the same as concerns the "there own box" in column 3. But I do see an inconsistency in "there own box" in the unit code column 3 at Template:Convert/list of units/mass. I too wonder about that lack of information there.

I also see that "in parentheses in the same cell" applies to an alternative unit code: " μg (ug)", but that LT shows its alternative unit code it's in it's own box (as "long ton"), which is different. I think that's deliberate, and I agree with it. The "ug" is just an alternative way to type the unit code in on the keyboard, and has no connection to column 4 as LT does. LT has its own box in the unit code column 3, and it signifies an Abbreviation column 4 corresponding box.

I think the intricacy is really in the terminology. The term "abbreviation" is used three ways in the documentation. When identifying a unit to convert, we use the unit code (column 3), which is an input "abbreviation" or code. In a few cases, as shown in the Unit code column 3, you can spell out the unit code instead of using the "abbreviated" unit code. We can say meter or m, long ton or LT. Column 4 Abbreviation is for the parameter |abbr=, for output, but there's two outputs to abbreviate, and both types of output abbreviation are addressable: 1)an output of the to-convert-input unit and 2) an output of the converted-output unit. Note how if you used unit code LT, there is no or "(none)" Abbreviation column 4, for the |abbr= to abbreviate, LT input is apparently never output as LT, and long ton is abbreviated long ton.

{{Convert|9|LT|abbr=in}} → 9 long tons (9.1 tonnes)	LT→long ton, because abbreviation "(none)"
{{Convert|9|long ton|abbr=in}} → 9 long tons (9.1 tonnes)	abbr="long ton" per "its own box" column 4.
{{Convert|9|meter|abbr=in}} → 9 m (30 feet)	it actually works (its not "(none)")
{{Convert|9|m|abbr=in}} → 9 m (30 feet)	column 3 and 4 the same, no "there own box"

— CpiralCpiral 23:50, 30 August 2015 (UTC)

An authoritative description of the mass units is here. It's authoritative because the information displayed is used to generate the data that convert uses—the page defines what the units do. Because it is a machine-readable specification, it has a lot of mumbo jumbo, and it's too long for human consumption. However, in some ways it is easier to understand than the simplified documentation, although of course I'm used to it. To explain its relevance here, looking down the left-hand column (Unit code) for LT finds a row showing the symbol is "~long ton" and the name is "long ton". The tilde is part of the mumbo jumbo (explained near the top). The conclusion is that LT will show "long ton" if abbr=off applies, and the same if abbr=on applies—it always shows "long ton", or "long tons" if plural. I'm not sure what can be done to improve the documentation—complex stuff is complex. Johnuniq (talk) 01:45, 31 August 2015 (UTC)

Thank you, Cpiral and Johnuniq for your helpful and enlightening explanations. I had misunderstood from the start what column 4 represents, which was the cause of my confusion; my mind is much clearer now.

@Cpiral: 1. I see why the term 'abbreviation' can be unhelpful and/or misleading, both from a normal user's point of view, and also as a meta-word when trying to describe the different concepts involved. 2. I think I have seen the inconsistency in the Master table: 'LT' and 'lt' can be used for parameters 2 and 3, but '-ST' can only be used for parameter 3 to force the right side to display a symbol. Thus {{convert}} cannot output 'ST' as the abbreviated (symbol) left side of the displayed result (ie you can't use it as the second parameter.) 3. Also, 'drachm' is also inconsistent (maybe for a good reason). Input-code 'dram' should output 'dram' and not 'drachm'; the output symbol (or short form) should default to 'dr' for both 'dram', not 'drachm' if |abbr=on . This means that {{convert}} can't use 'dr' as an input-code 'typing shortcut', to avoid user confusion between the two spellings in the displayed result.

@Jonuniq: I agree that the full documentation is somewhat clearer than the short form, thank you for the link. I almost =understand how *it ~works. As you say, it is complex, because of the numerous combinations involved. But your comment that the master doc is designed to be machine-readable, made me realise that the Template:Convert/list of units short documentation is not laid out from a normal user/editor's point of view (I used to manage a small office PC network LAN & WAN with 50 users.)

As a result of all this, I have been thinking quite hard about how the short documentation might be presented more from an end user's POV (which is not the usual purpose of WP). I think that the wording of the column titles could be clarified in order to give a clearer idea in the user's mind of the displayed result they are trying to achieve; the columns could also be ordered differently. I have been working on some changes to the tables to provide a slightly more user-centered version, which would hopefully be relatively trivial (hah!) to implement. I'll post my attempt when done. >MinorProphet (talk) 18:48, 1 September 2015 (UTC)

I think one reason the word "abbreviation" has been used is that the parameter is abbr=on or abbr=off (or others): abbr=on shows the unit symbol; abbr=off shows the unit name. Johnuniq (talk) 07:34, 2 September 2015 (UTC)

Time conversions

Can someone add Time units to CONVERT? Annums (standardized length years), Weeks, Days, Hours, Minutes, in addition to the currently used metric seconds. And D:H:M:S.s though that overlaps with angles so may cause problems -- 70.51.202.113 (talk) 06:14, 2 September 2015 (UTC)

Some time conversions are available, see Time at the full list of units:

• {{convert|1.5|wk|h|0|abbr=off}} → 1.5 weeks (252 hours)
• {{convert|1.5|year|s|0|abbr=off}} → 1.5 years (47,336,400 seconds)

Johnuniq (talk) 07:34, 2 September 2015 (UTC)

Thanks, it wasn't in the page I was looking at Template:Convert/list of units, that documented what was there. -- 70.51.202.113 (talk) 09:17, 2 September 2015 (UTC)

The only thing left is D:H:M:S.s/H:M:S/H:M/D:H:M type time interval values. Though I don't know what you'd call this as an input unit type. -- 70.51.202.113 (talk) 09:39, 2 September 2015 (UTC)

long ton not abbreviated

Is this conversion doing the right thing?

{{Convert|1120|t|LT|abbr=on}}

1,120 t (1,100 long tons)

Shouldn't it render as:

1,120 t (1,100 LT)

—Trappist the monk (talk) 12:51, 6 September 2015 (UTC)

In cases where there is not a standard symbol or abbreviation for a given unit (or where a unit name could not be contracted without risking widespread confusion or ambiguity), the template opts for the more conservative approach and spells out the unit name in full. The long ton and short ton do not have any standard abbreviations; same with some other units like the acre. Archon 2488 (talk) 15:13, 6 September 2015 (UTC)

Archon's answer is perfectly correct, and I find all the t/ton/tonne/LT/ST units a complete nightmare, however someone must have made a fuss about this particular case a long time ago because there is a kludge:

• {{convert|1120|t|LT|abbr=on}} → 1,120 t (1,100 long tons)
• {{convert|1120|t|lt|abbr=on}} → 1,120 t (1,100 LT)

This unit is in the full list and is used rarely in articles (around 80 times), with LT occuring over 21,000 times. Johnuniq (talk) 00:19, 7 September 2015 (UTC)

See also {{long ton}}. It does avoirdupois. -DePiep (talk) 21:19, 9 September 2015 (UTC)

Conversion from inches to millimeters

"convert|5.2|in|mm|abbr=on|disp=flip" is showing 130 mm for both 5.2 and 5.3 inches, which should equate to 132.08 mm and 134.62 mm respectively. --uKER (talk) 04:04, 11 September 2015 (UTC)

The following shows the issue:

• {{convert|5.2|in|mm|abbr=on|disp=flip}} → 130 mm (5.2 in)
• {{convert|5.3|in|mm|abbr=on|disp=flip}} → 130 mm (5.3 in)

Convert determines what default precision should apply in order to show the output that corresponds to the precision of the input. The precision can be specified:

• {{convert|5.2|in|mm|0|abbr=on|disp=flip}} → 132 mm (5.2 in)
• {{convert|5.3|in|mm|0|abbr=on|disp=flip}} → 135 mm (5.3 in)
• {{convert|5.2|to|5.3|in|mm|0|abbr=on|disp=flip}} → 132 to 135 mm (5.2 to 5.3 in)

Johnuniq (talk) 04:20, 11 September 2015 (UTC)

I don't get whether that's supposed to mean that there's not a problem, or if it's a reaffirmation of my report. You editing my title makes me think it's the former. Care to clarify? I still don't think the default behaviour should be a conversion that's off by 4.62 mm in the case of 5.3 inches. --uKER (talk) 13:46, 11 September 2015 (UTC)

The template doesn't (and probably can't) have the intelligence to convert units to the appropriate precision in every instance. For example, if a source says that one town is about 60 kilometres away from another, you'd want to convert that as {{convert|60|km|mi|sigfig=1}} → 60 kilometres (40 mi) (providing an equivalent approximation in imperial), whereas if it was a course designed to be exactly 60 kilometres long, you'd probably convert it as {{convert|60|km|mi|sigfig=2}} → 60 kilometres (37 mi) (converting the nearest kilometre to the nearest mile). You need to provide some editorial oversight, using the template options to adjust significant figures and decimal places. There isn't a shortcut, to the best of my knowledge. Archon 2488 (talk) 14:31, 11 September 2015 (UTC)

The documentation says (confusingly) "Specify the desired precision with the fourth unnamed parameter (or third unnamed parameter if the "convert to" parameter is omitted; or fifth unnamed parameter if a range is specified;", Template data section says it's 4th unnamed parameter. The documentation for rounding is very near the top, and the documentation on parameters is very near the bottom. So I think of two changes when I read these repeating complaints (whose frequency is alarming): 1) Better documentation (probably won't help, but there's always hope and room for improvement). 2) Better practice. Could Convert default to maximum precision? i.e. make a user undo precision, instead of adding it. Err on the side of too much? Never err on the side of a mistaken reader-editor interpretation; i.e. zeroes are always significant, until otherwise stated in a parameter? — CpiralCpiral 19:52, 11 September 2015 (UTC)

All references to "unnamed" parameters should probably be removed and replaced with simple clear examples of |precision=nnn and |sigfig=nnn. —Sladen (talk) 20:29, 11 September 2015 (UTC)

What I'm saying is that convert cannot handle all cases well. The current situation sometimes causes problems, but if convert gave extra precision on the assumption that editors could reduce the precision to what was appropriate, there would be complaints that convert was stupidly inventing precision not present in the input. Also, working out what is appropriate is not always straight forward. There is no precision=n parameter and introducing one now would not help because hundreds of editors are used to how convert works and they are not going to change, and there are well over 100,000 converts in articles that use the current method of specifying a precision just as a number. There are infrequent reports here of problems with rounding, but it's nothing like the debates that used to rage—for example, search October 2009 (and many other archive pages) for "rounding". What might help would be to brush up the documentation as suggested, but more importantly tweak the FAQ at the top of the page and introduce a brief page notice that is displayed when editing this page—it would point to the FAQ. For the particular case of converting a value of around 5 inches to mm, I've just single-stepped the code (function default_precision in Module:Convert) and I suppose it could be improved as a special case. However the trick would be working out how any change would impact other conversions—small tweaks can have unforeseen consequences. Johnuniq (talk) 01:25, 12 September 2015 (UTC)

Johnuniq, see Template:Convert/doc#Round to a given precision: use .7Cprecision.3D. —Sladen (talk) 10:48, 15 September 2015 (UTC)

Thanks for pointing that out. I have fixed the documentation so it no longer implies there is a parameter named precision. I decided to omit some of the complexity because people just want to know how to use convert, and there is no reason to try to explain how it works, particularly since there are various exceptions. Johnuniq (talk) 12:19, 15 September 2015 (UTC)

Johnuniq. Thank you, although I see this has now been reverted.[1]. Peter coxhead, you appear to have invoked WP:BRD, please could you help join the discussion so that we can get some corrected wording that also works for everyone? —Sladen (talk) 13:55, 15 September 2015 (UTC)

I just thought that removal was a step too far. I suggest moving the mathematical details to a footnote, and just showing, by examples, what the default is in some cases and how this can be changed. I only have limited internet access at present, so don't want to attempt this myself now. Peter coxhead (talk) 14:45, 15 September 2015 (UTC)

My edit briefly mentioned what default rounding does, and included several examples. If the details were in a footnote they would have to be correct, and there is more to it than the documentation stated. The result would be totally opaque. Please see the new section just below. Johnuniq (talk) 23:46, 15 September 2015 (UTC)

Proposed new units

Angular change per unit time

With angle units, it would also be good to have change between angular change per unit time and Hertz (cycles per second), since one cycle is 360-degrees. So 90-degrees per second would be a quarter of a full cycle, so 0.25Hz -- 70.51.202.113 (talk) 06:25, 2 September 2015 (UTC)

What are some examples where this would be useful in articles? Johnuniq (talk) 07:34, 2 September 2015 (UTC)

I was thinking the speed of a rotating vector should be able to be expressed in Hertz easily and back to radians to show what an electromagnetic field's rotation would result in a particular field signal, thus good for various EM descriptions. -- 70.51.202.113 (talk) 09:30, 2 September 2015 (UTC)

RPM

Can revolutions per minute / r.p.m. ; and beats per minute / b.p.m. be integrated into the conversions for cycles per unit time? 60rpm would be 1Hz. Since rpm is a common measurement for recycling times, it should be available for conversion. -- 70.51.202.113 (talk) 09:30, 2 September 2015 (UTC)

BPM

Can beats per minute / b.p.m. be integrated into the conversions for cycles per unit time? 60 bpm would be 1Hz. -- 70.51.202.113 (talk) 09:30, 2 September 2015 (UTC)

The sentence "60 bpm would be 1Hz" is an exact conversion, so presumably not allowed on Wikipedia per the new 70.51.202.113 "only decimal approximations allowed" regime. Sławomir
Biały 11:50, 16 September 2015 (UTC)

Discussion of proposed new units

My earlier comment was "What are some examples where this would be useful in articles?" This comment is an attempt to explain what I was getting at. More than a thousand units are defined in convert (not counting the many variations like SI prefixes), and hundreds of units are not used. I am very reluctant to add more units just because it's possible. Instead, please find an article with some text that could be improved with a new unit. If it's just one article, I would still think that there was no need for a new unit—something that is used just a couple of times does not need the complexity of automatic conversion. What gets fast attention on this page is when an editor is developing a series of article and finds that the text they are adding needs some unit unknown to convert. That hasn't happened for quite a while, but when it does, something is done. Extra units require documentation and maintenance, and add to the clutter of the list of all units, making it harder to find units that are actually useful. Johnuniq (talk) 07:59, 3 September 2015 (UTC)

Angle conversions

Can someone add Angular units to CONVERT? degrees, radians, gradians, hms, DMS; I suppose the overlapping names for seconds and minutes (and hours; days) would cause problems. -- 70.51.202.113 (talk) 06:14, 2 September 2015 (UTC)

I suppose we could call them "minutes of arc"/arcminute/arcmin, etc... but hms and DMS conflict... -- 70.51.202.113 (talk) 09:22, 2 September 2015 (UTC)

What are some examples where this would be useful in articles? Johnuniq (talk) 07:34, 2 September 2015 (UTC)

In many astronomical sources, there are differences in recorded units, depending on era, so converting them from the referenced source to the onpage value without hiding where a number appeared from is a good idea. Angles are used to establish where things are relative to others, how fast them move across the sky, and stellar parallax. -- 70.51.202.113 (talk) 09:22, 2 September 2015 (UTC)

In Wikipedia articles (and the astronomy sources I've read) it is routine to convert a format that occurs in a source to a format that is consonant with the citing article, with no mention of the original format. Even if, in some unusual situation, we needed to quote the original format as well as provide the consonant format, we would put the original format in a footnote, and the "convert" template wouldn't help with that. Jc3s5h (talk) 12:19, 2 September 2015 (UTC)

Convert would show the original source's number, in source view, and display the number in a manner consistent with how the article should show things. As several sources use decimal degrees for right ascension and declination, while Wikipedia consistently uses hms±DMS, it would be good to actually show the reference's values in source view while displaying the expected consistency values in rendered view. This will save on people asking where some number appeared out of thin air from, or deleting numbers that aren't explicitly in the references used as original research. Non-astronomy editors also work on Wikipedia, and we cannot expect all of them to understand the implicit conversions used, instead of just flagging the numbers as unreferenced, or removing them outright because they don't appear as written. -- 70.51.202.113 (talk) 04:42, 3 September 2015 (UTC)

Post by 70.51.202.113 (talk · contribs) is factually incorrect. Convert shows both the unit converted from and the unit converted to; there is no "hidden value" that is only shown in source view. Also, Wikipedia has no preference as to whether hours-minutes-seconds, degrees-minutes-seconds, decimal degrees, or some other variation is displayed in articles, although consistency in articles is normally expected. Jc3s5h (talk) 09:26, 8 September 2015 (UTC)

I've commented at WT:WPM but I'll repeat the same sentiment here: I think this would be of little use, and possibly harmful, for pure mathematics articles. Of little use, because most of the time in mathematics articles one wants to express an angle as an exact formula (π/2 radians) not an approximate numeric value (1.5708 radians), and I doubt that getting symbolic mathematical manipulation right is within the scope of this template or the template system in general. Harmful, because if this exists then naive editors will start insisting that it needs to be used for all angle measurements in all articles, and apply it even in situations where it would be inappropriate. —David Eppstein (talk) 07:01, 7 September 2015 (UTC)

I'm sure you're right. I've asked for specific examples (mainly below) where the proposed new units would be useful, and it is very unlikely that anything will happen unless several are available. Johnuniq (talk) 10:30, 7 September 2015 (UTC)

As I've already stated, for angle conversions, they would be very useful, for consistency of display of units between articles, while displaying the originating source's values, for astronomy topics. Especially considering the differing values for the location in the sky of some astronomical objects being expressed in decimal degrees instead of the standard hms/DMS values for our articles for right ascension and declination. And for sources that use degrees of arc in expressing angular separation and parallax instead of milliarcseconds (mas) which is the usual measure used in our articles. -- 70.51.202.113 (talk) 04:58, 8 September 2015 (UTC)

I don't think the template would be useful in the articles right ascension or declination. All of the conversions done there are exact. A template that does decimal manipulation would be inappropriate. In parallax, most of the conversions are done in displayed math, so a template wouldn't be useful. (Also, we wouldn't add to this template for the sake of a single article, even if the equations were converted from displaymath to html). Sławomir
Biały 15:39, 8 September 2015 (UTC)

Why are they 'exact' conversions? Right ascension and declination are measured quantities. They are only accurate to certain decimal places, and not beyond, because there is a limit to how precisely things can be measured depending on the limits of the instrument involved. -- 70.51.202.113 (talk) 05:35, 15 September 2015 (UTC)

Here are the conversion that the article right ascension makes:

Any units of angular measure could have been chosen for right ascension, but it is customarily measured in hours ( ^h ), minutes ( ^m ), and seconds ( ^s ), with 24^h being equivalent to a full circle. Astronomers have chosen this unit to measure right ascension because they measure a star's location by timing its passage through the highest point in the sky as the Earth rotates. The highest point in the sky, called meridian, is the projection of a longitude line onto the celestial sphere. Since a complete circle contains 24^h of right ascension or 360 degrees of arc°, 1⁄24 of a circle is measured as 1^h of right ascension or 15°; 1⁄(24×60) of a circle is measured as 1^m of right ascension or 15 minutes of arc (also written as 15'); and 1⁄(24×60×60) of a circle contains 1^s of right ascension or 15 seconds of arc (also written as 15"). A full circle, measured in right ascension units, contains 24×60×60 = 86,400^s, or 24×60 = 1,440^m, or 24^h.

Let me get this straight. You're saying that the article shouldn't be doing exact conversions anyway, like between 1/24 of a circle and exactly 15°, because right ascension is a "measured quantity"? That's a bit baffling, but if that's the case, then it looks as though you are trying to use this template as a pretext for imposing an idiosyncratic view on article content. I am strongly opposed to this proposed usage of the template, to replace exact conversions by decimal approximations. Sławomir
Biały 11:32, 16 September 2015 (UTC)

Let's get this straight, the values presented in our articles for right ascension and declination are not exact because they are measured with a device, since they represent a measurement of an object in the sky. Any measurement by any device is inexact. The conversion of any real measured right ascension / declination can never be exact because we do not have perfect instruments from which to measure these quantities. Theoretically the conversion from inches to millimeters is exact but actual quantities measured with say a micrometer or a laser rangefinder, is not exact, because they are measured quantities, and thus can only be represented with an inexact value. CONVERT right now does significant figure calculations for conversion between units, because they are measured values. This is the same case with right ascension and declination. CONVERT does not produce exact conversions (which make no physical sense), it produces that to the level of precision provided by hte input value, or the significant figure parameter provided. (it makes no sense provide more precision that the original measurement has, since those decimal places represent illusionary non-physical precision that is not accurate) -- 70.51.202.113 (talk) 05:18, 17 September 2015 (UTC)

"the values presented in our articles for right ascension and declination are not exact": Yes, I got that you believe this. I got that you don't believe that 1/24th of a circle is exactly 15°. This is why I am strongly opposed to adding angles to the template, because it seems like you are using the template as a pretext to impose some weird view on article content, in which we are not permitted to say that 1/24 of a circle is exactly $\pi /12$ radians. That's never going to happen. Sławomir
Biały 10:44, 17 September 2015 (UTC)

No, the values presented for "right ascension" and "declination" Just as you find at Mount Everest, the height is not exact; by analogy, how would you ever come to the conclusion that the conversion between metres and feet would be an exact figure, when there are error ranges for the initial value? This is exactly the same case. I don't see how you could ever think any value that is measured for any astronomical measurement would ever be exact since they are being measured by man and not God, for every single astronomical location ever measured -- 70.51.202.113 (talk) 03:06, 18 September 2015 (UTC)

IP, you were asked to provide examples of articles where the template would be useful. The examples you gave were right ascension and declination, right? You've been arguing that these conversions are meaningless as exact values. That's just wrong. Mount Everest has no angle conversions, so it seems to be a red herring. Conversions from meters to feet are rather different, because they are not based on intrinsic geometric properties of circles. Sławomir
Biały 19:48, 18 September 2015 (UTC)

This whole line of argument makes no sense. Sometimes a value quoted in a WP article will be exact (a defined or nominal value, say) and sometimes it will be inexact (a measurement or an approximation). You need human intelligence to differentiate between those cases and adjust the conversions appropriately. Archon 2488 (talk) 11:52, 17 September 2015 (UTC)

It seems to me that the request is rather garbled. I think that simple unit conversions amongst angle units are absolutely appropriate and should be in the template. eg

{{convert|30|arcmin|deg}} should output "30 arcmin (0.5°)"
{{convert|30|arcsec|arcmin|abbr=on}} should output 30" (0.5')
{{convert|20|deg|hms}} should output "20° (1^h 20^m)"
{{convert|20.5|deg|dms}} should output "20.5° (20° 30^m)"
{{convert|20d30m|dms|deg}} should output "20° 30^m (20.5°)"
The last one might be technically difficult to parse; I don't know templates well enough to know. I agree with others that converting to radians gets trickier because notation conventions involving pi exist for a very good reason and would be difficult to parse; editors would have to use it with considerable caution if the functionality were to exist in the convert template at all. However, the radians thing is a distraction; radians are essentially never used for the astronomical purpose mentioned by the IP. The main use of radians in this context would be for small angle approximations on the order of arcsec, for which the concern about exactness doesn't apply. (Not sure if that ever gets done on Wikipedia, though.) —Alex (Ashill | talk | contribs) 14:00, 17 September 2015 (UTC)

The examples of where this template would be deployed do not fill me with confidence that the template would be used wisely, if at all. WP:BEANS seems to apply here. Sławomir
Biały 14:54, 17 September 2015 (UTC)

The example you quoted above is just an example defining the term. So yes, when the article says as an example that 12^h of right ascension corresponds to 180° or pi radians, that's exact. But a much more common usage is to say that the Andromeda Galaxy is at right ascension, declination of 00^h 42^m 44.3^s, +41° 16′ 9″. It would be convenient to be able to plug that into convert and get out 10.68°, +41.27°. But researching this further, Template:HMS2Deg and Template:Deg2HMS may be part of what 70.51.202.113 is looking for: {{HMS2Deg|00|42|44.3}}: 10.684583. But it would still be useful to have the convert template handle things like "The semi-major axis of the Andromeda Galaxy is 190' (3° 10')." —Alex (Ashill | talk | contribs) 13:23, 18 September 2015 (UTC)

Documentation: Unified nomenclature

Carrying on from this and this above:

Apologies for the long post. Since my last post here, I have been thinking hard about these docs and examples etc., and I find that many of my ideas/worries/thoughts have been simultaneously expressed here by others; so it appears I'm not alone. NB I am not a mathematician/scientist/expert at markup or coding in any way.

It seems to me that a number of problems arise from the somewhat vague and inconsistently-applied terminology to describe the various unnamed/named parameters/options etc., such as terms like abbreviation, left-hand side, the word 'unit' used by itself, 'output value', 'round number' etc. I believe that all these similar equivalent terms can be dispensed with by the adoption of single, unambiguous terms which should be used consistently and meaningfully throughout the template (eg 'Input/output options' to describe 'un-/named parameters', etc.

Samples of current equivalent nomenclature

• input value = value to be converted
• unit-code for the unit to be converted from    = left-hand side = input parameter = 2nd unnamed parameter
• unit-code(s) for the unit(s) to be converted to = right-hand side = output parameter(s) = 3rd, 4th etc. unnamed parameter
• 3rd-6th 'input unit-codes' = units etc
• 'unit name' (column 2) = full name = unit =
• 'unit-symbol' (column 4) = abbreviation = symbol
• rounding-value = last named parameter = round value

Here are some of the same offenders, from a slightly different angle:

• Input options or "Unnamed parameters" - mostly input
  • Conversion-value /Value for conversion / Number to be converted / 'input value'
    • Rounding generally
    • Fractions - using fractions both in input values ('conversion-value') and the output (named parameter/option) |frac=
  • 'Range separator' / identifier, for converting two 'input-values': 3 x/by/to 4 feet, etc.
  • Input-codes ("2nd & 3rd unnamed parameters") / 'input unit-code' and 'output unit-code' / left/right -hand side / unit to be converted from/to
  • 'Rounding-value' / 'last unnamed parameter' / 'round value' / 'precision' - are |sigfig= and |round= named or unnamed parameters?

• Output options or "Named parameters" - mostly output
  • |abbr=| adj= |comma= |debug= |disp= |frac= |lk= |order= (possibly not |round= |sigfig= if they are input options?) |sortable= |sp=us |spell= ( what exactly is meant by 'input number' in any context - it may be obvious to some, but it's confusing for a non-scientist/mathematician. Some terms are mutually exclusive, but it's often to see which ones, and why. Each option should be treated in exactly the same way, with the same terms and layout, like any decent printed manual for OS commands or applications.

Suggestions

1. How about agreeing on a list of unique 'master terms' to describe most things in C/doc, for use by anyone who uses and/or maintains the Convert template and documentation (with a list of equivalent terms which will eventually all be replaced by the 'master term')
2. Agree on a general format for all the documentation - I think it's fairly evident that something needs doing.
3. Then, how about attempting to create a 'proper' manual in the manner of a Unix man page, or other OS (even MS-DOS...), in which the master terms are used consistently to describe each aspect of using (and maintaining) the template.

<aside> As someone who hasn't studied any science or maths subject academically since age 16, I find the concept of 'decimal places' relatively easy to understand, and 'significant places' somewhat daunting. </aside>

I think that a wide range of well-chosen examples is very important; I agree that a flowing, consistent prose style is very useful: but there are so many possible combinations that examples can be more helpful than prose.

Proposed manual

• Intro
• Terminology - defining the unique terms to be used consistently and passim in the documentation
• Basic operation for first-timers/non-mathematicians/etc., including rounding etc.
• Detailed, consistent, uniform sections like man pages etc.
  • input options (for calculation)
  • output options (for tweaking/customising the displayed output/result)
    • (could incorporate improved general layout of Template data table)
    • list of all default/silent options/parameters used by {{convert}} for a simple {{convert|1|kg}} (eg |disp=b, max. number of digits in 'number to be converted'/'conversion-value', etc.
• Trouble-shooting
  • List of Error messages etc.
  • Help:Convert messages

I have started a page User:MinorProphet/Draft subpages/man convert laying out and addressing some ideas for a manual, although I haven't got very far. It's not at all polished and may not be helpful, although I have learned a whole load just from constructing what is there so far. MinorProphet (talk) 11:04, 22 September 2015 (UTC)

I don't have time to digest this at the moment, but did you see #Documentation details above? In particular, what do you think of my edit? The edit does not address many of the points above, but I'm wondering if you think it was a step in the right or the wrong direction. I agree that terminology should be consistent, but I think the documentation should mainly be a list of examples, with minimal explanation and I cannot imagine any part of a man page that would be helpful here. Johnuniq (talk) 12:00, 22 September 2015 (UTC)

Man page#Layout applies, whereas man page#Manual sections doesn't. — CpiralCpiral 17:28, 24 September 2015 (UTC)

Convert is great for the MoS, for it's active and responsive talk page, and for its interesting units forum. It should be easy to satisfy these three with one terminology for the newcomers and entrenched alike. How Convert seems to newcomers is invaluable information.

Wikipedia is great for collaboration, but here's how it seems to me to work: single editor creates a draft. Then other editors modify it. When two or more editors try to work at the same time, I've yet to see that work efficiently, as much as I would like to try. — CpiralCpiral 17:28, 24 September 2015 (UTC)

Documentation details

The above section started discussing Template:Convert/doc. What do people want? My edit (diff) did a bunch of things but apparently the edit to "Default rounding" or "Round to a given precision" was too much and it was reverted. The before-and-after are below:

Section	Original	Proposed
Rounding	By 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 figures, whichever is more precise. An exception to this is rounding temperatures (see below).	By default, the conversion result is rounded to a precision comparable to that of the input value.
Precision	Specify the desired precision with the fourth unnamed parameter (or third unnamed parameter if the "convert to" parameter is omitted; or fifth unnamed parameter if a range is specified; or fourth unnamed parameter again if a range is specified and the "convert to" parameter is omitted; needs to be replaced with a "precision" named parameter). The conversion is rounded off to the nearest power of 1⁄10 this number. For instance, if the result is 8621 and the round number is "-2", the result will be 8600. If the result is "234.0283043" and the round number is "0", the result will be 234.	The precision is entered as an unnamed parameter after the units. The precision is 0 (round to nearest whole number), or a positive integer (round to the specified number of decimal places), or a negative integer (round to a power of ten, so the result finishes with the specified number of 0s).

A few years ago very extensive discussions were held about how rounding should work, and whether it was possible to implement using templates. At that time, the docs were updated to reflect the different ways that default rounding worked while people developed ideas. The solution implemented by Jimp has been universally accepted and has worked well for years, with the implementation now in Module:Convert. The system of default rounding works so well that people are surprised when it does not do what they expect, and there are occasional issues like in #Possible Convert Problem? and the previous section. However, the details of how rounding works are no help with those queries because the point is that the default does not do what the editor wants.

What should be in the documentation? Johnuniq (talk) 23:40, 15 September 2015 (UTC)

Principally working examples are what should be in the documentation. Examples are self-evident to readers/users. Distracting paragraphs of text about unnamed parameters and syntax from five years ago aren't helpful. —Sladen (talk) 00:24, 16 September 2015 (UTC)

Agreed. Learning Perl6 for example, at first I only want a REPL and examples. — CpiralCpiral 07:14, 16 September 2015 (UTC)

What should be in the documentation? Overall, better prose. Even the section titles have examples in them, and the examples are thick as bear hair. There's not enough prose balance for those who're looking to read the whole document in one sitting. I've read Convert only a few times. It was numbing, but I played the stalwart. I remember liking the many examples, and seeing a few style inconsistencies, and shuddering at the thought of editing them.

OK, if it were up to me, I'd take a few weeks, rework the overall arrangement (placement of section titles and their material), and add some new prose for lubrication.

==Rounding and precision == 100 ft is exactly 30.48 m. But 100 ft could call for a conversion to 30 m or 30.5 m, depending on the intended accuracy of the original call being cited. Template Convert uses roughly the number of significant digits, or you can change that with |sigfig= or ... and where conversions are required, the same accuracy must propogate to the conversion."

The TOC should flow like a narrative, like prose, and the prose take full advantage of hyperlinking and footnotes to reduce its size. Examples are primary and are what is needed, and there is no lack of this beneficial goodness, but section titles shouldn't have numbers or question marks or examples either. The entire TOC should have only subject matter phrases.

New, number-savvy, users will most likely also be in a big a hurry, and should be able to jump from the TOC subject to the given numerical examples (not at the given numerical example), and still be in and out in 10 seconds. In my tech-writing book, it's forbidden to force the reader to return there gaze back to the section title. In doing so, they'll likely be back for involvement later, and then they'll want to read the whole thing with good prose. But this means a new style for C/doc, and if one then all section titles must be purified.

— CpiralCpiral 07:14, 16 September 2015 (UTC)

Thanks for the ideas but the perfect is the enemy of the good.

• Any thoughts on whether the docs should have the Original text in the table above, or the Proposed text?
• Any thoughts on whether this edit (the one that was reverted) should be restored?

After that, other edits can be considered. Johnuniq (talk) 07:41, 16 September 2015 (UTC)

I would hope that we could start by restoring the edit, and that when other editors have internet access again those editors can work forward to improve the edit rather than stepping us backwards by performing a wholesale revert. As for wording, perhaps we could tighten it even more. "Rounding to a specific number of decimal places is performed by adding an extra positive integer parameter. If the rounding is zero or negative there will be no digits after the decimal place, and the result will be rounded to the nearest power of ten. Otherwise, a suitable precision and rounding will be chosen based on the input value." And then 3–4 examples. —Sladen (talk) 10:59, 16 September 2015 (UTC)

re Cpiral: I have put the examples in the /doc section headers, and still think that they belong in there. /doc is not for "reading the whole stuff before using the template", it is about finding the detail you are looking for. Is what TOC is helping in. So I'm with Sladen here. btw, {{this template}} has the samenot any more. (Or would you like having to read all the technically extended options?) -DePiep (talk) 15:45, 16 September 2015 (UTC)

The TOC top level probably won't provide what must be "remembered on the way through the hyperlink" to a whole 'nother environment. They'll expect the actual numbers and questions to pop up where they land. No one should notice or complain if the numbers were different, because it's just a TOC. Therefore, except for highly refined subtopics, say level ==== headings, having example material in the headings is unnecessary clutter where subject descriptions are readily available. Although 99% of users need quick examples and be gone, our most prized users will settle down here and read it all, looking for that structure I claim is missing. — CpiralCpiral 18:02, 16 September 2015 (UTC)

I don't understand. The reader looks in the TOC to find their detail of question (helped by a sharp example in there). Then clicking a TOC line brings the reader to the topic, with description, demos & more. -DePiep (talk) 15:11, 17 September 2015 (UTC)

Yes, to guide a seeking newcomer better where terminology in the heading is new, like Adjective, but it's not a style. It is apparently needed here in some cases, but for headings, shorter is better. Readers should know the terms "rounding" and "fraction", and "symbol" for example, if shorter headings were pursued. — CpiralCpiral 18:18, 18 September 2015 (UTC)

The MOS you link to is for content. Documentation may have other requirements. Also, using single word headers may be too short. Most doc topics have two or more elements (e.g., input and output, or 'multiple units' can be m,ft-in or km, mi, nmi). A word image (example) is very strong, and it skips the mental step having to read descriptions. -DePiep (talk) 19:24, 20 September 2015 (UTC)

Oops, my other example is gone for unclear reasons. The appearance is still here. -DePiep (talk) 15:25, 17 September 2015 (UTC)

Revert back but with tweaked prose and footnoting "how convert works", else someone will have to experiment to find out that 0.2 and 2 and 20 are magic. — CpiralCpiral 18:02, 16 September 2015 (UTC)

Precision

I agree with Wolfram and the this redirect that the term "precision" is synonymous with "significant figures", and that it might better be termed "accuracy" instead. But because "precision" may be "established", and because it seems to be advertised as a future parameter name, I thought it deserved a subsection.

Alternative terms to this colloquial and imprecise use of "precision" are "|trueness=" and "|scale=".

There are two attributes of numbers, the length and the scale. The length is the total number of significant decimal digits in a number and the scale is the total number of decimal digits after the decimal point. For example:

.000001 has a length of 6 and scale of 6.

1935.000 has a length of 7 and a scale of 3.

— The man page.

— CpiralCpiral 02:55, 17 September 2015 (UTC)

Is this correct for non-SI units too? -DePiep (talk) 20:12, 17 September 2015 (UTC)

I don't peruse the units literature. It was just a math thing. It's a good question, and I assume, a rhetorical one. — CpiralCpiral 22:00, 17 September 2015 (UTC)

Another alternative is to just write it out, and not make up a term for it, as I have done in an edit of Template:Convert#In temperatures: rounding °C, °F and K (Man, those section titles are scary.)

Lose precision. That edit shows the worst of Convert behavior. It does so on purpose. I think the behavior is wrong, and should rely only on significant digits, and just lose "precision" and any focus on decimal points, and the hidden side-effect. — CpiralCpiral 22:00, 17 September 2015 (UTC)

Alternatives to "precision" (because of the Wolfram complaint noted and linked-to above)

• radix=-1 or radix=0 or radix=2
• scale

— CpiralCpiral 17:35, 24 September 2015 (UTC)

Problem with hundredweight

I have a problem with the conversion of hundredweight. A hundredweight is 8 stone (110 lb) (WTF - 8 stone = 8 x 14 = 112 lb) but the template says 1 long hundredweight (110 lb; 51 kg). This is wrong. Can someone please fix this? Hawkeye7 (talk) 20:36, 8 September 2015 (UTC)

Oh I see. The problem is with the rounding. I need {{convert|8|st|lb|0}} (8 stone (112 lb) ) and {{convert|1|long cwt|0|lk=on}} (1 long hundredweight (112 lb; 51 kg)) Grrr. Hawkeye7 (talk) 20:41, 8 September 2015 (UTC)

Yes, I'm afraid rounding still trips me up occasionally. I don't think there is anything that can be done because the defaults works so well, mostly. Johnuniq (talk) 02:11, 9 September 2015 (UTC)

There exists dedicated conversion template {{long ton}} for this input:

100 long cwt (11,200 lb or 5,100 kg) → 100 long cwt (11,200 lb or 5,100 kg)

It mainly solves the four-number input option for long ton nicely. Maybe Jimp could consider adding stone. -DePiep (talk) 07:47, 9 September 2015 (UTC)

Thanks. I was not aware of this. Note however that it has the same problem with rounding: {{long ton||1}} → 1 long cwt (100 lb or 100 kg) Oops. I would need {{long ton||1||0}} → 1 long cwt 0 lb (112 lb or 51 kg) Hawkeye7 (talk) 21:02, 9 September 2015 (UTC)

Yes it has the same rounding issue ;-) In general, rounding is more stable & consistent in SI. {Convert} could have different rounding rules for non-SI units. And, as I said, {{long ton}} could cover stones & all of avoirdupois. But please remember where we came from, in this :-). -DePiep (talk) 21:15, 9 September 2015 (UTC)

The advantage of {{long ton}} is that it allows more than two sub units. I don't remember why I didn't include stones (perhaps I thought it might have been an overkill). Should they be added, do you think (how about ounces, drachms & grains)? Jimp 02:47, 10 September 2015 (UTC)

Yes, you should. Back in the day, you would not have said 1 cwt 16 lb; that would have been incorrect. You would have said 1 cwt 1 st 2 lb. This despite the fact that it would have been quite normal to say 16 lb or indeed 16 st. Baby boomers still measure their weight in stones, but us Gen X-ers grew up with metric. The rule anyway was that the highest could be used freely, but the rest follow in strict order. You don't have to say zero though; 1 cwt 0 st 2 lb would have been normal, but 1 cwt 2 lb would also have been acceptable. Hawkeye7 (talk) 06:37, 11 September 2015 (UTC)

For what it's worth, an old arithmetic book of mine (published 1899) didn't use stones but had exercises like (and I quote)

• "From 137 tons 12 cwt. 1 qr. 18 lbs. take 47 tons 12 cwt. 0 qrs. 24 lbs."

We made us own fun in them days! --Boson (talk) 15:27, 11 September 2015 (UTC)

PS: I see an older book on arithmetic has

... 16 ounces = 1 pound, 28 pounds = 1 quarter of a hundred weight, 4 quarters, or 112 pounds = 1 hundred weight, 20 hundreds = 1 ton." The stone, in the greater number of places, is 14 pounds, or one eighth of the standard hundred, but in different parts of England it is found to be of various magnitudes, from 8 to 16 pounds. In Ireland, also, in the sale of some articles, the stone of 16 pounds, or one seventh of the standard hundred is used.

— James Thomson LL.D., Professor of Mathematics in the University of Glasgow, A Treatise on Arithmetic, in theory and practice

That might explain not using stones. --Boson (talk) 15:57, 11 September 2015 (UTC)

• Another issue with these non-SI multiples is: how to represent 3+1⁄2 ft? Could be 3+1⁄2 ft and 42 in. -DePiep (talk) 21:19, 24 September 2015 (UTC)

Energy units for chemistry and physics

eV discussion

Is it possible to include a conversion from electronvolt (used in physics) to kilojoules per mole (used in chemistry)? We can convert from eV into kJ currently, which is 6.02 X 10²³ times too little. --John (talk) 11:31, 20 September 2015 (UTC)

I suppose we should have a kcal/mol option as well for the recalcitrant non-SI contingent. --John (talk) 11:41, 20 September 2015 (UTC)

It's traditional for me to ask for a couple of articles where the conversion would be helpful (see #Angle conversions and #Proposed new units above for why that is needed).

There are two "Energy per chemical amount" units: kcal/mol + kJ/mol. The reason they cannot be converted to eV is that the latter is just "Energy". Would any energy units other than eV be wanted for similar conversions? I guess the simplest would be to make a new unit which means eV as used in this case—it would also be an "Energy per chemical amount" unit.

I don't really have to understand the use case, but is there a brief explanation of how energy (eV) can be converted to energy/amount (kJ/mol)? I guess the new unit is some kind of energy per molecule?

What is needed is the unit code of the new unit (the text used in a convert), and the symbol to be displayed, and the name to be displayed if abbreviations are off, and the article for a link, if links are on. I guess the conversion factor is like eV to kJ, but also multiply by the Avogadro constant? Johnuniq (talk) 12:35, 20 September 2015 (UTC)

It's an issue at flerovium and I am confident (without actually having checked) that there will be other articles on exotic elements that kludge the units like this. Electronvolts is per particle, and chemistry typically talks about per mole, so yes, the Avogadro constant is the conversion factor here. --John (talk) 13:35, 20 September 2015 (UTC)

If the statement John made for flerovium [2] is sound, it may be used in most chemical & element articles, possibly by infobox too. -DePiep (talk) 23:42, 20 September 2015 (UTC)

Traditionally convert has only converted between different units for the same quantity. This would be a "conversion" of a different nature, between different kinds of units. It's similar to trying to convert mass to density. I would hope that people writing or reading about energy per mole would be proficient at conversions, and not need a template. If there is to be a template, I suggest a different template. Otherwise we will be going down a slippery slope, and people will be asking the convert template to convert between the American Democratic Party and the corresponding party in Australia. Jc3s5h (talk) 17:09, 20 September 2015 (UTC)

(ec) I'm a physicist, not a chemist (and thus don't know chemistry conventions), but electronvolt is just an energy unit. eV/particle is per particle (and can thus be converted to kJ/mole), but eV can't be converted to kJ/mole. Of course, "particle" is dimensionless, so eV/particle is in some sense equal to eV, but to me, dropping the "per particle" and converting straight to kJ/mole would be very confusing notation. In any use of eV outside of energy levels in a particle, converting eV to kJ/mole would be wrong. So it seems to me that adding eV/particle and kJ/mole (and, why not, eV/mole and kJ/particle) to convert would be a better approach. —Alex (Ashill | talk | contribs) 17:17, 20 September 2015 (UTC)

I've thought about this quite a lot. Both "per particle" and "per mole" are dimensionless, because a mole is a number unit like a dozen or a million. Physicists generally use the energy unit eV without specifying "per particle", whereas chemists are usually more punctilious about saying "per mole". So these are indeed different units for the same quantity, @Jc3s5h:, and not like your example of political parties from different countries, even though that might not be apparent at first glance. Blame lazy scientists who write "eV" when they mean "eV per particle". If this is a one-off thing, of course there is no problem, but I suspect it is fairly prevalent. I will look some more and think some more. --John (talk) 19:32, 20 September 2015 (UTC)

The more I think about it, the more I think that @Ashill:'s suggestion is the right one; I just worry that if the conversion {{convert|x|eV/particle|kJ/mol}} defaults to display x electron volts per particle (y kJ/mol), it might look rather odd in articles where a particular type of particle is being discussed, say a nucleus. As I say, I don't often recall the "per particle" being stated as I guess physicists take it as read in a way that chemists don't. Any thoughts? --John (talk) 23:25, 20 September 2015 (UTC)

We could define "/particle" and "/mole" be included and be omitted. Of course, then it is up to the page editor to pick a style. Infoboxes might need a standard. -DePiep (talk) 23:36, 20 September 2015 (UTC)

... but I missed the common but imperfect desire to write "x eV (y kJ/mol)". Worth discussing at WT:CHEMISTRY and WP:PHYSICS? (meanwhile preliminary options could be added). -DePiep (talk) 08:42, 21 September 2015 (UTC)

• Opposed Reading through Flerovium, the instances where eV is used are accurate, as are the instances where kJ/mol are used. It makes no sense to talk about decay energy in anything except eV, and likewise decomposition in anything other than kJ/mol. Each unit has a specific usage, and unless it's being used incorrectly there is no reason to state them otherwise. It would be like converting a cup of flour in a recipe into mL; both units are used in cooking but only one makes sense to measure flour. Primefac (talk) 22:37, 21 September 2015 (UTC)

In physical chemistry it is very common to go back and forth between eV and kcal/mol, see for example this or any other similar google search. --Steve (talk) 23:00, 21 September 2015 (UTC)

Absolutely. It was seeing ionization energy given in eV that raised my eyebrows; while I can see why it makes sense if you are only dealing with one or two nuclei these are nearly always given in kJ/mol and it makes sense to be able to compare them with other elements. --John (talk) 06:02, 22 September 2015 (UTC)

• Support kcal/mol, kJ/mol as straightforward energy quantities, convertible to any other type of energy (though in practice eV is most common). For example: "The molecule's ionization energy is 2eV (46 kcal/mol)". I just don't see how there's any problem or risk of confusion here. The "2eV" is obviously and unambiguously "2eV per molecule".

You almost never hear anyone refer to just energy, it's usually the energy of something (a molecule, a photon, a sandwich, whatever). If someone tells me that "the energy in this sandwich is 2 MJ", I would not respond "You have the units wrong, you should have said "the energy in this sandwich is 2 MJ per sandwich!" No, it is perfectly appropriate to treat "per sandwich" as implicit in the sentence and context, rather than part of the physical unit. Likewise, I think it is perfectly appropriate to treat "per particle" or "per molecule" or whatever as implicit in the sentence and context, rather than part of the physical unit. :-D --Steve (talk) 23:00, 21 September 2015 (UTC)

eV details

The suggestion to Google for "eV 4 kcal/mol" above makes a convincing case so I have put an experiment in Module:Convert/extra. That is a temporary area where units can be tried; if they are not used after a month or so they can be removed. I had to make a new unit that is compatible with kcal/mol and kJ/mol. The unit code is what is used in the convert template, and I picked eVpar to suggest electronvolts/particle. That is easily changed if wanted. Convert is not configured for scientific usage because most science articles use standard units and don't need conversions. At any rate, the new unit defaults to showing the unit name, and abbr=on is needed to make it show the symbol that is probably wanted. I made it accept metric prefixes—is that wanted? Please study the following examples and identify any problems:

• {{convert|1|eV|J|sigfig=15|abbr=on}} → 1 eV (1.6021764870000×10⁻¹⁹ J)
• {{convert|1|eV|kcal|sigfig=15|abbr=on}} → 1 eV (3.8292937069790×10⁻²³ kcal)
• {{convert|1|eVpar|sigfig=15}} → 1 electronvolt (23.060547208925 kcal/mol)
• {{convert|2|eVpar}} → 2 electronvolts (46 kcal/mol)
• {{convert|2|eVpar|abbr=on}} → 2 eV (46 kcal/mol)
• {{convert|2|eVpar|abbr=off}} → 2 electronvolts (46 kilocalories per mole)
• {{convert|2|eVpar|abbr=on|lk=on}} → 2 eV (46 kcal/mol)
• {{convert|2|eVpar|abbr=off|lk=on}} → 2 electronvolts (46 kilocalories per mole)
• {{convert|2|eVpar|kJ/mol|abbr=on}} → 2 eV (190 kJ/mol)
• {{convert|2e6|ueVpar|abbr=on}} → 2×10⁶ μeV (46 kcal/mol)
• {{convert|2|keVpar|abbr=on}} → 2 keV (46,000 kcal/mol)
• {{convert|2|MeVpar|e6kcal/mol|abbr=on}} → 2 MeV (46×10^⁶ kcal/mol)

The first two examples show the existing eV unit, and the rest are the new eVpar. The sigfig=15 examples are to show all the digits used in the calculation—I know that is not a plausible setting. The last example shows that what we call engineering notation can be used ("e6" as a prefix for kcal/mol). However, it's not true scientific notation.

Looking at this unit shows a problem. The current eV unit is defined so that 1 eV = 1.602176487e-19 J. But that value seems to be wrong? Where would it have come from? Has some unit definition changed? Electronvolt says 1 eV = 1.602176565e-19 J and Avogadro constant says there are 6.022140857e23 particles/mol. Multiplying the last two values gives 96485.329522144162 (yes, it's more sigfig than justified but computers have to be told something), and that is the scale I used for eVpar. Johnuniq (talk) 04:00, 22 September 2015 (UTC)

@GliderMaven: Any thoughts on the above? Why does convert (and lots of websites) use 1.602176487, but Electronvolt use 1.602176565 as the sigfigs for eV? Johnuniq (talk) 04:07, 22 September 2015 (UTC)

I've looked into it a bit, and looks completely fine. It's just a unit of energy. It's actually energy per unit charge, which dimensionally, which is all convert cares about, is just energy. I'm not sure why there would be minor differences in the value, perhaps somebody vandalised wikipedia or somebody redid a measurement in a standards body and it has officially changed, I'll look into it slightly more. But it's unlikely to make any practical difference, given the way convert rounds.GliderMaven (talk) 14:36, 22 September 2015 (UTC)

@Johnuniq: The Wikipedia "Electronvolt" article states the value, and refers to the Elementary charge article. The "Elementary charge" article does not contain the value directly, but obtains it from {{Physconst}}. The documentation for the Physconst template claims values are obtained from CODATA 2010 recommended values, which do not seem to agree with the value currently listed at the NIST website, which are 2014 CODATA recommended values. Jc3s5h (talk) 15:34, 22 September 2015 (UTC)

electronvolt says 1 eV = 1.602176565(35)e-19 C in the lede, uncited. this source, which claims to be based on CODATA 2006 (which is cited but only for the name, not the value) says 1.602176487(40)e-19 C, which is the number the convert template uses. Those values differ by about 2 sigma, so not a huge issue (and consistent with an updated measurement). For the convert template, I wouldn't worry about a disagreement at that level; for purposes where that many significant figures matter, editors should be checking numbers explicitly anyway. —Alex (Ashill | talk | contribs) 16:34, 22 September 2015 (UTC)

As a minor note, the {{physconst}} value for eV has been updated to the 2014 numbers, and I'll update the rest of the numbers in the near future. Thanks for bringing it up Jc3s5h. Primefac (talk) 21:24, 22 September 2015 (UTC)

• I object to the construct name eVpar. At least it should be

eVperpar or eV/par. The wp editor who actually uses this shortcut, should know this. -DePiep (talk) 22:29, 24 September 2015 (UTC)

• Thank you, Johnuniq, that seems to work and I have added it to Flerovium. One quibble: I think the default conversion should be to kJ/mol rather than kcal/mol, as per WP:UNIT. --John (talk) 01:04, 26 September 2015 (UTC)
  • @John: OK, that's done. What do you think about the unit code? The examples above use "eVpar". Should that be eV/par or something else? Johnuniq (talk) 03:22, 26 September 2015 (UTC)
    • I think eVpar is fine. It looks good. Thanks for your quick and diligent work on this. --John (talk) 00:35, 27 September 2015 (UTC)

Protected edit request on 25 September 2015

Please update the U.S. survey mile (smi) to its correct value of 6336000/3937 meters (m) and update all documentation. Please see the discussion above.  Buaidh  21:41, 25 September 2015 (UTC)

Please do not pad out this page unnecessarily. Things here are done slowly and by agreement. Before considering a proposal for a new unit, it is necessary to examine how it would be used. Please provide links to at least two articles and indicate which text would benefit from a conversion. If the examples show a trend—in other words, if it is likely the unit would be needed elsewhere—we can discuss the details of adding it, such as the unit code to identify the unit. Johnuniq (talk) 23:16, 25 September 2015 (UTC)

This is merely a request for the correction of an existing unit. Yours aye,  Buaidh  16:40, 26 September 2015 (UTC)

Not done: it's not clear what changes you want to be made. Please mention the specific changes in a "change X to Y" format. The data presents as follows:

    ["smi"] = {
	name1    = "statute mile",
	symbol   = "mi",
	utype    = "length",
	scale    = 1609.344,
	default  = "km",
	subdivs  = { ["chain"] = { 80, default = "km" } },

The abbreviation "smi" appears to refer to "statute mile", not to US "survey mile". Please be more explicit in your request. Painius  06:51, 27 September 2015 (UTC)

• Requests to change units need examination and consensus. The discussions earlier on this page show there is no consensus for a change. I referred to "new unit" above because changing the definition of smi effectively changes it to a new unit since there is no evidence that the current definition is wrong. I do not recall any units needing a fundamental correction like this. An explanation of "statute mile" as defined in convert is here. See mile#name for information about the UK/US difference. Johnuniq (talk) 07:31, 27 September 2015 (UTC)

• I believe there is clear evidence that "statute mile" can either be 1609.347219 m (accurate to 10 significant figures) or 1609.344 m exactly, depending on which definition one prefers, the definition used by the National Institute of Standards and Technology or the definition used by the rest of the world. In view of the conflicting definitions, I suggest the unit should be eliminated entirely. Jc3s5h (talk) 13:19, 27 September 2015 (UTC)

I believe we should either correct this unit or eliminate it. If U.S. survey foot is not included, there is no need for U.S. survey mile. Yours aye,  Buaidh  18:39, 27 September 2015 (UTC)

I forget if I asked for examples for survey foot/mile; I have done that for several other recently proposed new units. At any rate, let's start again. Please link to sections on at least two articles where a change to how convert operates would be useful. What would convert do differently that would affect the articles? I agree that "statute mile" is a poorly defined term in an encyclopedia with worldwide scope, but smi is used in many articles; we would need to investigate what they do before thinking about a change to smi. Johnuniq (talk) 01:55, 28 September 2015 (UTC)

U.S. survey foot and mile

I believe the U.S. statute foot (1200/3937 meter) and the U.S. statute mile (6336/3937 kilometers) should be added to the units of length. The United States National Geodetic Survey and United States Geologic Survey use these units for legal purposes. While the difference between these units and the International foot and the International mile is only 0.0002%, there inclusion would help to clarify the source of U.S. measurements. Yours aye,  Buaidh  20:16, 23 September 2015 (UTC)

I think it would be rare for lengths to be shown to sufficient precision for it to make any difference whether the conversion factors for the international or survey versions of these units were used. In those rare cases, I think the difference would have to be explained in the text; using a template would not be sufficient. I don't see the need for the convert template to cover every conceivable rare situation. Jc3s5h (talk) 20:59, 23 September 2015 (UTC)

I agree with Jc3s5h: it is not likely that a template can help with the confusion surrounding the different versions of mile that once were in use, or which are used now. The difference is too subtle for a mere conversion—if there were a difference, the article text would have to add a suitable explanation. However, convert has grown over the years and units smi (statute mile) and rtmi (route mile) are defined, although each has exactly the same scale as mi (a plain mile), namely 1 mi = 1 smi = 1 rtmi = 1609.344 m. I guess that is a UK definition. A US statute mile is approximately 1609.347218694 m. There is no statute foot in convert, and we would need to see examples in two or three articles of where convert would be useful before a new unit is defined. Johnuniq (talk) 02:35, 24 September 2015 (UTC)

In the US, the National Institute of Standards and Technology uses (on page C-2) the term "statute mile" to describe a mile consisting of 5280 US survey feet. Other sources disagree; for example the American Practical Navigator modifies "mile" with either "statute" or "nautical" and does not make any distinction between US survey and international miles. So the term "statute mile" does not have a precise definition. The term "statute foot" does not exist. Also, since the US survey foot is only used in surveying and related fields, clearly commonly used derived units used in surveying also exist. I believe the US survey square foot, rod and acre exist. Since surveyors do not use then, I doubt the existence of a US survey inch, yard, mile, square inch, square yard, or square mile. Jc3s5h (talk) 12:36, 24 September 2015 (UTC)

Some confusion arose when the USGS announced on September 2, 2015, that the new elevation measurement for the summit of Denali was 20310 U.S. statute feet.  Buaidh  14:16, 24 September 2015 (UTC)

I do not accept Buaidh's assertion. The word "statute" is not present in our "Denali" article nor is it present in the USGS press release which the Wikipedia article cites to support the elevation claim. Jc3s5h (talk) 14:29, 24 September 2015 (UTC)

Sorry I used the term U.S. statute foot in lieu of the more modern U.S. survey foot. They are identical in value. I am old.

Please see my private e-mail conversation with Dr. Childers of the NGS quoted at Talk:Denali#Precise metric elevation. All NGS and USGS elevations and distances are now calculated first in meters and kilometers and then converted to U.S. survey feet and U.S. survey miles. I am asking that the definition of the U.S. survey mile (smi) be updated to equal 6336/3937 kilometers and that a U.S. survey foot (sft) be added equal to 1200/3937 meter. Yours aye,  Buaidh  16:28, 24 September 2015 (UTC)

I object to the terms "statute foot"; I do not believe there is any such thing. I do not believe any well-edited reliable source has ever used the term. Also, one could infer that a U.S. survey mile must be 5280 U.S. survey feet, but surveyors don't use any kind of miles for precise work (sure, they might use them when giving road directions to a geodetic mark, e.g. "Drive 2.3 miles from the post office in East Bumpkin to the mark on the left" but not for precise stuff) so I'm not convinced the U.S. survey mile exists either. Jc3s5h (talk) 16:55, 24 September 2015 (UTC)

I question the need to support the US survey foot. I object to the presence of smi as a supported symbol. It is currently described as "statute mile". Because of conflicting uses in various parts of the world, and even by different agencies of the US government, I consider the term "statute mile" to be hopelessly ambiguous and the use of the term should be strongly discouraged in Wikipedia, starting by deleting it from this template. Jc3s5h (talk) 17:07, 24 September 2015 (UTC)

Please see the Measurement, Instrumentation, and Sensors Handbook for one. Yours aye,  Buaidh  17:04, 24 September 2015 (UTC)

Since the NGS and USGS use meters, kilometers, U.S. survey feet, and U.S. survey miles exclusively, I think all four of these units bear inclusion. Yours aye,  Buaidh  17:15, 24 September 2015 (UTC)

NGS and USGS, as far as I know, do not use U.S. survey miles at all, or at least, they use miles for imprecise measurements where you can't tell which kind of mile they are using. I don't know the USGS policy on what kind of feet they use, but the NGS provides data converted from meters into either US survey feet or international feet, depending on which kind of foot an individual state requests (or they just provide meters if a state makes no request). See their FAQ, search on "What & Why". Jc3s5h (talk) 18:11, 24 September 2015 (UTC)

Your reference above states:

For most of the years surveying has been undertaken in the United States, surveyors have used the U.S. Survey Foot.

and

The only other instance where NGS publishes linear values in feet is for elevations, i.e., orthometric heights. All computations are still done in meters, but for publication purposes we convert meters to feet. That conversion is done using the U.S. Survey Foot conversion factor. We publish elevations in meters to the nearest millimeter (3 decimal places) and in feet to hundredths of a foot (2 decimal places). For elevations above 5,000 feet (1,524 meters), the conversion factor will change the foot value by one in the second place.

Please see the NGS Pikes Peak Datasheet for an example.

Most published USGS topographic maps show elevations in U.S. Survey Feet based on the National Geodetic Vertical Datum of 1929 (NGVD 29). To convert these elevations to SI meters based on the North American Vertical Datum of 1988 (NAVD 88), you must first multiply by 1200/3937 to convert to meters based on NGVD 29 and then add the NGVD 29 to NAVD 88 conversion factor from VERTCON. This conversion may alter elevations by as much as 2.4 meters. For example, the USGS topographic map for Pikes Peak indicates an elevation of 14,110 U.S. Survey Feet based on NGVD 29, 1.57 meters less than the NAVD 88 value. We typically input U.S. NAVD 88 elevations in meters to the nearest millimeter to reduce rounding errors. See Template:Epi and the List of mountain peaks of North America for examples.

While millimeter accuracy is not required for elevation display values, its use reduces rounding errors. This recently became an issue when the USGS issued a report stating that the elevation of Denali was 20,310 feet. The report did not indicate whether this value was in U.S. survey feet or International feet. An elevation of 20,310 U.S. survey feet rounds to 6191 meters, while 20,310 International feet rounds to 6190 meters. I asked Dr. Childers of the NGS for more information and she replied that the actual elevation measurement was 6190.5 meters, so we increased the Denali elevation display accuracy to 0.1 meters and 0.1 feet.

While the U.S. Survey Foot and U.S. Survey Mile are interesting from a historical perspective, we avoid publishing any values in these units and instead display International feet and International miles. Our primary use of the U.S. Survey Foot is for converting published U.S. elevations in U.S. Survey Feet to meters and International feet based on NAVD 88. We need to be able to explain to users (and elevation editors) why the Wikipedia elevations usually do not match the published USGS elevations. Thanks for your input. Yours aye,  Buaidh  21:39, 24 September 2015 (UTC)

Protected edit request on 25 September 2015

Please change the value of the U.S. survey foot (sft) to 1200/3937 meter (m) and update documentation. This is the correct value. Please see the discussion above.

 Buaidh  20:08, 25 September 2015 (UTC)

Please add the U.S. survey foot (sft) (1200/3937 meter) to the length units and update all documentation. Please see the discussion above.  Buaidh  21:36, 25 September 2015 (UTC)

Oppose. There is no unit code sft, and there is no support for the US survey foot. Thus it is incorrect to describe this as changing a conversion factor to the correct value. Discussion above indicates considerable opposition to supporting the US survey foot. Jc3s5h (talk) 20:41, 25 September 2015 (UTC)

All elevations in the United States are expressed in U.S. survey feet. The 2 ppm difference between the U.S. survey foot and the International foot makes no appreciable difference in the foot values displayed on Wikipedia. The difference does sometimes make a difference in how elevations are rounded to meters. The inclusion of the U.S. survey foot may eliminate confusion.  Buaidh  21:22, 26 September 2015 (UTC)

Not done: please establish a consensus for this alteration before using the {{edit template-protected}} template. Painius  06:32, 27 September 2015 (UTC)

No problem. WikiProject Mountains will just stop using Template:Convert for U.S. elevations. Yours aye,  Buaidh  18:43, 27 September 2015 (UTC)

I see no reason for WikiProject Mountains to abandon the template. Most precise elevations stated by a reliable source in US survey feet would come from the National Geodetic Survey. Ordinarily they provide meters as their primary unit, with US survey feet as a convenience for some readers. So using Mount Elbert as an example, rather than using {{convert|14440|ft|m|0|adj=on}} (which renders as 14,440-foot (4,401 m)), use {{convert|4401.2|m|ft|0|adj=on|order=flip}} which renders as 14,440-foot (4,401.2 m). Jc3s5h (talk) 15:22, 28 September 2015 (UTC)

That is what we do for U.S. summits that have an NGS datasheet. However, most U.S. summits do not have an NGS datasheet. The elevation for these summits must be converted from U.S. survey feet to meters and then from NGVD 29 to NAVD 88. We currently do this manually. Yours aye,  Buaidh  16:02, 28 September 2015 (UTC)

If you have to convert from NGVD 29 to NAVD 88, that for sure isn't going into the convert template, so I still see no need for the convert template to support US survey feet. Jc3s5h (talk) 16:45, 28 September 2015 (UTC)