
Double sharpDozens Demigod
 Joined: Sep 19 2015, 11:02 AM
I have previously mentioned this person's senaryadvocacy site here.

sunnyRegular
 Joined: Jun 30 2013, 08:58 AM
I was at some point, so convinced that Senary might be a lot better base than Dozenal because of it's more friendliness to 5ths and 7ths. But alas, you can't do clear cut 5ths and 7ths in senary without a "remainder", the good visual easy reptends of those after its fractional point doesn't help with the case and could be as bad as any more larger reptends in other base, 3rds in decimal or 5ths in dozenal doesn't matter as you can't do that in both however beauty or ugly it might be. In comparision, you get direct 'quarters' in dozenal where you have to leap forward a square in that heximal base number to get it. In exchange, you get a large base with minified digit length just when you put that another factor of 2.

KodegaduloObsessive poster
 Joined: Sep 10 2011, 11:27 PM
You know, he manages to put together a fun video, and he's got the chutzpah of youth, but he's cherrypicked divisibility tests and reptends as the beall endall criteria for what makes a good base. He completely glosses over the compactness issue with senary.
For example, in a decimal or dozenal world, tendigit phone numbers suffice. But in a senary world, they would need thirteen digits. An area code would need four digits instead of three. Likewise for an exchange number. And if you want enough individual lines in your exchange, you'd need five digits instead of four. Social security numbers in the US are also ten decimal digits, so likewise we'd need thirteen senary digits to accommodate the population. Zip codes in the US would need to be 6 digits rather than 5. That much more to remember, that much more to store, that much more space needed on displays, in paper advertisements, on government forms, yadda, yadda, yadda...
Sure, the multiplication table you have to learn in third grade is simpler, but in exchange for that you get costs, costs, costs, all the rest of your life.
[I originally posted this on the wrong thread, so I copied the text, deleted the post, came here and tried to post it. Nannystate tapatalk scolded me that I can't post the same text as I previously posted. Are you kidding me?? So the presence of this little rant at the end here is just to make this post different. Please ignore.]
For example, in a decimal or dozenal world, tendigit phone numbers suffice. But in a senary world, they would need thirteen digits. An area code would need four digits instead of three. Likewise for an exchange number. And if you want enough individual lines in your exchange, you'd need five digits instead of four. Social security numbers in the US are also ten decimal digits, so likewise we'd need thirteen senary digits to accommodate the population. Zip codes in the US would need to be 6 digits rather than 5. That much more to remember, that much more to store, that much more space needed on displays, in paper advertisements, on government forms, yadda, yadda, yadda...
Sure, the multiplication table you have to learn in third grade is simpler, but in exchange for that you get costs, costs, costs, all the rest of your life.
[I originally posted this on the wrong thread, so I copied the text, deleted the post, came here and tried to post it. Nannystate tapatalk scolded me that I can't post the same text as I previously posted. Are you kidding me?? So the presence of this little rant at the end here is just to make this post different. Please ignore.]
As of 1202/03/01[z]=2018/03/01[d] I use:
ten,eleven = ↊↋, ᘔƐ, ӾƐ, XE or AB.
Baseneutral base annotations
Systematic Dozenal Nomenclature
Primel Metrology
Western encoding (not by choice)
Greasemonkey + Mathjax + PrimelDozenator
(Links to these and other useful topics are in my index post;
click on my user name and go to my "Website" link)
ten,eleven = ↊↋, ᘔƐ, ӾƐ, XE or AB.
Baseneutral base annotations
Systematic Dozenal Nomenclature
Primel Metrology
Western encoding (not by choice)
Greasemonkey + Mathjax + PrimelDozenator
(Links to these and other useful topics are in my index post;
click on my user name and go to my "Website" link)

sunnyRegular
 Joined: Jun 30 2013, 08:58 AM
I merely think of fourths as an equally important factor alongside thirds, if not more. I think that the minimized digit length is merely a gift that dozenal provides us. If achieving more minimized digit length is better, then by including another factor of 2 in dozenal provides us 24 which could be more better in that regard, we just have to spend a much detailed time in learning multiplication tables. But once achieved, it would certainly cost less later in life. As using such a huge, pure base in practicality seems highly subjective, so 12 might be the sweet spot, considering 1/8ths as "not so needed" at the cost of that much sacrifice in learning so much numbers and their multiplication tables.
I still think ways to improve senary to make it more practical, but I just can't. The best way that I like is to use it say, as a compression using color codes:
"0 1 2 3 4 5 0 1 2 3 4 5 0 1 2 3 4 5 0 1 2 3 4 5 0 1 2 3 4 5 0 1 2 3 4 5 10", which is respectively "0 1 2 3 4 5 6 7 8 9 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 10", as the latter are in base 36 represented in today's world.
These are the numbers that represent 036 with "10" as the base number, the 36 itself, if we follow this pattern, the multiplication table seems good to grasp?, because you get only numbers from the subset 05, and the patterns could be achieved with them. It can be color that tells us how large the number is. It's not just the colors, we could replace them with different styles in terms of writing them like plain, strikethrough, vertical strikethrough, underline, overline and finally, say a dot on them. Anything works fine as long as the numbers in one subset is similar to others in different subset but easily distinguishable from others.
It seems complicated, but once achieved, it could minimize the word length to a great level and we could get patterns such as multiples of 2 end in 0, 2 and 4 and its family (0, 2, 4, 0, 2, 4, 0, 2, 4, 0, 2, 4, 0, 2, 4). Multiples of 3 would end in its family 0 and 3. Multiples of 4 would end in 0 and 4 from one subset (black, blue and yellow here) and end in 2 from others (violet, green and red here). Multiples of 5 would end in decreasing order 5, 4, 3, 2, 1, 0 and so on but next with alternating colors starting 5 from red again.. 5, 14, 13,.. and so on, Multiples of 0(six) would end in 0 always, that '0' could mean any color here. Multiples of 1(seven) would end in increasing order 1, 2 ,3, 4, 5, 10 but in alternating colors shifted from here on (skipping a color afterwards when this has reached 5, 10, skipped black '0' here by jumping from red 5 to violet 0).
I could go on like this, there could be an easy rule to find out if a number is divisible by another number which for that, we need to look up in the color of the number left to unit's place to determine. But if anyhow, if we could get the gist of the multiplication table easily and which color/style is larger in value than the other, the digit length of this number base is highly minimized but now with achievable practicality of its implementation.
Has something like this discussed elsewhere in this forum? I don't know if I had seen something like this here, or something alike as far I can remember (pardon me for not knowing it, because it's in my subconscious mind for many days so I may have borrowed the idea unknowingly)., or if there is any better way to do this written out here?
I still think ways to improve senary to make it more practical, but I just can't. The best way that I like is to use it say, as a compression using color codes:
"0 1 2 3 4 5 0 1 2 3 4 5 0 1 2 3 4 5 0 1 2 3 4 5 0 1 2 3 4 5 0 1 2 3 4 5 10", which is respectively "0 1 2 3 4 5 6 7 8 9 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 10", as the latter are in base 36 represented in today's world.
These are the numbers that represent 036 with "10" as the base number, the 36 itself, if we follow this pattern, the multiplication table seems good to grasp?, because you get only numbers from the subset 05, and the patterns could be achieved with them. It can be color that tells us how large the number is. It's not just the colors, we could replace them with different styles in terms of writing them like plain, strikethrough, vertical strikethrough, underline, overline and finally, say a dot on them. Anything works fine as long as the numbers in one subset is similar to others in different subset but easily distinguishable from others.
It seems complicated, but once achieved, it could minimize the word length to a great level and we could get patterns such as multiples of 2 end in 0, 2 and 4 and its family (0, 2, 4, 0, 2, 4, 0, 2, 4, 0, 2, 4, 0, 2, 4). Multiples of 3 would end in its family 0 and 3. Multiples of 4 would end in 0 and 4 from one subset (black, blue and yellow here) and end in 2 from others (violet, green and red here). Multiples of 5 would end in decreasing order 5, 4, 3, 2, 1, 0 and so on but next with alternating colors starting 5 from red again.. 5, 14, 13,.. and so on, Multiples of 0(six) would end in 0 always, that '0' could mean any color here. Multiples of 1(seven) would end in increasing order 1, 2 ,3, 4, 5, 10 but in alternating colors shifted from here on (skipping a color afterwards when this has reached 5, 10, skipped black '0' here by jumping from red 5 to violet 0).
I could go on like this, there could be an easy rule to find out if a number is divisible by another number which for that, we need to look up in the color of the number left to unit's place to determine. But if anyhow, if we could get the gist of the multiplication table easily and which color/style is larger in value than the other, the digit length of this number base is highly minimized but now with achievable practicality of its implementation.
Has something like this discussed elsewhere in this forum? I don't know if I had seen something like this here, or something alike as far I can remember (pardon me for not knowing it, because it's in my subconscious mind for many days so I may have borrowed the idea unknowingly)., or if there is any better way to do this written out here?

KodegaduloObsessive poster
 Joined: Sep 10 2011, 11:27 PM
Sunny the yellow color you used made those numbers completely invisible against the post background on my mobile phone (Samsung Galaxy 7 Android). Color is not advisable anyway because a significant fraction of people suffer from colorblindness (my brother, for example).
Using [09AZ] for hexatrigesimal compression is problematic partly because of the confusion of 0 vs O vs Q, or 1 vs I.
Using [09AZ] for hexatrigesimal compression is problematic partly because of the confusion of 0 vs O vs Q, or 1 vs I.
As of 1202/03/01[z]=2018/03/01[d] I use:
ten,eleven = ↊↋, ᘔƐ, ӾƐ, XE or AB.
Baseneutral base annotations
Systematic Dozenal Nomenclature
Primel Metrology
Western encoding (not by choice)
Greasemonkey + Mathjax + PrimelDozenator
(Links to these and other useful topics are in my index post;
click on my user name and go to my "Website" link)
ten,eleven = ↊↋, ᘔƐ, ӾƐ, XE or AB.
Baseneutral base annotations
Systematic Dozenal Nomenclature
Primel Metrology
Western encoding (not by choice)
Greasemonkey + Mathjax + PrimelDozenator
(Links to these and other useful topics are in my index post;
click on my user name and go to my "Website" link)

Double sharpDozens Demigod
 Joined: Sep 19 2015, 11:02 AM
The trouble with doing this kind of thing is that learning what order the colours or styles go in is just like learning them as if they were senary digits, which is what they are and how they act like: they may look nice early in the digit range, but try writing the hexatrigesimal tables for digits in the middle of the range and they start appearing in many different orders. So it is really not very different from learning the senary tables up to 100_{6} * 100_{6}, as you still have to think of senary to reconstruct many values in the middle of the table, instead of simply memorising them. The main difference is actually a negative difference, because you now have to add extra steps to convert colours and styles to senary digits and back. A further problem is that it may not be clear if the colour or styling is part of the digit or part of the context: if the text is coloured, what happens to the digits in the text?
I think this idea is probably at its best for a small mixed radix where the top subbase is very small, like 2 or 3. This allows the digits to be thought of as single entities and means that the difficulty of remembering the ordering of the styles and working with them is minimised, although it might perhaps be less confusing to simply be aware of the correspondences between digits at the same positions in their ranges rather than to make them look like each other with a stylistic difference. Indeed, Oschkar and I have considered this for what we have been calling the "higher naturalscale", but some anecdotal experimentation by the two of us suggests that the need for the digits to be thought of as single entities means that its limit at making big bases manageable may be very small, something like 18 or 20. You are then still stuck with a large multiplication table, but since addition has been effectively abbreviated to become only as difficult as the smaller subbase, you have more time to deal with it, and it isn't so large that you almost always have to break up the digits while multiplying them to get anywhere (like doing j * m in hexatrigesimal). The large multiplication table is also ameliorated by the way the digits can be broken up when you need them to be (e.g. for vigesimal patterns like 9i171g25 and so on) and not broken up when you need them not to be (e.g. for vigesimal patterns like 48cg10 and so on), so that you get to work with patterns from both the smaller subbase and the larger full base. But while I can get my head around this for octodecimal and vigesimal I already can't think of base 24 without always breaking it up as either 4on6 or 2on12, and while there may be some variation between individuals here I highly doubt you could get it all the way to base 36 as you would need to make it more attractive arithmetically (not mnemonically) to compress senary than to leave it alone.
I think this idea is probably at its best for a small mixed radix where the top subbase is very small, like 2 or 3. This allows the digits to be thought of as single entities and means that the difficulty of remembering the ordering of the styles and working with them is minimised, although it might perhaps be less confusing to simply be aware of the correspondences between digits at the same positions in their ranges rather than to make them look like each other with a stylistic difference. Indeed, Oschkar and I have considered this for what we have been calling the "higher naturalscale", but some anecdotal experimentation by the two of us suggests that the need for the digits to be thought of as single entities means that its limit at making big bases manageable may be very small, something like 18 or 20. You are then still stuck with a large multiplication table, but since addition has been effectively abbreviated to become only as difficult as the smaller subbase, you have more time to deal with it, and it isn't so large that you almost always have to break up the digits while multiplying them to get anywhere (like doing j * m in hexatrigesimal). The large multiplication table is also ameliorated by the way the digits can be broken up when you need them to be (e.g. for vigesimal patterns like 9i171g25 and so on) and not broken up when you need them not to be (e.g. for vigesimal patterns like 48cg10 and so on), so that you get to work with patterns from both the smaller subbase and the larger full base. But while I can get my head around this for octodecimal and vigesimal I already can't think of base 24 without always breaking it up as either 4on6 or 2on12, and while there may be some variation between individuals here I highly doubt you could get it all the way to base 36 as you would need to make it more attractive arithmetically (not mnemonically) to compress senary than to leave it alone.

sunnyRegular
 Joined: Jun 30 2013, 08:58 AM
@DS., I agree with you, but practically it might get easier with use, all this for 5ths and 7ths to look slightly good and to achieve more minimization of the digit length compared to dozenal. The question is: Is it worth it? Now Instead of colors, we could come up with 5 more modification to the already existing numerals '05' that they visually be distinct but would resemble each other, we could also use Kode's Xohox numbers. But let's see if we could digest the first step of the numerals 05 and the colors applied to them as blackmagentabluegreenyellowred, in that increasing order. The Multiplication table would be:
Is this all correct? I haven't checked myself yet after making this up!
PS(to kode): I made yellow and green with slightly darker hues for better display
1  2  3  4  5  0  1  2  3  4  5  0  1  2  3  4  5  0  1  2  3  4  5  0  1  2  3  4  5  0  1  2  3  4  5  10 
2  4  0  2  4  0  2  4  0  2  4  0  2  4  0  2  4  10  12  14  10  12  14  10  12  14  10  12  14  10  12  14  10  12  14  20 
3  0  3  0  3  0  3  0  3  0  3  10  13  10  13  10  13  10  13  10  13  10  13  20  23  20  23  20  23  20  23  20  23  20  23  30 
4  2  0  4  2  0  4  2  10  14  12  10  14  12  10  14  12  20  24  22  20  24  22  20  24  22  30  34  32  30  34  32  30  34  32  40 
5  4  3  2  1  0  5  14  13  12  11  10  15  14  23  22  21  20  25  24  23  32  31  30  35  34  33  32  41  40  45  44  43  42  41  50 
0  0  0  0  0  10  10  10  10  10  10  20  20  20  20  20  20  30  30  30  30  30  30  40  40  40  40  40  40  50  50  50  50  50  50  00 
1  2  3  4  5  10  11  12  13  14  25  20  21  22  23  34  35  30  31  32  43  44  45  40  41  52  53  54  55  50  01  02  03  04  05  10 
2  4  0  2  14  10  12  14  20  22  24  20  22  34  30  32  34  40  42  44  40  42  54  50  52  54  00  02  04  00  02  14  10  12  14  20 
3  0  3  10  13  10  13  20  23  20  23  30  33  30  33  40  43  40  43  50  53  50  53  00  03  00  03  10  13  10  13  20  23  20  23  30 
4  2  0  14  12  10  14  22  20  24  32  30  34  32  40  44  42  50  54  52  50  04  02  00  04  12  10  14  22  20  24  22  30  34  32  40 
5  4  3  12  11  10  25  24  23  32  31  30  35  44  43  42  51  50  55  04  03  02  11  10  15  14  23  22  21  30  35  34  43  42  41  50 
0  0  10  10  10  20  20  20  30  30  30  40  40  40  50  50  50  00  00  00  10  10  10  20  20  20  30  30  30  40  40  40  50  50  50  00 
1  2  13  14  15  20  21  22  33  34  35  40  41  52  53  54  05  00  01  12  13  14  25  20  31  32  33  44  45  40  51  52  53  04  05  10 
2  4  10  12  14  20  22  34  30  32  44  40  52  54  50  02  04  10  12  14  20  22  24  30  32  44  40  42  54  50  02  04  00  12  14  20 
3  0  13  10  23  20  23  30  33  40  43  50  53  50  03  00  13  10  13  20  23  30  33  40  43  40  53  50  03  00  03  10  13  20  23  30 
4  2  10  14  22  20  34  32  40  44  42  50  54  02  00  14  12  20  24  22  30  34  42  40  54  52  00  04  02  10  14  22  20  34  32  40 
5  4  13  12  21  20  35  34  43  42  51  50  05  04  13  12  21  20  25  34  33  42  41  50  55  04  03  12  11  20  25  34  33  42  41  50 
0  10  10  20  20  30  30  40  40  50  50  00  00  10  10  20  20  30  30  40  40  50  50  00  00  10  10  20  20  30  30  40  40  50  50  00 
1  12  13  24  25  30  31  42  43  54  55  00  01  12  13  24  25  30  41  42  53  54  05  00  11  12  23  24  35  30  41  42  53  54  05  10 
2  14  10  22  24  30  32  44  50  52  04  00  12  14  20  22  34  40  42  54  50  02  04  10  12  24  30  32  44  40  52  54  00  02  14  20 
3  10  13  20  23  30  43  40  53  50  03  10  13  20  23  30  33  40  53  50  03  00  13  20  23  30  33  40  43  50  03  00  13  10  23  30 
4  12  10  24  32  30  44  42  50  04  02  10  14  22  30  34  42  50  54  02  00  14  22  20  34  32  40  54  52  00  04  12  20  24  32  40 
5  14  13  22  31  30  45  54  53  02  11  10  25  24  33  42  41  50  05  04  13  22  21  30  35  44  53  52  01  10  15  24  33  32  41  50 
0  10  20  20  30  40  40  50  00  00  10  20  20  30  40  40  50  00  00  10  20  20  30  40  40  50  00  00  10  20  20  30  40  40  50  00 
1  12  23  24  35  40  41  52  03  04  15  20  31  32  43  54  55  00  11  12  23  34  35  40  51  02  03  14  25  20  31  42  43  54  05  10 
2  14  20  22  34  40  52  54  00  12  14  20  32  44  40  52  04  10  12  24  30  32  44  50  02  14  10  22  24  30  42  54  50  02  14  20 
3  10  23  30  33  40  53  00  03  10  23  30  33  40  53  00  03  10  23  30  33  40  53  00  03  10  23  30  33  40  53  00  03  10  23  30 
4  12  20  34  32  40  54  02  10  14  22  30  44  42  50  04  12  20  24  32  40  54  52  00  14  22  30  34  42  50  04  02  10  24  32  40 
5  14  23  32  41  40  55  04  13  22  21  30  45  54  03  02  11  20  35  44  43  52  01  10  25  24  33  42  51  00  05  14  23  32  41  50 
0  10  20  30  40  50  50  00  10  20  30  40  40  50  00  10  20  30  30  40  50  00  10  20  20  30  40  50  00  10  10  20  30  40  50  00 
1  12  23  34  45  50  01  02  13  24  35  40  51  02  03  14  25  30  41  52  03  04  15  20  31  42  53  04  05  10  21  32  43  54  05  10 
2  14  20  32  44  50  02  14  20  22  34  40  52  04  10  22  34  40  42  54  00  12  24  30  42  54  00  02  14  20  32  44  50  02  14  20 
3  10  23  30  43  50  03  10  23  30  43  50  53  00  13  20  33  40  53  00  13  20  33  40  43  50  03  10  23  30  43  50  03  10  23  30 
4  12  20  34  42  50  04  12  20  34  42  50  04  12  20  34  42  50  54  02  10  24  32  40  54  02  10  24  32  40  54  02  10  24  32  40 
5  14  23  32  41  50  05  14  23  32  41  50  05  14  23  32  41  50  05  14  23  32  41  50  05  14  23  32  41  50  05  14  23  32  41  50 
10  20  30  40  50  00  10  20  30  40  50  00  10  20  30  40  50  00  10  20  30  40  50  00  10  20  30  40  50  00  10  20  30  40  50  100 
Is this all correct? I haven't checked myself yet after making this up!
PS(to kode): I made yellow and green with slightly darker hues for better display

SenaryThe12thCasual Member
 Joined: Mar 1 2018, 02:03 PM
How did I miss this thread??? I obviously don't know how to use taptalk yet.
BTW Kodo, when I saw this guy's video and the section on which symbols to use started up, I was basically rolling around on the floor laughing. I can totally see how my post would bring up memories of this video.
W.R.T. this guys style, yeah, that's just how millenials make videos. Since time immemorial, every generation has used verbal style to differentiate itself from the previous generation. Our parents did it, we did it, and our kids do it. If you find it annoying, well, that's the whole point :)
BTW Kodo, when I saw this guy's video and the section on which symbols to use started up, I was basically rolling around on the floor laughing. I can totally see how my post would bring up memories of this video.
W.R.T. this guys style, yeah, that's just how millenials make videos. Since time immemorial, every generation has used verbal style to differentiate itself from the previous generation. Our parents did it, we did it, and our kids do it. If you find it annoying, well, that's the whole point :)

SenaryThe12thCasual Member
 Joined: Mar 1 2018, 02:03 PM
Sunny, I endorse, appreciate, applaud, and otherwise encourage any and all attempts to make senary more useful. But remember, some people are colorblind. Also, you'll want to be able to chisel a number into a block of marble or granite, and have it still readable 10,000 years from now, after all paint has inevitably worn off of the stone.
Maybe instead of different colors, using different fonts? Or numerals?
IDK, but there has to be some solution. This is the right problem to work on. It directly addresses the most cogent objections to using senary.
Maybe instead of different colors, using different fonts? Or numerals?
IDK, but there has to be some solution. This is the right problem to work on. It directly addresses the most cogent objections to using senary.

Double sharpDozens Demigod
 Joined: Sep 19 2015, 11:02 AM
Moving from dozenal to pure hexatrigesimal makes the multiplication table eight and a half times as big just so that we can write two digits for every three of dozenal and write 1/5 and 1/7 as singledigit but still recurring fractions. I highly doubt these advantages will ever manifest themselves because with a multiplication table that big, simple extrapolation suggests that kids are still learning it well into high school. Actually, I think that almost everyone would find it impossible to learn: there are so many products and, unlike learning a large vocabulary, there's not much in the way of clues when an answer is wrong. A misspelled word at least doesn't usually look like another word: a mistaken multiplication product looks like any other number with no clue as to what the right answer ought to be. (There are clues, but they only start to be obvious once you gain some number sense  which learning the multiplication table is part of.)
The crux of the matter is the size of the base36 multiplication table. If you never memorise all of it, you end up having to use senary methods to compose the parts you don't know on the fly, and the need to decompress and recompress makes it slower than pure senary. After all, if you're going to use senary, it's better to actually use senary than to make hexatrigesimal pretend to be senary. But if you do memorise all of it  leaving aside the question of whether most kids would be able to do this (I think not)  I have to wonder how much extra time is being wasted on the extra 588 products that could have been used to teach algebra, geometry, trigonometry, calculus, and then some. Mathematics is cumulative: we don't want to lose anybody at arithmetic, because that locks the door to everything else.
The crux of the matter is the size of the base36 multiplication table. If you never memorise all of it, you end up having to use senary methods to compose the parts you don't know on the fly, and the need to decompress and recompress makes it slower than pure senary. After all, if you're going to use senary, it's better to actually use senary than to make hexatrigesimal pretend to be senary. But if you do memorise all of it  leaving aside the question of whether most kids would be able to do this (I think not)  I have to wonder how much extra time is being wasted on the extra 588 products that could have been used to teach algebra, geometry, trigonometry, calculus, and then some. Mathematics is cumulative: we don't want to lose anybody at arithmetic, because that locks the door to everything else.

SenaryThe12thCasual Member
 Joined: Mar 1 2018, 02:03 PM
Alas, I must agree. Using base36 compression might solve the problem of memorizing large numbers. But it really doesn't touch the problem of having to keep more senary digits in your head at one time during calculations.Double sharp wrote: The crux of the matter is the size of the base36 multiplication table.
As I said in another thread, to get 'round this I just use the dodge suggested by arbiter of truth for visualizing senary numbers: imagine a 6x6x6 cubic volume, partially filled up with 1x1x1 cubes. Because we can subitize the numbers 0 through 5, this is quite easy to do.
What's more, it leapfrogs base36. base36 can only give you 2digits at a time. A partiallyfilled 6x6x6 volume gives you 3 senary digits. If you find this kind of mental visualization easy (YMMV, some people are verbal thinkers, some people are visual thinkers) its not so hard to visualilze the senary operations. Addition is just rearranging two piles into one pile (if there's no carry beyond 3 digits) or two piles (if there is). Multiplication and division are harder; you have to keep up to 4 piles in your head at once, which takes some practice.
If you are at all good at these kind of visualizations, with practice you can do operations on any two 3digit numbers in your head. And, lets face it, if you are using larger numbers, you'll probably just grab a pocket calculator and do the damn problem in decimal anyways.

arbiteroftruthRegular
 Joined: Feb 17 2013, 05:51 AM
The argument about concision of phone numbers, zip codes, etc, has never held water. The fact that we use numbers to categorize those things is totally arbitrary. They're just an organized system of labels, and it doesn't matter what set of characters you use. You can use numbers in whatever base you like, or alphanumerics (skipping I and O to avoid ambiguity), or polygonal shapes, or the names of past presidents, or pictures of animals ("give me a call sometime, you can reach me at dog frog cat, ant dog spider horse"). It doesn't matter; they're just arbitrary labels and have no bearing on what system we use for arithmetic and measurements. When was the last time you had to multiply two zip codes together?
The concision tradeoff is a mild concern in science and engineering, where you might have large tables of precise measurements and specifications. But 1) that can largely be addressed through font design. You could go as far as designing a set of d36 characters that are simply pairs of numerals side by side in a single character space, so even monospace fonts can compress the space without people needing to memorize hexatrigesimal digits. And 2) the upside of the smaller base is that the number of significant digits used is more meaningful. In science and engineering, if you're presenting things in decimal, choosing the number of significant digits to display amounts to rounding off the precision of the measurement to the nearest power of ten. In senary, you're only rounding off the precision to the nearest power of six, preserving more information.
The only aspect in which concision is a real problem is when you're talking about holding digits in your head during a mental calculation. But it's not an unsolvable problem. The solution that works at least for me is to use a nomenclature that pairs up the digits. After all, memorizing an arbitrary list of 7 letters isn't really more difficult than memorizing a list of 7 digits, even though there are more than twice as many letters in the alphabet as their are decimal digits. So for memory purposes, seeing pairs of numbers as single objects should help greatly. But you don't want it to be some complicated/arbitrary conversion that slows you down; it should just naturally be the name of the corresponding twodigit number. So in decimal, you might hold 5734 in memory as "fiftyseven thirtyfour" rather than as "five seven three four". The same can be done in senary. In my case, I go ahead and abuse the nomenclature and use decimal terminology like "thirtyfour", to dodge the issue of needing to familiarize myself with a new nomenclature, but whatever terminology is used, the principle is the same; you can use language to parse twodigit numbers as single objects in memory while still being able to instantly 'convert' it back to the individual digits as needed.
Lastly, there's the sheer number of operations you need to carry out when doing a long form multiplication. In the worst case scenario, there's no avoiding that. But in my experience playing around with senary, most of the time you can factor one number or the other into relatively small primes, and multiply by the factors in sequence, with each multiplication being a simple operation. x2 is just addition, x3 is a shiftandhalve, x5 is a shiftandsubtract, x7 is a shiftandadd. It starts to get a bit more complex from there, but still not bad. Every twodigit prime number in senary is just some multiple of 6 +/1, so any of them can be done as a onedigit multiplication followed by an addition or subtraction. So in almost any senary multiplication you'd actually want to do in your head, one number or the other can be factored into a sequence of simple multiplications, which you then perform on the other number. Yes, there's some overhead involved in that factorization process, but since senary makes it easy to spot divisibility by the first four primes, this step is usually pretty quick.
The concision tradeoff is a mild concern in science and engineering, where you might have large tables of precise measurements and specifications. But 1) that can largely be addressed through font design. You could go as far as designing a set of d36 characters that are simply pairs of numerals side by side in a single character space, so even monospace fonts can compress the space without people needing to memorize hexatrigesimal digits. And 2) the upside of the smaller base is that the number of significant digits used is more meaningful. In science and engineering, if you're presenting things in decimal, choosing the number of significant digits to display amounts to rounding off the precision of the measurement to the nearest power of ten. In senary, you're only rounding off the precision to the nearest power of six, preserving more information.
The only aspect in which concision is a real problem is when you're talking about holding digits in your head during a mental calculation. But it's not an unsolvable problem. The solution that works at least for me is to use a nomenclature that pairs up the digits. After all, memorizing an arbitrary list of 7 letters isn't really more difficult than memorizing a list of 7 digits, even though there are more than twice as many letters in the alphabet as their are decimal digits. So for memory purposes, seeing pairs of numbers as single objects should help greatly. But you don't want it to be some complicated/arbitrary conversion that slows you down; it should just naturally be the name of the corresponding twodigit number. So in decimal, you might hold 5734 in memory as "fiftyseven thirtyfour" rather than as "five seven three four". The same can be done in senary. In my case, I go ahead and abuse the nomenclature and use decimal terminology like "thirtyfour", to dodge the issue of needing to familiarize myself with a new nomenclature, but whatever terminology is used, the principle is the same; you can use language to parse twodigit numbers as single objects in memory while still being able to instantly 'convert' it back to the individual digits as needed.
Lastly, there's the sheer number of operations you need to carry out when doing a long form multiplication. In the worst case scenario, there's no avoiding that. But in my experience playing around with senary, most of the time you can factor one number or the other into relatively small primes, and multiply by the factors in sequence, with each multiplication being a simple operation. x2 is just addition, x3 is a shiftandhalve, x5 is a shiftandsubtract, x7 is a shiftandadd. It starts to get a bit more complex from there, but still not bad. Every twodigit prime number in senary is just some multiple of 6 +/1, so any of them can be done as a onedigit multiplication followed by an addition or subtraction. So in almost any senary multiplication you'd actually want to do in your head, one number or the other can be factored into a sequence of simple multiplications, which you then perform on the other number. Yes, there's some overhead involved in that factorization process, but since senary makes it easy to spot divisibility by the first four primes, this step is usually pretty quick.

SenaryThe12thCasual Member
 Joined: Mar 1 2018, 02:03 PM
ArbiterOfTruth, I'm so glad you weighed in here. I've been a big fan of yours for a long time. You have a remarkable combination of clearheaded thnking, so you know which direction to go, and enormous intellectual strength, so you can actually get there.arbiteroftruth wrote: When was the last time you had to multiply two zip codes together?
You are right, concision of zip codes, etc, is a red herring. We might spell these words using digits instead of letters, but they actually are not numbers at all. Grammatically, they are proper names. A zip code is just a proper name for a geographic region. Since they are not numbers, we can just a priori rule out all considerations of them. They are a different topic than the ones we are discussing, which are numbers and computation.
When I read this, my jaw dropped so far it hit my desk. YES! The solution to keeping stuff in your shortterm memory is always *chunking*. And just (ab)using decimal nomenclature is an inspired way to do this. Decimal nomenclature has been pounded into our skulls, so its natural to us, and it therefore saves valuable processing resources.In my case, I go ahead and abuse the nomenclature and use decimal terminology like "thirtyfour", to dodge the issue of needing to familiarize myself with a new nomenclature, but whatever terminology is used, the principle is the same; you can use language to parse twodigit numbers as single objects in memory while still being able to instantly 'convert' it back to the individual digits as needed.
I'm going to be thinking about this for a long time. As I said previously, I use your visualization methods for senary not just for visualizing the numbers, but to visualize the computations. The way I was doing multiplication required keeping track of 4 piles when multiplying 2 3digit number (one pile for each of the inputs, and two piles to accumulate the partial product).Every twodigit prime number in senary is just some multiple of 6 +/1, so any of them can be done as a onedigit multiplication followed by an addition or subtraction
But if we do multiplication along the lines you suggest above, we can reduce that to just 3 piles:
 choose whichever number is easier to factor into primes. Visualize that as the input pile.
 The other number becomes the output pile.
 pull a prime factor out of the input pile, and multiply the output pile by that number. You might need to add another pile, but you'll never have more than 2 piles of output.
 repeat until the input pile has nothing left to pull out.
With a few extra tricks, it might be possible to mentally multiply two 6digit senary numbers into a 12digit result in your head. We'd need two things, one of which you've already provided:
 A good way to generate the prime factorization of larger senary numbers, which you describe here allyourbasesbelongtosenaryt1026s24.html
 More advanced chunking techniques. I think you've planted a seed of an idea in my head for this; let me experiment around with it and see if I can get it to bear fruit......

KodegaduloObsessive poster
 Joined: Sep 10 2011, 11:27 PM
Using digitpair chunking as a memory aid when doing mental computations is a fine technique, as far as it goes. Whether you coopt decimal nomenclature and think of e.g. 2345_{6} as "twentythree, fortyfive", or adopt some constructed senary nomenclature and think of it as "twensenthree, foursenfive" or what have you, doesn't matter all that much, as long as it is reasonably convenient for you, personally.
But then, in such a circumstance, the only person you're talking to is .... yourself. Suppose on the other hand we're thinking about communicating numbers to other people. Moreover, suppose we're in an environment where, as I've long advocated, we want to accommodate potentially many bases that different people find useful, and actually use many bases ourselves, following an ethic of amicable coexistence. In that context, trying to stake out decimal nomenclature for your own favorite base is a provocation in violation of that ethic. It implies one of two things: Either you're asserting that your base is superior, and all other bases are to be suppressed in its favor, so it can take over mainstream language; or you're asserting that mainstream language is generic and must be qualified by always mentioning the base being used ... unless it happens to be your own favorite base, because you don't want to bother with the same awkward qualifications that you require of everyone else. In either case, way uncool. And actually rather foolish, since there is little chance of ever dislodging decimal as the mainstream default. Better instead to cook up a senary nomenclature for talking senary, a dozenal nomenclature for dozenal, an octal nomenclature for octal, and so forth, with no overlap between them, and just reserve decimal nomenclature for decimal.
But then, in such a circumstance, the only person you're talking to is .... yourself. Suppose on the other hand we're thinking about communicating numbers to other people. Moreover, suppose we're in an environment where, as I've long advocated, we want to accommodate potentially many bases that different people find useful, and actually use many bases ourselves, following an ethic of amicable coexistence. In that context, trying to stake out decimal nomenclature for your own favorite base is a provocation in violation of that ethic. It implies one of two things: Either you're asserting that your base is superior, and all other bases are to be suppressed in its favor, so it can take over mainstream language; or you're asserting that mainstream language is generic and must be qualified by always mentioning the base being used ... unless it happens to be your own favorite base, because you don't want to bother with the same awkward qualifications that you require of everyone else. In either case, way uncool. And actually rather foolish, since there is little chance of ever dislodging decimal as the mainstream default. Better instead to cook up a senary nomenclature for talking senary, a dozenal nomenclature for dozenal, an octal nomenclature for octal, and so forth, with no overlap between them, and just reserve decimal nomenclature for decimal.
As of 1202/03/01[z]=2018/03/01[d] I use:
ten,eleven = ↊↋, ᘔƐ, ӾƐ, XE or AB.
Baseneutral base annotations
Systematic Dozenal Nomenclature
Primel Metrology
Western encoding (not by choice)
Greasemonkey + Mathjax + PrimelDozenator
(Links to these and other useful topics are in my index post;
click on my user name and go to my "Website" link)
ten,eleven = ↊↋, ᘔƐ, ӾƐ, XE or AB.
Baseneutral base annotations
Systematic Dozenal Nomenclature
Primel Metrology
Western encoding (not by choice)
Greasemonkey + Mathjax + PrimelDozenator
(Links to these and other useful topics are in my index post;
click on my user name and go to my "Website" link)

arbiteroftruthRegular
 Joined: Feb 17 2013, 05:51 AM
Do whatever works best for you, especially if approaching things visually is helpful. For me though, I find it easier to start by fully converting one number into a list of instructions, and then apply those instructions to the other number, so that I'm only ever working with one number at a time. First I'm factoring one number, then I'm translating the factors into sequential multiplication instructions, then I'm multiplying one number, so at no point do I have to deal with both numbers at the same time.SenaryThe12th wrote: I'm going to be thinking about this for a long time. As I said previously, I use your visualization methods for senary not just for visualizing the numbers, but to visualize the computations. The way I was doing multiplication required keeping track of 4 piles when multiplying 2 3digit number (one pile for each of the inputs, and two piles to accumulate the partial product).
But if we do multiplication along the lines you suggest above, we can reduce that to just 3 piles:The cool thing about this is that the information you need to keep in your head is about the same from beginning to end; as the output piles grow bigger, the input pile shrinks. What's more, as it shrinks, it becomes easier and easier to pull out the next prime factor from it. This is fortunate, for at the same time the output pile is growing bigger, so its getting harder to multiply each additional prime factor. But that's ok because other parts of the computation are getting easier.
 choose whichever number is easier to factor into primes. Visualize that as the input pile.
 The other number becomes the output pile.
 pull a prime factor out of the input pile, and multiply the output pile by that number. You might need to add another pile, but you'll never have more than 2 piles of output.
 repeat until the input pile has nothing left to pull out.
Absolutely, completely agreed. My use of decimal here is not intended as a proposal for how to implement a senary society. It's only meant as the quickest and easiest way to test drive the principle. The 'real' way to do it would be to have a separate nomenclature for senary and use that for the chunking, but it takes time to train my brain to instantly associate something like "fifsenthree" with the digit pair '53'. It always becomes a noticeable translation effort between the terminology and the digits, which would artificially increase the difficulty of the multiplication when evaluating the feasibility of senary. But if we were in a senary society, we'd have a senary nomenclature which would be just as ingrained into my brain as decimal nomenclature is. So for the purposes of the test drive, I just use the terminology that my brain already instantly associates with the correct digits.Kodegadulo wrote: Using digitpair chunking as a memory aid when doing mental computations is a fine technique, as far as it goes. Whether you coopt decimal nomenclature and think of e.g. 2345_{6} as "twentythree, fortyfive", or adopt some constructed senary nomenclature and think of it as "twensenthree, foursenfive" or what have you, doesn't matter all that much, as long as it is reasonably convenient for you, personally.
But then, in such a circumstance, the only person you're talking to is .... yourself. Suppose on the other hand we're thinking about communicating numbers to other people. Moreover, suppose we're in an environment where, as I've long advocated, we want to accommodate potentially many bases that different people find useful, and actually use many bases ourselves, following an ethic of amicable coexistence. In that context, trying to stake out decimal nomenclature for your own favorite base is a provocation in violation of that ethic. It implies one of two things: Either you're asserting that your base is superior, and all other bases are to be suppressed in its favor, so it can take over mainstream language; or you're asserting that mainstream language is generic and must be qualified by always mentioning the base being used ... unless it happens to be your own favorite base, because you don't want to bother with the same awkward qualifications that you require of everyone else. In either case, way uncool. And actually rather foolish, since there is little chance of ever dislodging decimal as the mainstream default. Better instead to cook up a senary nomenclature for talking senary, a dozenal nomenclature for dozenal, an octal nomenclature for octal, and so forth, with no overlap between them, and just reserve decimal nomenclature for decimal.

SenaryThe12thCasual Member
 Joined: Mar 1 2018, 02:03 PM
arbiteroftruth wrote:Do whatever works best for you, especially if approaching things visually is helpful. For me though, I find it easier to start by fully converting one number into a list of instructions, and then apply those instructions to the other number, so that I'm only ever working with one number at a time. First I'm factoring one number, then I'm translating the factors into sequential multiplication instructions, then I'm multiplying one number, so at no point do I have to deal with both numbers at the same time.SenaryThe12th wrote: I'm going to be thinking about this for a long time. As I said previously, I use your visualization methods for senary not just for visualizing the numbers, but to visualize the computations. The way I was doing multiplication required keeping track of 4 piles when multiplying 2 3digit number (one pile for each of the inputs, and two piles to accumulate the partial product).
But if we do multiplication along the lines you suggest above, we can reduce that to just 3 piles:The cool thing about this is that the information you need to keep in your head is about the same from beginning to end; as the output piles grow bigger, the input pile shrinks. What's more, as it shrinks, it becomes easier and easier to pull out the next prime factor from it. This is fortunate, for at the same time the output pile is growing bigger, so its getting harder to multiply each additional prime factor. But that's ok because other parts of the computation are getting easier.
 choose whichever number is easier to factor into primes. Visualize that as the input pile.
 The other number becomes the output pile.
 pull a prime factor out of the input pile, and multiply the output pile by that number. You might need to add another pile, but you'll never have more than 2 piles of output.
 repeat until the input pile has nothing left to pull out.
Absolutely, completely agreed. My use of decimal here is not intended as a proposal for how to implement a senary society. It's only meant as the quickest and easiest way to test drive the principle. The 'real' way to do it would be to have a separate nomenclature for senary and use that for the chunking, but it takes time to train my brain to instantly associate something like "fifsenthree" with the digit pair '53'. It always becomes a noticeable translation effort between the terminology and the digits, which would artificially increase the difficulty of the multiplication when evaluating the feasibility of senary. But if we were in a senary society, we'd have a senary nomenclature which would be just as ingrained into my brain as decimal nomenclature is. So for the purposes of the test drive, I just use the terminology that my brain already instantly associates with the correct digits.Kodegadulo wrote: Using digitpair chunking as a memory aid when doing mental computations is a fine technique, as far as it goes. Whether you coopt decimal nomenclature and think of e.g. 2345_{6} as "twentythree, fortyfive", or adopt some constructed senary nomenclature and think of it as "twensenthree, foursenfive" or what have you, doesn't matter all that much, as long as it is reasonably convenient for you, personally.
But then, in such a circumstance, the only person you're talking to is .... yourself. Suppose on the other hand we're thinking about communicating numbers to other people. Moreover, suppose we're in an environment where, as I've long advocated, we want to accommodate potentially many bases that different people find useful, and actually use many bases ourselves, following an ethic of amicable coexistence. In that context, trying to stake out decimal nomenclature for your own favorite base is a provocation in violation of that ethic. It implies one of two things: Either you're asserting that your base is superior, and all other bases are to be suppressed in its favor, so it can take over mainstream language; or you're asserting that mainstream language is generic and must be qualified by always mentioning the base being used ... unless it happens to be your own favorite base, because you don't want to bother with the same awkward qualifications that you require of everyone else. In either case, way uncool. And actually rather foolish, since there is little chance of ever dislodging decimal as the mainstream default. Better instead to cook up a senary nomenclature for talking senary, a dozenal nomenclature for dozenal, an octal nomenclature for octal, and so forth, with no overlap between them, and just reserve decimal nomenclature for decimal.

SenaryThe12thCasual Member
 Joined: Mar 1 2018, 02:03 PM
Fascinating. How do you remember the instructions? I can imagine a list of prime factors which would be even harder to remember than the original number (e.g. 4114 = 2*5*11*21), let alone remembering those after translating them into instructions.. do you have a cool technique? Or do you just find it easy?arbiteroftruth wrote:Do whatever works best for you, especially if approaching things visually is helpful. For me though, I find it easier to start by fully converting one number into a list of instructions, and then apply those instructions to the other number, so that I'm only ever working with one number at a time. First I'm factoring one number, then I'm translating the factors into sequential multiplication instructions, then I'm multiplying one number, so at no point do I have to deal with both numbers at the same time.

KodegaduloObsessive poster
 Joined: Sep 10 2011, 11:27 PM
Not so fast. The choice to construct identifiers from numerals as opposed to other symbols is by no means trivial. The fact that one can make a connection between any two phone lines using nothing more than a numeric keypad (or an oldstyle rotary dial) is not an insignificant design choice. That choice allowed the planners and maintainers of systems like zip codes and telephone numbers to use their number sense to instantly know, for instance, that a telephone exchange can accommodate up to ten thousand lines, that an area code can accommodate up to a thousand exchanges or ten million lines, that the country can accommodate up to a thousand area codes, a million exchanges, and ten billion individual lines. (A similar case can be made for the zip system being able to accommodate up to a hundred states/regions, each accommodating up to a thousand post offices.) Someone maintaining a switching system and trying to assess the cost of an outage, the amounts of resources to mobilize to fix it, and so forth, will most definitely be doing mental math based on telephone numbers, and will be acutely aware of the magnitudes involved depending on whether the outage is at the exchange level or the area code level or whatever. And these are by no means the only applications for numerals as identifiers.arbiteroftruth wrote: The argument about concision of phone numbers, zip codes, etc, has never held water. The fact that we use numbers to categorize those things is totally arbitrary. They're just an organized system of labels, and it doesn't matter what set of characters you use. You can use numbers in whatever base you like, or alphanumerics (skipping I and O to avoid ambiguity), or polygonal shapes, or the names of past presidents, or pictures of animals ("give me a call sometime, you can reach me at dog frog cat, ant dog spider horse"). It doesn't matter; they're just arbitrary labels and have no bearing on what system we use for arithmetic and measurements. When was the last time you had to multiply two zip codes together?
That sort of calculation becomes harder to do if we must resort to some number base other than one we may habitually use for arithmetic. Or for that matter, some alphanumeric encoding morally equivalent to a number base. Or worse yet, some SesameStreet zoologicalemoji encoding frivolously equivalent to a number base. Not to mention what it would have cost during the past biquennium to equip customers with bulky handsets that look more like typewriters (with or without circus animals on the keys), given the state of technology before microprocessors and touchscreen mobile phones.
If you are trying to advocate for senary as a "civilizational" base (one which people can habitually use for arithmetic), then it does not do much for your case to brush off this concision issue by saying "oh, you can just use another base when you need numeral concision". The very next question people are bound to ask is, "well then, why don't we just use that base for arithmetic too? Why bother investing time to learn your senary, if we're just going to have to learn some other base anyway?"
Using what Unicode slots? 0 through 9 plus A through Z? Reinterpreted by a special font depicting senarydigraphligature glyphs? It seems that Ma Bell would have had to produce telephone sets with full alphanumeric keyboards from the start. Or we would need software (or more complicated gearing on those rotary phones) to interpret pairs of keystrokes/dials  making the entry task for humans a bit more complicated. (I mean, do we always have to do an even number of senary digits, with leading zeroes if necessary, so they can be paired into one of 3 dozen ligatures?)arbiteroftruth wrote:The concision tradeoff is a mild concern in science and engineering, where you might have large tables of precise measurements and specifications. But 1) that can largely be addressed through font design. You could go as far as designing a set of d36 characters that are simply pairs of numerals side by side in a single character space, so even monospace fonts can compress the space without people needing to memorize hexatrigesimal digits.
Wait a twinkling! I think you've got that backwards. The larger the base, the more precision you get per digit of mantissa. The smaller the base, the less precision, per digit of mantissa.arbiteroftruth wrote:And 2) the upside of the smaller base is that the number of significant digits used is more meaningful. In science and engineering, if you're presenting things in decimal, choosing the number of significant digits to display amounts to rounding off the precision of the measurement to the nearest power of ten. In senary, you're only rounding off the precision to the nearest power of six, preserving more information.
Let me demonstrate by comparing dozenal timeofday in Primel (′) units, versus senary timeofday in Oschkar's AshAshtrian (✶) units: Suppose the time is 5:26:40_{d} P.M. = .888_{z} days = .421_{6} days. (I've deliberately contrived to use a time that happens to come out to exactly the same number of digits in dozenal and senary.) Now, let's take those one digit at a time:
.8??_{z} days indicates sometime between 4:00:00_{d} P.M. and 6:00:00_{d} P.M. That is, one digit of dozenal narrows the time down to the nearest ′dwell (2 hours).
.4??_{6} days indicates sometime between 4:00:00_{d} P.M. and 8:00:00_{d} P.M. That is, one digit of senary narrows the time down to the nearest ✶watch (4 hours). Dozenal is twice as precise at this level.
.88?_{z} days indicates sometime between 5:20:00_{d} P.M. and 5:30:00_{d} P.M. That is, two digits of dozenal narrows the time down to the nearest ′breather (10_{d} minutes).
.42?_{6} days indicates sometime between 5:20:00_{d} P.M. and 6:00:00_{d} P.M. That is, two digits of senary narrows the time down to the nearest ✶gong (40_{d} minutes). Dozenal is four times as precise at this level.
.888?_{z} days indicates sometime between 5:26:40_{d} P.M. and 5:27:30_{d} P.M. That is, three digits of dozenal narrows the time down to the nearest ′trice (50_{d} seconds).
.421?_{6} days indicates sometime between 5:26:40_{d} P.M. and 5:33:20_{d} P.M. That is, three digits of senary narrows the time down to the nearest ✶block (6 minutes and 40_{d} seconds). Dozenal is eight times as precise at this level.
At four digits, dozenal is 14_{z} times more precise than senary. At five digits, it's 28_{z} times. At six, 54_{z} times. Generalizing, at N digits of mantissa, dozenal is 2^{N} times more precise than senary.
As of 1202/03/01[z]=2018/03/01[d] I use:
ten,eleven = ↊↋, ᘔƐ, ӾƐ, XE or AB.
Baseneutral base annotations
Systematic Dozenal Nomenclature
Primel Metrology
Western encoding (not by choice)
Greasemonkey + Mathjax + PrimelDozenator
(Links to these and other useful topics are in my index post;
click on my user name and go to my "Website" link)
ten,eleven = ↊↋, ᘔƐ, ӾƐ, XE or AB.
Baseneutral base annotations
Systematic Dozenal Nomenclature
Primel Metrology
Western encoding (not by choice)
Greasemonkey + Mathjax + PrimelDozenator
(Links to these and other useful topics are in my index post;
click on my user name and go to my "Website" link)

Double sharpDozens Demigod
 Joined: Sep 19 2015, 11:02 AM
I think what arbiteroftruth means is that the smaller the base, the more control you have over what level of precision you have. This is easiest to see when the large base is a perfect power of the small base: in hexadecimal, rounding to each significant figure lets you round to the nearest 1/16, 1/256, and so on, but in binary, doing so lets you round to intermediate levels of precision like 1/2, 1/4, 1/8, 1/16, 1/32, 1/64, 1/128, 1/256, and so on.
Nevertheless, you can get around this simply enough by simply writing the uncertainty explicitly. One can just write "65.38(2)" to mean 65.38 ± 0.02 (this is the atomic weight of zinc, incidentally), and now you immediately have a level of precision intermediate between "to the nearest hundredth" and "to the nearest tenth".
Nevertheless, you can get around this simply enough by simply writing the uncertainty explicitly. One can just write "65.38(2)" to mean 65.38 ± 0.02 (this is the atomic weight of zinc, incidentally), and now you immediately have a level of precision intermediate between "to the nearest hundredth" and "to the nearest tenth".

KodegaduloObsessive poster
 Joined: Sep 10 2011, 11:27 PM
Very well, then, let's compare this using the same time examples I used before.Double sharp wrote: I think what arbiteroftruth means is that the smaller the base, the more control you have over what level of precision you have. This is easiest to see when the large base is a perfect power of the small base: in hexadecimal, rounding to each significant figure lets you round to the nearest 1/16, 1/256, and so on, but in binary, doing so lets you round to intermediate levels of precision like 1/2, 1/4, 1/8, 1/16, 1/32, 1/64, 1/128, 1/256, and so on.
Nevertheless, you can get around this simply enough by simply writing the uncertainty explicitly. One can just write "65.38(2)" to mean 65.38 ± 0.02 (this is the atomic weight of zinc, incidentally), and now you immediately have a level of precision intermediate between "to the nearest hundredth" and "to the nearest tenth".
On the one hand, we have a threedigit senary time, expressed down to the AshAshtrian ✶block, with a measurement error of 1 ✶block = .001_{6} day, which we shorthand as .421(1)_{6} day. To translate that into dozenal, note that 1 ✶block = 8 ′trices = .008_{z} day. So the equivalent dozenal timeanderror would be expressed as .888(8)_{z} day.
On the other hand, we have a threedigit dozenal time, expressed down to the Primel ′trice, with an error of 1 ′trice = .001_{z} day, which we shorthand as .888(1)_{z} day. To translate that into senary, note that 1 ′trice = 3/4 ✶moment = .43_{6} ✶moment = .000043_{6} day. So the equivalent senary timeanderror would be expressed as .421000(43)_{6} day.
So, sure, because of the shorter steps between orders of magnitude, senary allows rounding error to be expressed in a more finelydetailed way. Unfortunately, because of its lack of concision, senary requires rounding error to be expressed in a more finelydetailed  and hence verbose  way.
P.S. Just for comparison, if we use base 6^{2}=Ω, here's how the above numbers look with trinilial (hexatrigesimal) compression:
.888(8)_{z} = .421(1)_{6} = .4210(10)_{6} = .Q6(6)_{Ω} = .421000(1000)_{6} = .Q60(60)_{Ω} 
.888(1)_{z} = .421000(43)_{6} = .Q60(R)_{Ω} 
As of 1202/03/01[z]=2018/03/01[d] I use:
ten,eleven = ↊↋, ᘔƐ, ӾƐ, XE or AB.
Baseneutral base annotations
Systematic Dozenal Nomenclature
Primel Metrology
Western encoding (not by choice)
Greasemonkey + Mathjax + PrimelDozenator
(Links to these and other useful topics are in my index post;
click on my user name and go to my "Website" link)
ten,eleven = ↊↋, ᘔƐ, ӾƐ, XE or AB.
Baseneutral base annotations
Systematic Dozenal Nomenclature
Primel Metrology
Western encoding (not by choice)
Greasemonkey + Mathjax + PrimelDozenator
(Links to these and other useful topics are in my index post;
click on my user name and go to my "Website" link)

KodegaduloObsessive poster
 Joined: Sep 10 2011, 11:27 PM
Just a little experiment:
hundred = 10^{2}
googol = 10^{102}
googolplex = 10^{10102}
Wow, so Tapatalk not only supports adscripts, but adcripts on adscripts as well!
So that means we can do:
Ω = 6^{2} = 30_{z} = 36_{d}
Q60(R)_{Ω} = 42'10'00(43)_{62} = 22'06'00(23)_{30z} = 26'06'00(27)_{36d}
And thus we can express trinilial in any of the following ways:
hundred = 10^{2}
googol = 10^{102}
googolplex = 10^{10102}
Wow, so Tapatalk not only supports adscripts, but adcripts on adscripts as well!
So that means we can do:
Ω = 6^{2} = 30_{z} = 36_{d}
Q60(R)_{Ω} = 42'10'00(43)_{62} = 22'06'00(23)_{30z} = 26'06'00(27)_{36d}
And thus we can express trinilial in any of the following ways:
 Ω: base "om", or "omega", or the "alphanumeric" base, a simple base using 3 dozen separate symbols
 6^{2}: base "nif", or "six squared", a (degenerate) bicomposite superbase (degenerate because both subbases are the same)
 30_{z}: base "trinilial", or "dozenallyencoded base threedozen"
 36_{d}: base "hexatrigesimal", or "decimallyencoded base thirtysix"
As of 1202/03/01[z]=2018/03/01[d] I use:
ten,eleven = ↊↋, ᘔƐ, ӾƐ, XE or AB.
Baseneutral base annotations
Systematic Dozenal Nomenclature
Primel Metrology
Western encoding (not by choice)
Greasemonkey + Mathjax + PrimelDozenator
(Links to these and other useful topics are in my index post;
click on my user name and go to my "Website" link)
ten,eleven = ↊↋, ᘔƐ, ӾƐ, XE or AB.
Baseneutral base annotations
Systematic Dozenal Nomenclature
Primel Metrology
Western encoding (not by choice)
Greasemonkey + Mathjax + PrimelDozenator
(Links to these and other useful topics are in my index post;
click on my user name and go to my "Website" link)

KodegaduloObsessive poster
 Joined: Sep 10 2011, 11:27 PM
Of course, this isn't an exhaustive list. For instance, #3 can be reinterpreted as an alternating ternaryondozenal (3×z) bicomposite base:Kodegadulo wrote: Ω = 6^{2} = 30_{z} = 36_{d}
Q60(R)_{Ω} = 42'10'00(43)_{62} = 22'06'00(23)_{30z} = 26'06'00(27)_{36d}
And thus we can express trinilial in any of the following ways:
 Ω: base "om", or "omega", or the "alphanumeric" base, a simple base using 3 dozen separate symbols
 6^{2}: base "nif", or "six squared", a (degenerate) bicomposite superbase (degenerate because both subbases are the same)
 30_{z}: base "trinilial", or "dozenallyencoded base threedozen"
 36_{d}: base "hexatrigesimal", or "decimallyencoded base thirtysix"
22'06'00(23)_{30z} = 22'06'00(23)_{3×z}
In either case, the top subdigit is limited to ternary values from 0 to 2, the bottom subdigit to dozenal values from 0 through Ɛ.
Likewise, #2 could be reinterpreted as senaryencoded "nif" base:
42'10'00(43)_{62} = 42'10'00(43)_{1006}
In either case, it's still degenerate, because it's really just senary with some syntactic windowdressing.
#4 can't be reinterpreted as a bicomposite quadralondecimal (4×d) because ten is coprime with threedozen. Base 36_{d} only allows superdigits 00_{36d} through 35_{36d}. Whereas base 4×d would be base "forty", and allow superdigits 36_{4×d} through 39_{4×d} as well.
As of 1202/03/01[z]=2018/03/01[d] I use:
ten,eleven = ↊↋, ᘔƐ, ӾƐ, XE or AB.
Baseneutral base annotations
Systematic Dozenal Nomenclature
Primel Metrology
Western encoding (not by choice)
Greasemonkey + Mathjax + PrimelDozenator
(Links to these and other useful topics are in my index post;
click on my user name and go to my "Website" link)
ten,eleven = ↊↋, ᘔƐ, ӾƐ, XE or AB.
Baseneutral base annotations
Systematic Dozenal Nomenclature
Primel Metrology
Western encoding (not by choice)
Greasemonkey + Mathjax + PrimelDozenator
(Links to these and other useful topics are in my index post;
click on my user name and go to my "Website" link)

arbiteroftruthRegular
 Joined: Feb 17 2013, 05:51 AM
So, 4114 is a good example of a number that's not a good candidate for factoring. In that situation, I'd consider factoring the other number in the multiplication instead. If the other number is just as bad, then you're in one of the rare cases where Stevinian arithmetic is going to be easier on the memory. Especially in the case of 4114, where you only use two unique digits, and one of them is 1.SenaryThe12th wrote: Fascinating. How do you remember the instructions? I can imagine a list of prime factors which would be even harder to remember than the original number (e.g. 4114 = 2*5*11*21), let alone remembering those after translating them into instructions.. do you have a cool technique? Or do you just find it easy?
In a senary society, you'd still want to teach the Stevinian method first, as the straightforward universal method that always works. But you'd also want to teach factoring as a method that's more efficient (for senary) in most cases.
Consider US license plates. They are alphanumeric, and people have no trouble understanding them. Does that mean we have learned hexatrigesimal?Kodegadulo wrote:
If you are trying to advocate for senary as a "civilizational" base (one which people can habitually use for arithmetic), then it does not do much for your case to brush off this concision issue by saying "oh, you can just use another base when you need numeral concision". The very next question people are bound to ask is, "well then, why don't we just use that base for arithmetic too? Why bother investing time to learn your senary, if we're just going to have to learn some other base anyway?"
When we're just talking about an organized system of labels, all that matters is for people to know the character set. They don't have to do arithmetic with them, nor do they even need to know what order they come in. It's not even remotely the same thing as genuinely learning a new base.
As for why use different 'bases' for arithmetic and labeling, that's simple. The needs are different. In a use case that needs concise, arbitrary labels, and doesn't need arithmetic, the optimal 'base' depends solely on how many distinct characters people can easily parse as part of a single character set. When you talk about a base for arithmetic, many other factors come into play. Sometimes different problems have different solutions, and it's misguided to try to shoehorn the solution from one problem onto the other.
Since I wasn't talking about phone numbers at that point, but about scientific measurements, Ma Bell is irrelevant here.Kodegadulo wrote:
Using what Unicode slots? 0 through 9 plus A through Z? Reinterpreted by a special font depicting senarydigraphligature glyphs? It seems that Ma Bell would have had to produce telephone sets with full alphanumeric keyboards from the start.
As for Unicode, just use the existing characters for 05 with zerowidth joiners. You'd just need a font that supports joined forms of the digits, and a plugin that automatically inserts a zerowidth joiner before a typed digit. The joiner character takes up no space on its own, so this shouldn't visibly affect any fonts that wouldn't support it.