Even if we switch to using dozenal, we'd still have computers that work in binary, and thus base *14 would still be used as much as it is now.

So what would the hexadecimal ("tetradozenal"?) digits be? Would we still use 0123456789ABCDEF? Would we switch to 0123456789ΧƐABCD? Or the more backwards-compatible 0123456789ΧƐCDEF? Or decide that since if we want to go through the trouble of using 2 more digits, we might as well invent another 4?

I think we'd simply use our normal digits, then add letters afterwards as appropriate. So the hexadecimal numbers would be 1, 2, 3, 4, 5, 6, 7, 8, 9, :A, :B, A, B, C, D, 10.

Add our two and keep CDEF.

Originally I was a "hexadecimalist", and still use the hexadecimal extension of my own symbols. These mostly get used for rgb color notations or bluescreen data. The extension was done in 1983. Originally the twelve looked like a "C". In 1987 the arqam was extended to 20 symbols, then to 60 in 1990. It now has about 400 contiguous symbols, and around 500 symbols total. The base-60 symbols are used for keeping track of project time and fees, laps in the pool, etc. The symbols and their names do slowly change over time. Nope, it ain't perfect, but it works well. "Arqam" is Arabic for "numbers". (The name of the words I use for the numbers is "ismarraqam", Arabic for "number names"). Actually, since base 60 is used so often nowadays, the number names for certain numerals are shortened: "kinex", meaning 'five-six', for example, is just "kex", "kinove", meaning 'five-nine', is "kove". Here is a table of the arqam up to digit-59:



Technically, the hexadecimal portion of this system jives with Shaun's post. Yes, originally, the first 8 transdecimals were letters. The first two (ten and eleven) were letters from an alphabet I made up when I was in 7th grade. With "reverse three" used to convey 14, you now see why I can't use the "el" the DSA and the DSGB agree on. I've been using "reverse 3" for 14 since 1983 - to me, it means 14.

Wow, Icarus, that's impressive. I don't think dealing in base-60 with any kind of frequency is within my competence.

Shaun, why keep CDEF? The computer sure doesn't care either way, and it seems more intuitive to use ABCD.

Of course, ASCII can't be reformulated, as it's too widespread and long-standing a standard. I think ultimately we'll have to change it, but in the most limited way possible. Perhaps put :A and :B in some of the control character spots (0-31) which are rarely if ever used; e.g., 11 is a vertical tab. Maybe better would just be 30 and 31, which are "US (unit separator)" and "RS (record separator)", which I've never used nor seen used in all my days.

I started designing symbols for base sixty many years ago, but never used it much. And the symbols certainly weren't as interesting as those of Icarus! You need a decent pen and a bit of care to write them properly.
As for CDEF, well, I thought it would keep some of those symbols already in use with base sixteen; it's only used to record binary and octal, isn't it?

True enough. I just thought that :A, :B, C, D, E, F made it somewhat unintuitive. Human beings do occasionally have to work in hex; however, it's rare enough that I suppose it wouldn't make hex any larger a hurdle than it already is.

Still, I don't think the computer would care either way, so wouldn't it be better to make it logical for users?

That's what modified ASCIIs have traditionally done. For example, ATASCII redefined most of the control characters as graphics characters.

Unfortunately, this would have the problem that 'Ɛ' < '0', which would mess up a lot of software that depends on lexicographical order being the same as numerical order. A better choice would be code 8F and 90, which are obscure control characters in Latin-1 and unused in windows-1252. But then in UTF-8 they'd take up 2 bytes each.

Eventually we're just gonna have to make the twelve digits consecutive and move the colon and semicolon somewhere else.

True enough. Since the colon and semicolon are just punctuation, why not move them to 30 and 31, where they won't mess up the alphabetization and sorting algorithms that are already written, and replace them with :A and :B?

Would be a good idea had I not written code that depends on space being the lowest-numbered printable character. Even EBCDIC, with it's non-contiguous alphabet, does this.

But we could probably get rid of at half of the ASCII control characters and move space down to '\x10'.

@icarus: I believe I remember a post where you explained your system in detail, without the symbols. I just can't seem to find it...

Anyway, on ASCII: I don't see the need of it. Most computers nowadays use Unicode, and you can easily include transdecimal symbols, perhaps at first in the private use area. ASCII, being a legacy standard, should not be touched, for compatibility reasons. When working with software that still uses it, one can just take XE or TE or ABCDEF.

Using dozenal digits for the first twelve digits of hexadecimal only makes sense when dozenal has already completely supplanted decimal and we have two standard digits, charset support and so on. Until then, I will continue to use ABCDEF for everything over base twelve.

But the first 127 bits of Unicode exactly correspond to ASCII. As has been pointed out, a lot of code depends on ASCII being in a certain order. Dozenal will need to be integrated into that order with as little disruption to prior art as possible. If we move the space down, as Icarus suggests, along with the colon and semicolon, then put :A and :B there, that should be good enough. Perhaps interpreters could read the first line of each file before displaying them, which contains a simple line (say, "\oldascii") telling them to use those slots for their old rather than new values. Most standards require stating your encoding anyway, so this wouldn't be a real problem.

Ebbe, the orig post was at Dozensonline > Metric & Imperial > Extended prefixes. Thanks to the weird names it's easy to google! It's evolved a little but the idea is essentially the same.

Not the programmers that some other fine folks are on this forum, I have produced several dozen dozenal fonts which operate thus:

The ascii/unicode points for the traditional numerals 0 through 9 are used, then for convenience I overwrite the lowercase, then the uppercase roman alphabet which occupies the ascii range. This allows the fonts to operate so that Mathematica's BaseForm[] command can output a word which can be readily converted to whichever symbology desired. So if i input BaseForm[N[Pi, 24], 12] i'll get something like 3.184809493b9... (something like that), and the "b" will convert to the digit-11. I use mathematica so that the Duodecimal Bulletin can pull output into the mag when necessary. Someone recently requested pi to the 2000th digit (we wondered, 2000 or *2000?) so we did decimal 5000 digits and converted it, simply changed the font, and voila, pi to the 2000 or *2000th digit, in pitman, dwiggins, or whatever. whole thing takes about a minute.

Understandably this is not good for algorithms that rely on position of the character in unicode (or if you like to use the Latin alphabet in your writings :) ); the excel spreadsheets that I use to convert hours and dollars to sexagesimal numbers have very complex if() statements that convert each digit. In order to smooth that out, many of the fonts use a high unused range like 1000 to wherever to place contiguous numerals so that the scripts need not jump between ranges. One can imagine that perhaps a unicode range may be available where the entire contiguous range of numerals, especially those for numerals of very high bases, may be arranged. Yes, this reduplicates the numerals 0-9, but these are reduplicated for several languages already, and there are the chinese numerals which appear precisely the same as the ascii-range numerals.

point is, perhaps the dozenal / hexadecimal / (and beyond?) numerals might occupy a special, new, contiguous range further up in the unicode space. This would leave the decimal numerals, punctuation, function glyphs, etc. in the lowest part of the space unchanged.

Another way :) [or :( !] is that we are the present-day Romans, ahead of a major civilization-wide calamity. Unicode as a structure, along with all the intellectual achievements we've devised in the last couple centuries are awfully delicate. Lots of saber rattling, quibbling, and kids in the USA in the back of class jacking around rather than studying. Maybe all this wonderful technology is temporary, like the high point of an ocean wave washing on the beach, only to roll back into the sea, leaving a clean slate in a couple centuries. Maybe it's better that we start carving all these ideas into stone monuments so that perhaps they'll survive the test of time (just a daydream...not a good daydream - I am an architect don't like seeing ruins).

That's a good point. We can essentially just ignore the ASCII-range numerals and use this higher-range, continuous set.

LaTeX being a fantastically versatile language, I'm able to do something quite similar with the digits there. The command \x can simply be redefined at the beginning of a document; by default, it produces :A, but if you'd rather it produce something else, just find the appropriate symbol and put it in there. By changing a single line in this way, all the digits in the resulting document will be different.

Today, that would be a workable solution, although encoding another duplicate of the digits 0-9 may cause more problems than having non-consecutive digits.

However, using code points outside the ASCII range would double or triple the amount of space it takes to encode digits in UTF-8.

Thanks!

There will be a place for duodecimal digits in Unicode soon (or maybe, not so soon, I don't know when it's ready). The Tengwar numerals! There is a proposal to include Tolkien's Tengwar script in Unicode's Supplementary Multilingual Plane at U+16000 to U+1607F. On codepoints U+16062 to U+1606B will be the digits 2-(eleven). Digits 0 and 1 are U+16030 and U+16033 in Tengwar, they use existing signs; but U+16060 and U+16061 are free and could be used for 0 and 1.

A dozenal font could provide non-Tengwar digits at these codepoints. This solution would of course be far from ideal for dozenalists who want to write in Tengwar from time to time ;) .

I don't really think it's practical, but just found it interesting. Also, there is no space in Tengwar for hex-digits C to F.

I like that Tolkien's Elves are a dozenal culture: "The Eldar preferred to reckon in sixes and twelves as far as possible." (The Lord of the Rings, Appendix D).