Talk:Duodecimal/Archive 2

Archive 1

Archive 2

RfC: Extra digits

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Should this article use {{rotate|180|2}} and {{rotate|180|3}} (2 and 3) with markup or the special characters U+1614 ᘔ CANADIAN SYLLABICS CARRIER JU and U+0190 Ɛ LATIN CAPITAL LETTER OPEN E for the digits ten and eleven, like other articles? Or should we use something else entirely, like X and E? –LaundryPizza03 (dc̄) 22:09, 21 August 2019 (UTC)

@LaundryPizza03: Per WP:RFCBEFORE, why start an RfC on this before there's been any discussion? This seems like something that could be figured out without a big show. But anyway, this is also right after Spitzak converted all uses to {{d2}} and {{d3}}. Presumably, everything should use those (and while I appreciate the need for a short name, I wonder if d2 and d3 are maybe too short and likely to clash with something), and then any decisions could easily be implemented wiki-wide. There's also {{duodecimal}}, which is used by number articles (and maybe other stuff?), which is really just a wrapper for Module:BaseConvert – it uses A and B and automatically puts the ₁₂ subscript after the result.

Anyway, there are two main considerations here: rendering support and semantic correctness. A/B and X/E have both (probably). 2 and 3 will likely render fine just about everywhere, but lack semantic correctness, and likely won't work correctly with screen readers. The actual unicode points mentioned in the article are semantically most meaningful, but apparently lack support. Other things that just look close (like the ju syllabics thing) fail all tests and have no business being used at all. –Deacon Vorbis (carbon • videos) 23:32, 21 August 2019 (UTC)

• X and E. The rotated characters are clever but cleverness is not always a virtue. They make sense as modified versions of the digits 2 and 3 only if one is coming at this from the point of view of octal (where the numbers they represent are the base + 2 or 3), unlikely for readers of this article. The Canadian and Latin special characters are just wrong (have unrelated meanings to the ones here). And for purposes of both general audience readers not getting confused by special characters, and ease of editing, X and E are much better. (A and B would also both be acceptable but are more decimal-centric than X and E). —David Eppstein (talk) 23:35, 21 August 2019 (UTC)
• The template names were chosen because they were not already taken (t2 and t3 were taken, that is what I tried first). I don't have any problem changing them to produce X and E or A and B or whatever. However the few uses where they *should* be the rotated digits should be converted back. I think leaving them as templates is a good idea as this will allow further changes when this subject comes up again.Spitzak (talk) 15:17, 22 August 2019 (UTC)
• Everything except {{rotate}} which defeats text processing. Incnis Mrsi (talk) 07:51, 23 August 2019 (UTC)

  And more… “E” is stupid—at least for Wikipedia—because conflicts with the well-known hexadecimal notation. Seemingly “Ɛ” is the best for eleven. No strong opinion on character for the digit “ten”, although “X” is already used in Roman numerals and hence would not look unreasonable in this context. Incnis Mrsi (talk) 09:58, 23 August 2019 (UTC)

• I am in agreement with Deacon Vorbis. A and B will be understood as part of standard notation for bases higher than ten; the rotated 2 and 3 (as Unicode characters) are used by both Dozenal Societies (who probably constitute a significant fraction of the actual use and advocacy of base twelve); and X and E will probably be understood as an ASCII fallback used by the Dozenal Society of America itself. Of course, the trouble with the rotated 2 and 3 is that the actual Unicode characters are usually not supported, and using CSS to rotate an actual 2 and 3 will mean that copy-paste doesn't work (as Deacon Vorbis says, it's semantically wrong), so either A/B or X/E seems the way to go. Double sharp (talk) 13:26, 27 August 2019 (UTC)

  Where is Double sharp’s proposal? Obviously the bulk of the article should subscribe to one uniform notation, and there are already two templates: {{d2}} and {{d3}}. What to do (if anything) now? Incnis Mrsi (talk) 13:39, 27 August 2019 (UTC)

  As I said at the end: "either A/B or X/E seems the way to go" in my opinion. Double sharp (talk) 13:40, 27 August 2019 (UTC)

• Whatever else, I agree with the opinions that only characters that are compatible with keyboards and scanners should be used, or even considered. As a long-time user of Hexadecimal, I would prefer A and B for 10 and 11(denary) but if the majority prefer X and E, I could live with that. But above all, keep it simple, easy, and readable. JonRichfield (talk) 11:22, 29 August 2019 (UTC)

  “Characters compatible with keyboards”? For typing there are {{d2}} and {{d3}}, and how keyboards help an end user to read? A pack of down-to-ASCII simplifiers pushes for Latin letters and despise (or evade addressing) such options as U+0190. Would “A”, “B”, “X” and “E” be very helpful for people with screen readers? It isn’t certain that—when read aloud—this digits+letters mess would result in anything intelligible. Incnis Mrsi (talk) 12:06, 29 August 2019 (UTC)

• Do not use rotated characters. Softlavender (talk) 05:48, 8 September 2019 (UTC)
• How about * and #. * and # have been mentioned in the article, yet it isn't an option here. These two symbols answer both similarity to Hexadecimal problem and semantics! User:Worra Mait Kosit (talk) Worra Mait Kosit (talk) 09:12, 11 September 2019 (UTC)

  @Worra Mait Kosit: who uses these characters for encoding numbers in duodecimal? Wikipedia doesn’t invent or promote, Wikipedia mostly compile sources. Incnis Mrsi (talk) 09:52, 11 September 2019 (UTC)

  @Incnis Mrsi: From the article, although I understood that this is not a strong argument: Edna Kramer in her 1951 book The Main Stream of Mathematics used a six-pointed asterisk (sextile) ⚹ and a hash (or octothorpe) #. The symbols were chosen because they are available in typewriters, they also are on push-button telephones. This notation was used in publications of the Dozenal Society of America (DSA) in the period 1974–2008. Worra Mait Kosit (talk) 17:11, 11 September 2019 (UTC)

• First Choice A and B. Second choice X and E. A and B are used in hexadecimal, and anyone who knows hexadecimal knows what they are, and anyone who doesn't use hexadecimal either won't use duodecimal or can learn. Robert McClenon (talk) 13:01, 11 September 2019 (UTC)
• Absolutely not U+1614 ᘔ CANADIAN SYLLABICS CARRIER JU and U+0190 Ɛ LATIN CAPITAL LETTER OPEN E because those characters have different meanings to the Dozenal Society symbols. With the mention of screen readers, I'm inclined to prefer A/B over the rotated 2/3, but I see pros and cons to both choices. — Bilorv (talk) 19:07, 15 September 2019 (UTC)

References

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Why not use A for ten and B for eleven ?

In the same Wikipedia, the Base 16 (hexadecimal) article uses A and B for ten resp. eleven. So why not the same in duodecimal / dozenal ? That results in more consistency and the weird epsilon like symbol for eleven is not available in many letter fonts. S k a t e b i k e r (talk) 12:04, 16 January 2020 (UTC)

According to above discussion X and E are more popular. X is the roman numeral for ten, and E stands for "eleven". I am unclear why the epsilon is being used instead of E as that is not really mentioned above.Spitzak (talk) 18:44, 16 January 2020 (UTC)

The closing statement clearly says A/B is more popular among editors, and it looks accurate. I'll change the templates. -- Beland (talk) 16:59, 31 July 2020 (UTC)

Spacing in multiplication table

@Spitzak: I just looked at the column widths in Firefox's web inspector, and they are actually all different widths because of the different widths of the different character combinations. The right way to make consistent column widths would probably be to use CSS. But looking at it on a mobile phone, I also noticed that the width of the table is close to the width of my phone screen. I'm sure at slightly lower resolutions or higher zoom levels, the table would force horizontal scrolling, which is quite bad. So on balance I think the best thing to do is make the table as narrow as possible by letting the browser decide how wide each column should be, which is what we do for the vast majority of tables anyway, and simplifies the markup. -- Beland (talk) 16:51, 31 July 2020 (UTC)

This is an attempt to make the first column the same widths as the others. I agree that letting the browser choose the widths is best want the same answer for all of them. At least on my system the character given now produces matching widths and I have not seen any examples where it does worse than nbsp.Spitzak (talk) 17:50, 31 July 2020 (UTC)

All columns should now have equal widths. –Deacon Vorbis (carbon • videos) 18:07, 31 July 2020 (UTC)

Thanks David Eppstein; I forgot to kill the special character in all that. –Deacon Vorbis (carbon • videos) 18:10, 31 July 2020 (UTC)

Forcing the widths to all be the same (as opposed to letting the browser choose different widths for each column, which is what I was proposing) has the effect of making the table wider than it needs to be, and thus for horizontal scrolling to start earlier than it needs to. But at least this method makes the columns the same width; there were 1-pixel differences between most of the columns without the "width" CSS. -- Beland (talk) 18:28, 31 July 2020 (UTC)

Notations table

I have added the notation options in table form (by characters, by base indicators); § Notations and pronunciations. They are derived from the existing text. We could reduce the overlap, but I am not sure about removing (redundant) text boldly. -DePiep (talk) 07:48, 17 April 2022 (UTC)

Whitespace characters

@Spitzak: Hello, again! Regarding this revert: Best I can tell, the ensp characters are not needed because the text in question is aligned-right. Looking at Wikipedia:Manual of Style/Mathematics, thinsp characters are not used for spaces in HTML equations. I generally convert both types of whitespace to regular spaces to make the markup easier to read, per the "keep markup simple" guideline at MOS:MARKUP. -- Beland (talk) 20:08, 9 April 2022 (UTC)

Variation in spacing is definitely part of proper mathematical typography, as would be obtained by using LaTeX-style markup. It is normally provided automatically as part of the system that formats the mathematics. I see no guidance in Wikipedia:Manual of Style/Mathematics about avoiding variation in spacing for HTML-formatted mathematics. All I can see is some guidance to avoid using explicit spacing commands as a trick to force LaTeX formulas to be displayed as images. It doesn't even say not to use explicit spacing in LaTeX, only not to use them for that one weird purpose. —David Eppstein (talk) 20:19, 9 April 2022 (UTC)

The note re ensp is correct: right-alighed so useless (also, in general and here too margins, padding &tc in table cells preferable not done by space characters). -DePiep (talk) 14:07, 10 April 2022 (UTC)

MOS:MATH gives one clue for proper rendering in HTML: use {{math}}. And doing so stimulates having same formatting throughout, so no blanket reason to adjust whitespace case by case. I note that it is not a good idea trying to emulate exact Latex formatting. -DePiep (talk) 14:24, 10 April 2022 (UTC)

{{math}} is not proper mathematics rendering. It is a hack that sort of looks like LaTeX but is not as good. That does not mean that we have to make it even worse by sticking with uniform spacing when better spacing options are available. —David Eppstein (talk) 05:27, 28 April 2022 (UTC)

As always, you are invited to point out the "not proper" and propose improvements for those unspecified "worse" effects. Until that effectuates, {{math}} a good inline one to use. -DePiep (talk) 09:17, 28 April 2022 (UTC)

For me removal of the nbsp from the table results in the left column being centered, not right-justified. That was why I reverted the edit. I don't have any opinion on putting thinsp in the math expressions, except I have rarely seen this in other articles.Spitzak (talk) 14:34, 11 April 2022 (UTC)

Ah, the ! directive apparently overrides the table-wide align-right CSS. I fixed that by adding align-right to the needed cells and it should be behaving now. Sorry for not catching that the first time. -- Beland (talk) 23:09, 27 April 2022 (UTC)

Great catch, Beland! (the table is in § Comparison to other number systems). The "!" is the wikitable marker for "row/column header" (giving those styling effects, together with semantics). -DePiep (talk) 04:55, 28 April 2022 (UTC)