Template talk:Convert/Archive November 2017

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Expression of ratios of compound units

I see that this template appears to accept ratios of compound units, which is ambiguous and does not encourage editors to adhere to the general principles on presentation suggested by SI, and which we appear to use more generally, namely that we should disambiguate by using have brackets around any compound unit after a division sign, e.g. W/(K/s) or kg/(kW⋅h). The specific examples occur in the last table of Brake_specific_fuel_consumption#Examples_of_values_of_BSFC_for_shaft_engines, e.g. 0.22 kilograms per horsepower-hour (300 g/(kW⋅h)). —Quondum 12:04, 30 October 2017 (UTC)

Maybe it's just me, but these don't seem ambiguous. If I meant to say kg⋅h/kW I would write it that way. Kendall-K1 (talk) 13:29, 30 October 2017 (UTC)
EH? There's no way that they symbol for kilograms per horsepower-hour is g/kW-h. The SI hit squad might let you get away with missing off the "k", but not horsepower = kW ! Martin of Sheffield (talk) 13:51, 30 October 2017 (UTC)
C'mon, folks, let's stay with the program. Martin, to make my example above of an invocation of {{convert}} more explicit: {{convert|0.22|kg/hp.h|g/kW.h}} → 0.22 kilograms per horsepower-hour (300 g/(kW⋅h)). Kendall, if you can't be bothered with international standards, how about the MoS? "Indicate a ratio of unit symbols with a forward slash (/), followed by either a single symbol or a parenthesized product of symbols – do not use multiple slashes." I re-iterate my point: {{convert}} should at least provide a warning that the form of the units does not adhere to WP standards if it does not flat-out refuse to assign an interpretation to such units. Are there people who actually maintain this template out there who might be interested? —Quondum 01:41, 31 October 2017 (UTC)
I'm not arguing against the MOS. You're the one who brought up the ambiguity argument. Kendall-K1 (talk) 02:00, 31 October 2017 (UTC)
To avoid side-tracking from the main point, I've removed any argument about ambiguity from my original statement. —Quondum 02:29, 31 October 2017 (UTC)
I take the point but the way convert handles automatic per units is very general and very complex, and I don't think the problem is worth fixing for all possible cases. If specific units are used sufficiently often, those units could be defined with whatever symbol/name was wanted. However, the case in question would possibly be better handled by changing the second table to use the technique of the first. The second table currently uses converts in the SFC column like this:
{{convert|value|g/kW.h|lb/hp.h|3|abbr=on}}
That means the single column repeats the input and output units for each row.
Instead, there should be two columns that show only numbers:
{{convert|value|g/kW.h|lb/hp.h|3|disp=table}}
The heading row would then show the units once, and the editor would specify how the units appear. An example at Help:Convert#Sortable table shows the recommended procedure. Johnuniq (talk) 04:28, 31 October 2017 (UTC)
Thanks. Your point is fair: trying to impose a possible MoS constraint on detail of presentation through a template is probably not sensible; editors should be handling each case. Nevertheless, your answer implies that {{convert}} applies a specific interpretation (i.e. it does have a rule for parsing), which could be that in the absence of parentheses, '/' has lower precedence that '.' as an operator, but that each of these associate left-to-right (which is only significant for '/'). A mention of the parsing of compound units by the template seems appropriate on this template's documentation page. —Quondum 12:54, 1 November 2017 (UTC)

Mach

On Template:Convert/list of units/speed, can multiples of the speed of sound be used? I tried. 340.3 metres per second ([convert: unknown unit]) Didn't work. How about percentages of the speed of light? If not, can they be entered into the template? Thank you for your time. 50.64.119.38 (talk) 02:33, 12 November 2017 (UTC)

Mach is supported, but it has to be uppercase: Mach.
Mach can be used as an input unit or an output unit. For an input, the unit can be followed by a number which is the altitude in feet at which the speed applies. The speed of sound varies depending on conditions related to altitude, and convert uses a table from http://www.aerospaceweb.org/question/atmosphere/q0112.shtml to estimate the result. Convert does not display the altitude—if that is wanted, it has to be done outside the template. Examples:
  • {{convert|340.3|m/s|Mach}} → 340.3 metres per second (Mach 1.0)
  • {{convert|340.3|m/s|Mach|lk=out}} → 340.3 metres per second (Mach 1.0)
  • {{convert|2.7|Mach|m/s}} → Mach 2.7 (919 m/s)
  • {{convert|2.7|Mach|m/s|round=5}} → Mach 2.7 (920 m/s)
  • {{convert|2.7|Mach|234500|m/s|round=5}} → Mach 2.7 (795 m/s)
Johnuniq (talk) 03:02, 12 November 2017 (UTC)

5 feet 11/6 feet

Noticed this while looking over some baseball articles, and I see this template displays 5ft 11in and 6ft as the same amount of centimeters:

5 feet 11 inches (1.80 m)
6 feet (1.8 m)

Any fix that doesn't involve writing 183 manually? Trout me if I'm way late to the party, but my (admittedly poor) searching skills didn't come up with any discussions. Nohomersryan (talk) 19:15, 12 November 2017 (UTC)

This is within the defined rounding behaviour, as per the template documentation. Try, for example,
{{convert|6|ft|sigfig=3}} → 6 feet (1.83 m)
{{convert|6|ft|0|in}} → 6 feet 0 inches (1.83 m)
{{convert|6.00|ft}} → 6.00 feet (1.83 m)
—Quondum 19:31, 12 November 2017 (UTC)
That clears it up. Thanks! Nohomersryan (talk) 22:00, 12 November 2017 (UTC)

Errors for numbers with decimals

Hi, I just imported this template and module over to Wikiversity. However it misformats any numbers with decimal places. For example: {{convert|0.5|mg|abbr=off}} misformatted as "0.5 milligrams (Template:Hid0.0077 grains), in stead of the correct output: 0.5 milligrams (0.0077 grains). See example in v:Radiocarbon_dating. Any ideas which part is going wrong? T.Shafee(Evo&Evo)talk 04:03, 15 November 2017 (UTC)

Something went wrong with your version of Template:Convert. Check the wikitext. Johnuniq (talk) 04:13, 15 November 2017 (UTC)
I was going to fix v:Template:Convert but a required module is missing, having been previously deleted, and that's more drama than I have time for now. Please see Template:Convert/Transwiki guide for what is needed. Johnuniq (talk) 06:01, 15 November 2017 (UTC)

Scientific notation?

In the template doc, "Range separators in {{convert}}" table, "notes" column, what does "Scientific notation" mean? Kendall-K1 (talk) 22:33, 13 November 2017 (UTC)

'Scientific' refers to using the × symbol and repeated unit symbol; otherwise use 'by', and unit once. See WP:UNITSYMBOLS. -DePiep (talk) 23:51, 13 November 2017 (UTC)
I always thought scientific notation meant multiplying by a power of ten, for example with Template:E. Is it just anything that involves multiplication? Kendall-K1 (talk) 04:56, 14 November 2017 (UTC)
Of course, that is the scientific notation of numbers. Here, it is mentioned in a different sense.
In notation of an area, we can keep both length and width values. Per MOS:UNITSYMBOLS (see down in that section, right above the overview table):
  • BY-form: 2 by 5 m -- unit once, common spoken language
  • X-form: 2 m × 5 m -- unit symbol repeated
  • not MOS: 2 × 5 metre -- using "×", while unit is not repeated (corrected, better demo this way)
  • not MOS: 2 × 5 m, (2 × 5) m, 2 × 5 m2
Note that the BY-form has the unit mentioned once, the X-form repeats it.
Rule: when "×" is used, a unit symbol is repeated.
This is labeled 'scientific' in the documentation, because formal and correct physical quantity notation requires that the dimension of the unit(s) is maintained. An area has dimension metre × metre (or m2). Even more formally: Length × Length (L2). This is an algebraic notation, and allows us to do maths with the value (like: calculating some kg/m2 value when sowing seeds). It is not a sentence, while the "... by ..." is common in speech and non-scientific writing (also in this wiki).
Maybe the doc could have better wording in this: "correct quantity", "formal measurement notation", ...
As applied in convert
Convert applies this MOS. Actually, twice in a regular form: once for the input, once for the output (the bracketed value). Options:
  • {{convert|3|by|6|m}} → 3 by 6 metres (9.8 by 19.7 ft) -- BY-form both, formal in sc... corrected
  • {{convert|3|x|6|m|abbr=on}} → 3 m × 6 m (9.8 ft × 19.7 ft) -- X-form both (abbr enforced); formal in science and measurement handling
  • {{convert|3|x|6|m}} → 3 by 6 metres (9.8 ft × 19.7 ft) -- X-form (abbr is default for second value only, so X-form only there).
Note 1: Exception: when unit is in ft,in {{Convert}} repeats for clarity:
{{convert|2|by|5|m}} → 2 by 5 metres (6 ft 7 in by 16 ft 5 in) -- BY-form, exception
Note 2: the non-MOS form 2 × 5 m2 is correct in formal scientific writing (most common even), but not per our MOS.
Note 3: The parameter |2=by/x is usually labeled "range" in the {{Convert}} /doc, because is has same position and similar job.
HTH. -DePiep (talk) 12:00, 14 November 2017 (UTC)
Corrected & clarified examples. I'm sorry for the confusion. -DePiep (talk) 19:56, 15 November 2017 (UTC)

Round down?

Can conversions be rounded down? For example, motorway speed limits in the UK are 70 mph, which is given by the authorities as 112 km/h (presumably because 113 km/h is faster than 70 mph and thus illegal) - but {{convert|70|mph|0}} gives 70 miles per hour (113 km/h). -- DeFacto (talk). 22:13, 13 November 2017 (UTC)

The more situations {{convert}} covers, the more complex the instructions become, and the harder it is for new users to use it for even the most trivial cases. There is a tradeoff between making the template more complex, vs. keeping it simpler and handling the oddball cases with manual conversions. Jc3s5h (talk) 22:19, 13 November 2017 (UTC)
Maybe, but I wondered if that option was already available and I can't find how to do it. -- DeFacto (talk). 22:26, 13 November 2017 (UTC)
No, convert can't round down, and I agree with Jc3s5h. To spell out the problem, 70 mph is 112.65 km/h which could be rounded to 113 with |0 or 110 with |round=10 or 115 with |round=5. A kludge with #expr would work but probably just use fixed wikitext (no convert) with a comment that 112 is the published value. Johnuniq (talk) 22:29, 13 November 2017 (UTC)
Okay, and thanks for the full (if disappointing) explanation. -- DeFacto (talk). 22:51, 13 November 2017 (UTC)
Maybe not useful, but {{convert|112|km/h|order=flip}} → 70 miles per hour (112 km/h) produces the desired display in this particular case. —Quondum 23:51, 13 November 2017 (UTC)
Brilliant! Johnuniq (talk) 05:10, 14 November 2017 (UTC)
A good workaround for the specific case, thanks. -- DeFacto (talk). 07:15, 14 November 2017 (UTC)
OK, but now it is the other way around. Why not write 112 kilometres per hour (69.6 mph)? -DePiep (talk) 12:21, 14 November 2017 (UTC)
  • I note two more general {{Convert}} aspects.
  1. Do not require pre-calculation. When the source says "70 mph", and the correct entering form is {{convert|112|km|...}} (to get this output right), that would require a pre-calculation by the wiki editor. That is undesired, because that is difficult to get right and so might introduce an error by itself between source and wiki input. (However, in this case it looks like the source says "112 km/h", so this example is dead, the case is alive.)
  2. A definition, not a measurement. I understand the value is given by the authorities as 112 km/h. This being a law, the value is a definition not a measurement. So uncertainty rules do not apply (these are possibly specified elsewhere, e.g. in a bylaw or in practice). Of course, we must write that definition exactly. But what with the converted value (in mph)? Does the law says anything about that? And how is this wiki ({{Convert}} output) to be read, really as setting a law (and having responsibility for doing so)? Or can we claim rounding & presentation margin? -DePiep (talk) 12:21, 14 November 2017 (UTC)
@DePiep: just to be clear, my specific requirement was to use {{convert}} to convert the UK speed limit of 70 mph (which is defined in mph (not km/h) in law) to 112 km/h to match the conversion used by the authorities when also stating the limit in km/h (as guidance for foreigners, or whatever). The more general case is to be able to round down (or up I suppose) any conversion for similar uses where a rounded result mathematically bigger (or smaller) than the original is not acceptable. -- DeFacto (talk). 15:43, 14 November 2017 (UTC)
Yes I get that from the original post. New is that both numbers are defined: 70 and 112 (unlike what the OP said).
So the govt defines the "70 mph" in the law, and authorities define the "112 km/h" value. So it is not a calculation process, it's a formatting process only (present the two given values). {{Convert}} is a calculation tool, not a presentation (formatting) tool. If no calculation is needed, {{Convert}} can be skipped (note that to add the round-down calculation option, the editor is re-doing what the source says. It's our job to use source info, not synthesise or project its intentions, nor redo the experiment. In general: when it is defined in the source, don't touch it. -DePiep (talk) 07:11, 15 November 2017 (UTC)
I tend to agree for the specific example given, and if using a reference which gives both values, but that leaves the general case where a conversion with such rounding might be required. -- DeFacto (talk). 18:01, 15 November 2017 (UTC)
Yes. (I might keep both "do not require pre-calculation" and "don't recalculate a defined value" for future cases her ;-) ). -DePiep (talk) 19:47, 15 November 2017 (UTC)
I fully see what DeFacto is suggesting, and agree that having flexibility is in general a nice idea (just like it is nice to have a computer language that is Turing-complete). I think that here Jc3s5h's comment is relevant: there are trade-offs in including this flexibility, of which one must be aware. Utilization of such a feature, despite being of a general-purpose nature, would likely be low; hence it might not make sense to add it. —Quondum 03:21, 16 November 2017 (UTC)

Dots

Recent discussions made me wonder how dots are used in convert. The dots in question are:

  • U+00B7 · middle dot = · = · = interword separation
  • U+22C5 ⋅ dot operator = ⋅ = ⋅ = multiplication dot

Convert has lots of symbols and a small number of names that use middot, but none with sdot. Examples follow.

code symbol type
km/hs km/(h·s) acceleration
A.h A·h charge
ftlb ft·lb energy
GW.h GW·h energy
hph hp·h energy
kW.h kW·h energy
m3atm m3·atm energy
si tsfc g/(kN·s) speed
lb.ft lb·ft torque
Nm N·m torque

I have got totally confused. The dots in the table above use middot. Should they be sdot!? Johnuniq (talk) 09:41, 31 October 2017 (UTC)

Here are some things that might contribute to considering this:
  • The Unicode description favours sdot (U+22C5) where multiplication semantics apply.
  • The sdot is already extensively used (in science and maths articles and templates, including {{val}}), so it seems that it must be adequately supported on browsers.
  • There might nevertheless be rare contexts where the sdot is not supported or correctly substituted. I believe it has been defined since an early version of Unicode, but not the earliest. Particularly, copy-and-paste of template output from an article to some other context might be considered in value-producing templates.
  • WP:⋅ (this is the MoS/Mathematics subpage, examples at main MoS page still use middot) seems to be quite definite about which to use (quotes extracted here)
    For the dot operator, do not use punctuation symbols, such as a simple interpunct · (the choice offered in the "Wiki markup" drop-down list below the edit box), as in many fonts it does not kern properly.
    An alternative to the × markup is the dot operator ⋅ (also encoded and reachable in the "Math and logic" drop-down list below the edit box), which produces a properly spaced centered dot: "a ⋅ b".
  • It might make sense to deal with this at WT:MoS first.
I hope this helps. —Quondum 02:48, 1 November 2017 (UTC)
Thanks. There is a clue in "rare contexts where the sdot is not supported or correctly substituted". My real confusion is due to the fact that convert has used middot for many years and no one seems to have discussed whether sdot should be used (I searched the talk page archives). The old template, from before the module was introduced, used middot. Perhaps sdot was not well established several years ago, so middot was used. I am similarly confused about two symbols used for micro, but I'll stick to dots at the moment.
Any thoughts from other people on whether all units should be changed to use sdot? It's easy to do, but involves 82 changes so I'm a bit reluctant to be bold. I'll wait, and might ask for opinions at WP:VPT. Johnuniq (talk) 04:16, 1 November 2017 (UTC)
I first looked in to this about six months ago when Quondum changed some middots to sdots on a few articles I have watchlisted, and convinced myself at the time that sdot is correct. I believe it will render properly on all modern browsers. "For the dot operator, do not use punctuation symbols" seems pretty clear. Kendall-K1 (talk) 04:42, 1 November 2017 (UTC)
Thanks for the comment because I want to see a positive consensus before a change. I asked at VPT. My above comment about 82 changes is correct but in more detail that is 54 units with a symbol or name using middot, and an additional 23 unit codes which accept a middot in the code. For example, kW·h is an alias for the kW.h unit (and kW·h is the symbol for that unit). I'll download the November all-articles dump when it is available in a couple of weeks and will work out how many converts in articles use the 23 aliases. I might recommend replacing them and removing the aliases from convert. In June 2016, over 1100 converts had a unit code with a middot: over 850 lb·ft + 120 N·m + 20 acre·ft + more. Bit messy, but it would be very odd to remove middot from the output while accepting it in the input. Johnuniq (talk) 06:42, 1 November 2017 (UTC)
I have added some points above (underlined). I suggest treating the acceptance of a middot in the input code as an unrelated issue, nothwithstanding the "oddness" of translating from one to the other (accepting anything except "." in the input code for this should be disallowed, IMO, but any change here should be delayed until a global find-and-replace bot has run). —Quondum 12:42, 1 November 2017 (UTC)
Whatever the rendered dot (middot of math dot), the wrongdot in input should be accepted (recognised & used). No misunderstandings raise from there. An editor usually cannot see the difference (in a pick-symbol-list), so should not be frustrated. Also, copy/paste input better kept possible, even with the wrongdot in the source. Even better: I see the full stop is accepted in situation (see table, "lb.ft" input). This too is editor(keyboard)-friendly and should stay provided no confusion can occur. -DePiep (talk) 12:01, 2 November 2017 (UTC)
The Apollo dn330 is incapable of rendering sdot

Here is the official word on this from the SI Brochure English 8th edition. It says, "In forming products and quotients of unit symbols the normal rules of algebraic multiplication or division apply. Multiplication must be indicated by a space or a half-high (centred) dot (⋅), since otherwise some prefixes could be misinterpreted as a unit symbol." and gives "N m or N⋅m" as examples for the newton metre. In both instances, the official document uses the Unicode multiplication dot (the sdot). Seems like changing it to the sdot would be a good idea. Good eyes! I bet there's no particularly good reason why middot was used. It just "looked correct enough" and that initialized the decision and inertia carried it through until today. Jason Quinn (talk) 19:47, 1 November 2017 (UTC)

Sdot wasn't introduced until Unicode 1.1 in 1993. But given this is also the year that html and the web started to take off, I suspect we're safe in using it. It probably won't render correctly on my Apollo dn330 but I will put up with that inconvenience for the sake of the greater good. Kendall-K1 (talk) 20:08, 1 November 2017 (UTC)
Kendall, we'll just have the template detect your Apollo DN330 and substitute another character. Easy peasy. John, you can whip that up, right? (Yes, I support the change to sdot.) — Huntster (t @ c) 22:01, 1 November 2017 (UTC)
That sounds very reasonable. I'd better try to make it work with an ASR-33 as well. Johnuniq (talk) 01:07, 2 November 2017 (UTC)
I know you're just joking, but the asterisk on the ASR-33 was intended to be used as a multiplication symbol, so it appears exactly centered just like the "+" or "-", unlike in many modern fonts. So it's a good stand-in for sdot. Kendall-K1 (talk) 01:12, 2 November 2017 (UTC)
... and I bet the hyphen-minus has exactly the same width is '+' :-) —Quondum 01:47, 2 November 2017 (UTC)
re Jason Quinn: yes, this is the reason (the algebra) why we should use sdot. Also, support for the careful changeover process Johnuniq describes.
WP:MOSMATH explicitly says to use sdot (as Quondum wrote above). However, WP:MOSNUM contradicts this (prescribing middle dot). So as for MOSes, they should solve this between them (get popcorn). (BTW, any idea why it's named "sdot"?) -DePiep (talk) 12:31, 2 November 2017 (UTC)
  • For additional official guidance in addition to NIST, the Unicode v. 10 standard in Chapter 22 ("Symbols") p. 809 states

The distinction between middle dot and dot operator deserves special consideration. dot operator is preferred for mathematical use, where it signifies multiplication. This allows for rendering consistent with other mathematical operators, with unambiguous character properties and mathematical semantics. middle dot is a legacy punctuation mark, with multiple uses, and with quite variable layout in different fonts. For the typographical convention of a raised decimal point, in contexts where simple layout is the priority and where automated parsing of decimal expressions is not required, middle dot is the preferred representation.

Jc3s5h (talk) 12:58, 2 November 2017 (UTC)
  • Condensed, my overall view: no absolute (browser) issues preventing the change known yes it should be ⋅ in the output, yes the careful approach by Johnuniq is great, and no actual harm (pages rendering bad) pointed. -DePiep (talk) 21:53, 3 November 2017 (UTC)

I see no dissent here. Maybe this could be regarded as consensus for the change? —Quondum 15:15, 12 November 2017 (UTC)

On the input side

As for allowing middle dot (00B7 hex) as input, I think we could take the same attitude as the National Geodetic Survey does on inputting degrees, minutes, and seconds. One format accepted by some programs is, for example N384417 for North 38° 44′ 17″. That would obviously be unacceptable in any publication, but is accepted as an easy-to-type input format. If we accept middle dot as input, we should display dot operator when displaying the unconverted quantity. Jc3s5h (talk) 12:58, 2 November 2017 (UTC)

"unacceptable [...] but is accepted as an easy-to-type input format" — and unacceptable even as input for us because it introduces ambivalent numbers. Accepting (and interpreting correctly) a middot does not do that. (At best, we could research if problems occur when inputting the full stop for this). -DePiep (talk) 13:34, 2 November 2017 (UTC)
At present, the input strings are apparently generally geared to accepting the period (.), and anything else is probably only supported for a few cases. I expect that for general parsing, allowing for "what might be convenient to editors" is a slippery slope to a maintenance nightmare. For this reason, I oppose allowing inputs with middot, sdot and the like as a general option; support for only the existing supported codes should be retained only as legacy support and discouraged in the template documentation. I think the maintainers of the module will agree. The idea that the user of a template should not learn what that template accepts or even read its documentation is not sensible. (Actually, I'd argue that flexibility will lose time for editors due to exponential confusion creep.) —Quondum 19:51, 2 November 2017 (UTC)
I strongly object. what might be convenient to editors is a slippery slope is not the right approach. Better, we can rightly say: "when conveniant input is not causing confusion, {{Convert}} should accept". There is no slippery slope: it's clear today, and will be clear tomorrow. (That is: a · cannot be misunderstood so is OK for input; same for existing "lb.ft" option). -DePiep (talk) 21:15, 2 November 2017 (UTC)
Heh-heh. Let's leave comment on that that to the people who actually maintain the module. I will point out that this is unrelated to the purpose of this thread (#Dots), which is to determine what character should be in the output. —Quondum 23:36, 2 November 2017 (UTC)
"Heh-heh ... Let's leave that to ..." (patronising me?): no, Johnuniq is nicely asking us here for advice. And btw, how come you push opinions here, and then come patronise me for proposing stuff? -DePiep (talk) 23:58, 2 November 2017 (UTC)
"unrelated to ..." — I know. That is why I created this subsection. -DePiep (talk) 23:58, 2 November 2017 (UTC)

Micro symbols

Encouraged by the wisdom at #Dots above, my other confusion concerns what symbol should be used to represent the micro SI prefix. There are two possibilities which look the same in most fonts:

  • μ = Greek small letter mu = U+03BC
  • µ = micro sign = U+00B5 (displayed by µ in at least two browsers)

Convert acccepts the first (mu) but always displays using the second (micro). Examples:

  • {{convert|1|mm|um|abbr=on}} → 1 mm (1,000 μm) ("u" is accepted for micro as a convenience)
  • {{convert|1|mm|μm|abbr=on}} → 1 mm (1,000 μm) (mu for input; micro for output)
  • {{convert|1|mm|µm|abbr=on}} → 1 mm (1,000 μm) (micro for input and output)

However, Micro-#Symbol encoding in character sets says mu should be displayed, not micro. I have seen other comments suggesting that the article is correct and convert is wrong.

If, possibly after a MOS discussion, we decide to change how convert displays dots, we may as well make a decision about micro as well. It's clear that both mu and micro should be accepted for an input unit, as occurs now. Convert's output uses micro. Should convert be changed so that the output uses mu? Johnuniq (talk) 03:15, 2 November 2017 (UTC)

I was around at the time this was being discussed at the Unicode consortium (I'm older than I look) and as I recall the argument was that including µ but not the rest of the Greek alphabet in 8859-1 was a horrible hack and should just go away, in favor of the complete Greek and Coptic set. I think everyone assumed the glyphs would be the same. I see now that after I left they broke out Coptic as a separate block so I don't know how that fits in. I guess my vote would be to go with Greek mu. I would be surprised if it makes any difference on any real-life screens. (except my Apollo, which I think is actually 8859-1) Kendall-K1 (talk) 03:45, 2 November 2017 (UTC)
I have browsed through several standards-related sites and PDF documents, such as NIST, the SI Brochure, ISO 80000 and the like. While I did not see the matter mentioned, they all use the SI prefix μ, and in every case that I checked, the encoding is U+03BC. Support for the greek alphabet in Unicode seems to be greater than for the sdot: it was present in the first Unicode version (1.0.0 of 1991). I'd say you can change this one without a MoS discussion. (And I've often seen a difference in how they are rendered in a given font: the micro sign is generally less pleasing than the greek mu.) —Quondum 04:00, 2 November 2017 (UTC)
Historical standards (old Unicode, ISO) are no argument (except maybe for availability of the glyph in browsers). We should use the current version, including its backgrounds (say, original and cumulative motivation to include the separate MICRO SIGN still being valid; and check for the Deprecated note). "less pleasing" is no argument. -DePiep (talk) 11:49, 2 November 2017 (UTC)
Difference with the dot: the prefix is a chosen symbol (letter or letter-like), while the dot is a mathematical multiplication sign. -DePiep (talk) 11:49, 2 November 2017 (UTC)
mu. The use of mu as a metric symbol predates SI, let alone Unicode - for example, the 1911 Kaye and Laby uses it. SI is independent of Unicode and does not define symbols in terms of Unicode; it defines the micro- symbol as mu, not as any particular Unicode character. 92.19.24.9 (talk) 23:16, 20 November 2017 (UTC)

Since this has come up again, "micro" is what Unicode calls a "compatibility decomposable character." (Unicode chapter 2, section 2.3) Its decomposition is the Greek letter mu. As section 2.3 notes, these characters are part of Unicode only to support compatibility with older standards, in this case Latin-1. "The purpose for the inclusion of compatibility characters like these is not to implement or emulate alternative text models, nor to encourage the use of plain text distinctions in characters which would otherwise be better represented by higher-level protocols or other mechanisms. Rather, the main function of compatibility characters is to simplify interoperability of Unicode-based systems with other data sources, and to ensure convertibiliity of data." Kendall-K1 (talk) 00:21, 21 November 2017 (UTC)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Convert/Archive_November_2017&oldid=814182596"