Is The Decimal 12x Table Still Relevant?

icarusDozens Demigod
 Joined: Apr 11 2006, 12:29 PM
This article by a British writer at Wolfram questions the logic of learning the decimal 12x table. Link. Should we double down on decimal and memorize "near factors of 100" like 6 x 17?

Double sharpDozens Demigod
 Joined: Sep 19 2015, 11:02 AM
Yes! He suggests learning the squares and the powers of two! That lets you have some fun playing with numbers, and 16 * 16 is honestly more useful than 15 * 16. Furthermore, 2^24 = 16777216 is somewhat useful in a way that 92564 * 18437 = 1706602468 just isn't, as a lame example.
Learning nearfactors of 100 essentially lets you apply RDM to centesimal, handling two decimal digits at once.
Learning nearfactors of 100 essentially lets you apply RDM to centesimal, handling two decimal digits at once.

icarusDozens Demigod
 Joined: Apr 11 2006, 12:29 PM
Here's my responce (via Facebook): "This diagram shows that much of the multiplication table is related to 12, because 12 is a product of the two smallest primes. Purple and red numbers are divisors of 12. Orange and peach numbers have prime divisors in common with 12, the peach being multiples of 12 and its prime divisors. The pink numbers show the places where 12 appears in the table. The yellowish numbers have at least one prime divisor in common with 12 but also at least one prime divisor coprime to 12. Everything else is coprime to 12. Elevens are pretty much a given due to their simplicity, but 12s are highly useful."

Piotr
I earlier considered 11x9 (to 99) and 14x7 (to 98) for fun. I want a table that goes from 0 up to 32x32 (or even 64x64, which would be great) in senary, octal, decimal and dozenal.

OschkarDozens Disciple
 Joined: Nov 19 2011, 01:07 AM
I actually do something like RDM in centesimal to multiply large decimal numbers when I don't have a calculator. I'll actually think in myriads and hundreds, unless there's a number like 11007 that is much easier to do as thousands. I'll do your lame example:Double sharp @ Jan 5 2016, 03:07 AM wrote: Yes! He suggests learning the squares and the powers of two! That lets you have some fun playing with numbers, and 16 * 16 is honestly more useful than 15 * 16. Furthermore, 2^24 = 16777216 is somewhat useful in a way that 92564 * 18437 = 1706602468 just isn't, as a lame example.
Learning nearfactors of 100 essentially lets you apply RDM to centesimal, handling two decimal digits at once.
92564 * 18437 = 9'25'64 * 1'84'37
64 * 37 = 64 * (32 + 5) = 20'48 + 320 = 23'68 (write down 68, carry the 23)
64 * 84 = 74^2  10^2 = 70 * 78 + 16  100 = 54'60 + 16  100 = 53'76 (write down 76 + 23 = 99, carry the 53)
64 * 1 = 64 (write down 64 + 53 = 1'17)
1,17'99'68
25 * 37 = 37'00 / 4 = 9'25 (write down 25, carry the 9)
25 * 84 = 84'00 / 4 = 21'00 (write down 00 + 9 = 09, carry the 21)
25 * 1 = 25 (write down 25 + 21 = 46)
46,09'25'00
9 * 37 = 9 * 9'99 / 27 = 9'99 / 3 = 3'33 (write down 33, carry the 3)
9 * 84 = 3 * 2'52 = 7'56 (write down 56 + 3 = 59, carry the 7)
9 * 1 = 9 (write down 9 + 7 = 16)
16'59,33'00'00
16'59,33'00'00 + 46,09'25'00 + 1,17'99'68 = 17'06,60'24'68

icarusDozens Demigod
 Joined: Apr 11 2006, 12:29 PM
Okay folks I did some work on this in Mathematica (about an hour). I translated all the author McLoone's functions to handle duodecimal output (note, the tickmarks are unfortunately decimal, but at least I got them to snap to dozenalrelevant ticks). Because I need to include six images, I'm going to post six times ( ).
The first argument has a chart analogous to this:
Regarding the decimal chart (let's call it CHART 1), the author had written, "Interestingly, most of the improvement happens by the time you know your 7 times table. The odd bump at 10 is because the ability to approximate relies implicitly on knowing your 10 times table already (to be able to handle the trailing zeros)."
The dozenal chart appears to be similar to the decimal. I'll have to overlay them to really make a good comparison.
Note, I used a coarser sample, using a random range of 12^4 vs. 10^6 and 12^3 vs 10^5 samples. I didn't want to be here all night! As a result, my graphs are "coarser" but still reveal neat things about the duodecimal multiplication table.
The first argument has a chart analogous to this:
Code: Select all
ListLinePlot[Table[{table, meanErrorUniform[table]}, {table, 1, 36}],
Ticks > {3 Range@ 12, Range[12]/12}]
The dozenal chart appears to be similar to the decimal. I'll have to overlay them to really make a good comparison.
Note, I used a coarser sample, using a random range of 12^4 vs. 10^6 and 12^3 vs 10^5 samples. I didn't want to be here all night! As a result, my graphs are "coarser" but still reveal neat things about the duodecimal multiplication table.

icarusDozens Demigod
 Joined: Apr 11 2006, 12:29 PM
McLoone's next chart (CHART 2) starts after he writes this: "We can work out how much relative improvement there is in the typical error for each extra table learned."
This chart looks much different than its decimal cousin. The first numbers merit a second post  I'll return to them next. The "cyclical" nature of the decimal plot doesn't seem to manifest and I originally considered the coarseness of my sampling. (I think the "going negative" of some figures demonstrates the margin of error due to coarseness.) It is interesting to see that spike at *41. Looking more closely, we see that it "makes more of a difference" to learn the multiplication facts of primes coprime to the dozen and their powers, as well as nondivisor regular numbers like *14, *16. I don't know why *23 doesn't fare better, but *24 merits study. I think all the regular numbers that are multiples of regular figures and a power of the dozen (i.e., *20, *30, *40, etc.) are "zeros" in the graph.
Code: Select all
ListLinePlot[Table[{n, (meanErrorUniform[n  1]  meanErrorUniform[n])/
meanErrorUniform[n  1]}, {n, 2, 51}], AxesOrigin > {0, 0},
PlotRange > All, Ticks > {3 Range@17, Range[12]/12}]

icarusDozens Demigod
 Joined: Apr 11 2006, 12:29 PM
Let's look closer at the "home range" of numbers "in the standard multiplication table". Here we see in comparison with the decimal CHART 2 that the dozenal numbers {2, 3, 4, 5} merit less and {6, 7, 8, 9} merit more than they do in the decimal table. The curious thing is the "bump" at the 5x line. There is a second "hill" associated with {8, 9} before dropping off at *10  2 (i.e., ten).

icarusDozens Demigod
 Joined: Apr 11 2006, 12:29 PM
Looking at McLoone's CHART 3:
Dozenally, the "return on effort" according to the author, drops off as it does decimally with a couple differences. Overall, the central divisor pair {3, 4} and even 5 merit less than they do in the decimal table, with the pair more depressed in merit than 5. There is a noticeable "kink" at 5, 8, and 9 that brings the latter two semidivisors up in merit.
Again, north of the dozen the "cyclical" section that runs "nicely" in the decimal chart between multiples of ten is absent in our chart. I think these crenelations have to do with either the pattern of regulars north of the dozen, or the more caustic "feast or famine" treatment of numbers, due to their being "copacetic" with twelve or coprime to it.
Code: Select all
ListLinePlot[
Table[{n, (meanErrorUniform[n  1]  meanErrorUniform[n])/
meanErrorUniform[n  1]/(n^2  (n  1)^2)}, {n, 2, 36}],
AxesOrigin > {0, 0}, PlotRange > {1/144, 1/36},
Ticks > {3 Range@ 12, Range[144]/144}]
Again, north of the dozen the "cyclical" section that runs "nicely" in the decimal chart between multiples of ten is absent in our chart. I think these crenelations have to do with either the pattern of regulars north of the dozen, or the more caustic "feast or famine" treatment of numbers, due to their being "copacetic" with twelve or coprime to it.

icarusDozens Demigod
 Joined: Apr 11 2006, 12:29 PM
Now we get to McLoone's Bedford number studies (CHART 4):
Looks pretty much like the decimal, except the cusp happens at *10 instead of ten and at *20 instead of twenty.
Code: Select all
ListLinePlot[{#, meanErrorBenford[#]} & /@ Range@ 24,
Ticks > {3 Range@ 12, Range[12]/12}]

icarusDozens Demigod
 Joined: Apr 11 2006, 12:29 PM
The last graph looks like this:
Again, looks like the decimal table. In order to scrutinize what this says, we need to look at the numbers for each point.
Code: Select all
ListLinePlot[
Table[{n, ((meanErrorBenford[n]  meanErrorBenford[n  1])/(
n^2  (n  1)^2))}, {n, 2, 24}], PlotRange > {1/144, 1/36},
Ticks > {3 Range@ 8, Range[144]/144}]

icarusDozens Demigod
 Joined: Apr 11 2006, 12:29 PM
Now let's bear in mind that McLoone went down one of the many roads out of Rome when he wrote:
We have the benefit of having performed some of this, more from his first premise than the second (not really at all from his muchexplored third in this article until now).
Having performed these exercises, we might conclude the following:
1. It seems the dozenal table eases memorization for {3, 4} (that slightly don't merit as much study as they would in the decimal, where 3 is coprime to ten and 4 is a semidivisor of ten) and {8, 9} (that slightly merits more study than in their decimal analogs, perhaps because they are dozenal semidivisors). The ease of memorization derives from the patterns we are all familiar with in the duodecimal table.
2. It pays to be acquainted with the duodecimal 5x facts. However it is really only on par with the importance of knowing the 5x facts in base ten, where 5 is a divisor. It may pay off to know the 7x facts (I think it does, perhaps the peak at 7 was blunted by my smaller sample size). Of course, we know the 5x facts are most challenging in dozenal. The knowledge of the ten x facts doesn't seem to be as "important" per the study.
3. I think this "third route" that McLoone studied and that I had dozenalized seems to indicate that Treisaran's SPD technique is paramount. It has one know the 5x facts to *100. I think we sort of knew that before this article.
4. We need to study the granularity "north" of the dozen.
I am not sure the charts really hint at the dozenalvs.decimal question at all.
Now in the course of learning the multiplication table in school, kids seem to be challenged (obviously in decimal) by learning pretty much any line except the 2x, 5x, and 10x facts (if we include the 12x table, the 11x facts are also easy). (1x and 10x are trivial). I think that kids would best understand the dozenal 2x, 3x, and 4x facts (again, 1x and *10x are trivial). We've examined the "difficulty" question in other threads (I'll find them later, need to sign off).
I don't buy McLoone's whole "100 vs 144 facts to memorize" bit. (He's right to think about 55 vs. 78, I see). I think that the utility of knowing your 12's in the decimal table _vastly_ outweighs the couple weeks in second or third grade one spends memorizing it. Metric people get all hung up on the decimalization thing, but if they would think about it more widely we'd see that the factors {2, 3}, and then by extension all their multiples {4, 6, 8, 9, 12, 16, 18, 24, 27, etc.} crop up more often than those of {2, 5}.
He did write two other good uses that he doesn't explore at all before making his conclusion.So, now our "where do I draw the line" question becomes "how much better is a typical approximate calculation if I know up to the 12 times table compared to only knowing my 10 times table?" Let's investigate.
We have the benefit of having performed some of this, more from his first premise than the second (not really at all from his muchexplored third in this article until now).
Having performed these exercises, we might conclude the following:
1. It seems the dozenal table eases memorization for {3, 4} (that slightly don't merit as much study as they would in the decimal, where 3 is coprime to ten and 4 is a semidivisor of ten) and {8, 9} (that slightly merits more study than in their decimal analogs, perhaps because they are dozenal semidivisors). The ease of memorization derives from the patterns we are all familiar with in the duodecimal table.
2. It pays to be acquainted with the duodecimal 5x facts. However it is really only on par with the importance of knowing the 5x facts in base ten, where 5 is a divisor. It may pay off to know the 7x facts (I think it does, perhaps the peak at 7 was blunted by my smaller sample size). Of course, we know the 5x facts are most challenging in dozenal. The knowledge of the ten x facts doesn't seem to be as "important" per the study.
3. I think this "third route" that McLoone studied and that I had dozenalized seems to indicate that Treisaran's SPD technique is paramount. It has one know the 5x facts to *100. I think we sort of knew that before this article.
4. We need to study the granularity "north" of the dozen.
I am not sure the charts really hint at the dozenalvs.decimal question at all.
Now in the course of learning the multiplication table in school, kids seem to be challenged (obviously in decimal) by learning pretty much any line except the 2x, 5x, and 10x facts (if we include the 12x table, the 11x facts are also easy). (1x and 10x are trivial). I think that kids would best understand the dozenal 2x, 3x, and 4x facts (again, 1x and *10x are trivial). We've examined the "difficulty" question in other threads (I'll find them later, need to sign off).
I don't buy McLoone's whole "100 vs 144 facts to memorize" bit. (He's right to think about 55 vs. 78, I see). I think that the utility of knowing your 12's in the decimal table _vastly_ outweighs the couple weeks in second or third grade one spends memorizing it. Metric people get all hung up on the decimalization thing, but if they would think about it more widely we'd see that the factors {2, 3}, and then by extension all their multiples {4, 6, 8, 9, 12, 16, 18, 24, 27, etc.} crop up more often than those of {2, 5}.

wendy.krieger
Let's look at the tables.
The teaching of tables as eg 5Ã—1 to 5Ã—12, then 6Ã—1 by 6Ã—12, do represent 144 facts or 100 facts.
In multiplication, there is no great delay in putting 7Ã—8 for 8Ã—7 at random points. In practice, a table this size might well have failures at the 1% level. But if one is going to rely on this to reduce 'the number of facts', it does place an impost on speed. In essence, you have to look at each pair of numbers, and pick the smaller, then find that product.
Although it is presented as '144 facts' etc, this is far from the truth. Recall the learning is given as single lists. Perusing student tables, one finds talk of 'the eighttimes tables' or 'the fivetimes tables', &c, rather than the complete multiplication table. And here is where we find the efficiency.
The actual calculations are a series of short multiplications, one loads just the 'fivetimes' tables or the 'eighttimes' tables. That is, 8Ã—7 is different to 7Ã—8, because they're in 'different tables'. This presents the lag.
In division, including square roots (which is division with changing divisors), the thing is a question of 'running down the list' of a loaded table. So if you're current divison is '5', then it's the fivetimes tables that are the primary point of load. When this is decided, the process is again short multiplication with 5 loaded (ie 12 facts).
DD Tables
It would be remiss of me should i not mention the dickerdozen tables, and their effects on calculation.
The lag with DD is supprisingly less than multiplication, because in DD, both numbers come together always, while in multiplication, there is a slight dwell between finding the first and second numbers, which are invariably separate entries.
Although I have reccomended learning the DD table for the alternating base of choice, the reality is that DD works supprisingly well as you know the multiplication tables as far as the digits.
For example, if you don't regularly use base 17, it is nearly as fast, and somewhat more accurate, to do the calculation in a known base, eg 10 or 12, and then do a DD to 17. The order of columns in alternating bases, like 70 or 77 have little effect when the DD is done directly into decimal and back. Note on the other hand that in base 77, you still have to construct the alternate divisor (here by 11), and this can indeed be done by 11 DD 10 DD 7 if you can't do 11 DD 7 directly. It is a slight impost, but occurs only infrequently that it's not a worry.
Knowing the DD tables both forward and reverse, is similar to the tables like
eight dozen and three is ninetynine, ninetynine is eight dozen three.
DD is blazingly fast enough to allow one to use decimal tables throughout, with DD of the result in the tensstaff.
Multiple Bases
One of the queries raised, is why not do the high arithmetic in dozenal and the low in decimal. Mathematically, it's quite possible, but my experience here is that the impost is so great that it's somewhat less efficient than a single base.
What happens, is that one has to first figure out where the digits are going to go (z), then load the appropriate tables ( 5Ã— z), and then do the calculation. When one does it in one base, one still loads just one table (5Ã—), and then when the result is commited at a place demanding z, one does DD.
DD is hughly efficient, and it grows on you much faster than multiplication. In practice, if one uses the sort of punctuation I have explained elsewhere, then DD is integrated into 'reading/writing over the point'.
The teaching of tables as eg 5Ã—1 to 5Ã—12, then 6Ã—1 by 6Ã—12, do represent 144 facts or 100 facts.
In multiplication, there is no great delay in putting 7Ã—8 for 8Ã—7 at random points. In practice, a table this size might well have failures at the 1% level. But if one is going to rely on this to reduce 'the number of facts', it does place an impost on speed. In essence, you have to look at each pair of numbers, and pick the smaller, then find that product.
Although it is presented as '144 facts' etc, this is far from the truth. Recall the learning is given as single lists. Perusing student tables, one finds talk of 'the eighttimes tables' or 'the fivetimes tables', &c, rather than the complete multiplication table. And here is where we find the efficiency.
The actual calculations are a series of short multiplications, one loads just the 'fivetimes' tables or the 'eighttimes' tables. That is, 8Ã—7 is different to 7Ã—8, because they're in 'different tables'. This presents the lag.
In division, including square roots (which is division with changing divisors), the thing is a question of 'running down the list' of a loaded table. So if you're current divison is '5', then it's the fivetimes tables that are the primary point of load. When this is decided, the process is again short multiplication with 5 loaded (ie 12 facts).
DD Tables
It would be remiss of me should i not mention the dickerdozen tables, and their effects on calculation.
The lag with DD is supprisingly less than multiplication, because in DD, both numbers come together always, while in multiplication, there is a slight dwell between finding the first and second numbers, which are invariably separate entries.
Although I have reccomended learning the DD table for the alternating base of choice, the reality is that DD works supprisingly well as you know the multiplication tables as far as the digits.
For example, if you don't regularly use base 17, it is nearly as fast, and somewhat more accurate, to do the calculation in a known base, eg 10 or 12, and then do a DD to 17. The order of columns in alternating bases, like 70 or 77 have little effect when the DD is done directly into decimal and back. Note on the other hand that in base 77, you still have to construct the alternate divisor (here by 11), and this can indeed be done by 11 DD 10 DD 7 if you can't do 11 DD 7 directly. It is a slight impost, but occurs only infrequently that it's not a worry.
Knowing the DD tables both forward and reverse, is similar to the tables like
eight dozen and three is ninetynine, ninetynine is eight dozen three.
DD is blazingly fast enough to allow one to use decimal tables throughout, with DD of the result in the tensstaff.
Multiple Bases
One of the queries raised, is why not do the high arithmetic in dozenal and the low in decimal. Mathematically, it's quite possible, but my experience here is that the impost is so great that it's somewhat less efficient than a single base.
What happens, is that one has to first figure out where the digits are going to go (z), then load the appropriate tables ( 5Ã— z), and then do the calculation. When one does it in one base, one still loads just one table (5Ã—), and then when the result is commited at a place demanding z, one does DD.
DD is hughly efficient, and it grows on you much faster than multiplication. In practice, if one uses the sort of punctuation I have explained elsewhere, then DD is integrated into 'reading/writing over the point'.

randyhelzerman
Perhaps we should double down on Sexigesmial :)

wendy.krieger
Sixty is less efficient than 120, for the reason that 106 = 4, while 1210=2.
The point is that numbers would occur in the table that is the highest digit squared, which gives in 60, these: 7*9=1.03, 8*8=1.04, 8*9 = 1.12, and 9*9=1.21. (along with 9*7 and 9*8), or six instances
In twelfty, the only instance is E*E = 1.01
The point is that numbers would occur in the table that is the highest digit squared, which gives in 60, these: 7*9=1.03, 8*8=1.04, 8*9 = 1.12, and 9*9=1.21. (along with 9*7 and 9*8), or six instances
In twelfty, the only instance is E*E = 1.01

RutheRegular
 Joined: Feb 27 2006, 09:23 PM
I don't know how many of you learnt your multiplication tables to 12 x 12, but for people my age, (75) it was 12 x 12 as at that time we were still using Imperial measures with 1 foot = 12 inches and 1 shilling = 12 pennies, that facility served us very well. However, it is no less useful now, and I can still calculate a total faster than the young shop assistants because of it.
To finish, I don't see it matters what you use, but the higher your memory of multiplications the better it is no matter whether you are using a metric or non metric system.
To finish, I don't see it matters what you use, but the higher your memory of multiplications the better it is no matter whether you are using a metric or non metric system.
Why a Roman pocket abacus? They used dozenal fractions as their main form of fractions, 12 inches per foot & originally 12 oz per pound (inch=ounce=uncia=1/12). Columns 1 & 2 of the abacus are for dozenal fractions, column two for twelfths and column one, dozenal fractions of a twelfth. Columns 3 through 8 provided a decimal place value system with values from 1s to millions where each lower bead counts as 1 & the upper beads count 5 of a column's base 10 power, Is, Vs, Xs, Ls, Cs ,Ds, Ms etc.

KodegaduloObsessive poster
 Joined: Sep 10 2011, 11:27 PM
For anybody who grew up with the Multiplication Rock cartoons back in the 1970's_{d}=1180's_{z} or so, we certainly got them through 12x12_{d}. I mean, hey, ya gotta love "Little TwelveToes", right?Ruthe @ Oct 26 2016, 07:45 PM wrote: I don't know how many of you learnt your multiplication tables to 12 x 12, but for people my age, (75) it was 12 x 12 ...
Hmm. There was also "Naughty Number Nine" which cast the 9 times table as a nasty evil poolsharp cat because of how "hard" it is in decimal, but "The Good Eleven" casting the elevens table as an angel because of how it's almost as easy as ones. But I guess in dozenal that would reverse. We'd be talking about the elevens table as "The Evil Eleven", but the nines would be as nice as "3 Is a Magic Number". I guess we'd also have a "Good Onezeen" (11_{z}) playing the same role as "The Good Eleven" (11_{d}) ... which triskaidekaphobics would likely find an incredible turnabout!
As of 1202/03/01[z]=2018/03/01[d] I use:
ten,eleven = ↊↋, ᘔƐ, ӾƐ, XE or AB.
Baseneutral base annotations
Systematic Dozenal Nomenclature
Primel Metrology
Western encoding (not by choice)
Greasemonkey + Mathjax + PrimelDozenator
(Links to these and other useful topics are in my index post;
click on my user name and go to my "Website" link)
ten,eleven = ↊↋, ᘔƐ, ӾƐ, XE or AB.
Baseneutral base annotations
Systematic Dozenal Nomenclature
Primel Metrology
Western encoding (not by choice)
Greasemonkey + Mathjax + PrimelDozenator
(Links to these and other useful topics are in my index post;
click on my user name and go to my "Website" link)

icarusDozens Demigod
 Joined: Apr 11 2006, 12:29 PM
Let [i]b[/i] be the number base in use. Then . is one of the easiest numbers to multiply with in base [i]b[/i] as it is symmetrical with 1. That is, while (to show the symmetry). Dozenally, it is eleven that is easy to calculate this way; hexadecimal, fifteen.

Double sharpDozens Demigod
 Joined: Sep 19 2015, 11:02 AM
The 12*12 thing also varies regionally. The Far East has had a long tradition of using 9*9 tables (the tens being understood as trivial  and in some sense the 10x row is the most basic of all, because it underpins place value).
I think this shows that while a 12*12 table is "nice to have", it is not actually a "need to have" when the dozen is not already ingrained in the culture. Indeed, the traditional Chinese small auxiliary of choice is not twelve but sixteen, and yet there were no 16*16 tables (though the Chinese abacus can certainly be used for hexadecimal).
I think this shows that while a 12*12 table is "nice to have", it is not actually a "need to have" when the dozen is not already ingrained in the culture. Indeed, the traditional Chinese small auxiliary of choice is not twelve but sixteen, and yet there were no 16*16 tables (though the Chinese abacus can certainly be used for hexadecimal).

Double sharpDozens Demigod
 Joined: Sep 19 2015, 11:02 AM
Perhaps some of the attitude towards 12 in decimal comes from the fact that it is a good auxiliary base which is just a bit larger than 10. That's why it makes sense to speak about "dickering", to sell 10 when one would expect 12, and so the dozens feel like "baker's 10's".
{e}
I would be interested to see the results of this computation for tetradecimal, where c is still perfectly good as an auxiliary base, but it is now a "banker's 10" instead of a "baker's 10". How big is the bump at c, especially compared to the one at 10? Does it make sense to extend the tetradecimal multiplication table to 12 (sixteen), given that the alpha dominance tilts the balance to the "north" of fourteen instead of the "south" of ten (omega dominance)?
I don't think one could really dispense with the rows of d and 10 because you need the row of d for precision in multiplication, but for those who work in tetradecimal a lot here (Oschkar, I guess): is there a difference in how round the dozens appear to you in tetradecimal versus how they do in decimal? Obviously there is still a sense of utilitarian roundness about 3smooth numbers in the mantissa, but I wonder: since 7 is the largest prime factor included, how do 5smooth numbers feel? Do things like cc0 and 1ba0 feel round (decimal 2520 and 5040), despite their great size as auxiliary bases? (I suppose some of it is because the alpha feels friendly instead of the omega, so that repeated digits instantly convey threefoldness and fivefoldness combined; but what if they are separate?)
So many questions, and no way to answer them surely without engaging in rather unethical experiments raising kids in a dozenal or tetradecimal bubble! But I think the extrapolation is going to be at least helpful here, given the similarities of a=2×5 and 10=2×7, and how much influence c=2^2×3 exerts between them.
{e}
I would be interested to see the results of this computation for tetradecimal, where c is still perfectly good as an auxiliary base, but it is now a "banker's 10" instead of a "baker's 10". How big is the bump at c, especially compared to the one at 10? Does it make sense to extend the tetradecimal multiplication table to 12 (sixteen), given that the alpha dominance tilts the balance to the "north" of fourteen instead of the "south" of ten (omega dominance)?
I don't think one could really dispense with the rows of d and 10 because you need the row of d for precision in multiplication, but for those who work in tetradecimal a lot here (Oschkar, I guess): is there a difference in how round the dozens appear to you in tetradecimal versus how they do in decimal? Obviously there is still a sense of utilitarian roundness about 3smooth numbers in the mantissa, but I wonder: since 7 is the largest prime factor included, how do 5smooth numbers feel? Do things like cc0 and 1ba0 feel round (decimal 2520 and 5040), despite their great size as auxiliary bases? (I suppose some of it is because the alpha feels friendly instead of the omega, so that repeated digits instantly convey threefoldness and fivefoldness combined; but what if they are separate?)
So many questions, and no way to answer them surely without engaging in rather unethical experiments raising kids in a dozenal or tetradecimal bubble! But I think the extrapolation is going to be at least helpful here, given the similarities of a=2×5 and 10=2×7, and how much influence c=2^2×3 exerts between them.

OschkarDozens Disciple
 Joined: Nov 19 2011, 01:07 AM
{e}
I don’t really think that twelve is any less round in tetradecimal, although there certainly is a change in perspective. Dozens seem like the norm for roundness either way, but now 10 feels like getting a bonus over the dozen rather than being shortchanged as it is in decimal. (Of course, a still feels deficient, but now it’s just another digit.)
cc0 and 1ba0 seem very round, more so than any number in decimal or dozenal in fact. However, I’m not sure if they would ever be used as divisions. It’s practically impossible to discern an angle of 1/cc0 of a turn, and, to avoid confusion, concentrations of a solute would be best expressed in parts per some tetradecimal power. Perhaps their niche use would be in packaging; it doesn’t seem unlikely that at least some small items would be sold in packs of 30 or 60, and stored in boxes with 44 packs in them.
I would like to increase the multiplication table to 12, but I think it’s overkill. The tetradecimal multiplication table is at about the limit of what can be learned within a year in primary school, and the additional products that 11 and 12 bring to the table don’t really seem worth it.
55: In decimal, this is possibly the most important number outside the multiplication table; it’s three quarters of a hundred. Here in tetradecimal, however, it’s just an overabundance of fives.
77: This one at least looks round, but it isn’t really a useful number to work with, unless you’re somehow constrained to the odd numbers for some reason. It might be a quadrant, if the circle is divided into 220 degrees, but in any other case, it’s just uneventful, especially since both the round 70 and the highly divisible 7a are so close.
92: This is the seventh power of two. It will probably be very familiar from computing, about as much as it is in decimal.
99: Another odd repeated digit. In decimal, it’s three eighths of a circle, but here it’s just another awkward mess of threes and fives.
aa: This is twice the 55 we already came across. This makes a little more sense, as it’s just five lots of 22, but why five, and not four or six?
b6: Ten times zefftwo. Useful when you need a lot of binary divisions, at least.
bb: Eleven. Ugh. Even though the repeated digit makes this one instantly factorable, it seems even less inviting than the rest of the row of eleven.
c8: Another eleven, but this time it’s four times the “prim and proper” 32, as Donald Sauter might put it. Still pretty useless, however.
cc: The Babylonian half circle, on the other hand, seems about as friendly in tetradecimal as it does in decimal, or possibly even more so, since its obvious division is into twelfths rather than zefffourths. That said, it does have the deficiency that it can only be divided in half twice.
da: Now this does feel like getting the short end of the stick. It’s certainly a very convenient number, but it’s so close to the sandred that we might as well just use that. (Somehow, 96_{{a}} doesn’t feel that way for me, but then again, it’s twice as far away from a hundred, relative to its magnitude, so it’s not affected as much by the hundred’s “gravity well”.)
dd: This one is just there for exaggeration. “Kills dd% of germs.” “Only $2d.dd!” “I’m dd% sure that this is fake.”
I don’t really think that twelve is any less round in tetradecimal, although there certainly is a change in perspective. Dozens seem like the norm for roundness either way, but now 10 feels like getting a bonus over the dozen rather than being shortchanged as it is in decimal. (Of course, a still feels deficient, but now it’s just another digit.)
cc0 and 1ba0 seem very round, more so than any number in decimal or dozenal in fact. However, I’m not sure if they would ever be used as divisions. It’s practically impossible to discern an angle of 1/cc0 of a turn, and, to avoid confusion, concentrations of a solute would be best expressed in parts per some tetradecimal power. Perhaps their niche use would be in packaging; it doesn’t seem unlikely that at least some small items would be sold in packs of 30 or 60, and stored in boxes with 44 packs in them.
I would like to increase the multiplication table to 12, but I think it’s overkill. The tetradecimal multiplication table is at about the limit of what can be learned within a year in primary school, and the additional products that 11 and 12 bring to the table don’t really seem worth it.
55: In decimal, this is possibly the most important number outside the multiplication table; it’s three quarters of a hundred. Here in tetradecimal, however, it’s just an overabundance of fives.
77: This one at least looks round, but it isn’t really a useful number to work with, unless you’re somehow constrained to the odd numbers for some reason. It might be a quadrant, if the circle is divided into 220 degrees, but in any other case, it’s just uneventful, especially since both the round 70 and the highly divisible 7a are so close.
92: This is the seventh power of two. It will probably be very familiar from computing, about as much as it is in decimal.
99: Another odd repeated digit. In decimal, it’s three eighths of a circle, but here it’s just another awkward mess of threes and fives.
aa: This is twice the 55 we already came across. This makes a little more sense, as it’s just five lots of 22, but why five, and not four or six?
b6: Ten times zefftwo. Useful when you need a lot of binary divisions, at least.
bb: Eleven. Ugh. Even though the repeated digit makes this one instantly factorable, it seems even less inviting than the rest of the row of eleven.
c8: Another eleven, but this time it’s four times the “prim and proper” 32, as Donald Sauter might put it. Still pretty useless, however.
cc: The Babylonian half circle, on the other hand, seems about as friendly in tetradecimal as it does in decimal, or possibly even more so, since its obvious division is into twelfths rather than zefffourths. That said, it does have the deficiency that it can only be divided in half twice.
da: Now this does feel like getting the short end of the stick. It’s certainly a very convenient number, but it’s so close to the sandred that we might as well just use that. (Somehow, 96_{{a}} doesn’t feel that way for me, but then again, it’s twice as far away from a hundred, relative to its magnitude, so it’s not affected as much by the hundred’s “gravity well”.)
dd: This one is just there for exaggeration. “Kills dd% of germs.” “Only $2d.dd!” “I’m dd% sure that this is fake.”

Double sharpDozens Demigod
 Joined: Sep 19 2015, 11:02 AM
{e}
So I guess twelve always feels like the centre, against which we judge a as a "double banker's dozen" and 10 as a "double baker's dozen".
To be fair, we don't really use the multiples of eleven that much in decimal, and in tetradecimal the use of the multiples of zeffone is more to facilitate the lines of three and five, because 3 × 5 = 11. The individual "offgrid" numbers like decimal 77 are quite unimportant, and I think tetradecimal 99 is about the same thing: it is an awkward mess of threes and fives, and the only thing going for it is that it is obvious that it is an awkward mess of threes and fives.
I guess there are still the threedigit products, so I'll cover them briefly.
10c: I suppose this is a multiple of sixteen, but d0_{{g}} isn't all that important. Unlike the analogous decimal 108, this loses a lot of power because the tetradecimal omega is rather useless.
110: Now this is important! It's the fourth primorial and seems an obvious choice for an auxiliary (though 220 is better, for another binary power).
120: A round number with lots of binary powers.
121: The square of zeffone. Pretty recognisable, but honestly just another mess of threes and fives. Still, it's useful to recognise squares.
132: This is decimally much more famous as 240, and seems pretty reasonable in tetradecimal as well to me.
144: Two to the eighth power, which is likewise going to be familiar from computing.
I don't really know. You do get a lot of useful products, but because of all the coprimes, they get buried in a significant amount of dross. Maybe it's not fair to count the zeffones that way because it is really rather trivial to find out what they are (except maybe 121 and 132, but those are actually useful). As for the zefftwos, I am not really sure if the usefulness of {92, 144} and maybe da is really useful enough to make up for the dross of the products of most of the others (though I think 9*12 = a4 is illuminating, but it's also c squared). Maybe we could just think of those as part of the usefulness of squares and powers of two, and not so much of zeffones and zefftwos.
In the end, I guess most of this is because when you expand the base, you create greater concision, but you also add more useless digits. We're still out of the mud at fourteen, but at sixteen we have an opaque {7, 9, b, d} with not much of a better way to learn the first two directly but as 81 and 8+1. I still think sixteen is probably on the borderline, but I am willing to give it the benefit of the doubt.
Which makes me wonder: how much benefit would senary and octal gain from memorising the tables to the dozen?
(P.S. FWIW, I learnt the tables officially only up to 9*9, but the twelves came up often enough that I ended up passively recognising them anyway. The elevens closed the gap mostly because they are, well, trivial. I am not sure the sixteens would come up frequently enough in a tetradecimal world to allow this to happen, especially the weird ones like b*12.)
So I guess twelve always feels like the centre, against which we judge a as a "double banker's dozen" and 10 as a "double baker's dozen".
To be fair, we don't really use the multiples of eleven that much in decimal, and in tetradecimal the use of the multiples of zeffone is more to facilitate the lines of three and five, because 3 × 5 = 11. The individual "offgrid" numbers like decimal 77 are quite unimportant, and I think tetradecimal 99 is about the same thing: it is an awkward mess of threes and fives, and the only thing going for it is that it is obvious that it is an awkward mess of threes and fives.
I guess there are still the threedigit products, so I'll cover them briefly.
10c: I suppose this is a multiple of sixteen, but d0_{{g}} isn't all that important. Unlike the analogous decimal 108, this loses a lot of power because the tetradecimal omega is rather useless.
110: Now this is important! It's the fourth primorial and seems an obvious choice for an auxiliary (though 220 is better, for another binary power).
120: A round number with lots of binary powers.
121: The square of zeffone. Pretty recognisable, but honestly just another mess of threes and fives. Still, it's useful to recognise squares.
132: This is decimally much more famous as 240, and seems pretty reasonable in tetradecimal as well to me.
144: Two to the eighth power, which is likewise going to be familiar from computing.
I don't really know. You do get a lot of useful products, but because of all the coprimes, they get buried in a significant amount of dross. Maybe it's not fair to count the zeffones that way because it is really rather trivial to find out what they are (except maybe 121 and 132, but those are actually useful). As for the zefftwos, I am not really sure if the usefulness of {92, 144} and maybe da is really useful enough to make up for the dross of the products of most of the others (though I think 9*12 = a4 is illuminating, but it's also c squared). Maybe we could just think of those as part of the usefulness of squares and powers of two, and not so much of zeffones and zefftwos.
In the end, I guess most of this is because when you expand the base, you create greater concision, but you also add more useless digits. We're still out of the mud at fourteen, but at sixteen we have an opaque {7, 9, b, d} with not much of a better way to learn the first two directly but as 81 and 8+1. I still think sixteen is probably on the borderline, but I am willing to give it the benefit of the doubt.
Which makes me wonder: how much benefit would senary and octal gain from memorising the tables to the dozen?
(P.S. FWIW, I learnt the tables officially only up to 9*9, but the twelves came up often enough that I ended up passively recognising them anyway. The elevens closed the gap mostly because they are, well, trivial. I am not sure the sixteens would come up frequently enough in a tetradecimal world to allow this to happen, especially the weird ones like b*12.)