Talk:Duodecimal/Archive 2

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
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 (d) 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 12 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) #.[1] The symbols were chosen because they are available in typewriters, they also are on push-button telephones.[1] This notation was used in publications of the Dozenal Society of America (DSA) in the period 1974–2008.[2][3] 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

  1. ^ a b Cite error: The named reference Symbology Overview was invoked but never defined (see the help page).
  2. ^ "Annual Meeting of 1973 and Meeting of the Board" (PDF). The Duodecimal Bulletin. 25 [29] (1). 1974.
  3. ^ De Vlieger, Michael (2008). "Going Classic" (PDF). The Duodecimal Bulletin. 49 [57] (2).
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)