The Higher Natural Scale

OschkarDozens Disciple
 Joined: Nov 19 2011, 01:07 AM
It has been pretty much established that the bases within the human scale can be set at {(6), 8, 10, 12, 14}. I’m now interested in the next tier of bases, that scale where memorizing full multiplication tables is too burdensome for most people, but using something like subbase encoding or complementary divisors is too inefficient to keep up with the human scale. I named this range the “higher natural scale” in one of my posts in 2012, back when I thought that it could somehow be possible for a civilization to use a base at about this range without hesitation. I no longer believe any bases at twice the human scale can have any widespread use, but I don’t like calling it the “mid scale”, because that suggests the realm of subbases, complementary divisors and alternating arithmetic, where {60, 84, 120} reign supreme. So I’m going to keep calling it the “higher natural scale” with the caveat that I’m not assuming it to be part of the human scale, but something completely different.
There’s a stairway at my university that goes uphill towards the management and acounting faculties. Its tread length is about 1.1 metres (3.5 feet) per step, too long for me to comfortably step once on each stair, but too short to take two strides. I usually take a running start and try to climb them faster than normal, or alternate between one and two strides, but they’re still awkward, and I’ve tripped multiple times on them. The higher natural scale reminds me of this stairway: these bases are too large to use a single digit per place, but too small to use two.
The limits of the higher natural scale must be somewhat fuzzy. Its lower boundary should probably be set at {16}, the first base that requires help from something other than Stevinian arithmetic. The upper boundary is somewhat debatable, but I’ll set it at {36}, because it’s the square of 6, the largest number without any opaque totatives.
The numbers between 16 and 36 inclusive can be sorted by their prime signature and number of divisors:[list]
[*] The primes, {17, 19, 23, 29, 31}, have 2 divisors, 1 and themselves.
[*] The only square of a prime in this range is {25}. It has 3 divisors.
[*] The semiprimes, {21, 22, 26, 33, 34, 35}, and the only cube of a prime, {27}, have 4 divisors.
[*] {16} is the only fourth power of a prime at this scale, with 5 divisors.
[*] The products of a prime by the square of another prime, {18, 20, 28}, and the only fifth power in this range, {32}, have 6 divisors.
[*] {24} is the product of a prime by the cube of a different prime, and {30} is the product of three distinct primes. They both have 8 divisors.
[*] {36} is the product of the squares of two primes, and as such, has 9 divisors.
[/list]Anything with four or fewer divisors at this scale is probably unsuitable for general computation and should best be left alone, though {21, 34} in particular have excellent primesieving abilities. This removes all odd bases from consideration, together with the even semiprimes {22, 26, 34}, which contain large and essentially useless primes in their factorizations.
We are left with {16, 18, 20, 24, 28, 30, 32, 36} to try to wrangle. These bases are all multiples of either 4 or 6. On the one hand, except for {16}, they are clearly not in the human scale. On the other hand, they don’t seem too alien for human thinking, especially because one of them, {20}, was continuously employed by the civilizations of Mesoamerica for centuries. So, in this thread, I’ll try to determine not if these bases could be treated as if they were in the human scale, but what methods a modern society that ended up with these bases could use to calculate, and whether these methods could ever be as efficient as Stevinian arithmetic.
At first glance, it looks like there’s no one single method that can be used for all of these bases. The human scale bases can use Stevinian arithmetic, the lower midscale bases can use reciprocal divisors, and the higher midscale have alternating arithmetic to help them out. But the bases in the higher natural scale don’t seem to share methods of computation, and it seems that each base here has its own personality:
[list]
[*] {16, 32} are binary powers, and should best pretend to be binary,
[*] {18} is unbalanced and distant, though still 3smooth and divisible enough to make it on the list,
[*] {24} tries to solve the main issue with dozenal by putting two powers of 5 in the alpha,
[*] {36} is the senary “hundred”, and as such, inherits all of senary’s strengths at a larger scale,
[*] {20} is naturally found on the human body as the total number of a person’s fingers and toes,
[*] {28} is its septenary analogue, the number of phalanges on both hands,
[*] {30} is threedimensional and full of regulars, though not very deep.
[/list]
In the meantime, I’ll show here the digit maps of the bases I’m going to cover.

Double sharpDozens Demigod
 Joined: Sep 19 2015, 11:02 AM
I'd personally have thought of the classification as more binary, so that you'd have tiers {2, 3} "trivial", {47} "small", {812, 14, 15} "human", {16, 18, 20, 24, 28, 30} "superhuman or alternating small", {32, 36, 40, 42, 48, 56, 60} "CDM or alternating smallhuman", {64, 70, 72, 80, 84, 90, 96, 108, 112, 120} "alternating humanscale", {168, 180, 192, 210, 216, 240, 252} "alternating humansuperhuman", {336, 360, 420, 504} "alternating superhuman / smallsmallhuman", etc.
I think I can imagine the eventual conclusion that only {16} is really as efficient as a base as the humanscale {8, 10, 12, 14} among the superhuman scale, along with perhaps {6} in the small scale. I would further exclude both {6, 16} as the base is a technology that must be used by everyone, and borderline cases should be unacceptable.
But I eagerly await your elucidations on methods! I only went a little into this range because, as you say, it seems to be too large to walk and too small to run, and today I'm really not a fan of the running bases because tripping is too common.
I think I can imagine the eventual conclusion that only {16} is really as efficient as a base as the humanscale {8, 10, 12, 14} among the superhuman scale, along with perhaps {6} in the small scale. I would further exclude both {6, 16} as the base is a technology that must be used by everyone, and borderline cases should be unacceptable.
But I eagerly await your elucidations on methods! I only went a little into this range because, as you say, it seems to be too large to walk and too small to run, and today I'm really not a fan of the running bases because tripping is too common.

wendy.krieger
The digital arithmetic as taught, is good for bases from about eight to eighteen. Six is too much numberpushing to be effective.
You could handle something up to 30 or so, if you used a subbase, and a DD style table.
Bases like 30 and 36, i found too big for digital arithmetic, and too small for alternating arithmetic.
Alternating arithmetic works well over the product of digital arithmetic, eg 8*10 or 12*15. 36 is too small, and generally i find the likes of 14*15 or 12*18 is pushing friendship here.
I have done things like crisscross arithmetic in twelfty, but it needs a sharper mind, or a mind trained in this art. I normally rely on other mental arithmetic tricks, like adjacent numbers, and divisionformultiply tricks.
Added arithmetic (where 301 is 300 (1+1/300) ) works quite well, since much of the arithmetic can be simplified. So for example, pi is 3 1/8 1/60, and pi times 113 is 339 + 14 1/8 + 1 53/60 = 355 0/60 1/2.
You could handle something up to 30 or so, if you used a subbase, and a DD style table.
Bases like 30 and 36, i found too big for digital arithmetic, and too small for alternating arithmetic.
Alternating arithmetic works well over the product of digital arithmetic, eg 8*10 or 12*15. 36 is too small, and generally i find the likes of 14*15 or 12*18 is pushing friendship here.
I have done things like crisscross arithmetic in twelfty, but it needs a sharper mind, or a mind trained in this art. I normally rely on other mental arithmetic tricks, like adjacent numbers, and divisionformultiply tricks.
Added arithmetic (where 301 is 300 (1+1/300) ) works quite well, since much of the arithmetic can be simplified. So for example, pi is 3 1/8 1/60, and pi times 113 is 339 + 14 1/8 + 1 53/60 = 355 0/60 1/2.

Double sharpDozens Demigod
 Joined: Sep 19 2015, 11:02 AM
I agree about 6, though not about 16 or 18 (or indeed 20). These at the low end may be usable by the exceptional, and certainly can be comprehended the way we do {8, 10, 12, 14}, but remember that the base is supposed to be used by the general population. Surely that, if anything, is the most important limit, not our own personal abilities (which may be wider!), since everyone needs to count and do basic arithmetic.
Sometimes I even think that tetradecimal has a problem because the factor of 7 is not subitisable like 5 is, so that rulers get more difficult to read. Still, this doesn't make the base unusable, it just makes it even worse than it already is. {10, 12} are about equal (the larger size of the tables for 12 are roughly compensated by the increased number of patterns, even if they're not actually made easier than the decimal tables), with {8} even easier than both (though if you want to have the natural prime factors {2, 3, 5} that commonly arise in mathematics all covered well, decimal is the best of the three).
Oh, and congratulations for octal 4000 posts!
Sometimes I even think that tetradecimal has a problem because the factor of 7 is not subitisable like 5 is, so that rulers get more difficult to read. Still, this doesn't make the base unusable, it just makes it even worse than it already is. {10, 12} are about equal (the larger size of the tables for 12 are roughly compensated by the increased number of patterns, even if they're not actually made easier than the decimal tables), with {8} even easier than both (though if you want to have the natural prime factors {2, 3, 5} that commonly arise in mathematics all covered well, decimal is the best of the three).
Oh, and congratulations for octal 4000 posts!

OschkarDozens Disciple
 Joined: Nov 19 2011, 01:07 AM
I don't know. Base 36 is essentially compressed senary after all, and I have some preliminary ideas about {20, 24} that may help their efficiency, though I don't know whether they would be enough to fix them on a civilizational level.Double sharp @ Dec 6 2016, 09:11 AM wrote: I think I can imagine the eventual conclusion that only {16} is really as efficient as a base as the humanscale {8, 10, 12, 14} among the superhuman scale, along with perhaps {6} in the small scale. I would further exclude both {6, 16} as the base is a technology that must be used by everyone, and borderline cases should be unacceptable.
I know that vigesimal can be civilizational, because it was. However, I'm still doubting that it could be adapted to our presentday civilization without an inordinate amount of difficulty. As for tetravigesimal, well, its multiplication table is so richly patterned that whatever works for 20 can be adapted to 24 without too much additional effort.
I'll evaluate {16, 32} first, then {20, 24, 28}, then {18, 30, 36} at the end.

Double sharpDozens Demigod
 Joined: Sep 19 2015, 11:02 AM
The Binary Bases
Since Oschkar hasn't continued here yet, here are a few thoughts from me  strictly qualitative, so I'm not going to even use my trademark 'number of operations per product' metric.
Hexadecimal can easily be thought of as a compression of binary. Indeed, that is what it is used for today.
The digits can be seen as binary fractions of a whole, which facilitates memorising the roll table. Thus b is 11/16, and double it must be 11/8 = 1 3/8, which is 16. Similarly, this gives five tiers of binary saturation of a digit: {0}, {8}, {4, c}, {2, 6, a, e}, {1, 3, 5, 7, 9, b, d, f}. This fraction sense also facilitates adding. It's clear that 9+4 adds a quarter and must be d. The roll table thus has only 32 entries, 8 for the eight odd digits and four for the singleton, double, quadruple, and octuple.
Of course, some thinking must be used. You wouldn't split ff additively, but rather subtractively as 1001. Still, this method seems efficient enough to make hexadecimal on par with {615} among the humanunderstandable bases. The issue I see is that teaching it means that you have to introduce rationals before naturals, which seems to go against the order numbers are usually acquired...
Duotrigesimal has more of a problem here. It adds a sixth class and a further binary subdivision in the levels {0}, {g}, {8, o}, {4, c, k, s}, {2, 6, a, e, i, m, q, u}, {1, 3, 5, 7, 9, b, d, f, h, j, l, n, p, r, t, v}. I think this is entirely too many digits without mitigation by bitwise representations of digits, except that then 5 bits stacked on a string make it difficult to distinguish 16+8+1, 16+4+1, and 16+2+1.
Even worse, there are now 16*5=80 facts in the roll table, and they are all a mindless jumble of totative static. I think this accords with how the larger a base is, the more baroque procedures you must invent to keep it fruitful, and even then its quality of life is not as great as the range from octal to tetradecimal inclusive.
I would also note that this sort of splitting makes both bases little better than binary in speed, only saved somewhat because you don't go crosseyed distinguishing 110110101101001 from 11011011010101001. Though, given that hexadecimal may need bitwise digits and duotrigesimal quite definitely does, we appear to be saddled with the same problem unless we can handle 16 easily.
Since Oschkar hasn't continued here yet, here are a few thoughts from me  strictly qualitative, so I'm not going to even use my trademark 'number of operations per product' metric.
Hexadecimal can easily be thought of as a compression of binary. Indeed, that is what it is used for today.
The digits can be seen as binary fractions of a whole, which facilitates memorising the roll table. Thus b is 11/16, and double it must be 11/8 = 1 3/8, which is 16. Similarly, this gives five tiers of binary saturation of a digit: {0}, {8}, {4, c}, {2, 6, a, e}, {1, 3, 5, 7, 9, b, d, f}. This fraction sense also facilitates adding. It's clear that 9+4 adds a quarter and must be d. The roll table thus has only 32 entries, 8 for the eight odd digits and four for the singleton, double, quadruple, and octuple.
Of course, some thinking must be used. You wouldn't split ff additively, but rather subtractively as 1001. Still, this method seems efficient enough to make hexadecimal on par with {615} among the humanunderstandable bases. The issue I see is that teaching it means that you have to introduce rationals before naturals, which seems to go against the order numbers are usually acquired...
Duotrigesimal has more of a problem here. It adds a sixth class and a further binary subdivision in the levels {0}, {g}, {8, o}, {4, c, k, s}, {2, 6, a, e, i, m, q, u}, {1, 3, 5, 7, 9, b, d, f, h, j, l, n, p, r, t, v}. I think this is entirely too many digits without mitigation by bitwise representations of digits, except that then 5 bits stacked on a string make it difficult to distinguish 16+8+1, 16+4+1, and 16+2+1.
Even worse, there are now 16*5=80 facts in the roll table, and they are all a mindless jumble of totative static. I think this accords with how the larger a base is, the more baroque procedures you must invent to keep it fruitful, and even then its quality of life is not as great as the range from octal to tetradecimal inclusive.
I would also note that this sort of splitting makes both bases little better than binary in speed, only saved somewhat because you don't go crosseyed distinguishing 110110101101001 from 11011011010101001. Though, given that hexadecimal may need bitwise digits and duotrigesimal quite definitely does, we appear to be saddled with the same problem unless we can handle 16 easily.

Double sharpDozens Demigod
 Joined: Sep 19 2015, 11:02 AM
The 'CountingonToes' Bases
As Oschkar so concisely put it, base 20 was civilisational, even if that was from a bygone age, and its time has passed, never to return. The origins are pretty clear and are given in my chosen title. Presumably, hexadactyls or heptadactyls would go for 24 or 28 instead.
By the same token, of course, it was interrupted and couldn't compete with base 10, and the sane would happen with 24 and 28 outcompeted by 12 and 14. But supposing a misplaced sense of cultural pride, how could we use these?
Using these as double decimal, duodecimal, or tetradecimal is the best idea I have so far come up with. Addition can easily be done by treating the base as {4:5, 4:6, 4:7} and essentially following the approach of the Mayan numerals, making full hands and feet. Or maybe they'd become {2:10, 2:12, 2:14}. I recommend the latter approach (adding a diacritic, meaning "add all the toes", to the lower half of the digit range to make the higher half), for reasons that will soon become clear...
We could learn the tables only to a*a in vigesimal (half the base), and then continue as follows:
7*h = 7(a+7) = 3a+29 = 5j
d*h = (a+3)(a+7) = a(a) + a(3+7) + 3(7) = 50 + 50 + 11 = b1
This is an improvement over the 'pseudobalanced' idea by removing subtraction. Of course, we again start messing severely with the order subjects are thought, having to master multiplying binomials so early! (I still doubt this is as efficient as the true human scale, but oh, the possibilities, when 24 really is so sweet in this range!)
Maybe that can be fixed by treating multiplication as finding an area. Then this is merely splitting the thing at a and then the derivation is pretty clear. What concerns me is that multiplying multidigit numbers requires you to split the sum like this several times, but the method is not hard to do mentally. If the digits make it clear that aj are ten more than 09 (as I think they should so that you can add), then the splitting becomes quite easy since the halfthebase times table is so very trivial. Using a caret for this,
7 * 7^ = (7 * a) + (7 * 7)
3^ * 7^ = (a * a) + (a * [3 + 7]) + (3 * 7)
Maybe these are the "easy numerals", like some phonetic English infant typefaces, before you graduate to the full adult forms.
I think the initial learning is feasible in pure {20, 24} because the lines are short and wellpatterned. I have said many times that large bases suffer because the upper half gets harder, where divisors provide no help. This obviates the need for this half totally!
Now vigesimal has an easy {1, 2, 4, 5, a} as divisors, an alpharelated {3, 7}, a neutral {6, 8}, and an opaque {9}. This is the same as decimal, only trading the places of 7 and 9!
Tetravigesimal has an easy {1, 2, 3, 4, 6, c} as divisors, alpharelated {5}, a neutral {8, 9, a}, and an opaque {7, b}. This is the same as duodecimal, only trading the places of 5 and b!
Octovigesimal I am more worried about. Now {1, 2, 4, 7, e} are divisors, {3, 9} are omegarelated, {8, a, c} are neutral, and {5, b, d} are opaque. This is a little worse than tetradecimal even, and I am more worried about it having less patterns. I fear it may not actually be usable, which is a shame.
Despite my fangirling (more for 24 than for 20 or 28), I should also note that chopping the line off halfway means that the patterns will be harder to see because they don't last as long. Vigesimal 3 only just gets to "11" before being abruptly curtailed at "1a".
Now why I think none of these will last is that we are already using half the base as a splitting point so much that the decay appears to be partially setting in, soon to consume the entire large base entirely. This is similar in spirit to {6:10} except that the higher subbase has shrivelled to complete triviality, so the only product of high digits you need is a*a=50, c*c=60, or e*e=70. But it does mean that when you add, you will be basically using a decimal addition table with vigesimal, and so forth. So people may easily discover that you can get rid of the multiplication issue by using only the fingers, stopping the digit range halfway (after all, no one would have memorised products past the ones I just mentioned), and halving the base.
But it does make the base wieldable by the dedicated, I think  especially those who already know their hardier and sweeter younger sisters, who, while not so rich in factor delights, are more richly accommodating to the average person, and in any case share the same regulars.
As Oschkar so concisely put it, base 20 was civilisational, even if that was from a bygone age, and its time has passed, never to return. The origins are pretty clear and are given in my chosen title. Presumably, hexadactyls or heptadactyls would go for 24 or 28 instead.
By the same token, of course, it was interrupted and couldn't compete with base 10, and the sane would happen with 24 and 28 outcompeted by 12 and 14. But supposing a misplaced sense of cultural pride, how could we use these?
Using these as double decimal, duodecimal, or tetradecimal is the best idea I have so far come up with. Addition can easily be done by treating the base as {4:5, 4:6, 4:7} and essentially following the approach of the Mayan numerals, making full hands and feet. Or maybe they'd become {2:10, 2:12, 2:14}. I recommend the latter approach (adding a diacritic, meaning "add all the toes", to the lower half of the digit range to make the higher half), for reasons that will soon become clear...
We could learn the tables only to a*a in vigesimal (half the base), and then continue as follows:
7*h = 7(a+7) = 3a+29 = 5j
d*h = (a+3)(a+7) = a(a) + a(3+7) + 3(7) = 50 + 50 + 11 = b1
This is an improvement over the 'pseudobalanced' idea by removing subtraction. Of course, we again start messing severely with the order subjects are thought, having to master multiplying binomials so early! (I still doubt this is as efficient as the true human scale, but oh, the possibilities, when 24 really is so sweet in this range!)
Maybe that can be fixed by treating multiplication as finding an area. Then this is merely splitting the thing at a and then the derivation is pretty clear. What concerns me is that multiplying multidigit numbers requires you to split the sum like this several times, but the method is not hard to do mentally. If the digits make it clear that aj are ten more than 09 (as I think they should so that you can add), then the splitting becomes quite easy since the halfthebase times table is so very trivial. Using a caret for this,
7 * 7^ = (7 * a) + (7 * 7)
3^ * 7^ = (a * a) + (a * [3 + 7]) + (3 * 7)
Maybe these are the "easy numerals", like some phonetic English infant typefaces, before you graduate to the full adult forms.
I think the initial learning is feasible in pure {20, 24} because the lines are short and wellpatterned. I have said many times that large bases suffer because the upper half gets harder, where divisors provide no help. This obviates the need for this half totally!
Now vigesimal has an easy {1, 2, 4, 5, a} as divisors, an alpharelated {3, 7}, a neutral {6, 8}, and an opaque {9}. This is the same as decimal, only trading the places of 7 and 9!
Tetravigesimal has an easy {1, 2, 3, 4, 6, c} as divisors, alpharelated {5}, a neutral {8, 9, a}, and an opaque {7, b}. This is the same as duodecimal, only trading the places of 5 and b!
Octovigesimal I am more worried about. Now {1, 2, 4, 7, e} are divisors, {3, 9} are omegarelated, {8, a, c} are neutral, and {5, b, d} are opaque. This is a little worse than tetradecimal even, and I am more worried about it having less patterns. I fear it may not actually be usable, which is a shame.
Despite my fangirling (more for 24 than for 20 or 28), I should also note that chopping the line off halfway means that the patterns will be harder to see because they don't last as long. Vigesimal 3 only just gets to "11" before being abruptly curtailed at "1a".
Now why I think none of these will last is that we are already using half the base as a splitting point so much that the decay appears to be partially setting in, soon to consume the entire large base entirely. This is similar in spirit to {6:10} except that the higher subbase has shrivelled to complete triviality, so the only product of high digits you need is a*a=50, c*c=60, or e*e=70. But it does mean that when you add, you will be basically using a decimal addition table with vigesimal, and so forth. So people may easily discover that you can get rid of the multiplication issue by using only the fingers, stopping the digit range halfway (after all, no one would have memorised products past the ones I just mentioned), and halving the base.
But it does make the base wieldable by the dedicated, I think  especially those who already know their hardier and sweeter younger sisters, who, while not so rich in factor delights, are more richly accommodating to the average person, and in any case share the same regulars.

Double sharpDozens Demigod
 Joined: Sep 19 2015, 11:02 AM
The Perfect Square
Since 36 is the square of six, and senary (stretching the human scale to the lower end instead if the higher end) is usable by those willing to mount such excursions, the answer on how to use it as a base is very obvious and very dull: just split it into pairs of senary places.
I know, I know, it's not a very satisfying answer. You can supplement this by memorising some nearcomplementary divisors of the senary hundred, as I think Oschkar has suggested in one of his threads. But in general, it really does feel a little "too fast to walk, too slow to run"...
Now, icarus has I think mentioned his terminology: among the composites, we have "deep" prime powers, "broad" quadratfrei integers, and "vast" for everything else.
The Distant Vast Composite
If the humanunderstandable bases {6, 8, 10, 12, 14, 16, 18, 20, 24, 28, 30, 32, 36}, were personified, I'd see them as follows:
1. Senary is really short and, while very sweet and accommodating to all numbers, keeps tripping and falling whenever needing to reach high up for the jar on shelf number 101 (thirtyseven). Its 'hundred', hexatrigesimal, does not really have an independent existence, and manifests itself more as "dark and resistive 36" as a contrast to the normal personality of "light, sweet, and amiable 6" when things need to be done quickly.
2. The humanscale {8, 10, 12, 14} are a good, solid, dependable quartet who can do everything and are quite friendly, though they have slightly different personalities.
3. The binary {16} essentially acts as a proxy for binary that is distinct from the Stevinian {8}, while {32} is very resistive and mostly vanishes as a personality as an inadequate way to split binary. Hexadecimal is very logical, very precise, but has a devotion for 2 that is so strong (even in which power of two it is) that it sometimes takes a toll on the base's health.
4. The doublesized {20, 24, 28} are accommodating too, but they have serious problems that they have to essentially keep taking mathematical medicine to stay alive by splitting their span into half. When that is done, they work after a fashion, and still are very sweet with their richness in divisors, but if you want something to be done without them needing to pause for breath and grasp a nearby surface for support, {10, 12, 14} is better.
5. {18} and {30} are pretty aloof and distant and make themselves difficult to use by not being multiples of 4, but 30 at least gives a good reason to want to use it through the "5smooth" superpower no one else in this humanunderstandable category has! 18 is closest, if to anyone, to senary.
Now, if {20, 24, 28} were leveraged as double {10, 12, 14}, then it seems that {18} can be leveraged as half {36}, which is where that personification comes from. Of course, the only way to use 36 is as senary. So what seems to happen is that we have a strange senary with a halfsized hundred!
Thus, to do e * g, we convert to senary and get 22 * 24. This is
20 * 20 = 4 00, but the hundred is halfsized, so really octodecimal 80
20 * 4 = 1 20, which is really octodecimal 2c
2 * 20 = 40, which is really 30+10 and octodecimal 16
2 * 4 = 12, or octodecimal 8
Sum is 80 + 2c + 16 + 8 = b8 (I think; haven't checked it.)
Of course, this brings us to senary levels of inefficiency. We need, I think, {3:6} numerals. What I think is going on with this scale is that the numerals must transparently display their origins, i.e. {2:2:2:2, 3:6, 2:10, 2:12, 2:14, 2:2:2:2:2, 6:6} as {16, 18, 20, 24, 28, 32, 36}, but you don't need to actually use cumbersome mixedradix arithmetic because either the subbases or the same or they are just tiny and trivial! Once the numerals are like that and subitisable, like Mayanstyle "....." for h, we can do this perhaps a little more easily.
But the halving creates an imbalance in the prime factorisation to 2 * 3^2, so that ternary divisions are overemphasised, and soon people will question why the silly halving is present, and move to 36, which becomes 6, which may soon become 12. I also am not sure how on earth 18 would come about.
The Tricolour Detector
Thirty is like sixty's younger sister, getting 5smoothness for half the price. Similarly, perhaps {3:10} or {6:5} works as an encoding. Except there is no clear shortcut, because the subbases are coprime to each other.
I still haven't come up with a good way to use this. You see, the complementary divisor method can be pretty baroque and take a lot of steps, and essentially you need to use different tricks for every problem. When trying to multiply h by n, or 17 by 23, the best approach is k^2  3^2 among most methods, because 24 as 4/5 is not the easiest regular to offset to. The reason why 30 doesn't have a personality yet for me as a base is that I can't use it. I imagine it would feel like 60, but without so massive a scale, and without aggravating CDM roundoffs like for 43 squared.
So, I will bow out now, summarising the progress made here to the current limits, and hoping that Oschkar can extend it further.
Since 36 is the square of six, and senary (stretching the human scale to the lower end instead if the higher end) is usable by those willing to mount such excursions, the answer on how to use it as a base is very obvious and very dull: just split it into pairs of senary places.
I know, I know, it's not a very satisfying answer. You can supplement this by memorising some nearcomplementary divisors of the senary hundred, as I think Oschkar has suggested in one of his threads. But in general, it really does feel a little "too fast to walk, too slow to run"...
Now, icarus has I think mentioned his terminology: among the composites, we have "deep" prime powers, "broad" quadratfrei integers, and "vast" for everything else.
The Distant Vast Composite
If the humanunderstandable bases {6, 8, 10, 12, 14, 16, 18, 20, 24, 28, 30, 32, 36}, were personified, I'd see them as follows:
1. Senary is really short and, while very sweet and accommodating to all numbers, keeps tripping and falling whenever needing to reach high up for the jar on shelf number 101 (thirtyseven). Its 'hundred', hexatrigesimal, does not really have an independent existence, and manifests itself more as "dark and resistive 36" as a contrast to the normal personality of "light, sweet, and amiable 6" when things need to be done quickly.
2. The humanscale {8, 10, 12, 14} are a good, solid, dependable quartet who can do everything and are quite friendly, though they have slightly different personalities.
3. The binary {16} essentially acts as a proxy for binary that is distinct from the Stevinian {8}, while {32} is very resistive and mostly vanishes as a personality as an inadequate way to split binary. Hexadecimal is very logical, very precise, but has a devotion for 2 that is so strong (even in which power of two it is) that it sometimes takes a toll on the base's health.
4. The doublesized {20, 24, 28} are accommodating too, but they have serious problems that they have to essentially keep taking mathematical medicine to stay alive by splitting their span into half. When that is done, they work after a fashion, and still are very sweet with their richness in divisors, but if you want something to be done without them needing to pause for breath and grasp a nearby surface for support, {10, 12, 14} is better.
5. {18} and {30} are pretty aloof and distant and make themselves difficult to use by not being multiples of 4, but 30 at least gives a good reason to want to use it through the "5smooth" superpower no one else in this humanunderstandable category has! 18 is closest, if to anyone, to senary.
Now, if {20, 24, 28} were leveraged as double {10, 12, 14}, then it seems that {18} can be leveraged as half {36}, which is where that personification comes from. Of course, the only way to use 36 is as senary. So what seems to happen is that we have a strange senary with a halfsized hundred!
Thus, to do e * g, we convert to senary and get 22 * 24. This is
20 * 20 = 4 00, but the hundred is halfsized, so really octodecimal 80
20 * 4 = 1 20, which is really octodecimal 2c
2 * 20 = 40, which is really 30+10 and octodecimal 16
2 * 4 = 12, or octodecimal 8
Sum is 80 + 2c + 16 + 8 = b8 (I think; haven't checked it.)
Of course, this brings us to senary levels of inefficiency. We need, I think, {3:6} numerals. What I think is going on with this scale is that the numerals must transparently display their origins, i.e. {2:2:2:2, 3:6, 2:10, 2:12, 2:14, 2:2:2:2:2, 6:6} as {16, 18, 20, 24, 28, 32, 36}, but you don't need to actually use cumbersome mixedradix arithmetic because either the subbases or the same or they are just tiny and trivial! Once the numerals are like that and subitisable, like Mayanstyle "....." for h, we can do this perhaps a little more easily.
But the halving creates an imbalance in the prime factorisation to 2 * 3^2, so that ternary divisions are overemphasised, and soon people will question why the silly halving is present, and move to 36, which becomes 6, which may soon become 12. I also am not sure how on earth 18 would come about.
The Tricolour Detector
Thirty is like sixty's younger sister, getting 5smoothness for half the price. Similarly, perhaps {3:10} or {6:5} works as an encoding. Except there is no clear shortcut, because the subbases are coprime to each other.
I still haven't come up with a good way to use this. You see, the complementary divisor method can be pretty baroque and take a lot of steps, and essentially you need to use different tricks for every problem. When trying to multiply h by n, or 17 by 23, the best approach is k^2  3^2 among most methods, because 24 as 4/5 is not the easiest regular to offset to. The reason why 30 doesn't have a personality yet for me as a base is that I can't use it. I imagine it would feel like 60, but without so massive a scale, and without aggravating CDM roundoffs like for 43 squared.
So, I will bow out now, summarising the progress made here to the current limits, and hoping that Oschkar can extend it further.

OschkarDozens Disciple
 Joined: Nov 19 2011, 01:07 AM
{i}Double sharp @ Dec 17 2016, 01:42 PM wrote: I also am not sure how on earth 18 would come about.
Maybe not on Earth, but on Mark Rosenfelder’s surprisingly detailed conworld Almea.
The uestî have pentadactyl hands and tetradactyl feet, and numbers in his languages Meťaiun show their origins in the process of counting. Most of his languages are decimal, though, which makes sense for such a strange finger situation, since hands are much more mobile anyway.
1 grem
2 kuri
3 dama
4 ǧakaȟ ("almost")
5 amua ("a hand")
6 migrem amua ("a hand with one")
7 mikuri amua ("a hand with two")
8 midama amua ("a hand with three")
9 ǧakaȟ kuri ("almost two")
a kuramua ("two hands")
b poc pinaȟ ("down to the feet")
c mikuri kuramua ("two hands with two")
d midama kuramua ("two hands with three")
e mipoc kuramua ("two hands with a foot")
f migrem mipoc kuramua ("two hands with a foot with one")
g mikuri mipoc kuramua ("two hands with a foor with two")
h ǧakaȟ oranda ("almost a man")
10 oranda ("a man")
Not surprisingly, Meťaiun was the language of an ancient empire, and as that culture decayed, the surrounding cultures forced the people of Meťaiu to adopt their decimal system, which simplified matters immensely. The word for 100 (dikumi) became the word for 5a, and the word for 1000 (ťeleť) fell out of use.
{a}
In the modern language Kebreni, numbers are systematically decimal, but the teens are still descendants of the Meťaiun octodecimal system:
1 gem
2 kur
3 dam
4 hak
5 amma
6 migem
7 mikur
8 midam
9 hakur
10 kram
11 pinah́
12 migram
13 midakram
14 mipoc
15 mipokemai
16 mipokurai
17 hakraida
18 raida
19 raigemai
20 kur kram
{i}
In Uyseʔ, numbers are octodecimal up to the modern day. The system has subbases a (both hands) and c (no idea), and is subtractive for the numbers it fails to reach.
1 or
2 nre
3 swol
4 tswar
5 phun
6 het
7 swolpret
8 nrepret
9 orpret
a pret
b ortsum
c tsum
d phunħot
e tswarħot
f swolħot
g nreħot
h orħot
10 ħot
I’m not sure, however, how the Uytainese would calculate, and Mark Rosenfelder aparently doesn’t either...

Double sharpDozens Demigod
 Joined: Sep 19 2015, 11:02 AM
I'm fairly confident about the systems I described above for {16, 20, 24, 28, 32, 36}  binary rolling or mediation and duplation for {16, (32)} (though the latter is too resisive), treating {36} as senary compression, and treating {20, 24, 28} as {2:10, 2:12, 2:14} (the nicest possible case of radixmixing, because the top radix is not just simple like it is for {3, 4, 5, 6}, but it's utterly trivial and induces no blunting).
It's {18, 30} I am concerned about, 18 because treating it as half 36 is annoying (you don't get there natively, you have to "speak" senary and turn to octodecimal) and 30 because its tricolour aspect means that there is no coding that would prevent blunting of divisibility by some prime.
Thanks for the info on how 18 could plausibly arise! This expands the field to all even bases; if we use the 47 range of dactyly again, this adds {22, 26} to the list that could happen. I really do not envy the thought of working in those bases, though  too much stubborn resistance. So maybe, while 18 could stay due to high divisibility, these mixed1012 or mixed1214 digital people would just pick the number on their hands and get {10, 12, 14} fairly quickly.
It's {18, 30} I am concerned about, 18 because treating it as half 36 is annoying (you don't get there natively, you have to "speak" senary and turn to octodecimal) and 30 because its tricolour aspect means that there is no coding that would prevent blunting of divisibility by some prime.
Thanks for the info on how 18 could plausibly arise! This expands the field to all even bases; if we use the 47 range of dactyly again, this adds {22, 26} to the list that could happen. I really do not envy the thought of working in those bases, though  too much stubborn resistance. So maybe, while 18 could stay due to high divisibility, these mixed1012 or mixed1214 digital people would just pick the number on their hands and get {10, 12, 14} fairly quickly.

Double sharpDozens Demigod
 Joined: Sep 19 2015, 11:02 AM
Rereading icarus' thread on octodecimal, it strikes me that only memorising the regular products is a sensible approach. There are only ten regular rows: {1, 2, 3, 4, 6, 8, 9, c, g, 10}, of which the first and last are trivial. For sure, most of the rows are now patternless because we've taken out many of the rows: so 3 now looks like {3, 6, 9, c, 10, 16, 19, 20, 2c, 30} instead of a full 369cf10 cycle. But given that many people manage to learn a 12*12 table in decimal while being unaware of the patterns, I think it is actually fine.
The reason this works well is that nothing ever needs an offset higher than 2 (for octodecimal e), and the table is small. Totative products are an annoyance, though. To do b*d, I think the most sensible approach is to do it as c^2  1, but asking the kids developing a number sense to see that may be too much  unless, again, you show graphical illustrations of multiplication as finding an area.
Vigesimal has much sparser regulars, as does octovigesimal, so it is a good thing that this method is no longer necessary for them. Tetravigesimal could use this too: the regular rows are {1, 2, 3, 4, 6, 8, 9, c, g, i, 10}. The issue I see here is that the gap in the top end of the digit range is pretty big; I'd much prefer splitting the span as {2:12}.
Now that octodecimal is sorted, it's back to trying to save trigesimal  for which this will not work, because the regulars are {1, 2, 3, 4, 5, 6, 8, 9, a, c, f, g, i, k, o, p, r}  entirely too many, in other words.
The reason this works well is that nothing ever needs an offset higher than 2 (for octodecimal e), and the table is small. Totative products are an annoyance, though. To do b*d, I think the most sensible approach is to do it as c^2  1, but asking the kids developing a number sense to see that may be too much  unless, again, you show graphical illustrations of multiplication as finding an area.
Vigesimal has much sparser regulars, as does octovigesimal, so it is a good thing that this method is no longer necessary for them. Tetravigesimal could use this too: the regular rows are {1, 2, 3, 4, 6, 8, 9, c, g, i, 10}. The issue I see here is that the gap in the top end of the digit range is pretty big; I'd much prefer splitting the span as {2:12}.
Now that octodecimal is sorted, it's back to trying to save trigesimal  for which this will not work, because the regulars are {1, 2, 3, 4, 5, 6, 8, 9, a, c, f, g, i, k, o, p, r}  entirely too many, in other words.

OschkarDozens Disciple
 Joined: Nov 19 2011, 01:07 AM
{u}Double sharp @ Dec 18 2016, 07:49 AM wrote: Now that octodecimal is sorted, it's back to trying to save trigesimal  for which this will not work, because the regulars are {1, 2, 3, 4, 5, 6, 8, 9, a, c, f, g, i, k, o, p, r}  entirely too many, in other words.
We could memorize only the products of the regulars up to richness 2: {1, 2, 3, 4, 5, 6, 9, a, c, f, i, k, p} and leave it at the size of the tetradecimal table. The other digits could be handled like this:
7 = 6 + 1
8 = 6 + 2
b = a + 1
d = c + 1
e = f − 1
g = f + 1
h = i − 1
j = i + 1
l = k + 1
m = k + 2
n = p − 2
o = p − 1
q = p + 1
r = p + 2
s = 10 − 2
t = 10 − 1
{a}
Offsets would be essentially trivial, either the same number as the other factor or its double. We’d have 196 singlestep products (about a fifth of the full table), 448 twostep products (regulars times coprimes), and 256 threestep products (coprimes times coprimes).
Trigesimal might also be treated as {3:10}, or {6:5}. I’m not sure, though, which method is more efficient.

Double sharpDozens Demigod
 Joined: Sep 19 2015, 11:02 AM
An eminently sensible approach for trigesimal!
I tend to see {30} as opposed to {60} as being more superficial, if they were personified. Both of them should be very introverted (hence the lack of extrinsic relationships to useful primes up to about 13), but 30 is more uninterested in "deep" regulars like 16, while 60 understands the greater importance of 2 over other primes and has its prime factors in a better balance. 120 is then heavily extroverted. (To be fair, I really dislike mixedradix approaches when the top digit isn't totally trivial, which implies 2  but there's nothing stopping you from using bases like {60, 84, 120} if you like them, even though they are so not extensible to society at large.)
Hence the aversion to overly rich regulars makes sense. I considered using CDM, but the ability to use halves, thirds, fifths, and sixths without quarters is really annoying for me.
I dislike both {3:10} and {6:5}, but I think this is mostly because I have a strong aversion to odd subbases. Partially it is also the blunting thing: when you have a base with at least three prime factors, you cannot have all three of 1/2, 1/3, and 1/5 handled in one digit. Normally I would prefer 1/5 or 1/7 to be sacrificed, so I find {6:10} and {6:14} more fun (I don't use {12:10} or {12:14}  maybe that's just me  but it would work too)  until you get tired of dancing around to get 5smoothness or 7smoothness.
Essentially, I find that if using a base like {236} can be done by walking or running, anything higher ends up like a Pythonesque sillywalk. This is why I like this thread so much, extending the regime to the "humanunderstandable" range!
Actually I think I've figured out a criterion for this: the "humanunderstandable" range is the range where you "want" to work one digit at a time, setting down the multiplication in an approximately Stevinian method, but are unable to memorise the full tables and must use scaffolding and do course corrections to reach less friendly products.
The distinction is perhaps not so well understood by the average person trying to look into bases, partially because of the allure of the large and imposing, but partially because most such haven't yet used themselves as guinea pigs trying to memorise the octodecimal table. An outstanding way to never get this civilisational sense of perspective is to do everything in decimal and then convert to base b. All this really does is test your decimal b times table, and I am sorry to say that I was guilty of it mentally for a while for {6:10} sexagesimal. When you do things like this, an approach heavily influenced by mixedradix units as opposed to numbers, almost anything looks usable, whether it be 17, 99, 360, or 2520. At least, until you get sick of the mixedradix rules and sillywalking everywhere to reach the Royal House of Fivesmooth.
But normal people, really learning a base, have to have leverage from divisors, and not too much resistance from totatives.
I tend to see {30} as opposed to {60} as being more superficial, if they were personified. Both of them should be very introverted (hence the lack of extrinsic relationships to useful primes up to about 13), but 30 is more uninterested in "deep" regulars like 16, while 60 understands the greater importance of 2 over other primes and has its prime factors in a better balance. 120 is then heavily extroverted. (To be fair, I really dislike mixedradix approaches when the top digit isn't totally trivial, which implies 2  but there's nothing stopping you from using bases like {60, 84, 120} if you like them, even though they are so not extensible to society at large.)
Hence the aversion to overly rich regulars makes sense. I considered using CDM, but the ability to use halves, thirds, fifths, and sixths without quarters is really annoying for me.
I dislike both {3:10} and {6:5}, but I think this is mostly because I have a strong aversion to odd subbases. Partially it is also the blunting thing: when you have a base with at least three prime factors, you cannot have all three of 1/2, 1/3, and 1/5 handled in one digit. Normally I would prefer 1/5 or 1/7 to be sacrificed, so I find {6:10} and {6:14} more fun (I don't use {12:10} or {12:14}  maybe that's just me  but it would work too)  until you get tired of dancing around to get 5smoothness or 7smoothness.
Essentially, I find that if using a base like {236} can be done by walking or running, anything higher ends up like a Pythonesque sillywalk. This is why I like this thread so much, extending the regime to the "humanunderstandable" range!
Actually I think I've figured out a criterion for this: the "humanunderstandable" range is the range where you "want" to work one digit at a time, setting down the multiplication in an approximately Stevinian method, but are unable to memorise the full tables and must use scaffolding and do course corrections to reach less friendly products.
The distinction is perhaps not so well understood by the average person trying to look into bases, partially because of the allure of the large and imposing, but partially because most such haven't yet used themselves as guinea pigs trying to memorise the octodecimal table. An outstanding way to never get this civilisational sense of perspective is to do everything in decimal and then convert to base b. All this really does is test your decimal b times table, and I am sorry to say that I was guilty of it mentally for a while for {6:10} sexagesimal. When you do things like this, an approach heavily influenced by mixedradix units as opposed to numbers, almost anything looks usable, whether it be 17, 99, 360, or 2520. At least, until you get sick of the mixedradix rules and sillywalking everywhere to reach the Royal House of Fivesmooth.
But normal people, really learning a base, have to have leverage from divisors, and not too much resistance from totatives.

Double sharpDozens Demigod
 Joined: Sep 19 2015, 11:02 AM
One thing I think we might keep forgetting for bases {18, 30} is: how do we add?
I mean, if you use numerals like "3^" (I'd prefer the circumflex to actually go on top of the 3) for "13" (I'm abusing notation and leaving the small base deliberately ambiguous between ten, twelve, and fourteen) in base 20, it looks pretty straightforward for {20, 24, 28}. How we would do it in the hardest (28) is:
9 + b = 6^ (this is from the "small" part of the table up to "0^", the part heptadactyls can get to using only fingers and toes; and I now think that 7 may be a valid human subitising limit if trained, because I can actually imagine heptadactyly)
9^ + b = 16 (compare true tetradecimal 19 + b = 26)
9^ + b^ = 16^ (compare true tetradecimal 19 + 1b = 36)
So the addition table is practically identical to the base's 'younger sister'. The counting is thus done in the obvious way: 07 on one hand, 80^ on two; then 0^ also on the toes, to which you add the fingers to get 1^7^ and then 8^10^.
{36} can add like the {6} it really is. {16} seems to want to act like binary, so the addition is bitwise. To do 8+b, you see it as (8+8)+(2+1) = 13. Then b+d is (8+2+1)+(8+4+1) = (8+8+4+2+1+1) = 18.
In fact, if the digits transparently show bitwise components, this is very clear:
8 8
 4
2 
1 1
And anything doubled must spill over to the next position. The sum is 18, although the avalanche of carries may prove a little confusing at first. (I must add the caveat that I haven't actually tested this on myself). I suggest that {32} wants to act the same way, which is also cool because finger binary on both hands gets us something similar (although I don't like finger binary, both because the gesture for 4 is a bit suspect, and numbers like 9 are hard to show for the more inflexible among us). Though I still think 32 is ruled out because multiplication becomes too annoying and baroque with too many obscure totative products with no good pattern to memorise (can you imagine having 16 odd digits migrating through the binary stick)? This is why I personally think this scale really ends at 30, not 36, since 32 is so hard and 36 is just senary.
Now we've made the methods for {16, 20, 24, 28} among my reduced scale feasible, but how do you add in octodecimal or trigesimal? It would seem that in base 18, there is no clear way to abbreviate addition, save using a 3on6 representation as half the senary hundred. Even so, we'll keep running into things like "22 + 23". The higher subbase is no longer totally trivial and it shows. We get the same problem for trigesimal as 3on10 or 6on5. Either the efficiency plummets with honesttogoodness radixmixing, we have to internalise the arithmetic of an odd subbase, or we just can't use it.
It looks like a bruteforce pulloutallthestops approach leveraging the factors of octodecimal may be the best way to go. Let's be very nice and consider easy addition of the divisors 0, 1, 2, 3, 6, and 9, the doubles, the doubles plus or minus one, sums that make h, 10, or 11, and addition of the divisorcomplements c, f, g, and h. We still choke on {4, 5, 7, 8, a, b, d, e}, making a hard 7+4, 8+4, a+4, b+4, 7+5, 8+5, a+5, b+5, d+7, e+7, d+8, e+8, d+a, e+a, d+b, and e+b. And note that this is overly optimistic: divisors over 2 don't just need you to distinguish even from odd, but all the different residues modulo that divisor. Even a bruteforce attack on addition fails to work for octodecimal. Trigesimal thus has no hope, like octodecimal, unless we can think of something new.
I still personally think that {16, 20, 24, 28} would decay eventually to the halfsized {8, 10, 12, 14}, which are so similar in their thinking, but they would last for a while at an earlier stage of civilisation in a way I can't quite yet see {18, 30} doing!
I mean, if you use numerals like "3^" (I'd prefer the circumflex to actually go on top of the 3) for "13" (I'm abusing notation and leaving the small base deliberately ambiguous between ten, twelve, and fourteen) in base 20, it looks pretty straightforward for {20, 24, 28}. How we would do it in the hardest (28) is:
9 + b = 6^ (this is from the "small" part of the table up to "0^", the part heptadactyls can get to using only fingers and toes; and I now think that 7 may be a valid human subitising limit if trained, because I can actually imagine heptadactyly)
9^ + b = 16 (compare true tetradecimal 19 + b = 26)
9^ + b^ = 16^ (compare true tetradecimal 19 + 1b = 36)
So the addition table is practically identical to the base's 'younger sister'. The counting is thus done in the obvious way: 07 on one hand, 80^ on two; then 0^ also on the toes, to which you add the fingers to get 1^7^ and then 8^10^.
{36} can add like the {6} it really is. {16} seems to want to act like binary, so the addition is bitwise. To do 8+b, you see it as (8+8)+(2+1) = 13. Then b+d is (8+2+1)+(8+4+1) = (8+8+4+2+1+1) = 18.
In fact, if the digits transparently show bitwise components, this is very clear:
8 8
 4
2 
1 1
And anything doubled must spill over to the next position. The sum is 18, although the avalanche of carries may prove a little confusing at first. (I must add the caveat that I haven't actually tested this on myself). I suggest that {32} wants to act the same way, which is also cool because finger binary on both hands gets us something similar (although I don't like finger binary, both because the gesture for 4 is a bit suspect, and numbers like 9 are hard to show for the more inflexible among us). Though I still think 32 is ruled out because multiplication becomes too annoying and baroque with too many obscure totative products with no good pattern to memorise (can you imagine having 16 odd digits migrating through the binary stick)? This is why I personally think this scale really ends at 30, not 36, since 32 is so hard and 36 is just senary.
Now we've made the methods for {16, 20, 24, 28} among my reduced scale feasible, but how do you add in octodecimal or trigesimal? It would seem that in base 18, there is no clear way to abbreviate addition, save using a 3on6 representation as half the senary hundred. Even so, we'll keep running into things like "22 + 23". The higher subbase is no longer totally trivial and it shows. We get the same problem for trigesimal as 3on10 or 6on5. Either the efficiency plummets with honesttogoodness radixmixing, we have to internalise the arithmetic of an odd subbase, or we just can't use it.
It looks like a bruteforce pulloutallthestops approach leveraging the factors of octodecimal may be the best way to go. Let's be very nice and consider easy addition of the divisors 0, 1, 2, 3, 6, and 9, the doubles, the doubles plus or minus one, sums that make h, 10, or 11, and addition of the divisorcomplements c, f, g, and h. We still choke on {4, 5, 7, 8, a, b, d, e}, making a hard 7+4, 8+4, a+4, b+4, 7+5, 8+5, a+5, b+5, d+7, e+7, d+8, e+8, d+a, e+a, d+b, and e+b. And note that this is overly optimistic: divisors over 2 don't just need you to distinguish even from odd, but all the different residues modulo that divisor. Even a bruteforce attack on addition fails to work for octodecimal. Trigesimal thus has no hope, like octodecimal, unless we can think of something new.
I still personally think that {16, 20, 24, 28} would decay eventually to the halfsized {8, 10, 12, 14}, which are so similar in their thinking, but they would last for a while at an earlier stage of civilisation in a way I can't quite yet see {18, 30} doing!

OschkarDozens Disciple
 Joined: Nov 19 2011, 01:07 AM
Wendy uses a prime before the digit for this, which seems about equally sensible to me, so that your 3^ is ′3 in her scheme. It’s also extensible to {3:6} octodecimal and {3:10} trigesimal, because the double prime character is in the WGL4 character, and therefore in most modern Unicode fonts.Double sharp @ Dec 18 2016, 12:56 PM wrote:I mean, if you use numerals like "3^" (I'd prefer the circumflex to actually go on top of the 3) for "13" (I'm abusing notation and leaving the small base deliberately ambiguous between ten, twelve, and fourteen) in base 20, it looks pretty straightforward for {20, 24, 28}.
For me, a {3:10} encoding would be the best way to generate usable trigesimal digits. There would be ten distinct base symbols and two diacritics. If the diacritics were simply a circumflex or a prime, it would be uncomfortably easy to change a ′1 into a ″1 when forging a cheque. Maybe we could use a circumflex for 10_{small} and a double prime for 20_{small}, with digits under ′0 getting an overline.
In trigesimal, we’d probably learn to carry when three diacritics come together.How we would do it in the hardest (28) is:
9 + b = 6^ (this is from the "small" part of the table up to "0^", the part heptadactyls can get to using only fingers and toes; and I now think that 7 may be a valid human subitising limit if trained, because I can actually imagine heptadactyly)
9^ + b = 16 (compare true tetradecimal 19 + b = 26)
9^ + b^ = 16^ (compare true tetradecimal 19 + 1b = 36)
4 + 5 = 9
4 + ′5 = ′9
4 + ″5 = ″9
′4 + ″5 = 19
″4 + ″5 = 1′9
If there’s already a diacriticcarry on the singlesubdigit addition, it’s slightly more complicated, but still, I think, within what a person can keep in mind.
3 + 8 = ′1
3 + ′8 = ″1
3 + ″8 = 11 (because of the diacriticcarry meeting the double prime on the ″8)
′3 + ″8 = 1′1
″3 + ″8 = 1″1
This makes sense. I’m fairly sure that addition in {16} can be memorized directly:In fact, if the digits transparently show bitwise components, this is very clear:
8 8
 4
2 
1 1
And anything doubled must spill over to the next position. The sum is 18, although the avalanche of carries may prove a little confusing at first. (I must add the caveat that I haven't actually tested this on myself). I suggest that {32} wants to act the same way, which is also cool because finger binary on both hands gets us something similar (although I don't like finger binary, both because the gesture for 4 is a bit suspect, and numbers like 9 are hard to show for the more inflexible among us).
1. Adding 0,
2. Adding 1,
3. Adding 2,
4. Adding 8,
5. Doubles,
6. Consecutive numbers,
7. Making 10,
8. Making 11,
9. Making f,
a. Adding f,
b. Adding e,
c. Adding 4 or c,
d. Singledigit leftovers: {5+3, 6+3, 7+3, 7+5, 9+3, 9+5, a+3, b+3}
e. Doubledigit leftovers: {b+7, b+9, d+5, d+6, d+7, d+9, d+a, d+b}
In {32}, bitwise digits seem indispensable, although they might want to degrade to more fluid forms when actually written out.
With bitwise digits, it does seem somehow doable, though, with the provision that {32} should really pretend to be binary. Duotrigesimal really does seem like its problems are insurmountable, though, in a way that puts it out of this class. I’ll try to maintain it, but there really does seem to be too much resistance from {32}, even though, under the surface, it’s all binary.Though I still think 32 is ruled out because multiplication becomes too annoying and baroque with too many obscure totative products with no good pattern to memorise (can you imagine having 16 odd digits migrating through the binary stick)?
Well, if number keypads work for saving tetradecimal multiplication, they will work for saving octodecimal addition.It looks like a bruteforce pulloutallthestops approach leveraging the factors of octodecimal may be the best way to go. Let's be very nice and consider easy addition of the divisors 0, 1, 2, 3, 6, and 9, the doubles, the doubles plus or minus one, sums that make h, 10, or 11, and addition of the divisorcomplements c, f, g, and h. We still choke on {4, 5, 7, 8, a, b, d, e}, making a hard 7+4, 8+4, a+4, b+4, 7+5, 8+5, a+5, b+5, d+7, e+7, d+8, e+8, d+a, e+a, d+b, and e+b. And note that this is overly optimistic: divisors over 2 don't just need you to distinguish even from odd, but all the different residues modulo that divisor. Even a bruteforce attack on addition fails to work for octodecimal. Trigesimal thus has no hope, like octodecimal, unless we can think of something new.
The best octodecimal keypad for this is probably:
Code: Select all
┌───┬───┬───┐
│f │g │h │
│ │ │ │
├───┼───┼───┤
│c │d │e │
│ │ │ │
├───┼───┼───┤
│9 │a │b │
│ │ │ │
├───┼───┼───┤
│6 │7 │8 │
│ │ │ │
├───┼───┼───┤
│3 │4 │5 │
│ │ │ │
├───┼───┼───┤
│0 │1 │2 │
│ │ │ │
└───┴───┴───┘

wendy.krieger
I used base 18 and 30 quite heavily. But let's have a look at these.
Base 18 is still in the learnable tables range, although i do agree with DoubleSharp that it's getting a bit high. It's the largest base to feature 'primedecades', where every coprime in a given decade is also prime (like dec 101, 103, 107, 109, and doz 81, 85, 87, 8E). But they're a lot rarer. You have eg 7921, 7925, 7927, 792B, 792D, 792G, for example. I used decimalstyle runes for this, with characters from 0 to 17 resp.
Base 30 is done as primed decades, like 1, '0, 3'0, 13'0, '13'0 and 3"13'0 for the powers of 10. I never got around to devising tables for it. Unlike numbers less than it, 30 is a threeprime, which means that the number of regulars grow very fast. The sumerian tables went to 20, and decades thereafter, also match the pattern here.
Both 18 and 30, along with 80, feature sevenites as far as 7smooth, which were useful. On the other hand, the treatment of 2 was nothing like what i would desire in a modern metrology. You need the log of the power of 2 to be something between 1/3 and 1/2 of the base. 60 is pushing the friendship here, i would had liked something more in keeping with 28 or the like.
30 is better suited to weights, as 1+2+4+8=15. In 18, you still need 5 weights, although the 5 proper divisors do nicely here. In this regard, the divisors of 18 (and 120) are more evenly spread on the log wheel than those of 12 and 60. 20 and 117 do a pretty awesome job here, with the 13 divisor mantissa of the cube of the base falling almost exactly at the thirteenths.
Base 18 is still in the learnable tables range, although i do agree with DoubleSharp that it's getting a bit high. It's the largest base to feature 'primedecades', where every coprime in a given decade is also prime (like dec 101, 103, 107, 109, and doz 81, 85, 87, 8E). But they're a lot rarer. You have eg 7921, 7925, 7927, 792B, 792D, 792G, for example. I used decimalstyle runes for this, with characters from 0 to 17 resp.
Base 30 is done as primed decades, like 1, '0, 3'0, 13'0, '13'0 and 3"13'0 for the powers of 10. I never got around to devising tables for it. Unlike numbers less than it, 30 is a threeprime, which means that the number of regulars grow very fast. The sumerian tables went to 20, and decades thereafter, also match the pattern here.
Both 18 and 30, along with 80, feature sevenites as far as 7smooth, which were useful. On the other hand, the treatment of 2 was nothing like what i would desire in a modern metrology. You need the log of the power of 2 to be something between 1/3 and 1/2 of the base. 60 is pushing the friendship here, i would had liked something more in keeping with 28 or the like.
30 is better suited to weights, as 1+2+4+8=15. In 18, you still need 5 weights, although the 5 proper divisors do nicely here. In this regard, the divisors of 18 (and 120) are more evenly spread on the log wheel than those of 12 and 60. 20 and 117 do a pretty awesome job here, with the 13 divisor mantissa of the cube of the base falling almost exactly at the thirteenths.

Double sharpDozens Demigod
 Joined: Sep 19 2015, 11:02 AM
I think the diacritic (prime, circumflex, whatever) makes most sense when the upper digit reaches triviality and becomes binary. That way, the rules are very simple. You can never have more than one carry, and the worst case is something like octovigesimal (I don't know why I'm so taken with the heptadactyl conworld) 9^ + b^; then we have the two circumflexes cancelling out into a carry, plus the carry inherent in the addition, to get 16^.
The rules get more complicated when the upper digit becomes more than binary, in which case the diacritics seem about the same in complexity as just using a true ternaryondecimal encoding  which acts the same anyway as 23 + 28 = 1'21. In fact, that is also a little easier then separate diacritics. It is not obvious to me that _5 + ^8 should equal "3. It is a little more obvious that 5 + '8 = "3, even if this is so horribly easy to forge. It's still okay since the primes are still subitisable, and I suggest that this works until your top base is quaternary (then the primes get hard to read past ''', which is why I think after Chinese 一二三 we have 四). Incidentally, this allows addition for {40 = 4:10, 42 = 3:14, 48 = 4:12, 56 = 4:14} as well, even though I'm not sure multiplication can be achieved for these easily. They seem to be already approaching the idea of using real mixed radices, which is something I suggest 30 does as well. Even if the memorised multiplications don't need ternaryondecimal addition, the offsets do, and so do multidigit problems!
I would take a lesson from Chinese on the forgery problem. The standard numerals from 110, 一二三四五六七八九十, are very easily forgeable. As a result, there are financial forms to avoid forgery in such circumstances, namely 壹贰叁肆伍陆柒捌玖拾. Not easy to write at all, and giving up most of the resemblance to the numeric forms (though I find the prime digits still are reminiscent of the basic forms), but rendering forgery nearimpossible.
For a base like vigesimal or trigesimal, then, maybe the diacriticised numerals would be used normally, but when forgery was to be avoided a system more like the argam could be used. (It is certainly not impossible to remember the first 30. I remember those quite easily. The first 60 sometimes get mixed up by me and I never can cram in more than about 84 before they spill out again.)
I'm starting to think of {16, 18} as the first transition zone out of the Stevin paradigm, where we know all the addition table but not all the multiplication table. {20, 24, 28} form a second transition zone where we have not yet reached true mixedbase computation, which only becomes a necessary part of using the base at {30}. This seems to fit the binary classification, where {30, 60, 120} behave as though they were past the nominal {32, 64, 128}, I suggest because the latter are unwieldable.
So now I have a revised classification of even 7smooth bases:
Trivial: {2} The range easily used by computers.
Small: {4, 6}. Easily understood, but too small to work with after a while (too simple to be simple, in other words).
Natural, low (humanscale: pure Stevin): {8, 10, 12, 14}. Outstanding, practical bases for civilisation; you can't get any more efficient.
Natural, high (unstable humanscale: Stevin with help): {16, 18, 20, 24, 28}. The range of using purebase symbols with help: the scaffolding in the multiplication, and later addition past 18, however never really goes away. In 16 it is okay because doubling is very quick and the totativeproduct table is small and octalsized; in 18 I think most people will never outgrow the crutches for products like 7*e. (In hexadecimal we have memorised 7*7=31, so 7*e is 62. The roll table is so easy that way. So c*c screams 3*3*4*4 = 3*3*10 = 90. So I may add back 16 to my humanscale list to make {8, 10, 12, 14, 16*}, the asterisk meaning that you can achieve nearly the humanscale efficiency here exceptionally without a fully memorised multiplication table. I still find the small size of 6 aggravating and therefore I do not think I shall add it back.)
Beyond this comes true radixmixing, where you are no longer working in one column at a time.
The rules get more complicated when the upper digit becomes more than binary, in which case the diacritics seem about the same in complexity as just using a true ternaryondecimal encoding  which acts the same anyway as 23 + 28 = 1'21. In fact, that is also a little easier then separate diacritics. It is not obvious to me that _5 + ^8 should equal "3. It is a little more obvious that 5 + '8 = "3, even if this is so horribly easy to forge. It's still okay since the primes are still subitisable, and I suggest that this works until your top base is quaternary (then the primes get hard to read past ''', which is why I think after Chinese 一二三 we have 四). Incidentally, this allows addition for {40 = 4:10, 42 = 3:14, 48 = 4:12, 56 = 4:14} as well, even though I'm not sure multiplication can be achieved for these easily. They seem to be already approaching the idea of using real mixed radices, which is something I suggest 30 does as well. Even if the memorised multiplications don't need ternaryondecimal addition, the offsets do, and so do multidigit problems!
I would take a lesson from Chinese on the forgery problem. The standard numerals from 110, 一二三四五六七八九十, are very easily forgeable. As a result, there are financial forms to avoid forgery in such circumstances, namely 壹贰叁肆伍陆柒捌玖拾. Not easy to write at all, and giving up most of the resemblance to the numeric forms (though I find the prime digits still are reminiscent of the basic forms), but rendering forgery nearimpossible.
For a base like vigesimal or trigesimal, then, maybe the diacriticised numerals would be used normally, but when forgery was to be avoided a system more like the argam could be used. (It is certainly not impossible to remember the first 30. I remember those quite easily. The first 60 sometimes get mixed up by me and I never can cram in more than about 84 before they spill out again.)
I'm starting to think of {16, 18} as the first transition zone out of the Stevin paradigm, where we know all the addition table but not all the multiplication table. {20, 24, 28} form a second transition zone where we have not yet reached true mixedbase computation, which only becomes a necessary part of using the base at {30}. This seems to fit the binary classification, where {30, 60, 120} behave as though they were past the nominal {32, 64, 128}, I suggest because the latter are unwieldable.
So now I have a revised classification of even 7smooth bases:
Trivial: {2} The range easily used by computers.
Small: {4, 6}. Easily understood, but too small to work with after a while (too simple to be simple, in other words).
Natural, low (humanscale: pure Stevin): {8, 10, 12, 14}. Outstanding, practical bases for civilisation; you can't get any more efficient.
Natural, high (unstable humanscale: Stevin with help): {16, 18, 20, 24, 28}. The range of using purebase symbols with help: the scaffolding in the multiplication, and later addition past 18, however never really goes away. In 16 it is okay because doubling is very quick and the totativeproduct table is small and octalsized; in 18 I think most people will never outgrow the crutches for products like 7*e. (In hexadecimal we have memorised 7*7=31, so 7*e is 62. The roll table is so easy that way. So c*c screams 3*3*4*4 = 3*3*10 = 90. So I may add back 16 to my humanscale list to make {8, 10, 12, 14, 16*}, the asterisk meaning that you can achieve nearly the humanscale efficiency here exceptionally without a fully memorised multiplication table. I still find the small size of 6 aggravating and therefore I do not think I shall add it back.)
Beyond this comes true radixmixing, where you are no longer working in one column at a time.

wendy.krieger
The closest we get to antifraud in english, is to use 'only', 'neat', and doublebars to cancel out lower digits, eg "fifty dollars neat" or "====fifty=dollars====" or "fifty dollars only". This stops people adding amounts to the right.
I take your point about using primes, but implementation issues are not something that comes early in baseexploration. The idea of the chinese commercial numbers sounds interesting, and is the sort of thing one could mix into a 'secondseries' number order. I'm not sure. I'd prolly need to see 11 22 33 written in the different digits.
一壹 二贰 三叁 四肆 五伍 六陆 七柒 八捌 九玖 十拾
Base 56, i normally do this 8:7 rather than 4:14. The powers of 2 are easier to remember in 8:7.
66 is normally 6:11,
The only base i use that breaks the divisions high that i usually use is 70 as 7:10.
Heptadactylity is something which facinated me too: Seven is the smallest prime not used in a regular base, and seven and nine are well in the biological range of digits. According to Stephen Jay Gould (The Burgess Shales), there were heptasegmented animals etc in the precambrian world, until the pentadactyls won.
I take your point about using primes, but implementation issues are not something that comes early in baseexploration. The idea of the chinese commercial numbers sounds interesting, and is the sort of thing one could mix into a 'secondseries' number order. I'm not sure. I'd prolly need to see 11 22 33 written in the different digits.
一壹 二贰 三叁 四肆 五伍 六陆 七柒 八捌 九玖 十拾
Base 56, i normally do this 8:7 rather than 4:14. The powers of 2 are easier to remember in 8:7.
66 is normally 6:11,
The only base i use that breaks the divisions high that i usually use is 70 as 7:10.
Heptadactylity is something which facinated me too: Seven is the smallest prime not used in a regular base, and seven and nine are well in the biological range of digits. According to Stephen Jay Gould (The Burgess Shales), there were heptasegmented animals etc in the precambrian world, until the pentadactyls won.

Double sharpDozens Demigod
 Joined: Sep 19 2015, 11:02 AM
BTW, this sort of 'capital numerals' idea similar to the Chinese commercial ones makes mixed radices a little more palatable for me. This way, every time you see a symbol, you treat it in the same way. So writing 12on10 eightyeight as 八8 makes it easier for me to know that while 8 * 4 is going to be 三2, 八 * 4 is going to be 2八. (Alas, I still think of it as first '32' and convert, though since I can do it in octal and tetradecimal now I should think that duodecimal and hexadecimal would be just as possible for me, if I found the time and motivation.)
I still don't think you can teach it to kids, though. Remember that the idea of poking a decimal number into a set of dozenal or tetradecimal columns only works if, while the units are mixedradix all over the place, the numbers are not, so decimal 190 lb can easily be translated as 13 st 8 lb (decimal 190 is tetradecimal d8). If the numbers were mixedbase to begin with, you could not even start teaching this. Only those who'd already learned arithmetic in a pure base would get it, and most would prefer the simplicity of decimal to the 5smoothness of a base like 60 or 120.
The issue is of course creating plausible Chinese transdecimals. I think I previously suggested 夬 for eleven, suggesting the right half of 缺 (missing); it's not really used for anything else today. 打 already means dozen, but it also unfortunately means 'hit'.
Or maybe a better approach is to directly follow the motivation of the alphabetic sequence in English, and use the standard Chinese series for ABCD sort of ranking: the ten celestial stems. This allows you to go up to base 20 before hitting the rankindicators (十 10, 百 100, 千 1000, 万 10000, 亿 1 0000 0000, 兆 1 0000 0000 0000, 京 1 0000 0000 0000 0000; no one remembers anything higher, in my experience). I realise this is naughty of me to repurpose the ranknames, but I suppose it is a little less naughty to use this visual pun (calling 100 a "hundred" even if it's four in binary) if I don't expect the base to be used by the general public.
Thus Chinesestyle capital transdecimals to vigesimal become:
〇一二三四 / 五六七八九 / 甲乙丙丁戊 / 己庚辛壬癸 // 十
0 1 2 3 4 5 6 7 8 9 a b c d e f g h i j 10
ling2 yi1 er4 san1 wu3 liu4 qi1 ba1 jiu3 jia3 yi3 bing3 ding1 wu4 ji3 geng1 xin1 ren2 gui3 shi2
Yes, it's not perfect. I dislike how e, g, h, and j are so much more complicated than the others. Still, it doesn't sound completely unnatural. If you can stomach 18 and 20 as pure bases (the first isn't implausible with scaffolding, and the second is facilitated by knowing decimal), you can go all the way up to alternating {18:20} for 360.
I'm not suggesting that 56 is best handled as 4:14 with primes for the subitising top base, though that is one way to go about doing it. But I'm not personally a fan of mixed radices anymore, so I'm not really thinking much about it.
Maybe if you were to teach kids the 'diacritics' numerals for {20, 24, 28} and then give the full set for the upper range it could work. We use 'infant' typefaces with simplified forms of letters like a and g for kids, after all. My personal experience trying them out by writing a multiplication table in full for them with icarus' argam is that it's still okay up to 20, but beyond that I think the scaffolding from doubling {12, 14} becomes permanent. I've been writing about these using alphabetic transdecimals and I keep stumbling past j.
Maybe {16, 18, 20} form intermediate steps in the march to radixmixing?
I still don't think you can teach it to kids, though. Remember that the idea of poking a decimal number into a set of dozenal or tetradecimal columns only works if, while the units are mixedradix all over the place, the numbers are not, so decimal 190 lb can easily be translated as 13 st 8 lb (decimal 190 is tetradecimal d8). If the numbers were mixedbase to begin with, you could not even start teaching this. Only those who'd already learned arithmetic in a pure base would get it, and most would prefer the simplicity of decimal to the 5smoothness of a base like 60 or 120.
The issue is of course creating plausible Chinese transdecimals. I think I previously suggested 夬 for eleven, suggesting the right half of 缺 (missing); it's not really used for anything else today. 打 already means dozen, but it also unfortunately means 'hit'.
Or maybe a better approach is to directly follow the motivation of the alphabetic sequence in English, and use the standard Chinese series for ABCD sort of ranking: the ten celestial stems. This allows you to go up to base 20 before hitting the rankindicators (十 10, 百 100, 千 1000, 万 10000, 亿 1 0000 0000, 兆 1 0000 0000 0000, 京 1 0000 0000 0000 0000; no one remembers anything higher, in my experience). I realise this is naughty of me to repurpose the ranknames, but I suppose it is a little less naughty to use this visual pun (calling 100 a "hundred" even if it's four in binary) if I don't expect the base to be used by the general public.
Thus Chinesestyle capital transdecimals to vigesimal become:
〇一二三四 / 五六七八九 / 甲乙丙丁戊 / 己庚辛壬癸 // 十
0 1 2 3 4 5 6 7 8 9 a b c d e f g h i j 10
ling2 yi1 er4 san1 wu3 liu4 qi1 ba1 jiu3 jia3 yi3 bing3 ding1 wu4 ji3 geng1 xin1 ren2 gui3 shi2
Yes, it's not perfect. I dislike how e, g, h, and j are so much more complicated than the others. Still, it doesn't sound completely unnatural. If you can stomach 18 and 20 as pure bases (the first isn't implausible with scaffolding, and the second is facilitated by knowing decimal), you can go all the way up to alternating {18:20} for 360.
I'm not suggesting that 56 is best handled as 4:14 with primes for the subitising top base, though that is one way to go about doing it. But I'm not personally a fan of mixed radices anymore, so I'm not really thinking much about it.
Maybe if you were to teach kids the 'diacritics' numerals for {20, 24, 28} and then give the full set for the upper range it could work. We use 'infant' typefaces with simplified forms of letters like a and g for kids, after all. My personal experience trying them out by writing a multiplication table in full for them with icarus' argam is that it's still okay up to 20, but beyond that I think the scaffolding from doubling {12, 14} becomes permanent. I've been writing about these using alphabetic transdecimals and I keep stumbling past j.
Maybe {16, 18, 20} form intermediate steps in the march to radixmixing?

wendy.krieger
The idea of using secondseries numbers to represent commercial numbers, would allow a more complex form than say, roman numbers, and still give them some currency. For example, if you had to write a currency amount AJJ for 100, then people would more likely learn the symbols.
When i write the babylon sumerian numbers, i tend to follow their character structure. So they use blockcharacters like the chinese, which you can spread the blocks, but not parts of the block. So A,B,C,D,E represent 1050, and 19 the units. 38 is C8, and so forth. It works here because the heavenletters are different to the earthletters even in their own script.
But i found that alternating arithmetic works on alternating columns, not alternating symbols in the column. So '5' means five of the unit in that column, like five, fifty. The idea of 5 and E works less in this arithmetic.
I have been playing around with the mixedcolumn idea, because it's more common in the older European measurement systems, and it is the system that Fibonacci uses.
The way i read how chinese numbers work, is that 三百 is '300', the is no need for a zero here, because the 百 points to a particular column of counting, and 三 the value in the column. In western letters, i write this as 3C (3 centum).
Weights don't work like counting numbers, in that where one cow is one, and twenty cows, even for being in a different column, is still 20, you don't have to think of a stone as 14 lb or 224 oz. It can be a unit itself, and you can say you weigh say 192, meaning 19 stones, 2 pounds.
In this sense, you still have columns, but no 'unit'.
The idea came to me, that you could use some kind of fractionnumber, where each column consists of a numerator and the fullheight of the column. So instead of writing something like 19 st 2 lb, you might write something like v2 o3 dq2, meaning the first column is 20, you have 2, the second column is 8, you have 3, the third column is 14, you have 2. Of course, when you add, you carry over the letter (like o = 8), so if you subtract o4 dq0 from this, you get v1 o7 dq2.
Multiplication and division would be by method of invoice, which works quite well here.
When i write the babylon sumerian numbers, i tend to follow their character structure. So they use blockcharacters like the chinese, which you can spread the blocks, but not parts of the block. So A,B,C,D,E represent 1050, and 19 the units. 38 is C8, and so forth. It works here because the heavenletters are different to the earthletters even in their own script.
But i found that alternating arithmetic works on alternating columns, not alternating symbols in the column. So '5' means five of the unit in that column, like five, fifty. The idea of 5 and E works less in this arithmetic.
I have been playing around with the mixedcolumn idea, because it's more common in the older European measurement systems, and it is the system that Fibonacci uses.
The way i read how chinese numbers work, is that 三百 is '300', the is no need for a zero here, because the 百 points to a particular column of counting, and 三 the value in the column. In western letters, i write this as 3C (3 centum).
Weights don't work like counting numbers, in that where one cow is one, and twenty cows, even for being in a different column, is still 20, you don't have to think of a stone as 14 lb or 224 oz. It can be a unit itself, and you can say you weigh say 192, meaning 19 stones, 2 pounds.
In this sense, you still have columns, but no 'unit'.
The idea came to me, that you could use some kind of fractionnumber, where each column consists of a numerator and the fullheight of the column. So instead of writing something like 19 st 2 lb, you might write something like v2 o3 dq2, meaning the first column is 20, you have 2, the second column is 8, you have 3, the third column is 14, you have 2. Of course, when you add, you carry over the letter (like o = 8), so if you subtract o4 dq0 from this, you get v1 o7 dq2.
Multiplication and division would be by method of invoice, which works quite well here.

OschkarDozens Disciple
 Joined: Nov 19 2011, 01:07 AM
I’ll say that I have the alphabetic transdecimals memorized up to k, and then I know {o = 24, s = 28, u = 30, w = 32, A = 36, Y = 60, ぬ = 84, サ = 120} because of baseannotation subscripts, with digits from 62 onward being the Japanese kana convention you proposed somewhere on this forum. Sometimes I remember {40, 42, 48, 72, 90, 96}, but most of the time I have to count on from a familiar digit.Double sharp @ Dec 19 2016, 01:54 PM wrote: Maybe if you were to teach kids the 'diacritics' numerals for {20, 24, 28} and then give the full set for the upper range it could work. We use 'infant' typefaces with simplified forms of letters like a and g for kids, after all. My personal experience trying them out by writing a multiplication table in full for them with icarus' argam is that it's still okay up to 20, but beyond that I think the scaffolding from doubling {12, 14} becomes permanent. I've been writing about these using alphabetic transdecimals and I keep stumbling past j.

Double sharpDozens Demigod
 Joined: Sep 19 2015, 11:02 AM
I can't find that post of mine, though I remember proposing that up to decimal 160 as a base. (Would've preferred to support 168, though, since it's the highest I ever considered trying as 12on14.) Maybe it's a little more transparent if you know the usual order. (I considered following the iroha instead as an analogue of 'ABC' from music, but I think choosing otherwise was a better idea.)
Since both of us seem to run out of remembering alphabetic transdecimals after vigesimal, I'll use that as a tentative upper limit to purebase notation.
This actually makes for one annoying thing I dislike about {24, 28} as {2:12, 2:14}  more the former, because sevenths are frankly not very important. You see, it blunts fractions that have an odd number in the denominator. This also takes a toll on the lines, because some of the lines that would have been divisors don't hit "0^" as well as "0" and thus look like semidivisors and are harder to learn.
Let's try base 24 as double 12:
1, 2, 3, 4, 5, 6, 7, 8, 9, a, b, 0^ (trivial)
2, 4, 6, 8, a, 0^, 2^, 4^, 6^, 8^, a^, 10 (divisor)
3, 6, 9, 0^, 3^, 6^, 9^, 10, 13, 16, 19, 10^ (divisor)
4, 8, 0^, 4^, 8^, 10, 14, 18, 10^, 14^, 18^, 20 (divisor)
5, a, 3^, 8^, 11, 16, 1b, 14^, 19^, 22, 27, 20^ (alpha, but looks opaque)
6, 0^, 6^, 10, 16, 10^, 16^, 20, 26, 20^, 26^, 30 (divisor)
7, 2^, 9^, 14, 1b, 16^, 21, 28, 23^, 2a^, 35, 30^ (opaque)
8, 4^, 10, 18, 14^, 20, 28, 24^, 30, 38, 34^, 40 (divisor, but looks like semidivisor)
9, 6^, 13, 10^, 19^, 26, 23^, 30, 39, 36^, 43, 40^ (semidivisor)
a, 8^, 16, 14^, 22, 20^, 2a^, 38, 36^, 44, 42^, 50 (semitotative)
b, a^, 19, 18^, 27, 26^, 35, 34^, 43, 42^, 51, 50^ (opaque, but looks like omega)
0^, 10, 10^, 20, 20^, 30, 30^, 40, 40^, 50, 50^, 60 (divisor)
The difficulty seems not far from that of duodecimal, except that:
1. The 'false omega' is a bit harder (because the units and 'tens' don't fall and rise in synchrony)
2. Maybe it's just that we're not used to such markers, but I keep thinking that "40^" should be smaller than "43", when it really isn't.
3. This isn't the full table and later you'll need to multiply 5^ by 7^.
In fact, the digit map looks just like the lower subbase. Octovigesimal I am more concerned about. 4 is a divisor, but it looks like a semidivisor. 9 looks opaque when it shouldn't, but 5 cancels it out. And the false alpha patterns like "3, 6, 9, c, 1^, 4^, 7^, a^, d^, 12, 15, 18, 1b, 10^" are not as nice and easy as a real one would be  so all neighbourfactors get negatively impacted and look practically opaque.
This makes {24} have easy {1, 2, 3, 4, 6, 0^} and pretty hard {5, 7, 8, 9, a, b}. But this is about how hard 12 would be if no one saw the patterns, so it must still be okay.
But {28} has only easy {1, 2, 7, 0^} and pretty hard {3, 4, 5, 6, 8, 9, a, b, c, d}, as if tetradecimal had no patterns shown, so it does not look okay.
{20} has easy {1, 2, 5, 0^} and pretty hard {3, 4, 6, 7, 8, 9} under this scheme, but this is not so bad because decimal is pretty easy even if no one sees the patterns. Besides, it may not actually need accented numerals.
So I think my humanscale is now {8, 10, 12, 14}, with a special marginal {16}, as well as perhaps {18, 20, 24} in the high range if suitably alleviated as humanunderstandable  but not {28, 30, 32, 36}. I exclude senary mainly because multiplying 3digit numbers has to become a mental exercise.
The next thing to do would be to analyse the efficiencies of {16, 18, 20, 24} in my metric of number of operations per product, noting that {16} is probably buoyed by the ease of doubling and halving.
Since both of us seem to run out of remembering alphabetic transdecimals after vigesimal, I'll use that as a tentative upper limit to purebase notation.
This actually makes for one annoying thing I dislike about {24, 28} as {2:12, 2:14}  more the former, because sevenths are frankly not very important. You see, it blunts fractions that have an odd number in the denominator. This also takes a toll on the lines, because some of the lines that would have been divisors don't hit "0^" as well as "0" and thus look like semidivisors and are harder to learn.
Let's try base 24 as double 12:
1, 2, 3, 4, 5, 6, 7, 8, 9, a, b, 0^ (trivial)
2, 4, 6, 8, a, 0^, 2^, 4^, 6^, 8^, a^, 10 (divisor)
3, 6, 9, 0^, 3^, 6^, 9^, 10, 13, 16, 19, 10^ (divisor)
4, 8, 0^, 4^, 8^, 10, 14, 18, 10^, 14^, 18^, 20 (divisor)
5, a, 3^, 8^, 11, 16, 1b, 14^, 19^, 22, 27, 20^ (alpha, but looks opaque)
6, 0^, 6^, 10, 16, 10^, 16^, 20, 26, 20^, 26^, 30 (divisor)
7, 2^, 9^, 14, 1b, 16^, 21, 28, 23^, 2a^, 35, 30^ (opaque)
8, 4^, 10, 18, 14^, 20, 28, 24^, 30, 38, 34^, 40 (divisor, but looks like semidivisor)
9, 6^, 13, 10^, 19^, 26, 23^, 30, 39, 36^, 43, 40^ (semidivisor)
a, 8^, 16, 14^, 22, 20^, 2a^, 38, 36^, 44, 42^, 50 (semitotative)
b, a^, 19, 18^, 27, 26^, 35, 34^, 43, 42^, 51, 50^ (opaque, but looks like omega)
0^, 10, 10^, 20, 20^, 30, 30^, 40, 40^, 50, 50^, 60 (divisor)
The difficulty seems not far from that of duodecimal, except that:
1. The 'false omega' is a bit harder (because the units and 'tens' don't fall and rise in synchrony)
2. Maybe it's just that we're not used to such markers, but I keep thinking that "40^" should be smaller than "43", when it really isn't.
3. This isn't the full table and later you'll need to multiply 5^ by 7^.
In fact, the digit map looks just like the lower subbase. Octovigesimal I am more concerned about. 4 is a divisor, but it looks like a semidivisor. 9 looks opaque when it shouldn't, but 5 cancels it out. And the false alpha patterns like "3, 6, 9, c, 1^, 4^, 7^, a^, d^, 12, 15, 18, 1b, 10^" are not as nice and easy as a real one would be  so all neighbourfactors get negatively impacted and look practically opaque.
This makes {24} have easy {1, 2, 3, 4, 6, 0^} and pretty hard {5, 7, 8, 9, a, b}. But this is about how hard 12 would be if no one saw the patterns, so it must still be okay.
But {28} has only easy {1, 2, 7, 0^} and pretty hard {3, 4, 5, 6, 8, 9, a, b, c, d}, as if tetradecimal had no patterns shown, so it does not look okay.
{20} has easy {1, 2, 5, 0^} and pretty hard {3, 4, 6, 7, 8, 9} under this scheme, but this is not so bad because decimal is pretty easy even if no one sees the patterns. Besides, it may not actually need accented numerals.
So I think my humanscale is now {8, 10, 12, 14}, with a special marginal {16}, as well as perhaps {18, 20, 24} in the high range if suitably alleviated as humanunderstandable  but not {28, 30, 32, 36}. I exclude senary mainly because multiplying 3digit numbers has to become a mental exercise.
The next thing to do would be to analyse the efficiencies of {16, 18, 20, 24} in my metric of number of operations per product, noting that {16} is probably buoyed by the ease of doubling and halving.

Double sharpDozens Demigod
 Joined: Sep 19 2015, 11:02 AM
Cursory analysis:
In hexadecimal with odd products and a roll table: the roll table has 4*8=32 unique facts and the totative products have a further 7*8 = 56 (since the trivial 1* row is in both). This makes 88 onestep facts out of 136. The remaining 48 are twostep (getting to a result and then multiplying from the roll table); at least they feel that way because {1, 2, 4, 8} are such nice digits to work with here. So that makes for 1.35 unique operations per product, and taking that root of 16 gives the efficiency of Stevinian base 7.8, or nearly octal. That's not bad, and makes me think that {16} exceptionally ranks only just under the true humanscale {8, 10, 12, 14}.
Octodecimal has {1, 2, 3, 4, 6, 8, 9, c, g, 10} as regulars, making a decimalsized regular product table of 55 unique facts out of the 171 unique facts. The semitotative facts require a second step here and the totative facts like a*b require yet a third of nontrivial addition or subtraction. The nontrivial totatives are {5, 7, b, d, h}, making a quinarysized totative product table of 15 facts. The other 101 are semitotative facts. Now 18^(171/302) is about 5.1, so the efficiency has plummeted once more to that of quinary. Thus octodecimal seems completely inefficient if the scaffolding is permanent, and is only efficient if you can take it down. I am inclined to doubt the latter, having tried to write out its multiplication table before and never having succeeded on the first try without mistakes.
Memorising the upper quadrant of the vigesimal table means that out of the 210 facts, 55 are onestep, 55 are threestep, and the other 100 are twostep. Actually if you do the maths for both {20, 24} you find that the average multiplication needs two steps, so the efficiency seems to be squarerooted to below that of quinary.
In hexadecimal with odd products and a roll table: the roll table has 4*8=32 unique facts and the totative products have a further 7*8 = 56 (since the trivial 1* row is in both). This makes 88 onestep facts out of 136. The remaining 48 are twostep (getting to a result and then multiplying from the roll table); at least they feel that way because {1, 2, 4, 8} are such nice digits to work with here. So that makes for 1.35 unique operations per product, and taking that root of 16 gives the efficiency of Stevinian base 7.8, or nearly octal. That's not bad, and makes me think that {16} exceptionally ranks only just under the true humanscale {8, 10, 12, 14}.
Octodecimal has {1, 2, 3, 4, 6, 8, 9, c, g, 10} as regulars, making a decimalsized regular product table of 55 unique facts out of the 171 unique facts. The semitotative facts require a second step here and the totative facts like a*b require yet a third of nontrivial addition or subtraction. The nontrivial totatives are {5, 7, b, d, h}, making a quinarysized totative product table of 15 facts. The other 101 are semitotative facts. Now 18^(171/302) is about 5.1, so the efficiency has plummeted once more to that of quinary. Thus octodecimal seems completely inefficient if the scaffolding is permanent, and is only efficient if you can take it down. I am inclined to doubt the latter, having tried to write out its multiplication table before and never having succeeded on the first try without mistakes.
Memorising the upper quadrant of the vigesimal table means that out of the 210 facts, 55 are onestep, 55 are threestep, and the other 100 are twostep. Actually if you do the maths for both {20, 24} you find that the average multiplication needs two steps, so the efficiency seems to be squarerooted to below that of quinary.