Printable Version of Topic
Click here to view this topic in its original format
Dozensonline > Non-Dozenal bases > Le Tour Des Bases


Posted by: icarus May 1 2012, 03:01 PM
[doHTML]

Posted by: icarus May 1 2012, 03:04 PM
[doHTML]

Posted by: icarus May 1 2012, 03:14 PM
[doHTML]

Posted by: Dan May 2 2012, 12:39 AM
QUOTE (icarus @ May 1 2012, 09:04 AM)
[doHTML]

I'm curious as to how you decided that 10 is male but 8, 9, and 18 are female.

Posted by: icarus May 2 2012, 02:06 AM
Dan,

Indeed there is a pattern! Even if it is accidental (recalling from memory) I speak Russian, that should be a hint, and the pattern is number theoretical at least with part of the set of possible categories.

Posted by: Dan May 2 2012, 03:45 AM
I don't know Russian, so the hint is lost on me.

Posted by: dgoodmaniii May 2 2012, 06:08 PM
QUOTE (Dan @ May 2 2012, 03:45 AM)
I don't know Russian, so the hint is lost on me.

Grammatical gender. I don't speak (much) Russian, so I can't so for sure, but I think he's ascribing sex to these numbers based on their grammatical gender in Russian.

Posted by: icarus May 2 2012, 09:11 PM
Gentlemen,

Actually all I meant was I think the assignment of gender is completely random but there are three of them; feminine {(6), 8, 9, 12, 15, (16), 18} masculine {(6), 10, (20)}, and neuter {7, 11, 13, 14, 17}. So it appears that powers of two, multiples of three are feminine, multiples of ten are masculine, and primes and multiples of 7 are neuter.

I say 6 can be masculine or feminine, maybe stretching it, because my wife is into MMA. So women can be fighters, tho I am not sure the whole "welterweight" deal applies to them.

Anyway, the entire masculine/feminine/neuter thing is entirely random, just there to make the stories a little more lively. The 8 "because it has more beauty" had me thinking female, the "beauty" remark comes from the poster of the thread and not me. Sixteen may not be female from the title, as the title refers to a Stones song I happened to be listening to at the time: "Please allow me to introduce myself / I'm a man of wealth and taste...". No, the masculine/feminine/neuter gender trends won't necessarily be carried up or down scale; 21 may be male or neuter or something else. I think I am trying to impose order given dan's question. No this isn't an identity politics statement either. It's simply for levity.

I do hope you enjoy the posts. This is simply a proof of concept for a particular audience that isn't necessarily on the forum, or at least active on it. It also happens to serve to illustrate the properties of other number bases for folks who'd like to see things for themselves (skeptics/sceptics).

Posted by: icarus Aug 29 2012, 02:15 PM
Folks,

I've been able to take my multiplication tables from a print document and fold them into HTML so now I can produce tours of mid-scale bases pretty easily. I am working on a method of transferring Mathematica tables to Excel. When this happens I can produce any size table, though the notation won't be the same, instead it would be decimal coded. I think we can continue to explore the very high bases if desired.

Others have written great pieces on other bases. This series will continue to expand in the same character as the previous essays, with links to the other conversations (i.e., tridecimal, base-24, base-22, etc.). This way this forum will eventually have the broadest such number base tour on the internet, if it isn't already so.

I may revisit a few earlier threads and inject some new data so that they are on par with the latest essays. If there is anything (practical!) you'd like to add in the tour of each base, please suggest it.

Again, the frequent posters on this site continue to influence me in seeing the "sights" to be seen in these number bases. Please don't wait till I cover a given base to chat about it. I can mention a "sight" and link to whatever conversation has been had about it in other threads, so that we have an integrated experience.

I've written most of bases 9, 24, and 21; these will come next. I may try to write 60 or 120, but want to do my "experiment" first. As we push into September, I may not have much time to write, so the progress will be discontinuous.

Posted by: icarus Aug 31 2012, 01:58 PM
I've updated decimal, dozenal, and hexadecimal threads to show "regular figures", which are equivalent to "units" defined by Wendy Krieger at her "Number Theory 102" thread in the number theory forum. Also, I've added diagrams of patterns in the decimal, dozenal, and hexadecimal multiplication tables, and diagrams showing the relationship of the positive primes less than the base in the same threads.

There is a limit to the size of posts and this has affected the hexadecimal thread the most. The usual format is interrupted, but the same data is linked from the introductory post.

Posted by: icarus Sep 6 2012, 09:27 PM
I've added some limited tours of "grand bases" 210, 240, and 360. These were laying around this summer in partial form when I was mulling over other matters and away from the forum. If you've got a "grand base" to inspect, I'll put it on the queue. I am producing base 2520 but that's experimental and we'll see what needs to be done to do it. Hopefully some of these might spark some debate. I think they are curiosities, mountains that are fun to climb but impractical places to live.

Look at the tour menu, second post in this thread.

Posted by: Dan Sep 7 2012, 12:34 AM
While it may be a little too small to count as a "grand base", I'd like to see an analysis of Base 36, the highest base supported by the C http://www.cplusplus.com/reference/clibrary/cstdlib/strtol/ function (due to the convention of using 0-9 and A-Z for digits), and coincidentally a highly-composite number.

Posted by: Oschkar Sep 7 2012, 01:08 AM
QUOTE (Dan @ Sep 7 2012, 12:34 AM)
While it may be a little too small to count as a "grand base", I'd like to see an analysis of Base 36, the highest base supported by the C http://www.cplusplus.com/reference/clibrary/cstdlib/strtol/ function (due to the convention of using 0-9 and A-Z for digits), and coincidentally a highly-composite number.

I would like to see 36, 40, 42, 48, 56, 60, 72 and 84 as possible midscale bases on the way to grand 120 and higher.

Posted by: icarus Sep 7 2012, 02:41 AM
I wrote about base 144 tonight, and it ties to many posts on this forum (Shaun, m1n1f1g et al.) in a cool way. Will do 100 too. These things tend to illustrate a tidbit, but aren't terribly useful. Then 36 will be next.

I have tables for 36 and 60. I am not sure the board will handle the tables, but maybe I could split them. I've dispensed with the tables for "grand bases", but may circle back and do other things done for the small bases. A link to a PDF for bases larger than 40 or so might relieve the board of so many big tables. This stuff can fold over into indesign to be a big book of bases one day, that's exciting (to me).

Indeed many of the bases Oshkar suggested are on the list. I had HCNs, and the "runner up" bases to the HCNs, I think they are {24, 30, 36, 48, 60, 72, 84, 90, 96, 120, 144, 168, 180} plus Wendy's/Triesaran's beneficial-flank numbers {21, 34, 55, 99, 120} (doing from memory). Will add 42, 56. I'd written the full list on the menu post but commented them out. (it looked daunting! And I didn't want to promise and leave it stand) I also felt averse to starting a bunch of threads, only to have a "partial" set. Now I think we start threads and folks can comment and see patterns etc., with other info coming later. I think I'll start the bases off like the grand bases then fill in the details later. If you've written something about the bases please post a link to your discussions in the tour thread so people reach your thoughts, if I hadn't done that already. I am not as familiar with what happened between May and mid August this year, due to all the mulling on another non-number-base issue. (my midlife crisis, lol. Good thing: it's mostly over!)

Any idea on a really big prime (between say 60 and 360), just to illustrate what many of these look like? I think 55 will serve as a really big semi prime.

Posted by: Dan Sep 7 2012, 02:50 AM
QUOTE (icarus @ Sep 6 2012, 09:41 PM)
Any idea on a really big prime (between say 60 and 360), just to illustrate what many of these look like?

61, 67, 71, 73, 79, 83, 89, 97, 101, 103, 107, 109, 113, 127, 131, 137, 139, 149, 151, 157, 163, 167, 173, 179, 181, 191, 193, 197, 199, 211, 223, 227, 229, 233, 239, 241, 251, 257, 263, 269, 271, 277, 281, 283, 293, 307, 311, 313, 317, 331, 337, 347, 349, 353, 359

Pick one.

Posted by: wendy.krieger Sep 7 2012, 07:50 AM
70 has a place in there somewhere. This is the first abundant number that can not be represented as the sum of its divisors. Also, i am rather fond of it. It has, for example, among the squares, 2.00.01.


Posted by: Oschkar Sep 7 2012, 08:37 PM
QUOTE (Dan @ Sep 7 2012, 02:50 AM)
QUOTE (icarus @ Sep 6 2012, 09:41 PM)
Any idea on a really big prime (between say 60 and 360), just to illustrate what many of these look like?

61, 67, 71, 73, 79, 83, 89, 97, 101, 103, 107, 109, 113, 127, 131, 137, 139, 149, 151, 157, 163, 167, 173, 179, 181, 191, 193, 197, 199, 211, 223, 227, 229, 233, 239, 241, 251, 257, 263, 269, 271, 277, 281, 283, 293, 307, 311, 313, 317, 331, 337, 347, 349, 353, 359

Pick one.

In this case, I'd choose 109, probably, for its intutive relationships with 108=2^2x3^3 and 110=2x5x11. It is not exactly the typical large prime base, but it is rather versatile for such a base. On the other hand, 173 is an example of the worst possible type of prime base, with 172=2^2x43 and 174=2x3x29 as neighbors. You could do both as contrasting bases.

And I suggest that you separate 60 from 120.

Posted by: icarus Sep 7 2012, 10:04 PM
Oschkar: surely we will separate bases 60 and 120: that was a comparison and a stand-in till I get a proper page set up.

I like the suggestion 109 and 173 for the very reasons you've described.

The weird thing that occurred to me is with any composite, I can "shorten" the table by using two divisors. For the primes, the "shortening" will look odd, because the numbers don't have nontrivial integer divisors. I am trying to respect 30 cells as the maximum width, so might use some convenient number below that to "fold" the cells.

Wendy: 70 is now on the list!

Posted by: m1n1f1g Sep 8 2012, 11:16 PM
QUOTE (icarus @ Sep 7 2012, 03:41 AM)
I have tables for 36 and 60.

What about complementary divisor method ("truncated") tables? I'd like to see what they're like in terms of size and memorability.

Posted by: Treisaran Sep 9 2012, 12:25 AM
Very impressive, Icarus! (Yeah, mood's improved a bit the past few days smile.gif ) I'm especially interested in the rundowns of those bases that have a relationship to the dozen: 6 (half-dozen; already here), 18 (dozen half-dozen, or as I call it, dozen ha'zen wink.gif ), 24 (double dozen), 36 (triple dozen), 96 (octodoz?) etc. The last three I find intriguing because of the slight improvements (at an undeniable price, of course) they offer over dozenal, through their neighbour relations (96 is for the 240-lovers who want something better than a primeflank but don't want to abandon the sixteenfold division). All in contrast to 18, that 'total loss' of near-dozenal bases, which gains nothing and loses quite a lot.

On another note, I think a comparison of 34 and 120 is warranted: together with their neighbour relationships, they offer the same factors:
  • 34 = 2·17, ω = 3·11, α = 5·7
  • 120 = 2·2·2·3·5, ω = 7·17, α = 11·11

and yet, they don't have the same utility. The diprime 34 is at a considerable disadvantage in comparison to the divisor-rich 120. That's another case for the argument that handy neighbour relationships are no substitute for richness in divisors.

Posted by: icarus Sep 9 2012, 02:05 AM
[doHTML]

Posted by: Oschkar Sep 9 2012, 03:49 AM
To me, the relationship between 21 and 22 looks a lot like the one between 14 and 15, only backwards, since 10, 14 and 22 are all manageable semiprimes. For example, like 10 uses the omega for 3, 14 the alpha, and 22 the omega again. Bases 10 and 14 both are compatible with 5, and 22 could use SPD to reduce the numbers with the alpha-2, since duovigesimal 101=decimal 445 is divisible, and there are still only 88 multiples to memorize (easily reduced to 22 by subtracting multiples of duovigesimal 50). For 7, 14 has it as a divisor, and in 22 it is an omega inheritor, but in decimal, 7 is out of SPD reach (143 multiples of 7 less than the decimal thousand, and subtracting multiples of 70, or even of 98, is rather impractical for a 3 digit number).
Although now that I think about it, the fact that 301 is so close to 300 could be used as an extension of SPD in decimal (not a neighbor of the square of the base, but of a multiple of it). To test for 7, instead of adjusting the remaining digits by what was added to the final 2, adjust them by triple that amount:
164472424704
1644724247 04+3=7 → 47+9=56
16447242 56
164472 42
1644 72-2=70 → 44-6=38
16 38-3=35 → 16-9=7

Posted by: Treisaran Sep 9 2012, 01:50 PM
QUOTE (icarus)
I have started base 2520, a leviathan, will take a couple weeks, jobs rolling in soon.


Good luck! But how are you going to squeeze the huge tables required for this monstrosity of a base into forum posts? dry.gif

QUOTE (Oschkar)
and there are still only 88 multiples to memorize (easily reduced to 22 by subtracting multiples of duovigesimal 50).


Compacting the number of SPD sequences, eh? Sounds good. I just wonder how far it could be carried. For base 22 it looks feasible, but I wonder about base 32, or the dozenal SPD test for 7 (which is based on *1001, the dozenal cube-α).

QUOTE
and 22 could use SDN [...] 7 is out of SDN reach [...] could be used as an extension of SDN in decimal


SDN stands for 'Systematic Dozenal Nomenclature', a comprehensive dozenal number naming scheme devised by Kodegadulo on this board; SPD stands for 'Split, Promote, Discard', a divisibility testing shortcut method stumbled upon by yours truly. smile.gif

Reminds me of that passage from the 1989 film Hunt for Red October: 'Pavarotti is a singer, Paganini was a composer'. smile.gif

Posted by: Oschkar Sep 9 2012, 05:32 PM
QUOTE (Treisaran @ Sep 9 2012, 01:50 PM)
QUOTE
and 22 could use SDN [...] 7 is out of SDN reach [...] could be used as an extension of SDN in decimal


SDN stands for 'Systematic Dozenal Nomenclature', a comprehensive dozenal number naming scheme devised by Kodegadulo on this board; SPD stands for 'Split, Promote, Discard', a divisibility testing shortcut method stumbled upon by yours truly. smile.gif

Reminds me of that passage from the 1989 film Hunt for Red October: 'Pavarotti is a singer, Paganini was a composer'. smile.gif

Thanks. Fixed.

Posted by: icarus Sep 12 2012, 10:08 PM
Added bases 60, 70, 72, and 84 this afternoon, in excitement over Wendy's comparison of 70 and 72. These will set the pace for the mid-scale bases. May still add some of the frills of the human scale bases, and will update the larger (grand) bases.

Posted by: icarus Sep 15 2012, 01:42 PM
Bases 90, 96, 108, and 120 have been added, along with the Midscale Mashup. These bases round out the upper midscale bases. These also incorporate SDN and a more canonical "common lexicon" name based on greek units and latin decades.

Have a fine weekend!

Posted by: Oschkar Sep 15 2012, 05:29 PM
Why are 18, 20 and 21 mid-scale bases? The multiplication tables have 171, 210 and 231 products, still within the reach of memorization, and divisibility tests still cover the majority of their digits. The primes 17 and 19 still have their uses, however rare they might be (19, for example, is used sometimes to pack pencils in a hexagon). The abbreviated multiplication tables of 22, 25 and 26 products are still in the senary-septimal range, and the bases only have 6 or 4 factors, small bases for themselves.

Posted by: icarus Sep 15 2012, 08:52 PM
Oschkar, brilliant question and excellent thoughts! Let's debate it, see this http://z13.invisionfree.com/DozensOnline/index.php?showtopic=751. I really don't know the answer but the thread outlines my thoughts. I invite anyone to add their thoughts, because perhaps these classes don't make sense. They don't come from anywhere but here, so we can decide how to classify them. My concept of classes has to do with educating children to wield a number base, i.e., might this base actually stand as a civilizational number base.

Posted by: icarus Sep 18 2012, 10:18 PM
I've added bases 48, 80, and 112, as well as a midscale mash-up of {32, 48, 80, 112}. These might be the last tour bases for a while as a large project is upon the office >yay<. Like ostmark loves, time to make some wampum! ( smile.gif in increments of twelfty).

Posted by: Treisaran Sep 18 2012, 11:28 PM
QUOTE (icarus)
These might be the last tour bases for a while as a large project is upon the office >yay<.


Pity, I was hoping bases 24 (double-dozen) and 36 (triple-dozen) would make it into the tour. They and the long hundred are, IMO, the only alternatives I'd consider to dozenal for general-purpose use.

Posted by: icarus Sep 18 2012, 11:34 PM
Oh, those bases will certainly make it in the tour. I have 32 partially done and just need to set it aside for maybe a week or so. There might be windows, but I also have family, etc.

Posted by: Treisaran Sep 24 2012, 02:18 PM
QUOTE (icarus)
Oh, those bases will certainly make it in the tour.


Once they're in, the only dozenal-multiple base outside the tour will be 132 (levanunqual), admittedly a useless base (ω is prime, α is 7·19).

I'd like to make, myself, a single-thread mini-tour of all dozenal-multiple bases up to *140 (unquadranunqual, unquadnilimal, 192) inclusive. But I'd better wait with that post till you've had your say on bases 24 and 36, because I don't do coloured tables so well.

Posted by: icarus Sep 24 2012, 11:34 PM
Treisaran,

Shortly before the big crunch I was preparing two mashup threads. The first compared the first twelve multiples of the dozen. This was a lengthier mashup than the Midscale Mashup, comparing all twelve multiples in groups of similarity in this or that aspect. The thread has all the tables including binunqual, trinunqual, and levanunqual. We'll see if I can't finish it because the tough part was finished last week.

Basically the thread considers bases that are integer multiples 12k with 0 <= k <= 12,
In terms of intrinsic properties there are the groups k = {1, 2, 3, 4, 6, 8, 9, 12} (2 distinct primes), {5, 7, 10, 11} (3 distinct primes). The extrinsic properties (neighbor factors) are also considered as well.

Posted by: Treisaran Sep 25 2012, 12:19 AM
I find the dozenal-multiple bases interesting because not just because they're related to the dozen, but also because they have some interesting groupings:
  • The 3-smooth community: 12, 24, 36, 48, 72, 96, 108, 144, 192.
  • Prime factor exogamists: 60, 84, 120, 132, 156, 168, 180.
  • Quinary-haters: 48, 72, 108, 132, 168, 192.
  • Primeflanked Flacks: 12, 60, 72, 108, 180, 192.
  • Omega Warriors: 36, 96, 156.
  • The Alpha Team: 24, 48, 84, 132, 168.
  • Extroverts: 120, 144.
  • Squares: 36, 144.

I wouldn't go beyond 192, *140, 0xC0 in a survey, but there are some interesting multiples still, some of them already covered in your tour: 216 (cube, flanked by composites), 240 (primeflank), 300 (flanked by composites, first multiple of the dozen divisibly by the decimal hundred) and 360.

Posted by: Oschkar Sep 25 2012, 03:33 AM
On a side note, I'd like to suggest base 64. Being a power of two, it might seem that it is lacking in diversity, but its neighbors are 3²×7 and 5×13, giving it an advantage over the first six primes, excluding 11 (but then again, only the multiples of 11 and their neighbors are fair to it).

CODE
    7   2^3     3^2
  3×5   2^4      17
   31   2^5    3×11
3^2×7   2^6    5×13
  127   2^7    3×43
3×5×17   2^8     257
 7×73   2^9  3^3×19


All other power-of-two bases, except eight, have large primes in their factorizations, which makes 64 a rather convenient base. The product of 63, 64 and 65, 262080, is the quadruple of the already suggested radix 65520, very close to a binary power and with 168 factors (an important base in itself, 2^3×3×7).

Posted by: Treisaran Sep 25 2012, 02:53 PM
QUOTE (Oschkar)
On a side note, I'd like to suggest base 64.


Yes, probably the best base to choose if you're confined to a binary world to such a degree that you need to do all your calculations in it. (Hexadecimal isn't the product of so dire straits, it's just an auxiliary.)

QUOTE
Being a power of two, it might seem that it is lacking in diversity, but its neighbors are 3²×7 and 5×13, giving it an advantage over the first six primes, excluding 11 (but then again, only the multiples of 11 and their neighbors are fair to it).


Base 64 (*54, SDN pentquadral) enjoys the relationships that any sixth power does. There is a regularity for powers that can be obversed, and I assume also grounded in modular arithmetic:
  • Every number has the prime 3 as its divisor or neighbour.
  • Every square has the prime 5 as its divisor or neighbour.
  • Every cube has the prime 7 as its divisor or neighbour.
  • Every fifth power has the prime E as its divisor or neighbour.
  • Every sixth power has the prime *11 as its divisor or neighbour; and as every sixth power is also a square and a cube, it also has a relationship with the primes 5 and 7.

Doubtless the list could go on for higher primes. For a number to have a relationship with all first six primes (2, 3, 5, 7, E, *11), you need to pick either a pentanunquate* (=sixtieth) power of a number (like 2↑*50, already astronomical) or a sixth power of a multiple of E (like 1X↑6).

───

* I assume 'pentanunquate' is the correct form on the basis of Kodegadulo's coinages 'binate' and 'trinate' to replace the confusing 'quadratic' and 'cubic' (for equations with a second-power term and a third-power term, respectively).

Posted by: icarus Sep 25 2012, 11:24 PM
Oschkarthe other mashup isthe power of 2 mashup! This goes to 256. Nearly have the dozens mashup done, have to little pieces here and there. Next week I think Ill be double loaded, so won't be any progress there.

Posted by: Oschkar Sep 30 2012, 10:04 AM
QUOTE (icarus @ Sep 18 2012, 11:34 PM)
There might be windows

There's always Windows, even when you use another operating system in your daily life, just like there's always decimal although you use a different number base. (Or, in icarus's, wendy's, or my case, all of them.)

Posted by: Oschkar Oct 4 2012, 06:24 AM
Small lower-mid scale bases 17, 18, 19, 22, 24, those which Icarus has ignored up to this point.

17: A just-beyond-manageable prime with no uses that I know of (a heptadecagon can be constructed with a compass and straightedge, but is virtually never used in practice.) It has maximal expansions of 1/5, 1/7 and 1/11 (0.36da36da36..., 0.274e9c274e..., 0.194adf7c63...), but it is intimately familiar with the dozen, having 2⁵×3² as the omega-2. There are 7 opaque totatives {5, 7, 10, 11, 13, 14, 15}, and, although SPD can alleviate the 5-situation, there's not much to do in heptadecimal.
18: There is something intriguing about octodecimal. Eighteen is an α²β type of base, like twelve or twenty, but the square factor is the larger prime in this case, something that does not happen again until 50. Because of this, base 18 acts more like 10 and 14 in some cases. but like 12 and 20 in others. 1/5 and 1/11 are maximally recurrent (0.3ae73ae73a..., 0.1b834g69ed...), and the neighbors are the useless primes 17 and 19. Base 18 has 6 divisors {1, 2, 3, 6, 9, 18} and 4 opaque totatives {5, 7, 11, 13} (once more, SPD helps with 5 and 13). The non-divisor regular digits {4, 8, 12, 16} are treated to short two or three digit expansions (somewhat like {4, 8} in bases 10 and 14), and the remaining digits {10, 14, 15} are semitotatives.
19: Another just-beyond-manageable prime, but a little bit friendlier on the neighbors. The omega-2 is 360, a highly composite number. On the other hand, the alpha-2 offers no help. 1/7 and 1/13 have maximal expansions. There are 5 opaque totatives {7, 11, 13, 14, 17}, and SPD is no help, since 362 is only a semiprime.
22: Duovigesimal is the divisibility-test paradise, the first six primes have relationships with the square and the cube. It is a semiprime, like 10 and 14, but the eleven-factor causes all sort of strangeness. The divisors {1, 2, 11, 22} are few and far between, and all of the remaining regular digits are powers of two {4, 8, 16}. There are 3 alpha-inheritors {3, 7, 21}, but the 6 opaque totatives {5, 9, 11, 13, 15, 17, 19} really hinder computation. The rest of the digits {6, 10, 12, 14, 18, 20} are semitotatives.
24: The diametrical opposite of 22 is 24, the double dozen. With eight divisors and a very useful relationship with the alpha, we are able to render {1, 2, 3, 4, 5, 6, 8, 9, 10, 12, 15, 16, 18, 20, 23} as «transparent», a full 62.5% of all digits. The remainder can be classified in two types, the «negatives» {14, 19, 21, 22} where the multiplication rows are the inverse of those of the transparent digits, and the «irrelevant» digits {7, 11, 13, 17}, two prime pairs.

Posted by: Oschkar Oct 10 2012, 03:06 AM
When are 17, 19, 22, 28, 32, 40 and 56 coming? And as weird bases go, I'd like to see 351, simple divisibility tests for 5 powers of 2, 3 powers of 3, 2 powers of 5, and 1 power of 7, 11, 13.

Posted by: Treisaran Oct 10 2012, 05:51 PM
QUOTE (Oschkar)
And as weird bases go, I'd like to see 351, simple divisibility tests for 5 powers of 2, 3 powers of 3, 2 powers of 5, and 1 power of 7, 11, 13.


Among what are called 'grand bases', I've recently thought about 2640 as offering a bit more bang for the buck than 2520:

2640 = 2↑4 · 3 · 5 · 11, with its ω = 7· 13 · 29, providing for all the primes needed for calendric use (I'm talking about a lunisolar calendar, not the Gregorian one with its prime 31 there to make matters so much more complicated).

For those bases off the possibly beaten track (meaning, a track not necessarily beaten but which people might seriously consider beating), I think full-blown tour posts would be overkill; perhaps an 'Esoteric Bases' tour thread would serve here.

Posted by: icarus Oct 10 2012, 10:01 PM
Guys 351 was a weird base!

I am afraid I am going to be absolutely slammed in the coming fortnight, plus I will be in NYC for a bit. There might not be too much action. Am in a permission gap (two projects held) and I think both will break loose with a rapid deadline.

The American elections have likely caused a little vacuum in demand; now that these are coming up I might not be able to post quite as much. This said, the first bases on the tour were posted during heavy demand. So we'll see!

Posted by: Treisaran Oct 17 2012, 03:00 PM
I do hope you take those invitations as encouragement rather than pestering, Icarus. I'm looking forward to what you've got to say about base 2, because of your contention that it's an exceptional base in so many ways.

Posted by: icarus Oct 17 2012, 09:23 PM
No I do not take it as pestering, we are all curious! I am in new York thru Sunday and will see next week.

Posted by: Oschkar Nov 15 2012, 01:50 AM
First post in four days!

I'm just going to remind Icarus of bases 22, 32, 40, 50, 56, 64, 99. Will they be published here or on your number base website?

Posted by: icarus Nov 15 2012, 03:20 AM
Oschkar,

I've been writing a very extensive compendium of definitions, which will stand as independent pages, then get boiled down into a glossary that will serve as a basis for what is the tour here. The tour pages will have expanded coverage. The intuitive divisibility tests will factor in practicality, and a full range of transparent numbers can be described. The new CSS is getting very colorful! The best thing is that diagrams will be integrated in the work, communicating concepts in more than one way. I'm also re examining nomenclature (semidivisor vs. quasidivisor, regular figure vs. regular root, etc.).

I have an active project with a deadline in a couple weeks and have had to lay it aside. I believe the American debt ceiling is damming up a great deal of demand potentially so will be blitzing the number base project in December. This has consumed my attention unfortunately. We'll see if I can put out a couple units.

The good thing is that the resources built here are applicable to the number base project.

Posted by: dgoodmaniii Nov 15 2012, 02:38 PM
Have you considered compiling all of this, and expanding it somewhat, into a book? You've got enough material for a big fat volume, the 800 (that's eight biqua, of course) pound gorilla of the field. It'd serve as the mandatory textbook for alternate base work in colleges.

I honestly think this would be a great, if heavy, project.

Posted by: Treisaran Nov 15 2012, 03:48 PM
QUOTE (icarus)
The new CSS is getting very colorful!


Good, hope it doesn't get too hard to distinguish between the many colours. While I'm about it, why not see to devising distinctive cross-hatch patterns? They wouldn't be needed on the Web, but they would for print (my laser printer is monochrome).

Posted by: icarus Nov 17 2012, 03:50 AM
I don't think the colors will ever be used in the same work. We have the colors you are familiar with, the red divisors, orange rich regulars, yellow semicoprimes, and gray coprimes. The pale blue and aqua omega and alpha factors become full-bore blue and aqua in divisibility test maps.

Essentially we have several kinds of regular number. All regular numbers are products restricted to the prime divisors of the base (or simply the number 1, which we call a unit on account of its special status as both a divisor and coprime to the base, and neither prime nor composite). We can divide the regular numbers four ways. Regulars that divide the base evenly are divisors, those that are non divisors are called rich regulars. Regulars less than or equal to the base are digits; the others are non digits and they are all rich regulars. Rich regular digits, i.e., nondivisor regular digits are called semidivisors. If we look at regular numbers as a product of a regular root gamma and a power of the base, then we have three possible classes: regular roots (regular numbers that are not multiples of the base, e.g., "2" vs. the family {20, 200, 2,000, } or "125" vs. {1,250, 12,500, 125,000, }) regular compounds (like the numbers in families just mentioned as counterexamples of regular roots), and pure powers of the base (by this I mean nonnegative integer powers of the base, I am not being as rigorous as I normally am in writing this, so as to be brief). All the regular digits that are not the base itself are regular roots (I called regular roots "regular figures", what Wendy calls "units"). The trivial divisors and any nonnegative integer power of the base are obviously pure powers. The concept of regular root helps to make the range of practical regular numbers finite in some cases (not in the case of prime power bases). There are practical and impractical regular roots and powers of bases. So this produces many flavors of regular numbers, not all are of interest generally.

There are kinds of coprimes, we all know and love them. The types have to do with dividing the neighbors evenly. So there are alphas, omegas, and each have factors, alpha factors and omega factors. In base ten, we have the alpha 11 and the omega 9; the only neighbor factor of interest is the nontrivial omega factor 3. Then there are products of alpha and omega factors called alpha-omega factors, thus in base ten we have {33, 99}. The number 2 in odd bases is a factor of both alpha and omega, but it is more efficient simply to consider it omega factor. A coprime that is not a factor of the neighbors is opaque. A coprime that is a digit is called a totative. All neighbor factors have practical intuitive divisibility tests; they are never impractical. Neighbor factors have practical reptends but the multiples of these unit reptends may be impractical to keep in mind.

We then have semicoprimes, composite numbers that have at least one prime divisor of the base and at least one prime coprime to the base as factors. Generally any semicoprime is the product of a regular component and a coprime component. Practicality is a concern of the regular component, while neighbor-relatedness is a concern of the coprime portion. Concerning the coprime portion, we have alpha semicoprimes (aka alpha inheritors), omega semicoprimes, and alpha-omega-semicoprimes. In odd bases, we have even-semicoprimes that are always neighbor-related. Each of these is practical or impractical dependent on the regular component. A semicoprime digit is called a semitotative.

Since embarking on the fundamental portion of the website, the regular numbers have received a lot of attention, solidly integrating the concept of regular roots and the compound nature of regular numbers (when these are not compound, i.e., prime, one of the factors , the regular root or the power of the base, equals 1. When the regular number is 1, then both are 1). This affected what we'd called inheritors, which really are semicoprimes via the notion of practicality.

Practicality itself is a weird thing to define because it isn't fully arithmetic in nature. It's cognitive, so what we deem practical really is provisional until we have scientific research. But we can make a consistent computation of it provided these stand-in assumptions and then compare apples to apples. Practicality in divisibility tests is governed by the multiplicative complement to regular root, in the number of combinations less than the power of the base whose exponent is the regular root's richness (what I called remoteness). With some regular IDTs, we can reduce this range through "range folding", exhibited by the decimal test for divisibility by 8. Range folding can make some regular IDTs practical, but it is only applicable to powers or certain products of {2, 3}, maybe 5. Curiosly, in bases that are semiprimes like ten, the upper divisor has a larger range of practical powers. In base ten, the fourth power of 5 has a practical regular IDT (there are only 16 combinations; as these are the multiples of the decimally expanded 16th, they are relatively well known) but the fourth power of two is opaque (625 combinations, range folding is not practical, since it is easier to actually divide continually by 2 to determine divisibility by 16).

So all this new stuff is going in to the work. As I wrote, fortunately not all of these distinctions are useful at any one time.

Posted by: Treisaran Nov 17 2012, 11:07 PM
Sounds very comprehensive, Icarus. And I like the new, distinctive names like 'rich regular' to distinguish from 'divisor' and 'semidivisor', which are exclusively digits of the base.

One expansion of the coprimes category has cropped up on the boards in the context of the dozenal divisibility test for 5: the power-neighbour. It generalises the rules of the neighbours to multiple digits, though its practicality depends, much like rich regulars, on remoteness. We know that for every prime p that is not a divisor or neighbour of a certain number n, the number n to the power (p−1)/2 will have a neighbour that divides p. So, if a number does not have 7 as its divisor or neighbour, we can be sure its 3rd power (ie cube) will have a neighbour divisible by 7.

All power-neighbours allow compaction of the number to prepare it for divisibility testing. For example, any number not near enough to being a multiple of E will have a relation to E through its 5th power (see above rule), which will allow us to sum groups of 5 digits or subtract the sums of alternating 5-digit places according to the power-neighbour relationship. However, this is of little use practically speaking, because a number would have to be more than 5 digits long to benefit from compaction, and even then the remaining 5-digit number would need a universal test (long division, placeholder et cetera).

In decimal, the potentially helpful power-neighbours are the cube-ω 999 = 3↑3·37 and the cube-α 1001 = 7·11·13. We can use the former relationship to test for the third power of 3 by summing groups of three digits, then testing the compacted number, but this would be of little help; it would be far simpler to divide the tested number by 3, then test the result for divisibility by 9 using the digit-sum test. Likewise, a number to be tested for divisibility by 7 or 13 can be compacted down to three digits by successively subtracting the last three digits from all the rest, or by subtracting the sums of alternating 3-digit places. Again, this is only a slight aid.

It looks as if dozenal really hits the jackpot with a complete divisibility test using a power-neighbour relationship. Viewing again the rule above, it is inevitable that the square of base dozen should have a neighbour divisible by 5, but it is not inevitable that there should be few enough 2-digit multiples below the gross to be memorised. SPD is like the practical tests for rich regular numbers in that it is operative only below a certain memorisation threshold; the main difference is SPD tends to reach it much faster than the regular tests do, hence its rarity (beside dozenal, octal is probably the only other usable base that benefits from SPD). Still, given the way SPD brings the hitherto totally opaque totative 5 into the dozenal fold (at least as far as divisibility tests go, not so for fractions unfortunately), I think the category of power-neighbours is worth a mention in your work.

Posted by: icarus Nov 18 2012, 02:46 AM
Treisaran, indeed these are important. I think they are not as immediately apparent as omega and alpha. They would be mentioned in an article about dozenal simply because they ameliorate the five problem twelve has. I think through the Dozenal test for fivefoldness, base twelve has an appropriately evident and easily taught test for the third prime.

Indeed I do not think alpha is immediately apparent in decimal. I don't know if most folks know the test for elevenfoldness but the "stuttering" in the multiplication table is evident. Systemically, alpha is evident across many bases.

But you are right, power neighbors merit attention. It's funny, it's taken a month to get to basic things, and I don't know if I've fully explained the basic things. The basic things look pretty complex so they must be made basic, but in order to get to that point, we have to take it to the top first like a painter does his art before we can pare it down to essentials.

Posted by: Oschkar Nov 18 2012, 08:53 AM
There is an interesting pattern with bases 8, 13 and 18, which have relatively factorable betas of 65=5×13, 170=2×5×17 and 325=5²×13. Unfortunately, the pattern isn’t continued into bases 23 and 28, but coincidentally, bases 8, 13 and 18 also have decent psis: 63=3²×7, 168=2³×3×7. (Yes, I know that the psi is the product of the alpha and omega, but still...) In fact, tridecimal has memorable tests for the first seven primes except 11. I wouldn’t use this as a treizenalist argument, only an interesting curiosity, because base 13 fails at everything else (no useful divisors, all fractions repeating except powers of 13...).
Actually I think this strengthens the case for the 10-12-14 base triangle. SPD is useful, but it is suboptimal, especially considering that three of every five bases have a simpler test for five. Seven, on the other hand, is only remotely reachable by SPD, and eleven even further (this really complicates divisibility up to eleven).
In decimal, for example, to test for seven through the regular SPD test, one would have to promote groups of three digits to a multiple of 7. By coincidence, decimal 301 is divisible by 7, so you could promote groups of two digits and correct the rest by triple the amount. Dozenal is the same, only instead of triple, correct it by the double in the opposite direction, and tetradecimal has seven as a factor. For eleven, decimal has it as its alpha, dozenal as its omega, and tetradecimal has it as a factor of the terribly inconvent 601 (1177 decimal).
However, casting off 98’s in decimal and 102’s (decimal 198) in tetradecimal is a quite intuitive way of grabbing hold of seven and eleven.

Posted by: Treisaran Nov 18 2012, 03:39 PM
Icarus, from the standpoint of number theory, I might venture to make two sweeping generalisations:
  1. The regular relationship is the father of all regular-type tests (divisor, semidivisor, rich regular whether through memorisation or range folding).
  2. The trim-right test achieved by virtue of modular arithmetic is the father of all neighbour-type tests (digit-sum, alternating-digits and the multiple-digit versions of them; successive subtraction of some least-significant digits from all the rest; and SPD).

We could call the first large grouping 'modulo-0 based tests' and the second large grouping 'modulo-1 based tests'. What makes one test special and another test unremarkable is its ease of application, which in turn is usually a function of its closeness to a number we consider 'round' in the base. So the power-neighbour tests for 5 and 7 in dozenal, based on *101 and *1001 being multiples of 5 and 7 respectively, are more special than the trim-right tests for them, based on *21 and 2E (for 5) and on *41 and 2E (for 7), because the powers *100 and *1000 are rounder than the multiples *20, *30 and *40.

QUOTE (Oschkar)
In fact, tridecimal has memorable tests for the first seven primes except 11.


Only 9 (which has an unhelpful cube-ω relation to the base) and B (dozenal E, decimal 11) are opaque in ununimal. 2, 3, 4 and 6 benefit from the proximity to dozen, getting them the digit-sum test; 7 gets the alternating digit sum difference test from the neighbour upstairs; 5 uses SPD as in dozenal; and 8, like the one additional binary power in all odd bases, is a square-ω inheritor and can therefore be tested for after compacting the tested number down to two digits by summing up pairs of digits.

I find the two neighbours of dozenal interesting to compare for their divisibility tests, because they're slightly different even though they both leech off their highly composite neighbour. In levimal, 3, 4 and 6 are tested with the alternating digit sum difference test; 2 and 5 get the digit-sum test; 7 and 9 are opaque (they're cube-α and cube-ω inheritors, respectively); 8 gets the paired digit-sum compaction option. To summarise, the dozenal factors are easier to test for in ununimal than in levimal, except 2, which in odd bases is always both ω and α and therefore of the same difficulty; 5 is significantly harder in ununimal, while 7 is out of reach in levimal; 8 is of the same difficulty in both, and 9 is opaque in both.

Naturally, there's no import to this comparison beyond its value as a curio. A base rich in divisors is always preferable, and dozenal gives us divisors in spades while leaving only the prime 7 opaque, which is no big loss.

The comparison also brings to mind another comparison, between octal and unquadral, which highlights the difference between theoretical and practical benefits. Except for eleven, opaque in both, the first six primes and 9 differ greatly, with octal having tests for 3 (alternating), 5 (SPD), 7 (digit-sum), 9 (alternating) and *11 (SPD), while unquadral has tests for 3 and 5 (both digit-sum) but leaves 7, 9 and *11 (0xD) opaque (they're all cube-ω inheritors). Does this make octal better than unquadral for divisibility testing? I don't think so. For practical purposes we need no more than the first three primes to be covered; since octal and unquadral both have that coverage, they now compete on ease of application, and here unquadral wins, offering the easy digit-sum test while octal needs the harder alternating-digits test for 3 and even harder SPD test for 5.

Of course, for coverage of the first three primes, one might opt for the divisor relationship for all of them, which brings us to 30 and its multiples.

Posted by: wendy.krieger Nov 19 2012, 08:56 AM
What is generally useful is a 'preferred interval', rather than short periods. A preferred interval means that the periods divide a common small number (like 4 or 6), and that the various products of these primes thus divide a short period.

In this list, i include the factors of the base to give completeness. These contribute to the pre-period. For example, in (note * should read **)
  • 10, the omega6 cluster is (2).3³.(5.).7.11.13.19.
  • 21 gives for a 4-place cluster 2*4 (3) 5 (7) 11 13 17, which is all but one prime.
  • 30 gives on 6 places, (2) (3) (5) 7² 13 29 31 67
  • 68 gives on 6 places (2*2) 3*2 7*2 13 19*2 23 31 67.
  • 80 gives on the inverted-3 place (ie 1.0.0.1) (2*4) 3*5 (5) 7*2 43
  • 99 gives on four places 2*4 (3) 5*2 7*2 (11) 13*2 29 or 1820² * 29
  • 120 gives on two places (2*3) (3) (5) 7 11*2 17.

Another interesting thing is that when one uses omega-2 sums in bases like 68 and 200, the possible number of sums that a regular number comes to is much smaller. Even in 20, the sums come to one of these eighteen 0.1, 0.2, 0.4, 0.5, 0.8, 0.10, 0.16, 1.5, 1.12, 2.10, 2.13, 3.4, 5.6, 5.13, 6.8, 6.11, 10.12, 12.16, and their reversals (eg 5.1 or 16.0). For base 200, a similar process gives 198 possibilities.

Even in base 120, the single place sum of the powers comes down to just 48 possibilities out of the 96 available (less 16 mulitoples of 7 and 6 multiples of 17, and one of both).

One can not really tell that twelve's relative usefulness comes from its particular factors. 12 has a pretty tight 'opposition', in that the recriprocals of regulars are about the same size as the regulars themselves. But then 56 and 72 have this. It's also pretty small, and the power of 2 is the larger of the two prime-powers to make it.




Posted by: icarus Nov 19 2012, 12:26 PM
[doHTML]

Posted by: Treisaran Nov 19 2012, 01:13 PM
QUOTE (icarus)
Again the designation “intuitive” is a construction; in the new work we’ll go beyond intuitive, to “practical”.


Both are subjective terms. I only objected to 'intuitive' because it implies a elementary schooler can discover the test all on his own, which I think holds true only for the divisor, semidivisor and placeholder* tests. Even the digit-sum wouldn't occur to a young child except as a fluke.

'Practical' sounds better, but it's still subjective. The problem here is deciding what the upper threshold of practicality is. I consider the number of two-digit multiples to be memorised for the SPD test for 5 in base 18 to be over the threshold, but others like Oschkar have disputed this. Who's right? Since it's subjective, we may both be. We can safely call a test 'impractical' only when the consensus as to its impracticality is overwhelming.

QUOTE
I think techniques like SPD and the higher mod-1 tests won’t be “first-tier” considerations but do need to be discussed when we delve into the divisibility test portion of any base.


SPD is an involved test; perhaps easy enough once you get the required multiples memorised, but it still hasn't got the same out-of-hand usability to it as the digit-sum and alternating-digits tests. The only thing that makes it worthy of note is that, finally, finally, after a long time trying to get the prime 5 into the dozenal fold in various ways, we've got a complete test for 5 in dozenal. I might say SPD is remarkable in a 'world's tallest midget' kind of way.

─────────
* The placeholder test is the one where you test divisibility by seeing if the tested number is the sum of two known multiples. For example, decimal 238 divides by 7 because it is the sum of 210 and 28, both known to be multiples of 7 from the basic multiplication table.

Posted by: icarus Nov 19 2012, 07:03 PM
In the work, I attempt to measure the quantity of practical tests, etc. and resort to defining "intuitive" as including only the regular, alpha, omega, and their compounds as such. Practicality is similarly defined by a definition. We indeed would need scientific research, the messy, iterative, empirical type that involves the resources of a multitude to conduct. The "intuitive" tests would be so to educated young adults, so that these would be used in their work. Many adults use the rules of 3 and 9 and the regular tests in a way that they are not necessarily conscious of.

Practicality would concern the feasibility of teaching children how to use the tests. This sets the bar rather low! I am not saying that kids have to understand it coming into the subject, but that the kids would need to be able to be taught and to retain the knowledge so that further lessons can build to new topics in math. The whole subject of elementary arithmetic would have to "fit" into the 4 or so year long period in grade school. This is another reason why bases larger than 16 (maybe even including 16!) are not "human scale", and why it is important to have a base in the human scale.

It is the very argument or constraint I've done a very good job of ignoring when we consider bases like 20, 24, or 60, etc. There is a way to sneak around the barrier, i.e., using decimal coded sexagesimal, etc. We'd simply teach a different set of algorithms and that might fit into the school box. If we teach arithmetic for too long, we will delay subsequent topics and "set back" society because we haven't addressed algebra till age 16. This is why bases between about 7 and at most (and I am trying hard to be nice to the hexadecimalists) 16, possibly certain decimal coded bases and quinary coded vigesimal are likely the only practical bases to teach.

In recent weeks I am thinking that the practical bases to teach civilizationally really are very limited: {7, 8, (9), 10, (11), 12, 14, 20 via 4:5, 60 via 6:10, maybe 120 via 12:10}, that they might even be as limited as {8, 10, 12, 14, 4:5, 6:10} (I have to say 4:5, 6:10 because these were civilizational bases, but I think these are alien to the way we do things now). Clearly out of this range the dozen stands out as offering the most support for human arithmetic, decimal a decent second, followed by 8 and then 14, the two rather close to one another, rather much less practical than decimal. With octal we have problems with compression but they are not unmanageable, we have alpha-dominance and SPD for 5. With tetradecimal we have more static with opaque totatives but the scale is not yet unmanageable. Hexadecimal simply seems too laden with opaque totatives and a massive magnitude; I think we're in 5th grade learning our digit-{7, 9, 11, 13} multiplication facts while the decimal and dozenal worlds are applying these in geometry and early algebra. Every other number base seems impractical in education or application, with too little compression, insufficient pattern-recognition support for arithmetic, or massive arithmetic tables.

I do think the dozenal SPD test would be taught in grade school in a duodecimal society. It is rather simple, and the multiples of 5 would be common knowledge as the multiples of 7 are in decimal. Thankfully, base 12 is human-scale and fully within the grasp of human cognitive capacity. So I think that one can grasp the dozenal multiples of 5 less than one gross through a sort of range folding:

00 05 0a 13 18 21 26 2b 34 39 42 47
50 55 5a 63 68 71 76 7b 84 89 92 97
a0 a5 aa b3 b8

in effect all we need is what we would have learned in 2nd grade: the multiples of 5 in the multiplication table, then recognizing that the pattern repeats every five dozen. With this we can construct the required range until it stands on its own.

I don't think SPD for 5 would prove as prominent as the decimal rules for 3 and 9 (the omega IDT), but I do think it would find enough use to be common knowledge among young adults moving into their professions in a duodecimal civilization. It would be the "rule of 5".

Posted by: wendy.krieger Nov 20 2012, 07:40 AM
A preferred interval comes when you get a large omega that is still managable, and has lots of useful primes in it. What you get is something like ;abcd or ;abcdef with lots of useful primes in it.

In decimal, one has 1/7 as 0.142857 1/11 = 0.090909, and 1/77 as 0.012987.

The six-place period has a lot of more useful factors than other shorter or longer periods, and it's pretty much about the only decent choice.

In base 16, (which is an eighth period), the three-place and five-place periods vye for attention, eg 3*3*5*7*13, and 3*5*5*11*31*41, but it's hard to pick from one or the other. Base 18 (3: 7*7*7*17 vs 4: 5*5*13*17*19) vye for attention so it doesn't have a preferred interval either.

Very few bases as sucg do have preferred intervals.

Posted by: Oschkar Nov 20 2012, 04:13 PM
Just a weird anecdote I had. I was looking for properties of base 18 and then for the rest of the day I found myself thinking in octodecimal completely. I hadn't realized it until I found myself counting "five, ten, trick, twenteen, seventeen, twelfteen,..." (yes, that's what I called them). Just makes me realize how much time I spend with other bases.

Posted by: wendy.krieger Nov 21 2012, 06:52 AM
QUOTE
I was looking for properties of base 18 and then for the rest of the day I found myself thinking in octodecimal completely.


Lucky you. I usually doodle in bases 14 and 22, and sometimes 70.

Posted by: Treisaran Nov 21 2012, 06:05 PM
This is very interesting, Icarus, the issue of teachability. Decimal is so ingrained that it's strange yet enlightening to think how elementary arithmetic would be taught in another base.

Again I can only appreciate how relatively fortunate we are to have settled on decimal as a non-dozenal base. In the entire human-scale range, putting odd bases out of consideration, ten is truly the second best. The alpha relationship you have to 3 in octal and unbinal makes things too hard. The importance of 3, the major reason for the existence of dozenalism, makes the digit-sum test a minimum requirement. Having an alternating-digits test is acceptable for 5 (as in base *20), but not for 3. For fractions, even the single-digit thirds of decimal aren't good enough, so the two-digit thirds of bases 8 and *12 would be simply intolerable.

Regarding the tables for SPD:

QUOTE (icarus)
in effect all we need is what we would have learned in 2nd grade: the multiples of 5 in the multiplication table, then recognizing that the pattern repeats every five dozen. With this we can construct the required range until it stands on its own.


I'm for such range folding as a scaffold, to be used until you've memorised the table straight out. There must, however, be some upper limit beyond which the scaffold becomes permanent. I think I could memorise the basic multiplication table row of 5 in base *28 (2↑5), but never the entire extended block of a bit over two hundred 2-digit multiples.

Hmm, looks like I'm set to agree with Oschkar that base *16 can use the SPD test for 5 after all. But I'm not interested in memorising it, just as I haven't memorised the small (smaller than dozenal) SPD table for 5 in octal. I value SPD for being, as you said, the 'rule of 5' in dozenal.

Apropos, your Dozenal FAQs contain the note that the inability to test for divisibility by 5 'bugs' you. That section could probably do with an update. wink.gif When you have the time and inclination, of course.

Another note: I decided on the name 'SPD' to stand for 'Split, Promote, Discard', the three operations involved, as a descriptive initialism that, as it were, includes the manual in the tool itself. Formally the particular SPD test for dozenal could be called the Abbreviated Square-Alpha Test, and SPD in general could be called the Abbreviated Power-Alpha Test. As I have noted elsewhere, there exist SPD tests based on power-omega relationships, but they make things harder rather than easier; the power-ω invites you to sum groups of digits, nice and easy, so no SPD needed.

Posted by: icarus Nov 21 2012, 08:59 PM
Treisaran,

Indeed I think that it wouldn't be long, after a period of application, that someone might memorize the multiples of five in a dozenal civilization. I used to work as a custodian aide in college; I grew up in an industrial town. In the biomechanical department at the hospital and the maintenance shop during my high school and college summers, I noticed the guys simply knew their 16ths, 32nds, and 64ths. Especially in the machine shop. These are usually the same guys that tell you they didn't want to be in school after high school, completely disinclined to the classroom, yet they knew 64 multiples of .015625! (To be sure, though, the shops had a big chart with these multiples printed out). These guys would tell you they weren't "book smart" but knew their multiples because it was a matter of course in their work; fractions of an inch, something practical for them. We wouldn't say that 64 is a practical regular number; I don't think we'd teach young kids the multiples of 1/64. I think we could rely on them to know the eighths after a few years in school, maybe have a feeling for the 16ths. I think 8 is the limit of practicality for powers of 2 in decimal. This doesn't mean people simply don't get and can't reach larger regulars like 64. It simply means that a young kid in school wouldn't be able to handle memorization. In the course of a profession, some things are handy to know, thus "impractical" regulars like 64 fall into use.

Surely the multiples of 5 less than 144 (only 28 such, a figure that falls within the range of practicality in my estimation) is not beyond acquisition by memory through use. I think the dozenal SPD for 5 is practical. I don't know if the 64 multiples of 5 less than 324 in base 18 is practical, but we can range-fold the 5 table to reach that figure (it's just that I think that base 18 is beyond practicality in memorizing the arithmetic tables).

Truly, no work introducing dozenal should stand without this rule mentioned, because it fills a key gap in the utility of base twelve. With the SPD for 5, or the "rule of 5", we can't get a compound rule for {10, 15, 20, 30, 40, 45, 55, 60, etc.}. The rule of five simply renders dozenal even more powerful. So if it doesn't really appear anywhere in the FAQs, they deserve to be updated.

Most of my pondering happens in very large bases, but I usually use dozenal and sexagesimal for things like counting laps, etc. while swimming. I use dozenal massively nearly daily in my work, as it is a handy way of manipulating (US Customary) dimensions, which I use daily. I use sexagesimal also in the computation of fees and other things. I am fond of tetradecimal because it is awkward and serves as a sort of analogy for decimal. The "pondering" normally is restricted to integers, but sometimes involves fractions especially of regular numbers.


Posted by: wendy.krieger Nov 22 2012, 08:32 AM
One can learn a great list of useful numbers, and retain them some time. For example, i did a lot of calculations on four-function calculators, so i set the equations up to use the short-chord (the chord of a triangle, bounded by two edges), of the regular polygons. The shortchords for 3-7, 10, and 12 are usually given to 12 digits.

One of the bits of magic one can weave with an SWS system is to take something like "Btu-inch / sq foot hr degF", and reduce it to the sws-coherent measure with little fuss. Each of these units equate to a number in sws, so that unit is simply an equation in numbers, eg 6d6. 3 / 9d2 1d5 1d4 = 2d-5. d = exponent duodecimal. I use the tiof in twelfty to do this. This is the sort of magic that an sws in a high-factor scheme does. The current duodecimal version lines up the units in a pretty tight scale, while still allowing things like 1/16, so it nearly gets the advantages of 16 (where the regulars are actually powers of the base).

There are also useful conversion points, and ratios, which means that you can look at metric or imperial figures, and simply convert the number at duodecimal, although not always at the radix. For example, the pressure given in millibars convert into dbo (my sws scheme), by supposing that 1013 mb is 101.3, gives 85;4 add 1/20; to get 89; gives 890; mbars (DD). Minutes are converted at 10 min = 10; min DD, Because bdo passes through metric at nearly the dm, kg values, many of the handy values convert at that ratio (eg 183 cm = 18.3 = 16;4 gives 164 bc or 6 ft 1 inche.)

This sort of trick allows you to read regular instruments and get conversions.

My previous conversion tables were based on giving decimal expansions of metric or imperial units to many places. Now it takes this form

Metrics are rounded to the

c ton : 1 us 25/28 m 100 t = 125/126
ton 6/5 us 15/14 m 1 t = 25/21
cwt ditto 50c = 25/21
stone 9/10 7c = 1
pound 9/7 500 g = 10/7
ounce 28/27 25 g = 6/7
dram 3/5 * 1.25 g = 3/7

exact 539/540 * 385/384 m = 203/205

troy:
ounce = 16/15 m 30 g = 1
drachm = 4/3 m 3 g = 1
dwt = 16/15 m 1.5 g = 1
scruple = 4/3 m = 1
ounce / c = 32/25 m = 6/5 mg
carat = 64/75 m = 4/5 200 mg
grain = 4/3 m = 1 50 mg
mite = 8/5 m = 24/25 mg

exact 99/100 metric = 7308/7175

c = 100 in the unit, either 100 units, or unit divided into 100. so c ton is a hundred tons (120 TW, 100 ME or BI).

This is read as a BI stone is 9/10 of the twelfty stone, but if you want a more exact value, you have to multiply it by 539/540. The conversions happen from the nearest unit to the nearest unit, avoiding any preferential base unit. So weight say of 108 kgs (or c chogs), is converted into 15 st 6 lbs ME, which gives 15 st 8 lb TW.

Posted by: Paul Rapoport Jan 5 2013, 03:55 AM
Le tour des bases est vraiment la tour . . .

If only I had the time to go through it all. The setup of the relatively low bases after 12 reminds me of music written in equal temperaments other than 12, a subject I've had a fair amount of involvement with over the past decades. Easley Blackwood wrote music in 13 to 24 and wrote about those tunings, demolishing received opinion about most of them.

I have no idea whether we'd have a rapprochement. Although I've devised principles for the best notation for a very large number of equal temperaments, I doubt that they'd benefit from a numbers-heavy approach, especially if one tries to maintain centric pitch organization (tonal/modal widely interpreted), which implies a clear first principle that necessarily biases the notation.

I've written music in 19-equal, 31-, and 25-, with a few bars in 13- (and 12-, of course). Although equal temperaments are by no means the only way to go outside 12, they provide many surprises in their basic setup and their harmonic relations, partly because of their completely transposable enharmonicities.

Posted by: icarus Jan 5 2013, 12:26 PM
Paul,

Thanks! The tour is intended to be a resource against which we can test our statements regarding duodecimal or any other base. If most of our argument is based on number theory (arithmetic), we have logic on our side. Some of the argument has to do with human cognition, which requires scientific research. Some of the human cognition argument is evident through observation. If we stick with the arithmetic algorithms and positional notation we are used to, then the bases up to about 20 are "wieldable". The "word length problem" restricts us to bases above 6 or 7, but the loss of compression below decimal makes us reluctant to settle for any base smaller than ten. The implicit duration of elementary instruction in arithmetic seems to restrict us to bases 16 or less (and I think the bases between 7 and 14 represent the range of tolerable duration of instruction: 16 seems to have us learning multiplication for two and a half years, so a total of 5 years, meaning all one's primary school, we're only achieving basic arithmetic). Within the range of bases 7 to 14, dozenal is evidently the most richly patterned base, working with human pattern recognition faculties, facilitating the acquisition and practice of arithmetic.

With base 16, we might say that we could use duplation and mediation to calculate, as it is "natural" in a base that is 2^2^2. I am unsure whether this approach to arithmetic at the scale of our current civilizational level of development would be as efficient as our mnemonic multiplication. If D&M is as efficient or nearly so, then hexadecimal is part of the range {7-14, 16}. my guess is that D&M is akin to the complementary divisor method of multiplication, dividing a single problem into parts, this division seems inefficient. Also hexadecimal might be buoyed if we redesigned numerals to resemble their binary values. Then the numerals aid arithmetic. This is why I have not written off base 16 as a "human scale base". So I consider the range 7-16 "human scale". Hexadecimal is also buoyed by its neighbor 15 = 3 * 5, giving it transparency for {3, 5, f} to multiplicity = 1, and products of powers of two with these neighbor factors. But transparency is no substitute for having those small primes as factors. Hexadecimal is depressed by "putting all its eggs in one basket", i.e., being a prime power. It suffers a paucity of regular numbers, which are the font of a richly patterned base. Any way you look at it, hexadecimal is an interesting base.

With decimal, it is not optimum but it is buoyed by the neighbor relationship with 9, which grants decimal good transparency for the "skipped" prime 3, its commonly encountered product 6, and its square 9. Because of this, and the "native" properties (compact size, relatively small prime factors) I think it is second best.

Duodecimal represents the convergence of several small cycles, leaving it in a "void", i.e., with prime neighbors. So its strength is concentrated its "native" properties. The patterns and brief representations of product cycles and expansions of unit fractions of small integers overcomes the relatively poor handling of small primes that do not divide twelve evenly. The patterning is a great aid to human arithmetic, making it easy to acquire and exercise.

I think it's neat to take a look at different scales, even very large ones. If we admit mixed radix representation, we might see that decimal coded sexagesimal and base 120, or quinary coded vigesimal are only about as difficult as hexadecimal, maybe more meritorious to use than base 16. The studies, like your own studies of music in scales other than 12 and this of others, only contribute to one's understanding of how scales work/affect music or arithmetic. At the least, they act as a foil for work in a favorite base of choice, especially if that base is optimized.

The tour is intended for reference, so if you're interested, read it now and then. No one has to read every post or read the range like a book. This way it's more like a dictionary or encyclopedia.

Posted by: Oschkar Mar 27 2013, 03:53 AM
J'attends désespérément le nouveau site du Tour des Bases depuis deux mois...

Posted by: Treisaran Mar 27 2013, 11:43 AM
Censeo Icarum occupatum esse, quoniam multas dies in foro non postavit.

Posted by: Oschkar Mar 27 2013, 08:37 PM
I was going to try to write a comment in Hebrew, but I really couldn't find any grammar references to guide me...

Posted by: Dan Mar 28 2013, 12:08 AM
QUOTE (Treisaran @ Mar 27 2013, 06:43 AM)
Censeo Icarum occupatum esse, quoniam multas dies in foro non postavit.

Quidquid latine dictum sit, altum viditur.

Posted by: icarus Jun 19 2013, 12:18 PM
Folks we are coming out of the darkness. Have had to do some business development, then have had a surge of work that commanded all my time. Still about a week from when I can return. There is a lot to read in the forum.

Hope all are well.

Posted by: Oschkar Jun 19 2013, 07:49 PM
QUOTE (icarus @ Jun 19 2013, 12:18 PM)
Folks we are coming out of the darkness. Have had to do some business development, then have had a surge of work that commanded all my time. Still about a week from when I can return. There is a lot to read in the forum.

Hope all are well.

I was about to write a suitably Icarian overview of bases 17, 19, 34, 55, 64, 99 and 2520, thinking that you wouldn’t return to the Forum. At least I’m glad to see that you’re back. Also, my Argam Kinsevoctove extension is done.

Posted by: icarus Jun 19 2013, 09:09 PM
Oschkar,

There is no prohibition for you to do so, actually! I am very interested in your argam extension!

I have one big job moving out and a less intensive job starting, then it seems quiet. So next month will resume the production of numberbases.com. I'd spent about a month of cut-up time on polychora. It seems whenever I am rebooting my affection for number bases, I go through polychora first. There, I see Wendy's name and contributions.

Posted by: icarus Jul 4 2013, 03:40 PM
The tour is expanded to cover the "prime detective" bases http://z13.invisionfree.com/DozensOnline/index.php?showtopic=973, http://z13.invisionfree.com/DozensOnline/index.php?showtopic=974, and http://z13.invisionfree.com/DozensOnline/index.php?showtopic=975. Check out the http://z13.invisionfree.com/DozensOnline/index.php?showtopic=621&view=findpost&p=22006428 for other recently-added bases like http://z13.invisionfree.com/DozensOnline/index.php?showtopic=972 and http://z13.invisionfree.com/DozensOnline/index.php?showtopic=968. This covers the "prime detectives" {15, 21, 34, 55, 99, 120, ...} and the primes {5, 7, 11, 13, 17, 19, ..., 173}.

Posted by: anirudhk Aug 24 2013, 05:40 AM
Icarus, when will the tours for 2, 3, and 4 be over?

I'm especially eager to see your tour for base 4.

Posted by: Oschkar Jun 6 2014, 05:15 AM
*bump*

Posted by: icarus Jun 7 2014, 01:02 AM
We'll get to them when vacation is over.

Posted by: PiotrGrochowski Jul 17 2014, 12:20 PM
QUOTE (icarus @ May 1 2012, 05:04 PM)
[doHTML]

Oh, i need a link for base 3!

Posted by: icarus Nov 19 2014, 10:22 PM
I've updated the http://www.numberbases.com/essay/MultiplicationSynopsis.pdf to include tables for each base between 2 and 60 inclusive. Note, this is a 30Mb PDF. It includes the Lamadrid Base Nomenclature system and some material on squares, along with an explanation of argam used in the transdecimal bases.

An abridged version of this document appears at www.dozenal.org and is the usually most popularly downloaded document there. It has flaws in bases in the 20s, 30s, and 40s since the tables were produced "by hand". The version there will also be corrected very soon.

I am working on writing algorithms so that the Tour des Bases can be reproduced at the website as accurately and completely as possible. (I find I can't link folks to these posts.)

The scripts will be unified so that one can produce all the bases in a Mathematica notebook fully algorithmically.

I am working on a large format poster of the digit maps (arithmetic relationship tables) that includes all bases between 2 and 2520. This was started in June but set aside. There will be a limited print run and the posters will be available in 2015. The posters may be available when the numberbases.com site is finished. (i.e., when the North American continent collides into Japan, whichever comes first).

Posted by: Piotr Aug 9 2015, 07:02 PM
Posting it in category Non-Dozenal bases is completely misleading. This topic also describes bases larger than 60, so it would be better to post it in General category.

Posted by: Kodegadulo Aug 9 2015, 07:23 PM
QUOTE (Piotr @ Aug 9 2015, 07:02 PM)
Posting it in category Non-Dozenal bases is completely misleading. This topic also describes bases larger than 60, so it would be better to post it in General category.

Piotr, "Thread Necromancy" -- bringing a long-dead thread "back to life" -- is generally considered bad Internet etiquette, unless you have a useful or significant observation to add to that conversation. Complaining about the thread does not count as a useful or significant observation. Whether or not this thread is in the appropriate place is not worth troubling people about, given that the conversation was started and died out many months ago. (Icarus may certainly revive this thread if and when he has some update about the topic, such as some improvement or update to his numberbases site.)

More generally, it is not appropriate for someone under age to dictate rules to his elders. You may suggest, certainly, but not dictate. You have already been warned about this.

Posted by: Double sharp Oct 17 2015, 04:47 AM
QUOTE (icarus @ Jun 19 2013, 09:09 PM)
Oschkar,

There is no prohibition for you to do so, actually! I am very interested in your argam extension!

I have one big job moving out and a less intensive job starting, then it seems quiet. So next month will resume the production of numberbases.com. I'd spent about a month of cut-up time on polychora. It seems whenever I am rebooting my affection for number bases, I go through polychora first. There, I see Wendy's name and contributions.

Well, if there is no prohibition, here's a list of bases I'd love to have a tour to look at that are not already in:

{2, 3, 4, 22, (23), 26, 27, (29), 32, (33), (35), (38), 40, (44), (45), 50, 54, 56, 64}

I might try some of the ones in the twenties, to give complete coverage for the range {2-30}. {32, 64} have been covered elsewhere in mashups, and {27, 29, 40} have been covered as "random" bases, so they'd be easier.

I don't really have the time to try to do grand bases: if I did one at all, it'd be {180} to get the complete sequence of HCNs until {720} in the tour. I'd be scared to do the low bases {2, 3, 4} because they are so exceptional - so I think those are best left to Icarus. (^_^)

I also believe {2310, 2520} deserve a place here, but what an effort that would be!

Nevertheless I find I don't really have very good ideas for nice subtitles, like what Icarus has done for many of the covered bases. The personifications of bases are an interesting idea: I may need to think more about this.

Posted by: Double sharp Oct 17 2015, 09:52 AM
QUOTE (Double sharp @ Oct 17 2015, 04:47 AM)
QUOTE (icarus @ Jun 19 2013, 09:09 PM)
Oschkar,

There is no prohibition for you to do so, actually! I am very interested in your argam extension!

I have one big job moving out and a less intensive job starting, then it seems quiet. So next month will resume the production of numberbases.com. I'd spent about a month of cut-up time on polychora. It seems whenever I am rebooting my affection for number bases, I go through polychora first. There, I see Wendy's name and contributions.

Well, if there is no prohibition, here's a list of bases I'd love to have a tour to look at that are not already in:

{2, 3, 4, 22, (23), 26, 27, (29), 32, (33), (35), (38), 40, (44), (45), 50, 54, 56, 64}

I might try some of the ones in the twenties, to give complete coverage for the range {2-30}. {32, 64} have been covered elsewhere in mashups, and {27, 29, 40} have been covered as "random" bases, so they'd be easier.

I don't really have the time to try to do grand bases: if I did one at all, it'd be {180} to get the complete sequence of HCNs until {720} in the tour. I'd be scared to do the low bases {2, 3, 4} because they are so exceptional - so I think those are best left to Icarus. (^_^)

I also believe {2310, 2520} deserve a place here, but what an effort that would be!

Nevertheless I find I don't really have very good ideas for nice subtitles, like what Icarus has done for many of the covered bases. The personifications of bases are an interesting idea: I may need to think more about this.

As a first try at a "guest post" (since I haven't seen many very new entries on the tour), I've done http://z13.invisionfree.com/DozensOnline/index.php?showtopic=1390. Hopefully it's OK and I didn't miss anything very important.

My intent would be to cover {40, 54, 56} if nothing else. Following that, I'd go to {44, 45, 50, 52}, and then the binary powers {32, 64}.

Posted by: wendy.krieger Oct 17 2015, 12:01 PM
Hi Double Sharp.

I did a thread on 54 v 56. These have the same signiture, but the loosest and tightest oppositions (reciprocal pairs) of any base less than 100. 56 has the joys that among its regulars are 7^13 and 8^13. The former, written in base 56 is the best 7-smooth approximation to pi, using numbers under 10^9.

So the ripple-13 here contains in effect, pi, 2pi, 4pi, 56/pi, 28/pi and 14/pi.

Also, Icarus has been copying the sevenite entries into his tour-de-bases, so 48 has 7 and 257 as sevenite (Weiferich primes). Likewise 40 has 40: 11 17 307 66431. The number in base 40, ie 40^8+1, has a lot of divisors, eg

CODE

[C:\save\newin\tcmd18x64]aj 40 16
factorising 40A16 = 6553600000001
first trying brute force division by small primes
PRIME FACTOR     17
PRIME FACTOR     17
PRIME FACTOR     113
PRIME FACTOR     337
PRIME FACTOR     641
PRIME FACTOR     929


where 113 * 929 = 18^4 +1.

Posted by: Double sharp Oct 17 2015, 01:13 PM
QUOTE (wendy.krieger @ Oct 17 2015, 12:01 PM)
Hi Double Sharp.

I did a thread on 54 v 56.  These have the same signiture, but the loosest and tightest oppositions (reciprocal pairs) of any base less than 100.  56 has the joys that among its regulars are 7^13 and 8^13.  The former, written in base 56 is the best 7-smooth approximation to pi, using numbers under 10^9. 

So the ripple-13 here contains in effect, pi, 2pi, 4pi, 56/pi, 28/pi and 14/pi.

Also, Icarus has been copying the sevenite entries into his tour-de-bases, so 48 has 7 and 257 as sevenite (Weiferich primes).  Likewise 40 has  40: 11  17  307  66431.  The number in base 40, ie 40^8+1, has a lot of divisors, eg

CODE

[C:\save\newin\tcmd18x64]aj 40 16
factorising 40A16 = 6553600000001
first trying brute force division by small primes
PRIME FACTOR     17
PRIME FACTOR     17
PRIME FACTOR     113
PRIME FACTOR     337
PRIME FACTOR     641
PRIME FACTOR     929


where 113 * 929 = 18^4 +1.

I added a note about quadragesimal Wieferich primes (following Icarus' new preference in terminology).

I can see that 408 + 1 has many factors, but these are such high-rank neighbours that I am not sure it is significant enough to mention. 103 + 1 is divisible by 7, and this is not mentioned either in Icarus' tour for decimal. I would like the entries to be consistent, even my "guest posts", so they would have to all stop at square-neighbours.

Next up will be {54, 56, 64}.

EDIT: Could you link to that thread on {54, 56}? I seem to have missed it.

Posted by: icarus Oct 19 2015, 02:37 PM
Double Sharp:

Thanks for extending the tour! I've incorporated the threads you added to the tour to the menu post. I'd been out of town.

I am now working on code that will automatically generate a tour (possibly in parts).

Posted by: Double sharp Oct 19 2015, 02:51 PM
QUOTE (icarus @ Oct 19 2015, 02:37 PM)
Double Sharp:

Thanks for extending the tour! I've incorporated the threads you added to the tour to the menu post. I'd been out of town.

I am now working on code that will automatically generate a tour (possibly in parts).

You're welcome! Next will be {54, 64} as promised. I intend to return to {32, 50} also to complete the binary-power range and the even numbers flanked by composites up to 64.

After that (or possibly before {32, 50}?) I might work up enough courage to tackle some of the remaining bases in the twenties that need high-pass coverage. I will leave the exceptional cases {2, 3, 4} to you, as there are so many things to say (those are the ones I've greatly anticipated).

I do think most of the tours can be automatically generated, but there usually is something about a hypothetical world where the base was used in civilization and reasons why one would use that base, that would be a little difficult to automate. In cases like {6} vs. {12} (not that there are many of those cases left), there are many "soft" factors as well as "hard" factors; and in bases like {2, 3, 4}, things are so exceptional that I am not sure if the standard template can hold. Maybe after {30} most of the bases would be automatically generated, but before that I think the bases are distinct enough that we need a human tour guide walking through each of them. (I actually think everything below {30}, every composite below {60}, and many HCNs after that have their own distinct personalities.)

As for "grand" bases, after thinking more about them, I'd like to see at least {180, 216}, completions of the tours for {420, 840}, and the huge HCNs and primorials {1260, 1680, 2310, 2520, 5040}. I do not think most grand bases are even worth looking at: brimming on being too large to use, I think they need a really great advantage to carry the day, and outside {240, 360, 2520} I'm just not seeing it. But {180} is interesting as the remaining HCN below 840 not covered (we ought to fill that gap), and {216} is interesting as it is 63. But this is a job for automation! I wouldn't dare try for any but the lowest two, {180, 216}.

Posted by: icarus Oct 27 2015, 05:21 PM
Automation update.

While I've had a break this past week I've worked on algorithms that will automate the production of the tour for a website I already own. Some of the algorithms have application here.

I've written a Wolfram code that automatically produces regular number maps for any base between {2, 510510}, flattening anything more than 3-dimensional spaces to a series of "charts". (It takes several seconds to produce the map of the 4843 regular digits of base 510510 in order of primes involved in the factorization of the regulars.) I will probably never produce a map as large as that one, but the code soundly handles the "ceiling" base of 5040.

(I've tested the primorials because these set a new dimension to the field of regular numbers. 510510 = primorial 7. A primorial is a product of the primes up to the nth prime. Product_{k = 1...n} Prime(k). I tested the algorithm up to primorial 8 (9699690) but could not generate the set. I found a way to make the algorithm more efficient as it was assuming the first field (that of the smallest two primes) was the dimension to use on all subsequent fields. This was producing many null fields as the space represented as regular is the n-dimensional simplex, not the n-dimensional measure polytope. The new algorithm produces primorial 7 in a quarter of the former time, but the next primorial might be too complicated to display. It has 19985 regulars. The algorithm handles 510510 and that is sufficient. I have other algorithms that generate regulars in numeric order that do cover 9699690)

I am now working on an html-writing digit code script that would output a chart that would work on this forum. This is a more general script that would apply to many of the items (divisibility test charts, primes below a level, etc.) on the tour pages of this forum. The script already properly formats the charts; now it has to function for an expanded set of flags that will maximize the code's flexibility.

Algorithms already exist for fraction maps, multiplication tables, and digit maps. The latter two algorithms have an embedded routine that codes the digits, but the new coding algorithm will reverse the process. The tables will be generated first (a trivial or easy endeavor in and of itself) and the coding algorithm mapped across them to produce either html tables or graphics. The current regular matrix algorithm could be incorporated in the sort of manifold of the latter two algorithms, however I want to devise a mappable coding algorithm and abandon the self-contained approach.

Might take a break and write a regular-number - fraction table algorithm as seen at pentadecimal.

EDIT: regularUnitFraction function done. Just raw data:
CODE

regularSet[n_, e_] := Block[{f, a},
 f[x_] := First /@ FactorInteger@ x;
 a = f@ n;
 {1}~Join~Select[Range[n^e], Complement[f@ #, a] == {} &]]
enCode[m_, n_] :=
StringJoin[
 FromCharacterCode[
    Which[# < 10, # + 48, 9 < # < 36, # + 87,
       True, # + 29 ] & /@ #] &@ IntegerDigits[m, n]]
regularUnitFractions[b_, r_] := Block[{t = Rest@ regularSet[b, r]},
  Transpose@{enCode[#, b] & /@ t,
    StringJoin[".",
       enCode[#, b] & /@
          PadLeft[First@ #, Length@ First@ # + Abs[Last@ #]] &@
        RealDigits[1/#, b]] & /@ t}] // TableForm

Output:
CODE

regularUnitFractions[15, 4]

3 .5
5 .3
9 .1a
10 .1
1a .09
1c .085
30 .05
50 .03
56 .02ba
85 .01c
90 .01a
100 .01
113 .00dd5
1a0 .009
1c0 .0085
2ba .0056
300 .005
339 .00496a
500 .003
560 .002ba
850 .001c
900 .001a
9ac .0018235
dd5 .00113
1000 .001
1130 .000dd5
1a00 .0009
1c00 .00085
1e26 .0007ab1a
2ba0 .00056
3000 .0005
3390 .000496a
496a .000339
5000 .0003
5600 .0002ba
5c73 .000288a85
8500 .0001c
9000 .0001a
9ac0 .00018235
dd50 .000113
10000 .0001

Posted by: icarus Oct 27 2015, 07:53 PM
Here is a roster of canonical colors used in the tour, extracted with the following code:
CODE

colorCode[
 w_] := {Last@ #, RGBColor[#] &@ Take[#, 3],
    StringJoin[
     FromCharacterCode[If[# < 10, # + 48, # + 87 ] & /@ #] &@
          If[Length@ # == 1, PadLeft[#, 2], #] &@
        IntegerDigits[IntegerPart@ Times[#, 256], 16] & /@
      Take[#, 3]]} & /@ w //
 TableForm; colorCode@{{0.84375, 0.125, 0.15625, "d"}, {0.96875,
  0.53125, 0.5625, "dc"}, {0.96875, 0.78125, 0.78125, "di"}, {0.75,
  0.15625, 0.75, "u"}, {0.96875, 0.78125, 0.65625, "gi"}, {0.96875,
  0.65625, 0.46875, "gc"}, {0.953125, 0.46875, 0.1875, "g"}, {0.8125,
   0.90625, 0.125, "ha"}, {0.78125, 0.6875, 0.1875, "hb"}, {0.5625,
  0.75, 0.25, "ho"}, {0.99609375, 0.9375, 0, "h"}, {0.9375, 0.890625,
   0.75, "hh"}, {0.78125, 0.875, 0.625, "hoi"}, {0.875, 0.84375, 0.5,
   "hbi"}, {0.90625, 0.9609375, 0.5625, "hai"}, {0, 0.6640625, 0.625,
   "taa"}, {0.5, 0.1875, 0.5625, "tbb"}, {0, 0.4375, 0.75,
  "too"}, {0.74609375, 0.75, 0.75390625, "tpp"}, {0.83984375,
  0.84375, 0.84765625, "tp"}, {0.90625, 0.91015625, 0.9140625,
  "t"}, {0.78125, 0.8671875, 0.90625, "to"}, {0.78125, 0.765625,
  0.90625, "tb"}, {0.78125, 0.859375, 0.6953125, "ta"}}

The first group {d, dc, di, u, gi, gc, g} is the regular group. Positions 1-3 code divisors, positions -1 through -3 code nondivisor regulars. Position 4 codes units (coprime divisor = digit 1). There are three richness shadings if richness display is selected.
The second, {ha, hb, ho, h, hh, hoi, hbi, hai} is the semicoprime group. Position {1, -1} codes alpha-related semicoprime, Position {2, -2} codes alpha-omega semicoprime, position {3, -3} codes omega-related semicoprime. Position {4, -4} codes semicoprimes but does not take into account neighbor-factor. (Position -4 is the "impractical" or "rich" semicoprime, meaning its regular part is richer than 3x).
The last, {taa, tbb, too, tpp, tp, t, to, tb, ta} is the coprime group. Position {1, -1} codes alpha-factor totatives. Position {2, -2} codes alpha-omega factor totatives (i.e., digit 2 in odd base). Position {3, -3} codes omega-factor totatives. Position 4 codes long prime totatives. Position 5 codes semimaximal prime totatives. Position -4 codes totatives without distinction. Positions 1-3 are the "accentuated" versions of {-1, -3} when intuitive divisibility tests or simple view (regular-semicoprime-totative) maps are generated.

Posted by: icarus Oct 29 2015, 03:52 PM
The mapping algorithm has been made to produce maps of regular numbers and is mappable across the terms of a list (essentially elements in an array). Tweaking it today. Will add HTML capabilities. This is a big dragon to slay and I am excited about it. The algorithm will thus produce multiplication table maps, digit maps, prime ranges, and regular number maps. The fraction mapper will be a special case already produced that will be retained rather than revised and made flexible.

Next sortie will be to automate the writing of intuitive divisibility tests (IDTs). There are three main IDTs- the regular or "direct" (cf. decimal 5: look at one last digit, if {0, 5}, then yes), the neighbor-related or "indirect" (cf. decimal 3, add digits of the number, if divisible by 3 then yes), and the compound (cf. decimal 6, if even and divisible by 3, then yes). "SPD" is considered a neighbor rule and is once in a while practical. (I would say it is practical in dozenal and mitigates the "allergy: 12 has to 5.) Impractical rules will not be shown. For now, modular math tests will not be covered but could be.

Output: regular map for 5040, computed in .03 seconds (embedded). Produced same map with richness effects in same time. Produced a map of 30030 (Primorial 6) in .3 seconds and 510510 (Primorial 7) in 2.5 seconds.

Posted by: icarus Oct 29 2015, 09:54 PM
[doHTML]
The flexCell algorithm now can write HTML coded maps. The production of digit maps, multiplication tables, regular maps, prime range maps can now be entirely automated.

For real, I am jumping up and down in my office! Sorry. Longest code I've ever written in Wolfram Language, essentially a large if-then sort based on number-theoretical properties.

Here is an example: base 180 digits:
[doHTML]

Getting close to automating entries!

Posted by: icarus Oct 29 2015, 10:04 PM
Test area: today: Base 224 showing intuitive divisibility tests, regular richness, prime period.

(Formerly {641, 741, 216, 630, 930}).

[doHTML]

Posted by: Oschkar Oct 29 2015, 10:52 PM
This is beautiful... Would it be possible for you to share the code so I can test it out?

Posted by: icarus Oct 30 2015, 02:26 PM
Oschkar, let me iron out some bugs. I plan to furnish code on the website, creative commons, etc. Also plan to submit it to Wolfram Demonstrations. Otherwise I am happy to do so.

One of the things that need be corrected is smoothing input in the flexCell routine so it is rugged and smoothly mappable across any sort of list. The output of several process programs are usually smoothed out but I've got glitches with this. Then I need to integrate this into a wider context and may make other alterations. There is a color collision that I would like to handle now.

Posted by: Double sharp Oct 30 2015, 02:31 PM
Is your choice of {180, 216} because I said I found them the most interesting of the not-yet covered grand bases? (^_-)-☆

When {741} was up, I noticed that your digit map went past the last digit (omega), and was laid out in rows of thirty: is there a good reason for this, because I'm not seeing it (cutting off at 750 and arranging in 30s seems to impose trigesimal thinking on the base)? Although I do like how we now show "10" rather than "0" as a divisor in the maps for {180, 216}.

Posted by: icarus Oct 30 2015, 10:31 PM
Yes! (Now I changed it to 641 ; ) )

The numeralRange routine produces a rectangular field for the digits of base b when the number of digits exceeds a magic threshold. The threshold uses the first divisor of b >= Sqrt( b ), and if Sqrt( b ) > 30, the first divisor of b <= 30, or forces 30 if no clement width can be found. I do this because I generally want the table to be more or less square but it it's going to be rectangular, I want a wider box than taller (most often). I use a divisor to ensure a rectangle for composites. For primes, I find a nearby composite larger than the prime with a clement divisor and use that, and we get a few (but less than a row) of extra "numerals". So the digit maps of large bases will have a few extra "numerals" when they are prime. The algorithm is built such that it would make most of the decisions I would be inclined to make. 30 = primorial(prime(3)), but more practically, it fits the width of my website screen and most screens these days.

I have moved away from "digit 0" signifying 0 (mod b ) (which it does - it is not a normal digit) because it also signifies zero when it stands alone. I think showing the range 1...b is natural and have considered showing 1...(b + 1) and will do that for primes {p, q} < b + 1.

Today I began slaying the automatic generation of intuitive divisibility tests for bases. At the outset this seemed like an easy task. I wrote a threshold for this program to pre-validate numbers n in base b that have intuitive divisibility tests.

The "intuitive" divisibility tests include:
Regular tests: base itself, integer powers e of the base with e >= 2, divisors, regular numbers with richness <= 2, or richness = 3 IF the regular number g is such that b - g < 3. The regular number threshold for richness and string length of multiples of g in the multiplication table of b is not arithmetic-based but "soft". Regular tests with richness > 3-4 are considered impractical and labeled such, but still shown.
Neighbor-factor tests: factors of (b^2 - 1): if divisors of (b + 1), alpha, if divisors of (b - 1), omega.
Divisor of (b^4 - 1) for bases b = 0 (mod 6) and <= 18. This thus enables SPD for 5 in bases 12 and 18, however I am wondering if those for 7 should be included.
Inherited tests. The algorithm determines impracticality of the regular part and the mutually coprime "silos" of prime-divisor-powers of n (for n = 12, the "silos" are {4, 3}. Decimally, 4 has a 2-richness regular test and an omega factor test, but the algorithm merely will say "if divisible by 3 and 4, then...")

The threshold defaults to 30 and tends to be that for odd bases but prefers the regular number g base b that exceeds 30 by less than or equal to six. (Many even b have 32, bases b = 0 (mod 6) have 36, bases {31, 62} have 31, bases {33, 66} have 33, bases {34, 68} have 34, base {35, 70} have 35, etc.) I wanted a responsive threshold for the cutoff in the vicinity of the 3rd primorial, because for intuitive tests, we're generally looking at small numbers.

The prevalidation was tricky but I have it down now:
CODE

intuitive[m_, n_] :=
 If[IntegerQ[m/Power @@ First@ FactorInteger@ (n^2 - 1)], False,
  Or[Complement[First /@ FactorInteger@ m,
     First /@ FactorInteger@ n] == {},
   Divisible[Times[n^2 - 1, If[And[Mod[n, 6] == 0, n <= 18], 5, 1]],
    Times @@ Select[Power @@ Transpose@ FactorInteger@ m, CoprimeQ[n, #] &]]]]

Basically, within the range bounded by the threshold, this finds any regular number in the range. Then it finds any number with a coprime part that is a divisor of (b^2 - 1). It also adds 5 if in the SPD-useful range. For odd bases, it disqualifies any power of 2 greater than that power of 2 in (b^2 - 1). This reduces the work the idtCode routine needs to perform to generate HTML code.

Right now the program merely declares the arithmetic relationship of the vetted n to base r and its subdivision. For semicoprimes, it suggests using "silo" factors.

Examples: base 15:
CODE

2 Coprime: Evenness test in odd base.
3 Regular: Divisor.
4 Coprime: Alpha Factor.
5 Regular: Divisor.
6 Semicoprime: Use 2 3.
7 Coprime: Omega Factor.
8 Coprime: Alpha Factor.
9 Regular: Richness 2.
10 Semicoprime: Use 2 5.
12 Semicoprime: Use 3 4.
14 Coprime: Omega Factor.
15 Regular: Base.
16 Coprime: Alpha Factor.
18 Semicoprime: Use 2 9.
20 Semicoprime: Use 4 5.
21 Semicoprime: Use 3 7.
24 Semicoprime: Use 3 8.
25 Regular: Richness 2.
27 Regular: Richness 3.
28 Coprime: Alpha-Omega Factor.
30 Semicoprime: Use 2 3 5.


Dozenal:
CODE

2 Regular: Divisor.
3 Regular: Divisor.
4 Regular: Divisor.
5 Coprime: Alpha-2 Factor
6 Regular: Divisor.
8 Regular: Richness 2.
9 Regular: Richness 2.
10 Semicoprime: Use 2 5.
11 Coprime: Omega Factor.
12 Regular: Base.
13 Coprime: Alpha Factor.
15 Semicoprime: Use 3 5.
16 Regular: Richness 2.
18 Regular: Richness 2.
20 Semicoprime: Use 4 5.
22 Semicoprime: Use 2 11.
24 Regular: Richness 2.
26 Semicoprime: Use 2 13.
27 Regular: Richness 3.
30 Semicoprime: Use 2 3 5.


Things to do are to add the combinations and number of combinations for the regulars. If the number of combinations exceeds 12, I will abbreviate the list to only show the first 3 and the last one. Then it will have to handle range-folding for regulars with richness 2 and 3. I've entered all the language components "If an arbitrary number ...", " if the least significant ", " place values are one of ", etc. so all the program will do is catenate the appropriate components. The omega testable numbers are easy: " if the digital root of x is divisible by ". The inheritors are easy and will be converted to say " if the number x is divisible by " and list the prime-divisor-powers of x. Then I'll have the algorithm add the <ul>, <li> tags, catenate the language, etc. and the component will be complete.

This segment will eliminate all the drudgery of writing that language by hand, prone to missing a relationship or misstating the rule. These may be color-coded with a square character in the color canon representation of their regular and coprime factors.

Then we will move on to segment A, the first part of the boilerplate and work down.

I do agree with you Double Sharp that the entries can't be fully auto-generated. The auto-generation applies to the parts outside of the travelogue. The segment that describes auxiliaries will not be as prosaic and will merely show possibilities and common fractions (the natural ones, one fifth, one sixth, one eighth, etc.) in the system. The prosaic narrative can be incorporated in the travelogue.

I need to add grid labeling to the flexCell routine. This would require a way to recognize labeling and probably a flag. I will hold on this for a little while as I try to establish the other parts of the project.

The project could be suddenly interrupted by "real work", and I have to update my website with new project examples (i.e., "real work") but am focused on this project otherwise.

Posted by: Double sharp Oct 31 2015, 01:57 AM
QUOTE (icarus @ Oct 30 2015, 10:31 PM)
Yes! (Now I changed it to 641 ; ) )

How nice! 641 is pretty interesting for a prime base, as its omega 640 = 2^7 * 5 gives incredible binary divisibility, while the alpha 642 = 2 * 3 * 107 gives the minimal ternary coverage. As a result the most useful and common composites gain intuitive divisibility tests, as prime powers up to {2^8, 3, 5, (107)} are covered.

(Although: why's 256 shaded like the alpha-omega compounds? Its test doesn't work that way; it gets the square-omega test, doesn't it?)

QUOTE (icarus @ Oct 30 2015, 10:31 PM)
The numeralRange routine produces a rectangular field for the digits of base b when the number of digits exceeds a magic threshold. The threshold uses the first divisor of b >= Sqrt( b ), and if Sqrt( b ) > 30, the first divisor of b <= 30, or forces 30 if no clement width can be found. I do this because I generally want the table to be more or less square but it it's going to be rectangular, I want a wider box than taller (most often). I use a divisor to ensure a rectangle for composites. For primes, I find a nearby composite larger than the prime with a clement divisor and use that, and we get a few (but less than a row) of extra "numerals". So the digit maps of large bases will have a few extra "numerals" when they are prime. The algorithm is built such that it would make most of the decisions I would be inclined to make. 30 = primorial(prime(3)), but more practically, it fits the width of my website screen and most screens these days.

That makes sense. Thirty fits well on my phone as well. When doing the divisibility test map for octal I extended it to thirty-two as 36o is a little weird in octal, but then it went a little off the screen on my phone IIRC.

QUOTE (icarus @ Oct 30 2015, 10:31 PM)
I have moved away from "digit 0" signifying 0 (mod b ) (which it does - it is not a normal digit) because it also signifies zero when it stands alone. I think showing the range 1...b is natural and have considered showing 1...(b + 1) and will do that for primes {p, q} < b + 1.

I agree - alpha is usually pretty important; though it's not a digit, it enjoys alpha benefits just the same. This way it would always get shown, even if it is a prime (like in decimal, duodecimal, or hexadecimal).

QUOTE (icarus @ Oct 30 2015, 10:31 PM)
Today I began slaying the automatic generation of intuitive divisibility tests for bases. At the outset this seemed like an easy task. I wrote a threshold for this program to pre-validate numbers n in base b that have intuitive divisibility tests.

The "intuitive" divisibility tests include:
Regular tests: base itself, integer powers e of the base with e >= 2, divisors, regular numbers with richness <= 2, or richness = 3 IF the regular number g is such that b - g < 3. The regular number threshold for richness and string length of multiples of g in the multiplication table of b is not arithmetic-based but "soft". Regular tests with richness > 3-4 are considered impractical and labeled such, but still shown.

I think it still depends somewhat on the number of distinct sequences to memorise: to take an extreme example, 625 has richness 4 in decimal, but there are only 16 digit-sequences to learn, so it may well be practical (though pretty useless). OTOH, 16 has richness 4 as well, but there are 625 digit-sequences to learn, so it's completely impractical (and being two levels up from the highest memorisable binary-power test for 4, the range-folding algorithm is incredibly baroque and difficult to use).
QUOTE (icarus @ Oct 30 2015, 10:31 PM)
Neighbor-factor tests: factors of (b^2 - 1): if divisors of (b + 1), alpha, if divisors of (b - 1), omega.
Divisor of (b^4 - 1) for bases b = 0 (mod 6) and <= 18. This thus enables SPD for 5 in bases 12 and 18, however I am wondering if those for 7 should be included.

Those for 7 would be divisors of (b^6 - 1) in the worst-case scenario, so I'm not sure they are usable in most of the human scale bases, as there are so many multiples below "1000". What I think we need to do is to set down exactly how many digit-sequences we need to remember to use the test, and then impose a threshold beyond which the test is considered impractical.
QUOTE (icarus @ Oct 30 2015, 10:31 PM)
Inherited tests. The algorithm determines impracticality of the regular part and the mutually coprime "silos" of prime-divisor-powers of n (for n = 12, the "silos" are {4, 3}. Decimally, 4 has a 2-richness regular test and an omega factor test, but the algorithm merely will say "if divisible by 3 and 4, then...")

The threshold defaults to 30 and tends to be that for odd bases but prefers the regular number g base b that exceeds 30 by less than or equal to six. (Many even b have 32, bases b = 0 (mod 6) have 36, bases {31, 62} have 31, bases {33, 66} have 33, bases {34, 68} have 34, base {35, 70} have 35, etc.) I wanted a responsive threshold for the cutoff in the vicinity of the 3rd primorial, because for intuitive tests, we're generally looking at small numbers.

The prevalidation was tricky but I have it down now:
CODE

intuitive[m_, n_] :=
 If[IntegerQ[m/Power @@ First@ FactorInteger@ (n^2 - 1)], False,
  Or[Complement[First /@ FactorInteger@ m,
     First /@ FactorInteger@ n] == {},
   Divisible[Times[n^2 - 1, If[And[Mod[n, 6] == 0, n <= 18], 5, 1]],
    Times @@ Select[Power @@ Transpose@ FactorInteger@ m, CoprimeQ[n, #] &]]]]

Basically, within the range bounded by the threshold, this finds any regular number in the range. Then it finds any number with a coprime part that is a divisor of (b^2 - 1). It also adds 5 if in the SPD-useful range. For odd bases, it disqualifies any power of 2 greater than that power of 2 in (b^2 - 1). This reduces the work the idtCode routine needs to perform to generate HTML code.

Right now the program merely declares the arithmetic relationship of the vetted n to base r and its subdivision. For semicoprimes, it suggests using "silo" factors.

Examples: base 15:
CODE

2 Coprime: Evenness test in odd base.
3 Regular: Divisor.
4 Coprime: Alpha Factor.
5 Regular: Divisor.
6 Semicoprime: Use 2 3.
7 Coprime: Omega Factor.
8 Coprime: Alpha Factor.
9 Regular: Richness 2.
10 Semicoprime: Use 2 5.
12 Semicoprime: Use 3 4.
14 Coprime: Omega Factor.
15 Regular: Base.
16 Coprime: Alpha Factor.
18 Semicoprime: Use 2 9.
20 Semicoprime: Use 4 5.
21 Semicoprime: Use 3 7.
24 Semicoprime: Use 3 8.
25 Regular: Richness 2.
27 Regular: Richness 3.
28 Coprime: Alpha-Omega Factor.
30 Semicoprime: Use 2 3 5.


Dozenal:
CODE

2 Regular: Divisor.
3 Regular: Divisor.
4 Regular: Divisor.
5 Coprime: Alpha-2 Factor
6 Regular: Divisor.
8 Regular: Richness 2.
9 Regular: Richness 2.
10 Semicoprime: Use 2 5.
11 Coprime: Omega Factor.
12 Regular: Base.
13 Coprime: Alpha Factor.
15 Semicoprime: Use 3 5.
16 Regular: Richness 2.
18 Regular: Richness 2.
20 Semicoprime: Use 4 5.
22 Semicoprime: Use 2 11.
24 Regular: Richness 2.
26 Semicoprime: Use 2 13.
27 Regular: Richness 3.
30 Semicoprime: Use 2 3 5.


Things to do are to add the combinations and number of combinations for the regulars. If the number of combinations exceeds 12, I will abbreviate the list to only show the first 3 and the last one. Then it will have to handle range-folding for regulars with richness 2 and 3. I've entered all the language components "If an arbitrary number ...", " if the least significant ", " place values are one of ", etc. so all the program will do is catenate the appropriate components. The omega testable numbers are easy: " if the digital root of x is divisible by ". The inheritors are easy and will be converted to say " if the number x is divisible by " and list the prime-divisor-powers of x. Then I'll have the algorithm add the <ul>, <li> tags, catenate the language, etc. and the component will be complete.

This segment will eliminate all the drudgery of writing that language by hand, prone to missing a relationship or misstating the rule. These may be color-coded with a square character in the color canon representation of their regular and coprime factors.

Then we will move on to segment A, the first part of the boilerplate and work down.

I do agree with you Double Sharp that the entries can't be fully auto-generated. The auto-generation applies to the parts outside of the travelogue. The segment that describes auxiliaries will not be as prosaic and will merely show possibilities and common fractions (the natural ones, one fifth, one sixth, one eighth, etc.) in the system. The prosaic narrative can be incorporated in the travelogue.

I need to add grid labeling to the flexCell routine. This would require a way to recognize labeling and probably a flag. I will hold on this for a little while as I try to establish the other parts of the project.

The project could be suddenly interrupted by "real work", and I have to update my website with new project examples (i.e., "real work") but am focused on this project otherwise.

Looking forward to see how this works out - it looks really good even now!

Posted by: icarus Oct 31 2015, 02:08 PM
Indeed, there are some kinks in the output that have to be sussed out. Before I go too far with the divisibility test algorithm I need to look at Treisaran's thread, some resources to see if I am not forgetting something.

Test of divisibility rule script on base 17. (I don't have all the regular tests written). Looks pretty good. Might change how some things are written (m-dashes, etc.) (Updated 20151104)

[doHTML]

It's been a tough slog but I have extended the code to generate regular rules. This segment is complicated because we have to generate a range. If that range is too long (and I used 18 terms as the maximum) it abbreviates it with ellipses. If the number x involves a power of 2 or 3 it could take advantage of range folding (e.g., decimal 4, 8; dozenal 8, 9). That was a tricky thing to get through and I almost quit. The program now handles all bases up to 36. I will extend it to any base as soon as I fix the digit converter.

[doHTML]
I am still looking for glitches...this code took much longer to write than I ever thought and is more complicated than I considered.

Posted by: Double sharp Nov 4 2015, 01:00 PM
QUOTE (icarus @ Oct 31 2015, 02:08 PM)
[doHTML]

This was meant to be 2 and d, right? Earlier, your script writes "d if the tetradecimal digital root of x is divisible by d", so I'm assuming that all these numbers are supposed to be expressed in whatever base is being examined at the moment, not decimal.

P.S. {930} looks gorgeous, thanks to the neighbouring divisors 30 and 31 creating a beautiful orange diagonal in the digit map.

Posted by: icarus Nov 4 2015, 11:02 PM
Double Sharp,

Yes! There are some validation items that need to happen. I do need to ensure that any figure in the prose is stated in base b EXCEPT parenthetical ones, which are decimal. (There will be a note to this effect).

I am holding on fixing the script to represent large bases (here meaning bases greater than 36, for no other reason than I have to append the next sequence of transdecimals beyond lowercase letters). Do I want to *still* be putting out these sorts of verbal descriptions, or just rely on the digit map? I lean toward YES. If that's so, then do we continue the base-b representation or cut it off? This effects range-folding and the ranges stated for regulars. At some point we run out of transdecimals. I think at some point I don't give ranges / range-folding but merely state that there are so many combinations. For bases greater than 60 divisor tests become cumbersome; stating ranges is going to suck up a lot of real estate. Going to need to ponder it, what are you's all's thoughts?

Today I worked on the "segment A" again. Pretty satisfied with it so far.
Segment A includes the names, prime decomposition, prime signatures, classes in which base b resides. I think it's nailed. The LaMadrid and SDN names are given, then the prime decomposition and prime signature. The script produces a brief range of numbers with similar prime signature and declares which OEIS number and if available, classes such as "sphenic numbers", "squarefree semiprimes", etc. I have yet to add "primorials" and other types of number independent of prime signature. Want to add primorials, HCN, SHCN, highly regular number, pronic number, etc. and will do that. Here are samples:

[doHTML]

The prime cases should perhaps more simply read "p is prime, its prime signature is "1". The number p is term _primePi(p)_ in the sequence of primes is {2, 3, 5, ..., p, ...} (OEIS A000040)." This can be handled by an If statement that caters to primes. I think anything else can be treated in a more or less uniform way. [DONE 201511041718]

Also, hyperlinks to definitions need to be supplied as are in the tour. There are two separate references, one here and one at the home to-be. This will be added later. I think the hyperlinks are crucial so won't leave them out.

The OEIS hyperlinks can easily be made clickable because the site is so modular. (In fact I will do that now). [DONE 201511041718]

Next week I could lose focus due to business (At this point I would welcome that) but will resume when free time opens up again (feast or famine self employed).

I might tackle the generation of auxiliary bases if that is even possible. Will have to define criteria. Resolution of missing or ensuing primes is easy; what to do for bases that don't "need" it? This will favor resolution of the first three primes {2, 3, 5}, with preferred multiplicities {3, 1, 1} but this might require much thought. Again, what are your thoughts?

Posted by: icarus Nov 4 2015, 11:30 PM
The next segment (cool.gif describes the type of numerals (digits) 0 <= m <= n (with 0 standing for 0 (mod cool.gif rather than actual zero, and "10" not used). The kind and quantity of each numeral type, sets, idiosyncrasies (number of "practical" and "impractical", "alpha" or "omega" or "alpha-omega" inheritors, etc.) are described. Primes {p | b and q coprime to b} <= b + 1 are described. There are pictorials that can be automatically generated thanks to flexCell. I'll work this out at a meeting (heh) and then maybe also gain ground on this side of the task.

Posted by: Double sharp Nov 5 2015, 03:42 AM
QUOTE (icarus @ Nov 4 2015, 11:02 PM)
Double Sharp,

Yes! There are some validation items that need to happen. I do need to ensure that any figure in the prose is stated in base b EXCEPT parenthetical ones, which are decimal. (There will be a note to this effect).

I am holding on fixing the script to represent large bases (here meaning bases greater than 36, for no other reason than I have to append the next sequence of transdecimals beyond lowercase letters). Do I want to *still* be putting out these sorts of verbal descriptions, or just rely on the digit map? I lean toward YES. If that's so, then do we continue the base-b representation or cut it off? This effects range-folding and the ranges stated for regulars. At some point we run out of transdecimals. I think at some point I don't give ranges / range-folding but merely state that there are so many combinations. For bases greater than 60 divisor tests become cumbersome; stating ranges is going to suck up a lot of real estate. Going to need to ponder it, what are you's all's thoughts?

I think it would be mighty interesting to see lists of sexagesimal and centovigesimal divisibility tests. However, you raise a good point about stating ranges. Maybe at some point you'd shift to simply giving the rule without stating what digits are involved? For example, the rule for 2 in pure sexagesimal is that a number is even if it ends in one of {0, 2, 4, 6, 8, a, c, e, g, i, k, m, o, q, s, u, w, y, A, C, E, G, I, K, M, O, Q, S, U, W}. Hmm, quite a mouthful. But what if we just said "if the least significant place value of x is divisible by 2"? That would get the point of the test across, without drowning the reader in so many even digits. (Although maybe you do want to illustrate that point where even the divisor tests can reach exhaustion!)

I think we can safely use a range up to 62 with 0-9 a-z A-Z, making pure sexagesimal available. My kana suggestion for bases up to 160 alas doesn't work quite as well as they are not contiguous in Unicode, so maybe we really have to avoid stating ranges for bases like centovigesimal, let alone trecentosexagesimal.

QUOTE (icarus @ Nov 4 2015, 11:02 PM)
Today I worked on the "segment A" again. Pretty satisfied with it so far.
Segment A includes the names, prime decomposition, prime signatures, classes in which base b resides. I think it's nailed. The LaMadrid and SDN names are given, then the prime decomposition and prime signature. The script produces a brief range of numbers with similar prime signature and declares which OEIS number and if available, classes such as "sphenic numbers", "squarefree semiprimes", etc. I have yet to add "primorials" and other types of number independent of prime signature. Want to add primorials, HCN, SHCN, highly regular number, pronic number, etc. and will do that. Here are samples:

[doHTML]

The prime cases should perhaps more simply read "p is prime, its prime signature is "1". The number p is term _primePi(p)_ in the sequence of primes is {2, 3, 5, ..., p, ...} (OEIS A000040)." This can be handled by an If statement that caters to primes. I think anything else can be treated in a more or less uniform way. [DONE 201511041718]

Also, hyperlinks to definitions need to be supplied as are in the tour. There are two separate references, one here and one at the home to-be. This will be added later. I think the hyperlinks are crucial so won't leave them out.

The OEIS hyperlinks can easily be made clickable because the site is so modular. (In fact I will do that now). [DONE 201511041718]

Next week I could lose focus due to business (At this point I would welcome that) but will resume when free time opens up again (feast or famine self employed).

I might tackle the generation of auxiliary bases if that is even possible. Will have to define criteria. Resolution of missing or ensuing primes is easy; what to do for bases that don't "need" it? This will favor resolution of the first three primes {2, 3, 5}, with preferred multiplicities {3, 1, 1} but this might require much thought. Again, what are your thoughts?


I think any base with a gapless prime factorisation like {2, 3} has a real problem with auxiliary bases. To get the factor 5, it goes into the vicious cycle I've mentioned several times already:

[z]
10 doesn't have 5. Multiply by 5!
50 blunts halves. Multiply by 2!
a0 blunts thirds. Multiply by 3!
260 blunts quarters. Multiply by 2!
500 blunts halves. Multiply by 2!
[/z]

And we're back in the same loop, an order of magnitude up. Whereas in decimal, this would resolve gracefully:

[d]
10 doesn't have 3. Multiply by 3!
30 blunts halves. Multiply by 2!
60 keeps the decimal factor {2} clean (we're torpedoing the not-so-important {5}). First workable decimal auxiliary base: sixty.

In fact, this seems like a reasonable algorithm for auxiliary base generation. Take the first prime factor you don't have in your base, and multiply your base by it: this factor will gain prominence. (In decimal's case, 3.) Then reinforce the more important prime factors of the base. (In decimal's case, 2.) Now you will have the most important fractions dealt with cleanly. If you ever get stuck in a loop like for dozenal (or senary), there isn't a good auxiliary base available. But there are so many factors at play that it might not work 100% accurately. For example, users of a prime-power base like octal or hexadecimal may be quite willing to torpedo high prime powers that are already factors of the base, as for example {3, 5} are more important than {8}.

Posted by: icarus Nov 5 2015, 09:22 PM
I have been interrupted a bit today.

At yesterday's meeting, I worked out some thoughts about auxiliaries.

Generally, and auxiliary base is simply a radix used as an aid to some application within the context of the "civilizational base" or the "base in play". This could really be any number. We use base 7 for weeks merely because there are seven heavenly wandering lights. Divisibility apparently didn't come into play. Wendy uses many of her bases as auxiliaries perhaps, maybe in the context of her use of 120. We use a mixed radix to represent years-months-days, etc. (but it is pretty shabby).

What we are really considering is a "divisional" (akin to "multiplicative") or "flexible" auxiliary base. (There must be a better word...)

We want to be able to divide a cyclical unit by a highly factorable base in order to avoid fractions.

In base 10 we have the flex aux bases {12, 60, 360} (among others, but these are predominant). These cover different ranges and "sacrifice" more of the decimal-native "flexibility" to take advantage of the aux base's.

In the case of 12 we completely abandon 5 and replace it with 6. Thus the natural fractions are neatly resolved {3, 4, 6, 8, 9} and we can tell time from across a room or on our wrists as we assault a beach to stop the moves of a despot. It's a rugged and coarse auxiliary base.

When we want more resolution we use decimal coded sexagesimal. Here we retain 5 and add the primes {2, 3} to get the following:

Retain the half (30) and pick up clean thirds (20, 40) and sixths (10, 50).
Retain quarters as blunt as decimal-native 2nd rank quarters (15, 45) vs. (25, 75).
Sacrifice the fifths (12, 24, 36, 48) and tenths (6, 18, 42, 54).

Apparently this works because we native decimalists aren't really using the larger prime 5 intrinsically, per se, but as a surrogate for the negative powers of 2. So we sacrifice 5 to pick up thirds and sixths and maintain halves and quarters. All in all, we really haven't lost anything, just muddied up the clearer fifths and tenths we would have. These fractions remain integers under base 60. Sevenths are completely unsupported.

We use 360 for even more resolution by adding {2^2, 3^2}. This broadens the clean fractions to include quarters and ninths, fifths and tenths. 90 is seen as "round" under 360 probably by dint of using it as a measure of a circle so often; it is the merger between circles and orthogonality.

In base 14 nothing argues against making the first deal. The dozen could be used just as we would in base 10. We might not use 60. The unit fractions of {2, 3, 4, 5, 6, a, c} end up being represented as {22, 16, 11, c, a, 6, 5} and that's unacceptably muddy. If we don't mind leaving out 5 and just garnering 3 without completely abandoning 7, maybe we'd use decimal 84 = "60" (heh). Then we'd show {2, 3, 4, 6, 7, a, c} as {30, 20, 17, a, 7, 6} rather analogous to decimal coded sexagesimal. If we want {3, 5} and plan to maintain 7 we need decimal 210 at minimum (poor because of poor quarters) but rather decimal 420, which is on par scale-wise with decimal 360. Then {2, 3, 4, 5, 6, 7, a, c, 10} as {110, a0, 77, 60, 50, 44, 30, 27, 22}

Yes, generally we are filling in to get factorization something like Prepend[Union[{2, 3, 5, p}], 2], with p being any prime divisor of b, but it depends on whether we want to completely abandon p > 5, if we want to accept the fact that there is no 5, etc.

[doHTML]
The above figure is the output of a diagram that illustrates the prime-sieving properties of a base's totatives. (This is decimal).

Posted by: Piotr Dec 5 2015, 03:07 PM
QUOTE (Double sharp @ Oct 17 2015, 11:52 AM)
My intent would be to cover {40, 54, 56} if nothing else. Following that, I'd go to {44, 45, 50, 52}, and then the binary powers {32, 64}.

Remember to post base 54 in "Senary and {2, 3} bases" as 54 is 2 3³.

Posted by: Double sharp Dec 8 2015, 05:55 PM
QUOTE (icarus @ May 1 2012, 03:04 PM)
[doHTML]

Huh. So I see in the hidden comments to this thread the following planned tours: {2, 3, 4, 22, 26, 27, 32, 35, 45, 54, 420, 840, 1000, 1260, 1680, 1728, 2310, 2520, 5040}.

Here are my overambitious considered additions: {50} as a larger version of 18, {64} to extend the binary powers, {71} as queen of the leeches, {105} as an odd sphenic number, and {168, 180, 192, 216, 252, 300, 336} to lead to the desolate landscape at 360! I'd also include {160}, another merge of decimal and hexadecimal, and {480, 960} as covered in one of Treisaran's threads (useful as auxiliaries to {8, 16}). I'd love finally also {945} as odd and abundant.

The coverage that would result: {2-22, 24-28, 30, 32, 34-36, 40, 42, 45, 48, 50, 54-56, 60, 64, 70-72, 80, 84, 90, 96, 99, 100, 105, 108, 109, 112, 120, 144, 160, 168, 173, 180, 192, 210, 216, 240, 252, 300, 336, 360, 420, 480, 720, 840, 945, 960, 1000, 1260, 1680, 1728, 2310, 2520, 5040}.

The ones remaining to be written:
{2-4, 22, 26, 27, 32, 35, 45, 54, 64, 71, 105, 160, 168, 180, 192, 216, 252, 300, 336, 420, 840, 945, 960, 1000, 1260, 1680, 1728, 2310, 2520, 5040}. Of these, I think many of the large ones have to be automated, so I'll concentrate on the lower range.

Duly noted, Piotr!

Posted by: icarus Jan 18 2016, 11:09 PM
[doHTML]

Posted by: icarus Jan 18 2016, 11:10 PM
[doHTML]

Posted by: icarus Jan 18 2016, 11:11 PM
[doHTML]

Posted by: icarus Jan 18 2016, 11:12 PM
[doHTML]

Posted by: icarus Jan 18 2016, 11:35 PM
When the numberbases site begins, I will likely start with "human scale" bases and flesh out the site from there. I'd started long ago on a glossary and will revisit it but won't let that undertaking sap the effort. There is a makeshift glossary that I will expand from. The first part of development will be a couple dozen base pages in the format: numberbases.com/tour/base12.html.

If you have early suggestions I'd appreciate them.

The first bases will be: {6, 8, 10, 12, 14, 16}, {20, 24, 30, 36, 60, 120}, {210, 2310}, {5, 7, 11}, {21, 34, 55, 56, 64, 76, 99}.

Most of them will just be charts at first.

Posted by: Oschkar Jan 19 2016, 01:19 AM
QUOTE (icarus @ Jan 18 2016, 11:35 PM)
If you have early suggestions I'd appreciate them.

The first bases will be: {6, 8, 10, 12, 14, 16}, {20, 24, 30, 36, 60, 120}, {210, 2310}, {5, 7, 11}, {21, 34, 55, 56, 64, 76, 99}.

I'm going to suggest 42 and 84 together with the initial mid-scale and 9 and 15 as the human-scale composite odd bases.

I guess the next stage could be the small bases {2, 3, 4}, the superhuman scale {13, 18, 22, 28}, the remaining mid-scale 3-smooth {48, 72, 96, 108}, the two-dimensional {40, 56, 80, 112}, and the three-dimensional {70, 90, 126, 168, 180}.

126 sounds a lot like a mirror-universe version of 80, being a small-smooth number right next to a power of the prime it's missing. The problem is that 126 has only a single binary power, so testing for 4 is awful...

By the way, it's Lamadrid, without the CamelCase.

Also, I love the new alpha2/omega2 colours, they make the divisibility maps that much more varied. (80 and 85 in base 55 are beautiful...)

Posted by: Double sharp Jan 19 2016, 08:13 AM
Please don't forget {240, 360} and the huge {2520, 5040}! I also think 54 deserves a place in there.

Posted by: Oschkar Jan 19 2016, 06:58 PM
QUOTE (Double sharp @ Jan 19 2016, 08:13 AM)
Please don't forget {240, 360} and the huge {2520, 5040}! I also think 54 deserves a place in there.

Going to add {1680} to the huge bases. I'm fairly sure that I can work in 12:10:14 a bit more easily than in 12:15:14, with all three subbases being even, but we lose the nice omega relationship with 11, which then becomes a maximal prime.

The four-place ninths (0.134'8) don't bother me, really, but the seven-place 27ths (0.046'269'4) do a little, and the only way to resolve it is through base 5040, whose 18:20:14 encoding seems like overkill even for tristaff bases, and whose best 4-staff encoding is probably the relatively unbalanced 12:10:7:6.

However, I’m reasonably sure that if people were to actually use 12:10:14 as a finer replacement for percentages or something, rounding to three places would be enough to distinguish all relatively common fractions.

Posted by: icarus Jan 19 2016, 10:46 PM
I've got http://numberbases.com/base/55.html and http://numberbases.com/base/60.html up as tests (mainly testing the CSS).

Posted by: Oschkar Jan 19 2016, 11:19 PM
QUOTE (icarus @ Jan 19 2016, 10:46 PM)
I've got http://numberbases.com/base/55.html and http://numberbases.com/base/60.html up as tests (mainly testing the CSS).

In the full map, we also need colours for compound square-alpha tests, like pentaquinquagesimal 51 (α²×ω), 68 (α²×α) and 272 (α²×ω²). I'm going to suggest for these a medium blue-violet, about #865edb, and for things like pentaquinquagesimal 255 and 340 where they combine with the divisors a lavender like #da89fa for richness 1 and #e4a7fc for higher richness.

Posted by: icarus Jan 20 2016, 12:08 AM
Oschkar,

I'll look at that. I am running up against a browser sort of limit in terms of the number of colors we can display in tables in web pages. Of course, in Mathematica we can have any number of colors. So long as there is a mathematical manner of defining the category, I can show it.

One of the problems we might run into is, where do we draw the line in saying a test is "intuitive" or not? Now I think I have the ability to "shut off" items that are more obscure using bits. I would enable such tests using the fifth bit. If I "run out of bits" I can "borrow" the seventh (that which enables the regular figure categorization) since it nullifies the effect of most of the other bits. I could use a Boolean method to enable specialty tests to show.

Another problem is the human-eye ability to distinguish color. The colors you've chosen happen to be in a space we haven't made much use of yet.

On another note I just discovered a pre-categorizing method in which I can use MemberQ rather than factoring each number - I only have to factor once per base (!) (so far, not totally fleshed out) and can derive all the flavors of the chart. This will reduce the generation time enormously (currently it puts out base 2520 in about a half second). It will also simplify the code. I am surprised and embarrassed that I hadn't done this sort of step sooner.

Posted by: Oschkar Jan 20 2016, 12:30 AM
QUOTE (icarus @ Jan 20 2016, 12:08 AM)
One of the problems we might run into is, where do we draw the line in saying a test is "intuitive" or not? Now I think I have the ability to "shut off" items that are more obscure using bits. I would enable such tests using the fifth bit. If I "run out of bits" I can "borrow" the seventh (that which enables the regular figure categorization) since it nullifies the effect of most of the other bits. I could use a Boolean method to enable specialty tests to show.

You’re probably right that compound square-alpha tests are probably not something that could be reasonably applied in most bases, especially ones like 55, but they might turn out to be intuitive in some small bases, say, testing for 15 in octal, where 5 comes from the square-alpha and 3 from the alpha itself. I don’t think that the three types of compound square-alpha tests need to be distinguished in the charts, though.

I’m not sure if you want to reserve the purple range for things like 1 and 2 only, or if other relationships can fit in there somehow, but if they must be in a range other than purple, we can put them in the browns, distinguished from the regular figures by their saturation.

Posted by: icarus Jan 20 2016, 02:55 AM
Now I am not sure we'll get better performance. There isn't much factoring and maybe looking up values in tables of hundreds or thousands of values is less efficient. Many of the tests are GCD. But will test it out. The code is over 100; lines in wolfram. There are dual routines for HTML and wolfram and maybe it might be combinable into a single routine with conversion to the other.

Posted by: wendy.krieger Jan 20 2016, 10:47 AM
Omega2 (which is i suppose, checking for the likes of 49 in base 120), is not really that useful, because it supposes that you have to divide through by alpha and then apply the same test again, eg

2.54 => 56, 2.54 divide by 7 gives 42.

But it gets a little strained when one deals with very large numbers.

Note, eg that Alpha2 and Omega2 don't include the powers included in the Alpha and Omega, so in base 50, the test for 49 is the same as 7, is simply add the places.

It must be kept in mind, that while 11 divides 120's Alpha, that there is a test at digit level for 11 ( +--+) over the staff-pairs, eg 4.48 +--+ = 0+8, - 4+4. It's kind of like an alpha in decimal and an omega in dozenal.

Generally, Omega tests are very useful for parallel calculation checks, and where omega has divisors, or is small enough to deal directly, then this can be blazingly fast. (I often do mod-7 checks on twelfty-calculations).

For general primes, one can make use of numbers adjacent to multiples of the base, so for 13 and 37 together, note 4.01 is 13*37. When one does a cast-out division, one does not have to recall the full carry, eg

9.85.10.16 9.85 - 8.02 gives 1.83,10 - 1.80,50 guves 3.10 - 50 = 2.80. Then 2.80.16 less 2.80.80 gives 16-80 = -64, and this is the common remainder 13 and 73,

65-64 = 1, modulo 13, and 74-64 gives 10 modulo 37.

The larger richness (or ripple) regulars present a problem too. One notes that the success or failure depends on the co-divisors of the relevant primes. For example, 120 = 8*15, and one can treat the last two places of twelfty as a pair of base-15 digits, eg 10.16 = 10.2 (b15, divide 16 by 8), and 10-2 is a multiple of 8, thus this number is a multiple of 64.



Posted by: icarus Jan 20 2016, 12:47 PM
Indeed omega-2 is not very useful but was a by-product of panning for semicoprimes (products of a regular g and coprime t) that have a coprime part t that is a factor of (b^4 - 1). Now that I might pre-sort the numbers n in the range under study (often that of b itself) the need to handle omega-2 is gone. I could color omega 2 "hh" or "opaque semicoprime". This would free up a "slot" in HTML.

I am going to rebuild the function with pre-sorting in Associations and MemberQ and generating Wolfram only, mapping an HTML encode function across the InputForm of the Wolfram output to get HTML. The latter should prove to be a mass ReplaceAll routine for the most part. The function will be association rather than list based.

I have a way around the browser CSS ceiling.

Q: in an expanded panning for arithmetic relationships, which should we include? Should I retain omega-2 and add alpha2^2-omega etc. as Oschkar suggests?

Now we recognize richness levels in the sixth bit. I didn't program "practicality" because it is more complicated than richness. But I have a good guideline. Using the 25 present in the range folded regular test for decimal 8, I look for the closest number regular g to b near 30. If a number, even a divisor, has more than g values in the table, it is impractical. If we can range fold to get the value at or below, then it is semipractical. This renders the evenness test impractical in bases greater than 60, unless it is perceived as 6-on-10. The complexity of practicality is the reason why I just us d the guidelines.

The richness guidelines are as follows:
Richness 0 — the unit, 1 in any base, as it is the empty product and is a coprime divisor. Purple.
Richness 1 — divisors, red.
Richness 2 — nondivisor regular with fractions terminating in 2 digits, div tests with 2 digits, orange.
Richness 3 — nondivisor regular with fractions terminating in 3 digits, div tests with 3 digits, peach.
Richness > 3 — light peach.

The threshold for semicoprimes is richness=2 for their regular part.

The settings could be changed dynamically in the new function.

First I need to test efficiency.

Posted by: Oschkar Jan 21 2016, 07:33 AM
QUOTE (icarus @ Jan 20 2016, 12:47 PM)
Indeed omega-2 is not very useful but was a by-product of panning for semicoprimes (products of a regular g and coprime t) that have a coprime part t that is a factor of (b^4 - 1). Now that I might pre-sort the numbers n in the range under study (often that of b itself) the need to handle omega-2 is gone. I could color omega 2 "hh" or "opaque semicoprime". This would free up a "slot" in HTML.

{a}

However, omega-2 is functionally identical to alpha-omega composites in even bases, and adds just one more binary power in odd bases. I’m sure that we will still need a colour to represent alpha-omega composites, which wouldn’t really free up a slot anyway, because things like 21 in octal and 15 in undecimal still need to be represented somehow, and omega-2 is practically the same test.

Alpha-2, on the other hand, is a totally new test that is only practical for a few bases, probably {7, 8, 12, 13, 17, 18} to test for 5, {5, 8, 18, 21} to test for 13, and {13, 21, 30} to test for 17, assuming a very generous memory limit of 60 instead of your 30, since, because the alpha-2 test isn’t at all obvious, I assume that, except for users of bases {7, 8, 12, 13} testing for 5, they will be closer to the field of advanced mnemonists and mental calculators.

---------------------------------------------------------------------------

I have some thoughts on range folding, somewhat in response to Wendy’s comment about testing for 64 in base 120. Icarus, if this is too off topic, can you split the following over to another thread?

I use this decimal test for 16 frequently: A number is divisible by 16 if the sum of the hundreds places and a quarter of the units places is divisible by 4.
a*100 + b = a*4 + b (mod 16)
Since b will be a multiple of 4, we can divide everything by 4, to get a + b/4 (mod 4).
16777216: 72 + 16/4 = 72 + 4 = 76, which is divisible by 4

My test for 32 is something like: A number is divisible by 32 if the sum of the hundreds places and a quarter of the units places, plus 4 if the myriads digit is odd is divisible by 8. I don't really use it, though; I usually just halve the number and then test for 16.
a*10000 + b*100 + c = a*16 + b*4 + c (mod 32)
We divide everything by 4 again, to get a*4 + b + c/4 (mod 8)
a*4 (mod 8) will be 0 if a is even, and 4 if a is odd.
16777216: 72 + 16/4 + 4 = 72 + 4 + 4 = 80, which is divisible by 8

This test doesn’t extend easily to 64, though:
a*10000 + b*100 + c = a*16 + b*36 + c (mod 64)
Dividing by 4, we get a*4 + b*9 + c/4 (mod 16)
I could try out something like "4 times the myriads twistaff, plus 9 times the hundreds twistaff, plus a quarter of the units places", but that seems more complicated than what even I can bear, and I actually use the cube-neighbour tests for decimal 7, 13 and 27... I'll stick with halving twice and then testing for 16.

{6}

Let me see how senary might handle large binary powers. In senary, you can actually memorise all 43 three-digit multiples of 12, so we might range-fold on 12 instead of 4. The problem is that 1000 isn't within 12 steps to a multiple of a large power of 2.

Testing for 24 is simple enough, just the standard range-fold test for one more binary power.

The test for 52 is similar to the decimal test for 24, but subtractive instead of additive:
a*1000 + b = a*-12 + b (mod 52)
Dividing by 12, we get -a + b/12 (mod 4)
A number is divisible by 52 if the difference between an eighth of its last three digits and the two preceding digits is divisible by 4.

The test for 144 (d|64) is weird, because the residues run out just like in decimal, but it might just be workable, because the residue of the "thousands" is 3, almost trivial to multiply by in senary.
a*100000 + b*1000 + c = a*52 + b*40 + c (mod 144)
Dividing by 12, we get a*4 + b*3 * c (mod 12)
a*4 (mod 12) is 0 if a is even and 4 if a is odd.
A number is divisible by 144 if the sum of an eighth of its last three digits and three times the two preceding digits, plus 4 if the sixth-to-last digit is odd, is divisible by 12.

{a}

It is true, however, that 120 offers a very good range of 7 binary powers, 2 ternary powers (maybe 3, if the hundreds residue of either 4 or -5 doesn’t turn out to be that bad) and 3 quinary powers.

Posted by: icarus Jan 21 2016, 12:11 PM
(Oschkar, will split when back in office rather than on iPhone)

I think I can get around the limit to some extent, and either way,the limit doesn't apply to Mathematica output. I can process the Mathematica using rules to rewrite it as HTML. We just can't display all colors at once in HTML.

The range folding technique, essentially going negative (permitting a negative power of the common prime divisor) seems valid. Division by two or three is accessible but indeed at some point it's not. Range folding is seen as "quasi intuitive" and I think shunting negative rules to some less "intuitive" category isn't that meaningful, so will accommodate it.

You, Wendy, and many here are fiercely intelligent folks. The problem with us bright people is that we forget how rare people with our faculties really are. We project that average people will be keen to use rules we would see plainly as simple.

This said, there isn't a reason why the sieve can't handle rules we would see as beneficial. I'll just make a bit setting to represent these as an option.

Posted by: wendy.krieger Jan 21 2016, 12:48 PM
I misread omega2 as omega^2, ie 81, rather than two places 99. I see now. It is the sort of thing one would handle 77 with in base 120.

The test for large powers of 3 in twelfty is fast-remainder by 203. Here you can discard the dividend, and because fast-remainder does not actually need to evaluate it, it is a simple matter of subtracting multiples of the divisor. It is good mentally.

So you pretty much get 2^8 3^5 5^3, from range folding and from fast division by 203.

It's rather like the omega and alpha tests, which are 1,-1 and 1,1 respectively, but you do multiples, like 2,3 at a time. You decide the multiple by looking at the hundreds for pairs, eg 1.44.03 // 2.03 1.44 = 80*2 gives 1.44 - 1.40 = 4. You carry the 80 to the unit and multiply by three, noting that the quotient is 4.03, gives 80*3 = 200 gives a remainder of 2.03

If you pair up primes, you can test for pairs of primes at once. For example, 9.01 = 23 * 47, and doz EEE8 (ie 1,-4) is 71*73*4. I keep 'handy multiples of primes' around for this end. Prime powers are also doable: 1.00.06 is 7^4 * 6, and in base 18, 111 is 7^3, are also worth the note.

But icarus has a point about the tables. It is his baby, so to speak.

Posted by: wendy.krieger Jan 21 2016, 01:12 PM
Senery test for binary powers is better done over a protobase of 36.

In essence, you take aa.bb.cc to get A.B.C

If we construct the number as base nine fours, we can eliminate much of the hassle by fitting it as 9 4. 9 4. 9 4. The first 9 and the last 4 is dicardable (the 4 tells us it's a multiple of 4, is essential.

So eg 4 53 44 gives 1.08.17.0 A second peak gives 1.2.04.00

We see that this ends in a multiple of 4, and a further 16, so it's a multiple of 64.

We can discard everything mod 4 from the top, and turn the bottom to nineths, getting

0 53 7/9.

Since 2 -2/9 represents a multiple of 64 (ie it is 16/9 * 36), we can add or subtract an even number of nineths to make it hole, and then get a single place, for which we can test for sixteens (which become sixtyfours)

53 7/9 - 1 7/9 (note 1+7=8) gives 52.

So what power of 2 goes to 52, (ie here as far as dec 16), gives 64.

As it should: it is 80 squared.

4 53 43 is good to check the rule for dividing by powers of nine.

Posted by: Oschkar Jan 21 2016, 04:57 PM
QUOTE (wendy.krieger @ Jan 21 2016, 12:48 PM)
The test for large powers of 3 in twelfty is fast-remainder by 203. Here you can discard the dividend, and because fast-remainder does not actually need to evaluate it, it is a simple matter of subtracting multiples of the divisor. It is good mentally.

So you pretty much get 2^8 3^5 5^3, from range folding and from fast division by 203.

Nice. Going to start using it (well, 403; I'm a sexagesimalist).

As long as we are trying to evaluate "intuitive" tests, I showed the SPD procedure of casting out 1001's to test for 7 and 13 in decimal to a few people at my school a few months ago, and a little more than half of them seemed to understand it well enough after a few examples. It's probably not "intuitive" if it has to be thought of as an algorithm involving that many steps, but might turn out to be manageable.

"If you add a multiple of 7 to a multiple of 7, the result will always be a multiple of 7, so to test if a number is divisible by 7 or 13, you can just add or subtract 1001 (which is a multiple of both) as many times from it as you want to. The best way to do this is by snapping the last 2 digits to the closest multiple of 7 or 13, and then adding or subtracting the same amount from the thousands. Then you can just forget the last two digits, since they're already a multiple."

Testing for 7:
68 574 961: 61 snaps to 63 by adding 2, so add 2000 more: 68 576 963
685 769: 69 snaps to 70 by adding 1, so add 1000 more: 686 770
6867: 67 snaps to 70 by adding 3, add 3000 more: 9870
98 = 7 * 14

Testing for 13:
68 574 961: 61 snaps to 65 by adding 4, add 4000 more: 68 578 965
685 789: 89 snaps to 91 by adding 2, add 2000 more: 687 791
6877: 77 snaps to 78 by adding 1, add 1000 more: 7877
78 = 13 * 6

And anyway, I think that 13 is by far the largest prime that needs a divisibility test for anything other than primality testing, and it doesn't have to be simple, especially since it's such a rare occurrence. I'll still stand by my assessment that {2, 3, 4} are crucial, {8} almost so, {5, 7, 9, 16, 2^n} are nice to have, but not necessary, and {11, 13, 25, 27} come up very rarely, but they do exist. Any higher powers of {3, 5, 7} and primes from 17 onward are essentially useless.

Posted by: icarus Jan 21 2016, 07:59 PM
I appreciate all feedback - this way the algorithm performs what people want to see.

IDTs (as "classically defined") can be toggled by one bit setting, and expanded content with another. I will attempt to accommodate what Oschkar suggests because it's interesting. How it gets accommodated is merely a programming technique.

Still experimenting with pre-validation. The effort isn't wasted because it's necessary to produce the textual description of the arithmetic entities (numbers and identification of divisors, totatives, alpha-semitotatives of richness 2, etc.) that is basically the first segment of the page. Also will attempt to have this written in Mathematica output and then convert it to HTML vs. the fork-style approach (wasteful) that I had continued developing from the fall.

Posted by: icarus Jan 22 2016, 02:58 PM
Here are results of pre-validation.

The pre-validation routine excels in sorting out all the various arithmetic entities of base b. It produces a database of all entities, including the ones Oschkar mentions and can even get a finer-grain sorting if desired. With the database I can list and enumerate many arithmetic classes of n in base b at least textually, but the goal was the routine might have made generating a digit map more efficient.

It is NOT more efficient for large bases than the current algorithm. Looking up the semitotatives of b = 5040 (there are 3623 of them) takes 0.468 s vs. using the test And(gcd(n, b )>1, gcd(n, b )<n, coprimePart(n, b )>1), which involves factoring all the n, takes 0.0624 s. Now producing the current flexCell digit map with everything on for b = 5040 takes 0.655 s. (the filtering in the flexCell is more efficient, looking for And(gcd(n, b )>1, gcd(n, b )<n) first in a Which statement, then proceeding once validated to coprimePart(n, b )>1 to find semitotatives). This implies that the code will require 8x seconds to generate the maps. I looked at semitotatives because for large composite b or for large ranges for many composite b, these are of the predominant arithmetic entity type; if b > 12^3, then we'll have thousands of semitotatives and the lookup for each requires more time than the validation that incorporates factorization for each candidate.

The prevalidation routine is still useful because it will be the engine I will use to enumerate and list arithmetic entities in the prose. I will not alter the Which-based validation routine in flexCell, but I may tap the prevalidation to look for certain rare arithmetic types (the ones Oschkar noted and perhaps others that merely produce handsful of n vs. thousands). I would merely continue to color "hh" (opaque semitotatives) but then recolor them with the rare types, which is the easiest thing to do.

There are benefits of the prevalidation routine over the validation used in flexCell. The former produces a database of each entity class and lists the members, principally by lookups, keys, and set functions (Union, Complement, etc.). The latter requires distinguishing each entity mathematically in what amounts to a giant If-Then-Else (Which) tree. For the former I can nearly completely avoid all the math tests and quite easily determine "opacity" of semitotatives or totatives, whereas I have to pre-qualify candidates for this or that recipe in the latter, then run further tests to distinguish which flavor I have, and if I am not interested in one "cousin" flavor I can use True to just color it opaque. I like the former technique but as said, it is less efficient and would reduce the range of the current flexCell routine.

Finally, for very large bases or ranges, though the full-formula prevalidation (looking for a2-semitotatives, etc.) now makes listing, say, the regulars of base 12^6 unreachable, I can narrow the scope of prevalidation to just listing regulars and semitotatives, etc. in general). I think I can reach running a more refined test on base 9699690, which was hitherto only reachable by the "simple" test (i.e., those related to the divisor counting function and the Euler totient function, so the d-s-t vs. the d-g-h-t tests.) I am more interested in d-g-h-t (divisor-nondivisor regular-semitotative-totative) than d-s-t (divisor-neutral-totative).

I've rambled on too long about all this geeky stuff. I think the exercise has been valuable, but it won't make the current flexCell more efficient.

Posted by: icarus Jan 27 2016, 11:26 PM
Status report:

The "sieving" algorithm is complete and works really well within the target range 2 <= b <= 5040. It pans for all the entities that we'd decided we wanted to see, including oschkar's suggestions. If I let it lie I could distinguish multiples of coprimes, but right now as he suggests I just lump them together into a "compound coprime" category. If I want to analyze larger numbers, I can use a watered down analysis (i.e., don't mess with richness and distinguishing among coprime/semicoprime flavors) and get to b = 9699690. The algorithm worked so well that it can track along dynamically like the charts. All flavors identified in the charts are also identified by the analysis but the latter includes Wieferich primes.

Now I am tapping the output to generate what I call Segment A, that is, the breakdown of the types of arithmetic entities (divisors, totatives, alpha-semitotatives, etc.) within the digit-span of the base. This will be HTML output. The formatting in Wolfram is odd and I don't get it completely, so I figure I'll just convert it by running replace-rules all over the HTML tags if I want Wolfram, or just rewrite the program.

I am thinking of rewriting the flexCell to output only Wolfram, then a converter to HTML would translate it. The odd thing is that embedding flexCell into Segment A would require conversion to HTML, then any conversion of Segment A with flexCell in it would reconvert it to Wolfram. Right now am just pushing forward and will figure it out later. (Perfect is enemy of good, and all.)

Segment A does most everything so far that the tour entries do, enumerate and list, give proportions in percent and per 120 (may add pergross but the reason why pergross is here is this forum is dozenal. The point of per 120 is to render more proportions whole. Percent is clumsy but everyone knows what it is.)

May get an interruption for business next week.

Posted by: Oschkar Jan 28 2016, 04:43 AM
When you say it works well up to 5040, is that an absolute limit, or can it be stretched a little? And if it can, can you post a full arithmetic map of base 5985? I want to see all of its relationships in their full glory, especially the way the Wieferich-square-alpha 13 combines with its regular numbers and its neighbour-factors... (I guess it can be coded as 63-on-95? Maybe???)

This is the way I would colour the multiples of 13 here (sorry for the bad quality pixelated digits...)
user posted image

Posted by: Oschkar Feb 14 2016, 07:52 AM
In the supergrand range, 714 seems interesting... It’s the first base that has more than 3/2 times the amount of transparent digits than any other base below it, surpassing even the trivial ternary, which has exactly 3/2 times the amount of transparent digits as binary, but only because it couldn’t surpass binary by any other amount.

I guess a lot of its benefits have to do with the fact that it’s 21*34, but still, it’s interesting to explore. I still think 351 is better, though, since 714 requires range folding even for 4.

Posted by: wendy.krieger Feb 14 2016, 08:46 AM
The test for divisibility can be done for 'close' numbers, not just alpha and omega.

For example, one can use 1.00 = 5 as a test of divisibility for 23, if one reduces a lot of multiples of 23 out beforehand. I use this cast-and-reduce method in base 120 for a great portion of the numbers under 120.

Numbers with four or five places (ie 8-10 digits) are not often met, but one can still use the cast-and-shift method (or fast-division) a lot faster than slow division, because one can make use of multiples not normally used in slow division. For example, 401 is a multiple of 37, but never occurs in a slow division by 37.

On the other hand, something like 16.78, one can see 16.04 is a multiple, remainder 74, and the whole number is a multiple of 37. We can also spot 9, because 16.24 subtracts leving 54. (This is 2.03 * 8), so it is definitely a multiple of 37 * 27.


Posted by: Double sharp Feb 14 2016, 10:39 AM
714 is one-half of a https://en.wikipedia.org/wiki/Ruth%E2%80%93Aaron_pair:

714 = 2 * 3 * 7 * 17
715 = 5 * 11 * 13

and

2 + 3 + 7 + 17 = 5 + 11 + 13 = 29

Another such pair is (5, 6), and a larger one is (77, 78).

Posted by: wendy.krieger Feb 14 2016, 11:01 AM
I'm not sure of 77, 78, but i will settle for 14, 15. No more primorials under 2..127 are in the set.

It's a different meaning to Ruth-Aaron pair to what I was told, ie consecutive numbers that multiply to a primorial.

Posted by: Oschkar Feb 14 2016, 09:03 PM
QUOTE (wendy.krieger @ Feb 14 2016, 08:46 AM)
The test for divisibility can be done for 'close' numbers, not just alpha and omega.

I know; I do that for primality testing (which is the only use for large primes that I can think of). I use 102 and 9996 for 17, 3002 for 19, 299 for 23, 2001 for 29 and 3999 for 31, with 7, 13 and 37 being handled through the cube-neighbours.

And it's not like anyone can use base 714 anyway; its test for 8 is distant enough to be as impractical as the decimal test for 64, without a keen neighbour to save it, and it's too big to be a twistaff {21:34}, but too small to be a tristaff {6:7:17}.

More importantly, how do you even wield it? While it may have awesome digit transparency, there are far too few divisors for CDM, and, even if you managed to commit their multiplication tables to memory, 21 and 34 are large enough subbases that the whole idea behind alternating arithmetic becomes unusable.

I'm going to stay with decimal for the real world, tetradecimal for my constructed world, compressed senary and sexagesimal for the math I do privately, and centovigesimal for divisibility testing.

Posted by: wendy.krieger Feb 15 2016, 01:15 AM
Given that 2001 = 3 * 23 * 29, you can use 2001 for both large primes, and simply test the reaminder after stripping out multiples of 2001. I have used 900 in the same way for 29*31.

Likewise 9996 provides access to not just 17 but 49 too.

Posted by: Piotr Oct 28 2016, 02:57 PM
Please do base 2, 3, 4, 35 and sqrt(2)
QUOTE (wendy.krieger @ Feb 15 2016, 02:15 AM)
Given that 2001 = 3 * 23 * 29, you can use 2001 for both large primes, and simply test the reaminder after stripping out multiples of 2001.  I have used 900 in the same way for 29*31. 

Likewise 9996 provides access to not just 17 but 49 too.

I keeped subtracting 1001 and 98 to test divisibility by 7 (and I also subtracted 980, 9800, ...).
Insert 0s at will. (98 can be 980, ...)

1001 works for 7, 11, 13
98 works for 7 and 49
102 works for 3 and 17
105 works for 3, 5, 7
104 works for 2, 4, 8 and 13
96 works for 2, 4, 8, 16, 32 and 3
999 works for 3, 9, 27 and 37

Primes:
For 7 use 1001, 105 and 98.
For 11 use 1001 and 99.
For 13 use 1001 and 104.
For 17 use 102.
For 19 use 95.
For 23 use 92 or your 2001.
For 29 use 2001.
For 31 use 93.
For 37 use 999 and 111.
For 41 use 99999, 984 and 82.

Prime powers:
For 3, 9, 27 use 999 and 108.
For 81 use 2997 and 81 itself.
For 7 and 49 use 98.
For 11 and 121 use 121 itself.

Posted by: icarus Nov 1 2016, 07:13 PM
I can do 35 pretty quickly as most of the coding is automated now. Let me get some of this workload out of the way, perhaps at the weekend. The lower bases can also be handled pretty easily.

The goal now with Tour is that it will be nearly fully code-generated html at its own site; it will open with bases 5 through 20 and 60, then expand from there. The "travelogue" sort of preamble will of course not be coded and will be base-neutralized, i.e., from a non-dozenal perspective, however there are a lot of things to say that do involve decimal and dozenal vis a vis another base and those things will be retained. Bases as large as 55440 can be considered in a sort of aggregate way.

Other bases that will be looked at are factorial, primorial, prime factor multiplicity bases, etc.

Posted by: Oschkar Nov 3 2016, 07:54 AM
Completely off topic, but I thought that this thread would be the best place to get your attention, icarus.

Can you use Mathematica to find all cities and towns between latitudes 28 and 2845' in both hemispheres with a population of at least 14400?

Posted by: icarus Nov 3 2016, 02:46 PM
Oschkar: Here is the script:
CODE

Reverse@
 SortBy[#, Last@ #&] &@
   Select[{First@ CityData[#, "Coordinates"], CityData[#, "Name"],
     QuantityMagnitude@ CityData[#, "Population"]} & /@ CityData[All],
     28 <= Abs@ First@ # <= 28.75 && Last@ # >= 14400 &] // TableForm


Here is the data:
CODE

28.67 Delhi India 10927986
28.02 Wenzhou China 7791100
28.47 Shangrao China 7282700
28.2 Changsha China 6515900
28.6667 Taizhou China 5784700
28.68 Nanchang China 4973300
28.6 Yiyang China 4705500
28.46 Lishui China 2573900
28.1417 Liuyang China 1404000
28.1958 Fengcheng China 1361000
28.38 Faridabad India 1280827
28.12 Yueqing China 1225000
28.66 Ghaziabad India 1199191
28.25 Yingtai China 1198200
28.37 Wenling China 1185000
28.63 Chihuahua Mexico 841490
28.4168 Gaoan China 821000
28.36 Bareilly India 745435
28.2861 Guixi China 595000
28.7361 Jiangshan China 594000
28.03 Bikaner India 576015
-28.07 Gold Coast Australia 558888
28.0667 Zhangshu China 543000
28.68 Jiaojiang China 470804
28.39 Tabuk Saudi Arabia 441351
28.58 Luqiao China 427890
28.58 Noida India 380309
28.1 Las Palmas Spain 377056
28.6 New Delhi India 317797
28.5887 Chishui China 302000
28.42 Rahim Yar Khan Pakistan 299763
28.32 Jishou China 292000
28.22 Pokhara Nepal 264991
28.5335 Orlando United States 262372
28.73 Hapur India 242920
28.09 Menia Egypt 239804
28.43 Hafar al-BaTin Saudi Arabia 231978
28.47 Santa Cruz de Tenerife Spain 223148
28.41 Bulandshahr India 198612
28.47 Gurgaon India 197340
28.59 Sambhal India 196109
28.68 Nangloi Jat India 194363
28.3 Sadiqabad Pakistan 189876
-28.47 Catamarca Argentina 188812
28.74 Bhalswa Jahangirpur India 180600
-28.25 Passo Fundo Brazil 178200
28.49 Deoli India 175601
28.28 Jacobabad Pakistan 170588
-28.68 Criciuma Brazil 166600
28.75 Loni India 164810
28.04 Budaun India 161555
28.69 Bahadurgarh India 153613
28.65 Huangyan China 150448
28.65 Khanpur Pakistan 142426
28.48 San Cristobal de la Laguna Spain 142161
-28.75 Kimberley South Africa 142089
28.71 Piedras Negras Mexico 139619
28.57 Dilli Cantonment India 138323
28.64 Pilibhit India 131008
-28.09 Virginia South Africa 122502
28.15 Palwal India 121965
-28.55 Emnambithi South Africa 117694
28.71 Gokalpur India 114014
28.13 Jhunjhunun India 113193
28.46 Chandausi India 112635
28.19 Rewari India 112079
28.19 Delicias Mexico 108187
28.26 Khurja India 105909
28.31 Churu India 103533
28.55 Jahrom Iran 103023
28.056 Lakeland United States 102346
28.4792 Spring Hill United States 98621
-28.48 Tubarao Brazil 98412
28.67 Jiroft Iran 97988
28. Telde Spain 97525
28.69 Dhangadhi Nepal 92294
28.42 Cuauhtemoc Mexico 90835
28.3 Samaloot Egypt 90671
28.24 Khandh Kot Pakistan 88468
28.45 Sardarshahr India 86672
-28.16 Dundee South Africa 84413
-28.53 Phuthaditjhaba South Africa 84258
-28.22 Bethlehem South Africa 83654
28.14 Tongzi China 80344
28.49 Beni Mazar Egypt 79553
28.1163 Melbourne United States 78490
28.0102 Town 'n' Country United States 78442
28.65 Maghagheh Egypt 75538
28.72 Pilkhuwa India 74212
28.44 Sikandarabad India 73379
28.22 Faridpur India 71783
-28.46 Upington South Africa 71373
28.57 Dadri India 70609
-28.39 Ijui Brazil 69107
28.09 Arona Spain 69100
28.3 Bisalpur India 68355
28.3029 Kissimmee United States 66722
28.09 Ratangarh India 66625
28.04 Narnaul India 66049
28.47 Xunchang China 64580
28.01 Ghotki Pakistan 64295
-28.3 Santo Angelo Brazil 62893
28.07 Nepalganj Nepal 61474
28.19 Jiangguang China 61469
-28.64 Cruz Alta Brazil 61412
28.08 Sahaswan India 60953
28.43 Tan Tan Morocco 60698
28.5818 Pine Hills United States 60076
28.72 Hushan China 59865
28.08 Gola Gokarannath India 58986
28.22 Khash Iran 57811
28.72 Hasanpur India 57481
28.0847 Palm Harbor United States 57439
28.42 Jahangirabad India 57363
28.68 Xiangyin China 57117
-28.29 Carazinho Brazil 56823
28.69 Xinjian China 56429
28.02 Ujhani India 56309
28.75 Darab Iran 56032
-28.5 Vacaria Brazil 55851
28.25 Ningxiang China 55312
28.6 Roshan Pura India 55183
-28.66 Sao Borja Brazil 54738
28.42 al-Khafji Saudi Arabia 54464
28.1187 Poinciana United States 53193
28.24 Gulariya Nepal 53107
-28.1775 Tweed Heads Australia 51788
28.6 Charkhi Dadri India 50558
28.28 Aonla India 50011
28.5 Tigri India 49705
28.63 Rajgarh India 49583
28.03 Mirpur Mathelo Pakistan 49311
-28.7 Icara Brazil 49304
28.08 Dungargarh India 48036
-28.12 San Lorenzo Argentina 47626
28.03 Atrauli India 47512
28.7038 Apopka United States 47084
28.43 MaTay Egypt 46725
28.6 Gulaothi India 46647
28.24 Dina Pakistan 46291
28.69 Babarpur India 45976
-28.57 Vallenar Chile 44895
28.5 Tikapur Nepal 44758
28.5734 Titusville United States 44557
28.62 Jhajjar India 44122
28.2045 Wesley Chapel United States 44092
28.18 Usta Muhammad Pakistan 43983
28.63 Siyana India 43022
28.2306 Saint Cloud United States 43005
28.6609 Altamonte Springs United States 42225
28.25 Chirawa India 41319
28.5786 Ocoee United States 41073
28.37 Naze Japan 41050
28.39 La Orotava Spain 40644
28.61 Gharonda India 40129
28.05 Daharki Pakistan 40083
28.52 Puranpur India 39988
-28.48 Laguna Brazil 39834
-28.32 Senekal South Africa 39584
28.13 Tulsipur Nepal 39058
28.5421 Winter Garden United States 38746
28.45 Palia Kalan India 38547
28.6619 Oviedo United States 38020
28.22 Dibai India 37873
-28.45 Marau Brazil 37573
28.12 Adeje Spain 36764
28.39 Los Realejos Spain 36746
28.0144 Plant City United States 36627
28.0458 Winter Haven United States 36371
-28.23 Imbituba Brazil 36231
28.0254 Dunedin United States 35819
28.0173 Egypt Lake-Leto United States 35282
28.1 Mehrabpur Pakistan 35263
-28.27 Harrismith South Africa 35108
28.56 Birendranagar Nepal 34983
28.57 Shahabad India 34962
28.11 Arucas Spain 34874
28.3579 Merritt Island United States 34743
-28.4 Theunissen South Africa 34718
28.28 Shikarpur India 34649
28.11 Granadilla de Abona Spain 34595
28.27 Thul Pakistan 34472
28.6881 Winter Springs United States 34169
28.55 Nawabganj India 34134
28.4 Bahjoi India 33752
28.43 Kashmor Pakistan 33732
28.33 Jimenez Mexico 33567
28.0582 Greater Carrollwood United States 33519
28.25 Sohna India 33361
28.28 Bhadasar India 33006
-28.29 Panambi Brazil 32682
28.32 Bisauli India 32154
28.2083 Land O' Lakes United States 31996
28.66 Khormuj Iran 31667
28.37 Ras Gharib Egypt 31414
28.1111 East Lake United States 30962
28.57 Kharan Pakistan 30841
28.0696 University United States 30736
28.5583 Clermont United States 30600
28.4 Puerto de la Cruz Spain 30585
28.49 Puerto del Rosario Spain 30555
-28.41 Sao Luiz Gonzaga Brazil 30295
28.14 Ghauspur Pakistan 29767
28.65 al-Wahat-al-Bahriyah Egypt 29681
28.63 Bilari India 29666
28.03 Katra India 29626
28.5991 Winter Park United States 29442
28.68 Taranagar India 29392
28.13 Jewar India 29316
28.33 Islamnagar India 29144
28.0817 Lake Magdalene United States 28509
28.62 Milak India 28505
28.33 Bareli Cantonment India 28374
28.7114 Eagle Pass United States 28329
28.37 Pilani India 28149
-28.74 Empangeni South Africa 28093
28.68 Dasna India 27926
28.7 Kundarki India 27197
28.6612 Casselberry United States 26707
28.13 Bilsi India 26320
28.3384 Four Corners United States 26116
28.3197 Rockledge United States 26071
28.28 Mahendragarh India 25728
28.07 Pawayan India 25708
28.07 Pasighat India 25581
28.3752 Meadow Woods United States 25558
28.0452 Temple Terrace United States 25419
28.37 Anupshahr India 25306
28.03 Dataganj India 24562
-28.1 Estrela Brazil 24538
28.071 Citrus Park United States 24252
28.1491 Tarpon Springs United States 24239
28.36 Icod de los Vinos Spain 24179
28.03 Rajaldesar India 24104
28.1276 Keystone United States 24039
28.47 Fatehganj Pashchimi India 23810
-28.21 Lagoa Vermelha Brazil 23645
28.72 Shisgarh India 23471
28.3247 Bayonet Point United States 23467
28.16 Ubauro Pakistan 23462
28.15 Galdar Spain 23453
28.27 Baglung Nepal 23296
28.24 El Tur Egypt 23172
28.22 Dharughera India 23132
-28.74 Forquilhinha Brazil 22998
28.55 Kot Samaba Pakistan 22953
28.0044 East Lake-Orient Park United States 22753
28.65 Dashti Iran 22701
28.47 Tacoronte Spain 22695
28.4729 Oak Ridge United States 22685
28.25 Bissau India 22620
-28.28 Braco do Norte Brazil 22577
28.65 Sirsi India 22549
28.04 Mandwa India 22463
28.2 Naraura India 22432
28.1862 Holiday United States 22403
28.03 Aurangabad India 22106
28.1098 Haines City United States 22072
28.6983 Wekiwa Springs United States 21998
28.3308 Yeehaw Junction United States 21778
28.0613 Westchase United States 21747
28.36 Candelaria Spain 21415
28.27 Meoqui Mexico 21179
28.74 Nyoria Husenpur India 21142
28.25 Gunnaur India 20980
28.5 Sarauli India 20923
-28.33 Ulundi South Africa 20753
28.0994 Greater Northdale United States 20461
28.31 al-Qaysumah Saudi Arabia 20316
28.65 Los Llanos de Aridane Spain 20173
28. Dhaurhra India 20098
28.0543 West Melbourne United States 20078
28.63 Deoranian India 19788
28.32 Surajgarh India 19721
28.33 Allende Mexico 19636
28.7 Richha India 19459
28.22 Wazirganj India 19372
28.1398 Lutz United States 19344
28.21 Guia de Isora Spain 19320
28.22 Taoru India 19310
-28.0667 Robina Australia 19182
28.2961 Jasmine Estates United States 18989
28.6 La Oliva Spain 18884
28.18 Pahasu India 18854
28.03 Santa Brigida Spain 18760
-28.03 Garopaba Brazil 18693
28.42 Nava Mexico 18639
28.35 Pajara Spain 18494
28.17 Along India 18425
28.32 Pataudi India 18248
-28.12 Warrenton South Africa 17946
28.5 Narauli India 17945
28.68 Santa Cruz de la Palma Spain 17640
28.3776 Cocoa United States 17419
28.0067 Safety Harbor United States 17234
28.6238 Maitland United States 16823
28.7 Beri India 16727
28.27 Babrala India 16670
28.31 Guimar Spain 16603
-28.35 Orleans Brazil 16422
28.32 Ahmadpur Lumma Pakistan 16352
-28.29 Sao Joaquim Brazil 16250
28.45 El Rosario Spain 16111
28.47 Rithora India 16066
28.55 Shahi India 16064
28.379 Southchase United States 15921
28.18 Bagar India 15670
28.2 Khutar India 15618
28.25 Bilsanda India 15538
28.2469 New Port Richey United States 15527
28.55 Mirganj India 15335
28.53 Khanpur India 14688
28.067 Auburndale United States 14518
28.62 Saidpur India 14496



Posted by: icarus Nov 8 2016, 09:19 PM
Working on tour codes again, improving the sieve algorithm.

I am confident that, outside of the "travelogue" portion that heads up the posts, the entire analysis can be code-generated. Lots of good things have been established.

Today I expanded the "enCode" function (a function that translates digits into the base). It had merely symbolized digits alphanumerically, i.e., those smaller than 10 were normal numerals, those between 10 and 35 inclusive the lowercase, those larger than 36 but smaller than 62 the uppercase. That function is retained, but there is now a decimal-coded feature that writes the decimal value of the digit with Floor(Log_10(cool.gif) digits, forcing leading zeros. A third feature will "code" any base to show alternating radix notation that supports 12 on 10, i.e., "twelfty", thus digit 108 base 120 is rendered as "a8".

Added quadratic residues to analysis. (digits that squares can end with.)

Added simple prime reptend classes to the sieve. Now it tests for minimal (1, i.e., omega), semiminimal (2, i.e., alpha), long prime (i.e., p - 1), and a catch-all class for other lengths.

Improved the sieve algorithm to use the most efficient (for Wolfram, i.e., PowerMod) method for regular numbers, and a sorting of regulars into richness classes. Added proper regulars to richness = 3.

The proper regulars are number "idioms" that would likely be common in a base, as these tend to be seen as "round," especially when they are surrogates for negative powers of small prime divisors vis a vis a sufficient power of the base. Decimally, we have {1, 125, 2, 25, 4, 5, 8} and it is the powers of 5 {125, 25, 5} that are seen as surrogates for 1/8, 1/4, and 1/2 of 1000, 100, and 10 respectively. Dozenal has a much broader set: {1, 14, 16, 2, 23, 28, 3, 4, 46, 54, 6, 8, 9}.

Will add/improve the neighbor-related flavoring in the sieve. FlexCell can sense many flavors.

Wieferich primes, coprime reciprocals with brief mantissae, and auxiliary numbers are next. The latter is a tougher problem.

An auxiliary number x in base b is one that resolves small primes q coprime to b at the expense of some resolution of a prime divisor p > q. The small primes we are normally concerned with resolving are 2 and 3, with 5 less necessary, and 7 very much less necessary. Decimally we have 2 and 5 as divisors. So we bargain away 5 to get 3. Thus 60 is a rather convenient auxiliary as is 12 and 120, each with their own granularity. The number 60 is often used decimally, while 120 is unused though it might have been more used in the past. Some bases such as 12 do not need auxiliaries, thus the problem of auxiliaries, if we want to incorporate q > p_max, involve multiplying a power of b by q. The computer would need to determine regular fractions in base b and see how much "resolution" is lost to the auxiliary. The algorithm will be complex but not as complex as FlexCell and other items I've written.

Some bases have peculiar properties and I would have to say hexadecimal is one of them. We would have to depart from some of the divisor/regular based analysis (though it would still be provided) in order to explore how it and other prime powers handle mediation/duplation and how digit design would affect maths. These alterations to "regular" arithmetic could make hexadecimal "civilizational".

Here are the peculiar bases: {2, 3, 4, 6, 8, 10, 12, 16, 18, 30}; these require special annotations that could be automatically incorporated. The toughest of the bases to handle are 2 and 3. The former requires discussion of logic and truth tables. The latter should require some mention of "balanced ternary" that might not as easily pertain to larger bases. This is why bases smaller than 5 have not appeared in the Tour des Bases. 4 is the smallest composite; 6 the smallest squarefree composite; 8 the smallest number that has only semitotatives, 10 the smallest number that has both neutral digits, 12 has practical alpha-2 divisibility tests that are crucial to utility, 16 has an alternate arithmetic and digit design that may render it civilizationally practical, 18 is similar to 12 and has Wieferich features, and 30 is the largest number where EulerPhi(n) = tau(n) and has no composite totatives. Other bases may have interesting "imbalances" and nuances that the travelogue should pick up on. Many small bases will have travelogues but most bases won't.

The code will be a fleet of freestanding functions and variables that are brought together, output concatenated to fully author an HTML page, complete with head section and CSS, along with analytics. The travelogue prose might be divorced from the page or incorporated manually. Once the code is ready we should be able to furnish any base in seconds (outside of the travelogue).

Posted by: icarus Nov 9 2016, 08:38 PM
Added Wieferich prime support, proper regulars, smallest nondivisor regular, smallest semicoprime, conversion to mixed radix representation. Generates all alpha, omega, alpha-2, omega-2 coprimes. Working on fine-tuning semitotative flavors (practicality classes), numbers with brief mantissae, and the auxiliary base algorithm.

The sieve is a pre-conditioning script that generates a register containing a lot of the raw entities of each base in an object called an association. The other subroutines can tap the register for quantities or instances of these objects. Currently the segmental subroutines either do this separately, reduplicating factorization and function calls. This is a one-stop shop for all the entities that would appear in the tour page, facilitating generation in one fell swoop.

Dozenal:
CODE

f@ 12

<|"u" -> {1},
"g" -> {1, 2, 3, 4, 6, 8, 9, 12},
"d" -> {1, 2, 3, 4, 6, 12},
"p" -> {2, 3},
"sd" -> {8, 9},
"g2" -> {8, 9},
"t" -> {1, 5, 7, 11},
"q" -> {5, 7, 11},
"tpp" -> {5, 7},
"ta" -> {13},
"tb" -> {},
"to" -> {11},
"to2" -> {143},
"ta2" -> {5, 29, 145},
"h" -> {10},
"ha" -> {},
"ho" -> {},
"hb" -> {},
"hh" -> {10},
"sq" -> {0, 1, 4, 9},
"w" -> {2693},
"ss" -> {8, 10},
"pr" -> {"1", "14", "16", "2", "23", "28", "3", "4", "46", "54", "6", "8", "9"}|>


u = unit, g = regular, d = divisor, p = prime divisor, sd = semidivisor, g2 = richness-2 regular, t = totative, q = prime totative, tpp = long prime, ta = alpha-factor totative, to = omega-factor totative, to2 = factor of (b^2 - 1) that does not divide (b - 1), ta2 = factor of (b^2 + 1) that does not divide (b + 1), h = semitotative, ha = alpha-inheritor, ho = omega inheritor = opaque semitotative, sq = quadratic residue (end digits of squares), w = wieferich prime < 7!, ss = smallest nondivisor regular, smallest semicoprime, pr = proper regulars to richness 3.

Vigesimal:
CODE

f@ 20

<|"u" -> {1},
"g" -> {1, 2, 4, 5, 8, 10, 16, 20},
"d" -> {1, 2, 4, 5, 10, 20},
"p" -> {2, 5},
"sd" -> {8, 16},
"g2" -> {8, 16},
"t" -> {1, 3, 7, 9, 11, 13, 17, 19},
"q" -> {3, 7, 11, 13, 17, 19},
"tp" -> {11},
"tpp" -> {3, 13, 17},
"ta" -> {3, 7, 21},
"tb" -> {},
"to" -> {19},
"to2" -> {57, 133, 399},
"ta2" -> {401},
"h" -> {6, 12, 14, 15, 18},
"ha" -> {6, 12, 14, 15, 18},
"ho" -> {},
"hb" -> {},
"hh" -> {},
"sq" -> {0, 1, 4, 5, 9, 16},
"w" -> {281},
"ss" -> {8, 6},
"pr" -> {"1", "15", "1c", "2", "2a", "34", "4", "5", "65", "8", "a", "ca", "g"}|>


The algorithm automatically encodes some output, cf. "pr" output.

CODE

f@ 120

<|"u" -> {1},
"g" -> {1, 2, 3, 4, 5, 6, 8, 9, 10, 12, 15, 16, 18, 20, 24, 25, 27, 30, 32, 36, 40, 45, 48, 50, 54, 60, 64, 72, 75, 80, 81, 90, 96, 100, 108, 120},
"d" -> {1, 2, 3, 4, 5, 6, 8, 10, 12, 15, 20, 24, 30, 40, 60, 120},
"p" -> {2, 3, 5},
"sd" -> {9, 16, 18, 25, 27, 32, 36, 45, 48, 50, 54, 64, 72, 75, 80, 81, 90, 96, 100, 108},
"g2" -> {9, 16, 18, 25, 32, 36, 45, 48, 50, 64, 72, 75, 80, 90, 96, 100},
"g3" -> {27, 54, 108},
"g4" -> {81},
"t" -> {1, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 49, 53, 59, 61, 67, 71, 73, 77, 79, 83, 89, 91, 97, 101, 103, 107, 109, 113, 119},
"q" -> {7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59, 61, 67, 71, 73, 79, 83, 89, 97, 101, 103, 107, 109, 113},
"tp" -> {19, 29, 71, 83, 103, 107},
"tpp" -> {23, 43, 47, 53, 59, 61, 73, 89, 97, 109},
"tt" -> {13, 31, 37, 41, 67, 79, 101, 113},
"ta" -> {11, 121},
"tb" -> {},
"to" -> {7, 17, 119},
"to2" -> {77, 187, 847, 1309, 2057, 14399},
"ta2" -> {14401},
"h" -> {14, 21, 22, 26, 28, 33, 34, 35, 38, 39, 42, 44, 46, 51, 52, 55, 56, 57, 58, 62, 63, 65, 66, 68, 69, 70, 74, 76, 78, 82, 84, 85, 86, 87, 88, 92, 93, 94, 95, 98, 99, 102, 104, 105, 106, 110, 111, 112, 114, 115, 116, 117, 118},
"ha" -> {22, 33, 44, 55, 66, 88, 99, 110},
"ho" -> {14, 21, 28, 34, 35, 42, 51, 56, 63, 68, 70, 84, 85, 98, 102, 105, 112},
"hb" -> {},
"hh" -> {26, 38, 39, 46, 52, 57, 58, 62, 65, 69, 74, 76, 78, 82, 86, 87, 92, 93, 94, 95, 104, 106, 111, 114, 115, 116, 117, 118},
"sq" -> {0, 1, 4, 9, 16, 24, 25, 36, 40, 49, 60, 64, 76, 81, 84, 96, 100, 105},
"w" -> {11, 653},
"ss" -> {9, 14},
"pr" -> {"01", "0105", "0108", "011340", "0115", "0124", "0130", "0140", "0160", "0172", "0180", "0196", "01a5", "02", "0210", "0216", "022680", "0230", "0248", "0260", "0280", "03", "0315", "0324", "0340", "0372", "0390", "04", "0420", "0432", "045340", "0460", "0496", "05", "0540", "0575", "06", "0630", "0648", "0680", "0724", "0760", "08", "0840", "09", "0945", "0972", "10", "1080", "1130", "12", "1260", "1296", "1340", "1448", "15", "16", "1680", "18", "1890", "1924", "20", "2140", "2260", "24", "25", "2680", "27", "2815", "2896", "30", "32", "3340", "36", "3760", "3848", "40", "45", "48", "50", "5340", "54", "5630", "5772", "60", "64", "6680", "72", "75", "80", "90", "96", "a0", "a680", "a8", "b260", "b524"}|>


Bases b > 36 switch from alphanumeric transdecimals to concatenated decimal-coded digits. Base 120 encodes to "twelfty" or 12-on-10 alternating radix, with leading zeros.

This output is essentially the kernel of the tour pages minus the charts. Code provides output for any base b <= 5040 in less than a second. It can process up to 55440 in about 45 seconds. There may be a need to dispose of some features with larger bases; there are over 4500 3-proper regulars for base 55440; that list is unusable and calculating the quantity is fairly easy.

Posted by: icarus Nov 10 2016, 09:01 PM
Register Coding Effort Updates

I've decided to use this post to update those interested on the coding effort, rather than constantly posting new developments again and again. This post concerns an upfront component called "the register". The idea is that all the main features of a base is generated upfront and all the other subroutines have to do is tap the register for data rather than separately process these within the subroutine. I've found that the programs tend to need the same things even across segments. This material will feed the segments but not necessarily the charts. This would also facilitate uniting the segments into a long piece of finished code in the end.

New Developments:
201612051745
Updated the last change so that totals for each of the primary categories (regular = "g", semicoprime "h", and coprime = "t") are given for each power b^e, with 1 <= e <= Floor(Log_b(p_8#)).

CODE

ght[b_, r_] :=Function[l,
 Function[s,
   Map[Function[
     x, {#1, x - (#1 + #2 - 1), #2} & @@ {#, x EulerPhi[b]/b} &@
      Length@ TakeWhile[s, # <= x &]], b^Range@ Floor@ Log[b, l]]]@
  Select[Range@ l, PowerMod[b, #, #] == 0 &]][
b^Floor@ Log[b, Times @@ Prime@ Range@ r]]

ght[10, 8]

{{6, 1, 4}, {15, 46, 40}, {29, 572, 400}, {48, 5953, 4000}, {72, 59929, 40000}, {100, 599901, 400000}}

Keep in mind that the number 1 is counted both by regular and by coprime registers.

201612051000
Per Wendy's request, added a regular counting function for regulars g <= b^e, with 1 <= e <= Floor(Log_b(p_8#)). This is an "expensive" computation and, next to the determination of Wieferich primes and their lengths, is responsible for the lion's share of processing time. Here is the code:

CODE

rg[b_, r_] := Function[l,
Function[s,
Map[Function[x, Length@ TakeWhile[s, # <= x &]],
b^Range@ Floor@ Log[b, l]]]@
Select[Range@ l, PowerMod[b, #, #] == 0 &]][
b^Floor@ Log[b, Times @@ Prime@ Range@ r]]

rg[12, 8]

{8, 23, 46, 78, 117, 164}


May add a "nondiscrete" method later.

201612031600, Segment A1 is complete.
The segment works on its own or with the register to furnish:
Base names, class (prime, prime power, composite, etc.) with OEIS links, prime divisors and distinct prime divisors, and the nature of primes less than b. Some glitches in the register were tweaked. Next segment is Segment A2, regarding divisors. Between Segment A1 and Segment A2, a map of digits will be produced by FlexCell.

Also added facilities for linking to MathWorld and Wikipedia to the register.

The idea is once the segments are complete, Mathematica will write an HTML page that is ready to post. The head section and coda will encapsulate a body composed of segments and diagrams, that will be the method of writing the pages.

201612021645
Jumped in, added a version number and datestamp to the register. This will help track changes and keep the system up to date as it matures. Minor tweaks in response to satellite software requirements.

Decided that all segments will retain a self-produce capability and a register-use capability. That is, they will be programmed to handle centrally-provided data or concoct the data themselves. Instead of deploying piecemeal insitu functions, they will generate a mini-register with only the data needed, the code cribbed from the master register, when they must generate their own data. This way the segments can be mapped across a list of bases to produce "mashup" style cross comparisons. These won't be the same as the mashups on the forum.

Also, FlexCell will be reprogrammed to deploy a register-style number theory engine. The advantage is that the routine would be able to pass text through to cells, color-code highly specific entities (for instance, only omega-related semitotatives with richness 2, or Wieferich primes of depth 3, etc.) Will also be able to specify spot color through a set of custom rules. This is a tricky rebuild. The current FlexCell has a monstrous Which statement and that was the previous number theory engine. The new one will still generate the all-encompassing charts (the digit maps, regular maps, abbreviated multiplication tables, and fraction maps) but also handle cross-comparisons of various micro-aspects of bases. This is something to do after the segments are programmed.

Focus will continue to rest upon development of segments that take or make a register and "write" an appropriate human-legible data section as we see here on the Forum. I am using RandomChoice to help make the verbage vary lest all the pages read dronelike in their similarity.

The new number theory engine and register application offers some expanded possibilities for the tour, yet I would like to focus on getting the auto-writing pages started and test some concepts before I add too many more features.

201612011130
Added numbers that have brief recurrent periods and primes that have same into the register.

CODE

briefp[b_, n_] :=
Function[w,
KeySort@ #[[All, All, 1]] &@ GroupBy[#, Last] &@
Map[{#, First@ FirstPosition[w, #]} &, Union@ Flatten@ w]]@
Map[Divisors@
Flatten[Times @@ ConstantArray[#1, #2] & @@@
FactorInteger[b^# - 1]] &, Range@ n]


This sorts the first occurrences of a given number as we increase the exponent e of (b^e - 1) between 1 and n. To sort for primes, I use:

CODE

Map[Select[#, PrimeQ] &, briefp[10, 8]]


Here for decimal numbers up to period = 8.

201611302000
Added some language in a test segment that processes the "cons", "logs", and "logd" fields, putting these in English.
[doHTML]
Just a proof of concept. These probably should be in tables.

201611291715
Heading into some deadline runs and will have to set project aside.
Today I added two more limits to the register along with the lesser and greater rounds. There is a digit-grouping number "dg" and a percent-like number "pc".

Let's take the easiest thing to explain first.

The current tour gives some base-b expansions for constants and logarithms. This requires us to convert and "typeset" the numbers such that digits are grouped, as it would seem plain to use a number near the lesser round as the total number of digits to compute. I like the usage of 5 decimal digits given in some scientific literature I read (the CRC Manual of Mathematics, Chemistry, etc.) and that number perhaps makes sense for base ten. Thus we have to set a base-b appropriate digit-grouping number that would function at least below the radix point for this sort of purpose. Generally the number is between 3 and 5, taking the largest number that is regular to b in that range, but defaulting to 5 south of 30 inclusive, then 3 between 30 and 60, then 2 (shifting the entire range to between 2 and 4 inclusive). We won't compute expansions in bases larger than 120.

This settled, I had to program a round-up function when we trim expansions. The algorithm works really well and lickedy split.

We also observe in the tour that the quantities of this or that type of numeral/digit/entity are given. This was a big hurdle for segment B, such that I had not written it. Now that we've aggregated all the entities in one place, it is fairly easy to do the meta-analysis in the register. This also furnishes the analysis for use anywhere in the tour page.

The general format is maybe best described per example:

Decimal has 6 regular numerals {1, 2, 4, 5, 8, 10}: six of ten digits (60%) are regular.

It's that "six of ten..." bit that needs to be prepared before farming out to the segments. Now I do want to use two further summary figures. The first is a sort of "percent" that makes sense in base-b. The dozenal equivalent would be "pergross" or "bicia". Finally I wanted to use parts in 120 to describe some factors universally. A long while ago I'd called these "twips" in this forum, but twips are actually parts in 1200. I did use "pertwelfty" but that is cumbersome and alien-sounding. I have settled on "grade," from "centigrade". I just won't go down the path of appending "centovigintigrade" (like the disease we have with "perigee"->"perilune"->"perihelion"->"perijove", i.e., carrying around the need to build novel suffixes). "Grade" will be explained in a high level FAQ.

This has not been implemented yet, but will inshallah before I get slammed tomorrow with work.

I also finalized the incorporation of modular math divisibility rules into the "hh" and "tt" registers. This then gives us truly "opaque" flavors of these species. I would regard semitotatives that require right trim rather more opaque than those with regular or neighbor-related rules, and I have already factored in practicality into the mix, unlike regular rules. Now the register has a keener number theory engine than the FlexCell routine, and I will have to extract the engine from that to make "formatCell" or some similar easily embedded subroutine.

After these next couple days the project will go into hibernation until the system of deadlines involving mid and late December, culminating in early January pass by.

201611281300
Have written a set of codes that results in a collation of all divisibility rules (except compound).

The left-right trim rules are first sorted such that the smallest absolute coefficient is selected that is either a regular number g <= 5 or the least divisor within the range 4..12 and the omega factor including at least omega itself and {2, 3, 5} if they divide omega. This seems to provide actionable and usable rules thus.

Numbers are assigned regular rules as to their richness, and neighbor-factor rules as to their flavor.

All rules are aggregated and collated.

What remains now is the determination of inherited rules for composites less than the greater round. Then the register will have everything needed to easily generate divisibility rules for base b within and including the greater round.

This is expected to conclude the incorporation of divisibility rules into the register.

201611280900
Incorporated the raw data for the left and right trim divisibility rules for numbers under the minimum of the greater round or the square of b. Generated language for the trim divisibility rules, including the right trim-2 rules. There are two other flavors of divisibility rule that I want to incorporate. Then the program can collate all the rules for a given number. In the short form only one good rule will be shown. Those that involve large coefficients will not be shown. In the condensed, technical form, the coefficients for all numbers will be summarized in a table.

I might simplify the rules language. Currently the language is pretty clear; I don't want to lose clarity.

The numbers in the divisibility rule field need conversion to base b. The field will be winnowed according to simple numbers to multiply by in base b, but all the data will be available in the summary.

201611272100
Over the last 24 hours I have examined incorporation of a wider set of practical but "non-intuitive" divisibility rules into the "Tour" pages. These include the "left trim" and "right trim" divisibility rules seen http://webspace.ship.edu/msrenault/divisibility/StupidDivisibilityTricks.pdf. These rules are attained easily through "Select[Range@ t, PowerMod[b^e, -1, t] == # &]" (right) and "SelectFirst[Range[k - 1], PowerMod[b, 2, k] == # &]" (left), selecting the shortest rules.

The inclusion of simple "non-intuitive" divisibility tests rounds out the third major "technology" posited in the manifest of the Tour, that is, the technology of the divisibility rule, a major part of the intellectual simple machine called the number base.

The incorporation of the major functions of the current "intuitiveDT" module, a 2-page long Wolfram function, will be tricky. Certain common subroutines (coprimePart, richness, silo) as well as the reduplication of the number-theoretical sieving algorithm (which has been upgraded and made more efficient in the register) imply its incorporation. The range-folding algorithm and the handling of text (unfortunately hard-wired rather than modular like the other segments) present challenges. I would like the register to be able to yield all the divisibility rules and simply have a new divisibility rule function merely put them in human-readable (English) narration. This allows all the number theoretical calculations to be concentrated up front in the register, and the segment routines merely take the data and weave it into a narration. Then we have several options (content in other languages, auto-generation).

201611240700
I have added unit fractions for numbers 2 <= m <= lesser round in the register under "fd". These will feed a table currently produced independently under the module "section3A".

201611231500
Working on the rounding algorithm. Originally, the rounding algorithm wanted to do something "smart" per observations in decimal. Namely, the application of some surrogates for negative powers of 2 seen as "semiround", e.g., 7500, 1250 as round numbers. I have just settled on the fact that we need only to find the number closest to the mark within the range in question that has the most number of trailing zeros. Trying to divine an analogous condition in an odd base, or a base severely out of the "human" range of bases is folly.

Added the "rd" register. It creates a "lesser round" number in the vicinity of 30, and a "greater round" number in the vicinity of 120, to be used to limit the number of examples in some tables. The lesser round, for instance, is applied to the number of unit fraction conversions to show in tables and the intuitive divisibility rules to show. The greater round is used in a condensed version of right and left trim divisibility rules I am studying.

"rd" gives the lesser and greater round both in raw and base-b format.

201611130900
Added prime factorization (I hadn't factored the base throughout development thus far!), class, prime signature, each with the appropriate OEIS citations. These shift gears throughout the segments. For example, primes need not discuss neutral numerals; prime powers need not show semidivisors because they don't have any. Both these classes only have regular figures that are proper divisors, etc.

201611120800, Register program finished.
Found a way to pre-process and incorporate auxiliaries. First we use the algorithm as described, except that the program now checks to see if SHCNs exist among the qualified auxiliary candidates. Then it takes the smallest of each goalset and any SHCNs and suggests these as the auxiliaries. Then, for each auxiliary a, the program converts the number a to base b, as well as unit fractions of m that result in integers that are any of the union of {2, 3, 4, 8} and the divisors of b. It states m, followed by the integer a/m converted to base b. This way, not only do we have a listing of the (decimal) auxiliary values, but the values in base b, as well as the base-b equivalent of any unit fraction 1/m for all m that result in integer values. "Clean" m are those that are 0 (mod b ), i.e., that end in a zero in base b.

Now that the register is finished, I will now proceed to engage it after a few tests. This means that all the subroutines previously written will be adjusted to tap the register versus homebrew results, and new subroutines will rely on the register.

201611111730
Finished the auxiliary base routine. There are three inputs: base, n = maximum prime to resolve, s = maximum power of 2 to resolve. The function is predicated on the presumption that we want to resolve the smallest primes and 2^e with 1 <= e <= 3. The usual values for n are 2 or 3, meaning resolve {2, 3} or {2, 3, 5}, but the program can go as high as desired, while I governed s to be the minimum of the maximum of the largest power of 2 that divides b or the s setting, and 3.

The algorithm successfully produces auxiliaries that produce 0 (mod b ) for the desired fractions. The desired fractions are related to the setting s, the prime divisors of b. If the base has a clean half, third, quarter, or eighth, it keeps it. The use of lcm(b, p_n#) automatically provides clean prime(x) with 1 <= x <= n. The goal s set to 1, 2, or 3 ensures halves, quarters, or eighths are clean.

Test: Bases 2 - 20
The program provides the following output for prime(2), s = 2^1:
CODE

{12, 18, 48, 30, 36, 42, 192, 54, 60, 66, 144, 78, 84, 90, 384, 102, 108, 114, 240}


The program provides the following output for prime(3), s = 2^1:
CODE

{60, 90, 240, 30, 180, 210, 960, 270, 60, 330, 720, 390, 420, 90, 1920, 510, 540, 570, 240}


I think the script works and am trying to think how to best incorporate it. Maybe it won't go into the register, because there are a lot of things I want to do with auxiliaries and need to sort out what to say.

Next week a major project gets started but won't really get intense until mid December. So I might have to lay the project down in the beginning of the week, but there should be more progress this weekend.

201611111111 wink.gif
Added the "name" field, storing the English number name, LaMadrid base name, and the SDN base name to the register. Not sure I will use SDN off the forum, but I do think it is a cogent system. Perhaps it would be added at the top but not throughout text, with a link to Kodegadulo's wiki. I will write an "alternate name" database that mostly pertains to the smallest bases (cf. "octonary", "denary", "quadradecimal") but won't use these outside of the introduction. The standard in the Tour will be LaMadrid or "base [English number name]"/"base [number]".

Wrote two modifiers to the "english" subroutine ("english" builds the standard English nominal number word). The first is "ordinal" that converts a number name, e.g., four -> fourth, fifty one -> fifty first. The second "fractional" converts an ordinal to a fractional form, e.g., second -> half, fourth -> quarter. The third "pluralfractional" converts an ordinal thus: second -> halves, fourth -> quarters, twenty fourth -> twenty fourths.

The function is now called "reg" for "register".

Worked on an algorithm for auxiliaries with goals one can set to achieve incorporation of primes. Now working on optimization goals (achieve a "clean" half, third, etc.). This problem will be slain today as the work is unopposed.

201611101745
Took a break and wrote a head section composition script. Just needed to get that out of the way, and was noodling too much on auxiliaries.

"fr" is the biggest addition. A section that is not currently in the tour for most bases is one on fractions that simply gives equivalents for the most common fractions. This subroutine gets base-b equivalents for all fractions m/n with n = {2, 4, 8, 16, 3, 6, 12, 5, 10, 7}, 0 < m/n < 1, and gcd(m, n) = 1. The format uses Mathematica's RealDigits function, but "fixes" it such that the nonrecurrent part is in the first position of the list, and the reptend is in the last position. This way I can add font treatments to highlight the different parts, and then automatically generate an abbreviation as you've seen on the tour pages.

Will change the regular figures to admit the decimal equivalents in case we want to produce logarithms of such in a way that apes a concept similar to Wendy's "log wheel". (see http://z13.invisionfree.com/DozensOnline/index.php?showtopic=620&view=findpost&p=22006426 for example).

I think after auxiliaries, this is for the most part done and I will then go back and rehash the segments already written to incorporate the register-furnished data.

201611101300
I've changed the algorithm to add richness to regulars and "neighbor-relatedness" to totatives. This has the consequence of easily discerning the "flavors" of semitotatives (which have a regular part with richness and a coprime part with neighbor-relatedness), easily determining richness of regulars without continual processing, and neighbor-relatedness of totatives without same. The wieferich primes now are followed by their length if former is < 6! (to save computation time).

"tp" assigns reptend period to a totative.
"sp" is a short-period prime with period equal to the order in the list.

Now working on auxiliary algorithm.

Some sketches for auxiliaries:
1. Primes desired are {2, 3, 5, (7)} in that order.
2. A good auxiliary must minimally "damage" halves/quarters, thirds/sixths, and fifths/tenths in that order. "Damage" means rendering the auxiliary fraction ending in something other than the pure-base expansion or zero.
3. Auxiliaries must have 1-3 base-b digits.
4. Auxiliaries are often semicoprime to b by definition, unless the prime divisors of b include those desired.
5. Bases that have all desired factors below a limit (perhaps at least {2, 3}) need not have an auxiliary, but perhaps desired prime p can be used as a coefficient to some small power of b to create an auxiliary.
6. Many bases will easily have an auxiliary that is 60b or some reduction of 60 to account for prime divisors of b.

Octal: {"30", "360"}
Decimal: {12, 60, 120, 360}
Dozenal: {"10", "500"}
Tetradecimal: {"440", "220", "110"}
Pentadecimal: {"190", "40"}
Hexadecimal: {"18", "f0", "1e0", "3c0"}
Vigesimal: {"300", "160", "c0", ("i0", "30")}
Unvigesimal: {"a0", "k0", "1j0", "3h0"}

Posted by: Piotr Nov 13 2016, 07:02 AM
QUOTE (icarus @ Nov 8 2016, 10:19 PM)
The toughest of the bases to handle are 2 and 3. The former requires discussion of logic and truth tables. The latter should require some mention of "balanced ternary" that might not as easily pertain to larger bases.

No, they don't. They are just bases! Base 2 is base 2, and base 3 is base 3, not some truth tables and balanced junk. They are simply bases, deal with it. When making it, remember that you are making base 7 page, but with all properties of base 7 replaced by base 2 or 3.
This is wrong:
"Base 3 is commonly found as balanced version, and we'll talk about it.
This is correct:
"Base 3 features terminating thirds, as well as 2 from omega, 4 from alpha, 8 from square-omega and 5 from easy SPD (or whatever is it called)"

Posted by: icarus Nov 14 2016, 02:34 PM
Piotr,

The focus now is writing an algorithm that will fully produce the tour pages. It would then be able to write any base en masse. The program would write dozens of HTML pages in a minute, including adjunct pages. I think there are certain bases that merit focusing on aspects commonly encountered when discussing them.

I appreciate your eagerness!

You've reminded me to write code that recognizes practical "SPD"/alpha-2 tests (i.e., if x is a divisor t_a_2 of (b^2 + 1) but not (b^2 - 1)). Currently the intuitive divisibility test program does not do that. What we need to consider is that the multiples of t_a_2 involved might be practically memorized.

Binary has {5}, ternary {5, 10}, quaternary {17}, quinary {13, 26}, senary {37}, septenary {5, 10, 25, 50}, octal {5, 13, 65}, nonary {41, 82}, decimal {101}, undecimal {61, 122}, dozenal {5, 29, 145}, tridecimal {5, 10, 17, 34, 85, 170}, tetradecimal {197}, pentadecimal {113, 226}, hexadecimal {257}, heptadecimal {5, 10, 29, 58, 145, 290}, octodecimal {5, 13, 25, 65, 325}, enneadecimal {181, 362}, vigesimal {401}.

The preponderance of these are unremarkable outside of binary-5, ternary-{5, 10}, septenary {5, 10, 25} (5 is a level 2 septenary Wieferich prime), octal {5, 13}, dozenal-5, tridecimal-{5, 10}, heptadecimal-{5, 10}, octodecimal-{5, 13}.

Septenary is interesting because despite the fact that it is prime, we have "intuitive" divisibility tests for {2, 3, 5, 7} when we count SPD for 5 as "intuitive". For bases less than or equal to 12 SPD-5 appears to be practical (28 combinations), but it is questionable whether SPD-5 in base 18 is practical (64 combinations). Octodecimal SPD-13 might be practical (24 combinations) even though it might not be as desirable.

Posted by: icarus Nov 14 2016, 11:28 PM
Working on a simple synopsis; this is too much detail but is a sketch of the auxiliary narrative.

[doHTML]

Tomorrow the new gig comes in and will take a break until after the late November deadline.

Posted by: Oschkar Nov 19 2016, 08:03 AM
Ive just noticed a correlation between the usefulness of a number as a division and the number of totatives it has.

The only numbers with only one totative are {1, 2}, and indeed the half is the most natural fraction.

{3, 4, 6} have 2 totatives, and are some of the more natural divisions. The turn can be divided into thirds, fourths and sixths, to get hexagons, squares and triangles, respectively, all of which naturally tile the plane. The smallest base that can be divided into these is dozenal.

{5, 8, 10, 12} have 4 totatives. The division into 12 was already covered as the difference between 1/3 and 1/4, but now we have fifths and eighths, surely the most important of the remaining fractions. The long hundred covers all of these within one place.

{7, 9, 14, 18} have 6 totatives. We reached one more prime number, and one more ternary power, whereas {15, 16, 20, 24, 30} have 8 totatives, and grant us one more binary power.

Extending this further seems to emphasize higher primes, and disregard powers of lower primes: the numbers with 32 totatives or less are {1-36, 38-40, 42, 44-46, 47, 50-52, 54, 56, 58, 60, 62, 64, 66, 68, 70, 72, 78, 80, 84, 90, 96, 102, 120}. I understand why this is: a more diverse prime factor composition results in a lower totient ratio. However, Im certain that 128ths must be much more important than 31sts, yet 128 has over twice as many totatives as 31 has. The correlation needs to be refined further, but its a starting point.

Posted by: icarus Nov 19 2016, 01:27 PM
oschkar,

I have six algorithms for determining regular numbers; a subsequence of regular numbers are the divisors, and a subsequence of the divisors are the prime divisors (obviously). One of the most interesting algorithms is the Mertens function method.

The root formula is:

sum_{1 <= t <= n}(mu(t) * floor(n/t))

i.e., the sum of the product of the Moebius Mu function of t and the floor function of the ratio n/t, taken across the totatives of n, where gcd(t, n)=1 and n a nonzero positive integer.

In other words the regulars are related to the totatives of n. This stands to reason. Basically, the logic behind this formula is that each totative contributes a negative score against a "potential" number of regulars (the sense of this is limited, but stay with me). The smaller the totative, the more "damage" against this potential. The most important logic (imho) behind this formula is that the smallest prime totative incurs the most damage, thus if we have gaps in factorization, we have a number n that is less efficient at generating regulars than one that has no gaps. The formula implies that primorials will at once minimize totatives but also maximize the number of regular m <= n. (It's part of a proof I wrote for another sequence, that I will publish soon).

The method works like this in Mathematica:
CODE

f[n_] := Total@
 Map[MoebiusMu[#] Floor[n/#] &,
  Select[Range[n - 1], CoprimeQ[#, n] &]]


The program requires about 15-1/2 seconds to generate r(p_8 #) and 445 seconds to produce r(p_9 #), where r is the regular counting function via Mertens, and p_x # is the primorial based on prime(x).

Now on my machine using Wolfram the powermod method is the most efficient; it avoids factoring and generation of totatives. This method is faster: The program requires about 10 seconds to generate r(p_8 #) and 224 seconds to produce r(p_9 #):

CODE

f[n_] := Select[Range@ n, PowerMod[n, #, #] == 0 &]


This is based on a more "traditional" fact related to regular m of n:

n^m (mod m) = 0.

But the Mertens method is of interest to your observation regarding unit fractions.

Posted by: Double sharp Nov 30 2016, 08:06 AM
I think 24 is pretty interesting too and may require individual annotations as well, as it is the largest base where http://z13.invisionfree.com/DozensOnline/index.php?showtopic=630:

1^2 = 1
5^2 = 11
7^2 = 21
b^2 = 51
d^2 = 71
h^2 = c1
j^2 = f1
n^2 = m1

This is only possible for bases {2, 3, 4, 6, 8, 12, 24}.

It is also perhaps half-usable if you think of the high digits as tetravigesimal 10 minus the low digit, as follows:

h * j = (10 - 7)(10 - 5) = 100 - 70 - 50 + (7 * 5) = c0 + 1b = db
d * n = (10 - b)(10 - 1) = 100 - b0 - 10 + b = cb
5 * k = 5(10 - 4) = 50 - k = 44

h + j = (10 - 7) + (10 - 5) = (10 + 10) - (7 + 5) = 20 - c = 1c
b + n = b + (10 - 1) = 1b - 1 = 1a

This would perhaps be more obvious if the digits echoed their complements. No, I don't think it really saves any base that isn't already divisible by 4 in this range (so it really only saves {16, 20, 24, 28} as the "big sisters" of {8, 10, 12, 14}), and I still don't think it's anywhere near as efficient as the smaller base of each pair, but it's a way of forcing a possible use of the doubly even low mid-scale bases that may be considered.

Posted by: Double sharp Nov 30 2016, 12:00 PM
@Oschkar: maybe you want to try the https://en.wikipedia.org/wiki/Carmichael_function instead of the standard one?

When this is one, we get the set {1, 2}. (These are the numbers that only have unitary totatives.)

When this is two, we get the set {3, 4, 6, 8, 12, 24}. (These are the bases such that every totative squares to a number ending in "1".)

When this is four, we get the set {5, 10, 15, 16, 20, 30, 40, 48, 60, 80, 120, 240}. (These are the bases such that the fourth power of every totative ends in "1".)

When this is six, we get the set {7, 9, 14, 18, 21, 28, 36, 42, 56, 63, 72, 84, 126, 168, 252, 504}. (These are the bases such that the sixth power of every totative ends in "1".)

When this is eight, we get the set {32, 96, 160, 480}. (These are the bases such that the eighth power of every totative ends in "1".)

(http://z13.invisionfree.com/DozensOnline/index.php?showtopic=644 already explained it a few years ago here. ^_-☆) The OEIS sequence http://oeis.org/A006863 shows that as you increase your desired result from 1 and then up through the even numbers, the numbers you get are the factors of {2, 24, 240, 504, 480, 264, 65520, 24, 16320, 28728, 13200, 552, 131040, 24, 6960, 171864, 32640, 24, 138181680, 24, 1082400, 151704, 5520, 1128, 4455360, 264, 12720, 86184, 13920, 1416, 6814407600, 24...}

This would seem to suggest that the primes and prime powers are important (according to this scale, which may not be the best for this job!) in the following order:

{2; 3, 4, 8; 5, 16; 7, 9; 32; 11; 13; 17, 64; 19, 27; 25; 23; 29; 31; 37; 41; 43; 49; 47; 128; 53; 81; 59; 61...}

This measure values the early powers of two very highly, but past a certain point they stop being so useful.

Posted by: wendy.krieger Nov 30 2016, 12:57 PM
{2; 3, 4, 8; 5, 16; 7, 9; 32; 11; 13; 17, 64; 19, 27; 25; 23; 29; 31; 37; 41; 43, 49; 47; 128; 53; 81; 59; 61...}

I've added 49. While this equates to the bi-totient (n) = ((n)) of the prime-powers, for composites, you have to take the LCM, not the product. So the period cycle of 120 is LCM((3), (5), (8)) = LCM(1,2,4) = 4.

It is true only for odd numbers. There is a special '2' that is orthogonal to the general cycle.

Posted by: Double sharp Nov 30 2016, 01:17 PM
Corrected; thank you!

Posted by: icarus Nov 30 2016, 03:39 PM
double sharp,

Indeed significant special statuses of any base ought to be noted. Any compendium of bases will not be complete without this. I may not have included them here and I am likely unaware of all the significant special statuses.

These can also be cultural, so long as the culture in question is influential. Cultural importance is undeniable when we talk about decimal, to a lesser extent bases 12 for Roman, 20 for Mayan, 60 for ancient Mesopotamian use and its continuation today, and 120 via "twelvety" at DSGB, for instance (not an exhaustive list). The predilection of computer programmers toward hexadecimal and its actual use is important. Some effort should be made to attempt to make hexadecimal as workable as possible, because I think people are interested in that; not to put a thumb on the scale, but to show what would be necessary to render it useful. These sort of considerations can be written in the "travelogue". This said, I am not interested in _every_ cultural nuance of a base. (That's for Wikipedia and other sources).

Number-theoretical statuses can be automatically generated, links provided to OEIS sequences and perhaps other sources to back up the assertions. Thus far I have only crystallized links to the OEIS but it would merit inclusion of MathWorld, Prime Pages, and other primary sources. I am not against Wikipedia links (despite my aversion to the aggregate political bias of its editorship; my experience is that the mathematics pages are not as badly infected with bias as other pages). The OEIS and other math resources do link to Wikipedia despite a general primary and secondary academic tilt against it.

If you have links and special statuses or remarks about any base, I would appreciate receiving notice. Now I want to credit contributors by name. Email me with your name (I know Wendy and Dan and Shaun and kodegadulo and oschkar) if you desire credit. I can't credit usernames (obviously on the Forum I can). For instance, the importance of Wieferich primes comes to me through Wendy and I will credit her. There will be page of acknowledgements that should be clickable from all the pages in the footer. Gratitude is important to me personally and I intend to thank and recognize every source that I can remember (some of the work came about when it wasn't as important to me and I have perhaps lost this or that provenance of an idea.)

Thank you.

Posted by: Double sharp Dec 1 2016, 03:26 AM
I think all that really needs to be done is to include the usual "travelogue" parts, and let readers decide for themselves if such mathematical curios are relevant. Bases in my "class C" (extended human scale, can be used by an individual person if not by a whole society) are mostly niche players that mostly get covered well already for either being great "prime detectives" or having many divisors. For example, 34 falls into the first category while my beloved 24 and 60 fall into the second.

I think a completely pure-base approach neglects that the best way to make sexagesimal usable is to treat it as a mixed radix of senary on decimal. Even treating hexadecimal as binary doesn't come close, mostly because doing that results in making it about as slow as binary. (Though I think you should show that, together with the loss of efficiency, to prove how {16} is really kind of a pipe dream.) I think mixed-radix arithmetic perhaps merits an explanation or tutorial, since it is not obvious how to do it. And perhaps the added baroqueness and non-obviousness will serviceably explain why {60} isn't usable today.

Cultural nuances are in any case rather limited. Wikipedia only has articles on the bases {2, 3, 4, 5, 6, 8, 10, 12, 16, 20, 60}. The reasons in most cases are obvious. (The classic non-decimal bases to advocate were always octal and duodecimal. The current love of hexadecimal mostly stems from thinking that what's good for computers should be good for us, but since we don't plug ourselves in and we don't toss bowls of soup over our computers, at least not if we want to live, that's an irrelevant statement.)

I'm not entirely sure that I've done anything other than restate and/or verify what others have said to my own satisfaction, though.

Posted by: icarus Dec 1 2016, 04:30 PM
Agreed.

The first priority is to get the math engine finished, then the verbage for the boilerplate pages, then special pages. I want this thing online as soon as I can get it there. It's been rolling around my mind since October 2011 when I first bought the domain.

There used to be a "pentadecimal" (it might've been "quindecimal") page on Wikipedia. I do find it VERY interesting (and not referenced! Silly editors!) that they seem to use the http://www.numberbases.com/terms/BaseNames.pdf in https://en.wikipedia.org/wiki/List_of_numeral_systems#Standard_positional_numeral_systems.

Posted by: icarus Dec 1 2016, 05:38 PM
Oschkar,

If you translate one of the more complete tour pages (not the Travelogue), I would also furnish a Spanish-language version at some point. Priority is to get this thing online, but also am interested in alternate pages for different languages. There is no deadline and completely voluntary. Of course would attribute you as the translator. I know Spanish but I am afraid of Engrishizing it. I am fluent in Italian and still would not endeavor the translation.

Posted by: Oschkar Dec 4 2016, 06:27 AM
QUOTE (icarus @ Dec 1 2016, 04:30 PM)
There used to be a "pentadecimal" (it might've been "quindecimal") page on Wikipedia. I do find it VERY interesting (and not referenced! Silly editors!) that they seem to use the http://www.numberbases.com/terms/BaseNames.pdf in https://en.wikipedia.org/wiki/List_of_numeral_systems#Standard_positional_numeral_systems.

To be fair, the Lamadrid convention seems like a reasonable extension of the already standard terms "undecimal", "duodecimal" and "hexadecimal".

By the way, this is how I would localize Lamadrid base names into Spanish:

{unario, binario, ternario, cuaternario, quinario, senario, septenario, octal, nonario}
{decimal, vigesimal, trigesimal, cuadragesimal, quincuagesimal, sexagesimal, septuagesimal, octogesimal, nonagesimal}
{un-, duo-, tri-, tetra-, penta-, hexa-, hepta-, octo-, enea-}
{centesimal, ducentesimal, tricentesimal, cuadringentesimal, quingentesimal, sexcentesimal, septingentesimal, octingentesimal, noningentesimal, milesimal}

To form the feminine form, replace "-ario" with "-aria", and leave "-al" unchanged. Plural forms have endings "-arios" (m.), "-arias" (f.), and "-ales".

My attempt at French, Italian, Portuguese and German versions of Lamadrid base names:

FR
{unaire, binaire, ternaire, quaternaire, quinaire, snaire, septnaire, octal, nonaire}
{dcimal, vigsimal, trigsimal, quadragsimal, quinquagsimal, sexagsimal, septuagsimal, octogsimal, nonagsimal}
{un-, duo-, tri-, ttra-, penta-, hexa-, hepta-, octo-, enna-}
Feminine: replace "-al" with "-ale", and leave "-aire" unchanged. Plural: "-aux" (m., for "-al"), "-ales" (f.), "-aires".

IT
{unario, binario, ternario, quaternario, quinario, senario, settenario, ottale, nonario}
{decimale, vigesimale, trigesimale, quadragesimale, quinquagesimale, sessagesimale, settuagesimale, ottogesimale, nonagesimale}
{un-, duo-, tri-, tetra-, penta-, esa-, etta-, otto-, ennea-}
Feminine: replace "-ario" with "-aria", leave "-ale" unchanged. Plural: "-ari" (m.), "-arie" (f.), "-ali".

PT
{unrio, binrio, ternrio, quaternrio, quinrio, senrio, setenrio, octal, nonrio}
{decimal, vigesimal, trigesimal, quadragesimal, quinquagesimal, sexagesimal, septuagesimal, octogesimal, nonagesimal}
{un-, duo-, tri-, tetra-, penta-, hexa-, hepta-, octo-, enea-}
Note that there should be no "p" in "setenrio". Feminine: Replace "-rio" with "-ria", leave "-al" unchanged. Plural: "-rios" (m.), "-rias" (f.), "-ais" (for "-al").

DE
{unr, binr, ternr, quaternr, quinr, senr, septenr, oktal, nonr}
{dezimal, vigesimal, trigesimal, quadragesimal, quinquagesimal, sexagesimal, septuagesimal, oktogesimal, nonagesimal}
{un-, duo-, tri-, tetra-, penta-, hexa-, hepta-, okto-, ennea-}
Not even going to attempt to describe how adjective declension in German works, because it depends on gender, number, case, and the presence of a definite or indefinite article. The possible endings are {-e, -er, -en, -em, -es}, which can just be added onto these words directly. In many cases, the adjective is compounded with the noun it modifies, and the entire word is treated as a noun and capitalized accordingly: "Duodezimalsystem", "Oktalzahlen".


Posted by: Oschkar Dec 4 2016, 06:28 AM
QUOTE (icarus @ Dec 1 2016, 05:38 PM)
Oschkar,

If you translate one of the more complete tour pages (not the Travelogue), I would also furnish a Spanish-language version at some point. Priority is to get this thing online, but also am interested in alternate pages for different languages. There is no deadline and completely voluntary. Of course would attribute you as the translator. I know Spanish but I am afraid of Engrishizing it. I am fluent in Italian and still would not endeavor the translation.

I will be able to translate it in a couple of weeks, maybe around the 16th. Do you mean one of the tour pages that are here on the forum, or do you have any "new and improved" tour pages to translate?

Posted by: icarus Dec 4 2016, 04:02 PM
Oschkar,

There is no big rush. If you translate one here I will inform the program in Spanish the same way. The problem is that I am using a lot of randomization so the same passage might never come out the very same way, just so that the tour is not monotonous.

A big thank you to you! I have finished segments A1 and A2. Here are a few A1s and an A2:

[doHTML]

Thank you for any work you do. I will credit you.

Posted by: Double sharp Dec 4 2016, 05:03 PM
QUOTE (Oschkar @ Dec 4 2016, 06:27 AM)
To be fair, the Lamadrid convention seems like a reasonable extension of the already standard terms "undecimal", "duodecimal" and "hexadecimal".

I agree: particularly with "hexadecimal", it seems that the natural thing to do is to make most of the units digits Greek instead of Latin, especially because a purely Latin construction for 18 and 19 would infuriatingly flip the order to "decenoctonary" and "decennoval".

I think "undeca" and "duodeca" are more well-known than any of the other names. (Though I still think base-16 should have been "sedecimal" or "senidenary".) I know there is a feeling in mathematics and science that we shouldn't mix Greek and Latin roots (this is why the IUPAC systematic names are not actually used much in the field; you will not hear "ununennium", you will hear "element 119"), which explains the rising popularity of "enneagon" over "nonagon". However, I think it's unavoidable with the popularity of hexadecimal.

The Latin language is set in stone at this point, but when we borrow words from it and Greek, I think we can change things around to make them more logical from a modern perspective. The thousands-hundreds-units-tens order is a bit weird, but if German deals with it, I think we're fine.

Posted by: icarus Dec 5 2016, 12:19 AM
I've started to write support for Spanish number words by modifying the English code. The convention for Spanish will be used as well.

There will always be purists, but I think the average speaker (at least here in the States) couldn't tell you Latin from Greek; they only know "hexa" evokes sixfoldness, "octo" eightfoldness, etc. the term hexadecimal may be unfortunate for its mashing the classics but it is entrenched now.

I agree with oschkar's observation about Lamadrid resembling extant words; indeed that was the point-to eliminate talking robospeak and make words that sound like they already had existed.

Posted by: Oschkar Dec 5 2016, 01:07 AM
QUOTE (icarus @ Dec 5 2016, 12:19 AM)
I've started to write support for Spanish number words by modifying the English code. The convention for Spanish will be used as well.

I just looked at a couple of websites in Danish, Dutch, Swedish, Polish, Czech and Russian that mention number bases. It seems that the Germanic languages I mentioned can use the Lamadrid convention directly, though Dutch in particular also accepts native names that take the name of the number and add the suffix -tallig. The Slavic languages in my list don't usually use Latin names for bases, but native words derived from the collective form of the number with the suffix -ичный (RU), -kowy (PL), -kov (CZ).

I don't know enough about these languages to create a suitable set of base names for them, though.

Posted by: wendy.krieger Dec 5 2016, 02:41 AM
Do you think of something like the number of regulars a base has under some power. I gave formulae for some of these.

eg a* ln^2(12)/ln(2)ln(3) - 2 for 12,

Posted by: Oschkar Dec 5 2016, 03:08 AM
Im not going to attempt to localize the Systematic Dozenal Nomenclature because the consonant clusters it creates tend to go against Romance phonotactics. As for the rest, Ill have to read up on number theory in Spanish... I dont know a lot of the terminology, except for the basics...

Posted by: Double sharp Dec 5 2016, 03:33 AM
This may not be quite as bad a problem as it could be because the IUPAC systematic names are invariant across languages (apart from the ending -ium, which in Italian for example becomes -io). French has no problem with https://fr.wikipedia.org/wiki/Unpenttrium, although I would say "l'lment 153", just like I would in English.

The IUPAC systematic names have certainly become popular among laymen, but scientists almost never use them. In the scientific literature, eka-actinium (in group IIIA) is "element 121", with symbol "(121)".

Posted by: Oschkar Dec 5 2016, 04:16 AM
QUOTE (Double sharp @ Dec 5 2016, 03:33 AM)
This may not be quite as bad a problem as it could be because the IUPAC systematic names are invariant across languages (apart from the ending -ium, which in Italian for example becomes -io). French has no problem with https://fr.wikipedia.org/wiki/Unpenttrium, although I would say "l'lment 153", just like I would in English.

The IUPAC systematic names have certainly become popular among laymen, but scientists almost never use them. In the scientific literature, eka-actinium (in group IIIA) is "element 121", with symbol "(121)".

True, but Id assume that a monolingual Italian would have a lot of trouble trying to pronounce "unseptquadio", with its three consecutive plosives. Do Italians even say "ununseptio", or is it assimilated as "ununsettio"?

Posted by: icarus Dec 5 2016, 04:18 AM
Wendy I do have a reasonably fast discrete method for counting regulars. It's good to about primorial p_8 = 9,699,690, will incorporate the counts in the register. I mostly counted regular figures i.e., regular numbers with all multiples of base boiled out. Example is decimal 25. All numbers that start with 25 and are followed by zeros (i.e., 25, 250, 2500, etc.) have the regular figure 25. This is just "shorthand" for all the regulars a base has. The number of figures is finite for primes (1) and prime powers (1, p, p^2, ..., p^k) whereas the number of regulars is otherwise infinite. For squarefree semiprimes the number is finite for a certain richness (you say ripple). For instance, ten has (1) for richness 0, (2,5) for richness 1, (25,4) for richness 2, thus 2 per level hereinafter. The number of regular figures increases with richness for numbers with more than one prime divisor and at least one prime divisor with multiplicity greater than 1. I have also determined for terms for the regular record setter sequence but have not updated it, using the regular counting function. Yes it would be interesting and it should be part of the effort.

Posted by: Double sharp Dec 5 2016, 04:28 AM
QUOTE (Oschkar @ Dec 5 2016, 04:16 AM)
QUOTE (Double sharp @ Dec 5 2016, 03:33 AM)
This may not be quite as bad a problem as it could be because the IUPAC systematic names are invariant across languages (apart from the ending -ium, which in Italian for example becomes -io). French has no problem with https://fr.wikipedia.org/wiki/Unpenttrium, although I would say "l'lment 153", just like I would in English.

The IUPAC systematic names have certainly become popular among laymen, but scientists almost never use them. In the scientific literature, eka-actinium (in group IIIA) is "element 121", with symbol "(121)".

True, but Id assume that a monolingual Italian would have a lot of trouble trying to pronounce "unseptquadio", with its three consecutive plosives. Do Italians even say "ununseptio", or is it assimilated as "ununsettio"?

The article on Italian Wikipedia is at https://it.wikipedia.org/wiki/Ununseptio. You can also hear on Rai http://www.raiscuola.rai.it/articoli/lununseptio/26309/default.aspx saying "ununseptio" with a clear "p", as well as "ununoctio" with a clear "c".

EDIT: Hmm, 626 posts, on the 225th death anniversary of Mozart...

Posted by: icarus Dec 5 2016, 04:29 AM
Half a life ago at age eleventeen I lived in Italy and had a girlfriend there named Mara. I adored her. She was lovely but troubled, older than me. I was essentially her property. She drove around all over with me. To soothe her we would sing along to the songs on the radio all over Tuscany and some Whitney Houston song came on. "Oddio Maicol mi piace tanto tanto questa canzone!" She loved the song. So she asked what the name of the singer was, "tanto difficile pronunciare". So hard to say. "Veetenee oosetawneh" was the closest she got. Some of SDN's concoctions are not easy to pronounce in Italian is all I can say.

Posted by: Double sharp Dec 5 2016, 10:28 AM
I don't think the butchering is important if it is intelligible and close enough from the spelling. There is no problem at all with the Japanese readings ミクロ mikuro and フェムト femuto for SI "micro-" or "femto-". So what does it matter if SDN "septqua" comes out as seputokuwa? It's still understandable.

Posted by: icarus Dec 5 2016, 02:59 PM
My opinion is that SDN is what it is "objectively"; how it is locally pronounced is not something we can control. The Lamadrid system by contrast was intended to build a scalable "vernacular" base name system. Thus I think SDN remains as is but we should attempt, in any language we support, to build base names that seem already part of that language.

Posted by: icarus Dec 5 2016, 03:59 PM
Wendy:

Added it! (see the register http://z13.invisionfree.com/DozensOnline/index.php?showtopic=621&view=findpost&p=40002492).

Posted by: Kodegadulo Dec 5 2016, 04:20 PM
In modern Greek (I'll transliterate): kilometer is khiliometro, literally "thousandometer"; centimeter is ekatostometro, literally "hundredthometer"; millimeter is khiliostometro, literally "thousandthometer". So there is some precedent for taking a lot of liberty with a prefix system originally designed for another language (in this case, French). (Do we really believe the French Metricists were thinking of anybody other than gallophones? I bet they were expecting Academy French to be everybody's lingua franca ad infinitum.)

SDN really only tried to cater to English, but we kind of expect other languages will take some liberties with its pronunciation.

Posted by: Double sharp Dec 24 2016, 01:29 PM
I had a bit of time, so I did another mid-scale "guest post": here's http://z13.invisionfree.com/DozensOnline/index.php?showtopic=1597.

There's not really that many other bases that I think are particularly interesting to cover above 60. The exceptions are {168} (as the tetradecimal "twelfty") and {180} (as another step in Robin's inequality), but they are really too big. Perhaps {336} would be nice as well to complete the sequence of http://math.univ-lyon1.fr/~nicolas/ramanujanNR.pdf up to 360.

Below 60, we might benefit from the addition of the bases {22, 26, 27, 32, 45, 50}, as well as of course the fundamental {2, 3, 4}.

Posted by: Oschkar Dec 27 2016, 11:22 PM
Another Mathematica request, icarus:

Can you calculate e^gamma*n*ln(ln(n))/sigma(n), where gamma is the Euler-Mascheroni constant and sigma(n) is the sum-of-divisors function, for all n from 2 to 60480, and post the values of n such that that function gives a result less than 5/4?

Posted by: Oschkar Dec 29 2016, 01:06 AM
Never mind; I did it in Python in a few minutes. The earliest bases in my list not yet covered by the Tour are 180 (already suggested by Doublesharp), and the three-digit alternating bases 2520, 5040 and 1680. Discarding bases larger than 840 thereafter, we have 168 (the tetradecimal long-hundred analogue), 480 (a traditional ream of paper), 504, 540 (one and a half turns), 252, 336 (the tetradecimal 240 analogue), 600 (two metric feet), 300 (a metric foot) and 216 (the senary thousand). Out of these, only {216, 252, 300} arent largely composite, though they are incredibly convenient numbers that would have widespread uses as auxiliary bases.

CODE
(0, -inf),
(1, -inf),
(2, -0.4351907024566895),
(3, 0.1256294938049997),
(4, 0.3324338692674033),
(6, 0.5193590079534068),
(12, 0.6947976937198777),
(8, 0.6954250622543046),
(5, 0.7063213660937592),
(24, 0.8237595340350533),
(10, 0.8252623244111414),
(18, 0.8724940521021748),
(60, 0.8966469707750959),
(36, 0.8993129699906918),
(30, 0.9084415828523706),
(120, 0.9297237382184487),
(20, 0.9305583483573915),
(48, 0.9332117136873619),
(16, 0.9374475334817786),
(72, 0.955645922168925),
(180, 0.967241667975146),
(9, 0.97065091152207),
(360, 0.9714211873353387),
(240, 0.9774190393054649),
(2520, 0.9869564831528942),
(840, 0.990689138028166),
(84, 0.9942284280532165),
(5040, 0.9944717499826147),
(720, 0.9991264395676062),
(420, 1.0009884030130405),
(1680, 1.007988530141842),
(14, 1.0082283565958516),
(1260, 1.0098444687844825),
(10080, 1.014385392865832),
(55440, 1.017031241946323),
(168, 1.0185506536412827),
(144, 1.0204132800891055),
(27720, 1.0221147099224563),
(7560, 1.0236539502517605),
(15120, 1.0244534419976108),
(42, 1.0273711320299845),
(480, 1.02924063349412),
(96, 1.0301558124571957),
(90, 1.0303059357734239),
(40, 1.0332774802244378),
(1440, 1.03554610947116),
(3360, 1.0361352904051313),
(7, 1.0374988780229564),
(1080, 1.038574163968858),
(30240, 1.0391601774844972),
(20160, 1.0392469286011672),
(25200, 1.040053197716099),
(12600, 1.0418457274652713),
(32760, 1.042601409605724),
(504, 1.0519798537643514),
(50400, 1.052782605677129),
(540, 1.0529251399143578),
(18480, 1.0529349862004858),
(9240, 1.0531920146092764),
(2160, 1.0539968227915038),
(252, 1.05431000605604),
(3780, 1.0563011460182148),
(60480, 1.0597032950898435),
(108, 1.060535543789161),
(13860, 1.062079791253483),
(3960, 1.0621395431253293),
(336, 1.0622338669655944),
(45360, 1.0644912616285656),
(37800, 1.0656024853699857),
(40320, 1.0656787792446576),
(600, 1.0662408035679),
(4200, 1.0664764054509657),
(7920, 1.0669420516567318),
(36960, 1.0671403256721155),
(6720, 1.0681856289274623),
(1800, 1.0682766840513145),
(22680, 1.0689878620794515),
(35280, 1.0707573994918167),
(8400, 1.0709026494840077),
(300, 1.0718010870840695),
(28, 1.0718797484531981),
(42840, 1.0719607117565775),
(1320, 1.073221955060826),
(17640, 1.0741836103228024),
(21840, 1.0744803937858967),
(2880, 1.0745338380025542),
(10920, 1.0756149501471686),
(1008, 1.076857133894279),
(6300, 1.07835204205717),
(216, 1.078353382074721),
(3600, 1.0792095281408574),
(960, 1.0808263306839587),
(4320, 1.0812507096478574),
(47880, 1.0829925384183423),

Posted by: Double sharp Jan 3 2017, 01:46 PM
Icarus covered 504 in the "Random Bases" thread, so I did some minor touching up of it to make it a http://z13.invisionfree.com/DozensOnline/index.php?showtopic=1610.

Truth be told, though, I think most large bases only need to show the digit map (possibly through an application) with not much of a travelogue, since most people would not seriously consider them as bases. They don't seem to cry out very much for full threads. I made an exception for 504 because it was really easy to copy and paste from Icarus' work and because it is the tetradecimal analogue to 360 (so our heptadactyl civilisation would have "280" degrees to a circle). This makes for nice fractions that look very much like the base-360 fractions of a circle:

{e}
1/2 = 140
1/3 = c0
1/4 = 90
1/6 = 60
1/7 = 52
1/8 = 47
1/9 = 40
1/c = 30
1/10 = 28
1/12 = 23.7
1/14 = 20

But really, I think the highest priorities would be to get bases {2, 3, 4} out. I'd try to do them myself but I presume Icarus has plans for them. Still, I dislike seeing them unfinished when they are the among most important, which I think is the range between 2 and 20 inclusive. Indeed 2 and 3 have a lot to talk about, but is 4 really that much of a problem?

{a}
The interesting thing is that not only do the decimal-friendly {60, 120, 180, 240, 300, 360, 420, 480, 540, 600} look familiar to me, but so do the tetradecimal-friendly {84, 168, 252, 336, 420, 504, 588, 672, 756, 840}. The ones with elevens and thirteens look alien, but somehow the seven doesn't make even the higher {1008, 1176, 1260, 1344, 1512, 1680, 1764, 2016} look that odd. I guess one could interpret it as 7 becoming a normal part of factorisation in the hundreds and thousands, but maybe it's not just that: 54 and 56 look about equally friendly to me in a way that 52 doesn't. Maybe the increased "warmth" coming from 7 as opposed to 11 or 13 is because 7 is a digit and so one is acquainted with its products in the decimal table, and also because it is of about the same scale as 5. But I wonder if tetradecimalists would recognise multiples of b or d in the same way.

I've posted about it http://z13.invisionfree.com/DozensOnline/index.php?showtopic=1281 (so I'll freely borrow my own words), but I tend to mentally imagine the digit map as a corridor of varying length and with no escape (once you go past the last digit, you carry and wrap around to the first). It has lamps hanging at the divisors, and some more poorly illuminating candles flickering at alpha- and omega-related totatives. With a human-scale base, we have to have one or two dark spots (octal 5, decimal 7, duodecimal 5 and 7, tetradecimal 9 and b), but those are few enough in number that we can work around them; we can walk through them, without a need to feel our way around because we should know that region well enough, and come out safely on the other side. (In the case of duodecimal 5 and 7, because there's a strong light at 6, we can simply avoid 5 and 7 whenever possible.)

But when we get to hexadecimal, even though we're mostly in the light for the first half of the digit range, we're blundering around in the dark for most of the top half thanks to the opaque totatives {7, 9, b, d} and opaque semitotative {e}. By the time we get to sexagesimal, even though we have many regular digits that are inviting and usable, there are many stretches where we're reduced to blundering around in the dark (e.g. {41, 42, 43, 44}), because most numbers are not 5-smooth. In base 360, what seems to happen in that extremely long corridor is that we attempt to make a break for it and run from 200 to 216 (the next lamp), and trip over and fall flat on our face around 209.

I think many of the "grand bases" and even the higher natural-scale and mid scale, would tend to need rather shorter tours. I don't think the human mind can actually stay up there and wield pure base 24, let alone 120. We have to break the span and use sub-bases, which is just not the same as real base 24 or base 120, any more than binary is the same as octal or hexadecimal, and is much more complicated and would rather quickly be rejected by the general public (if not ourselves). I think the "human-understandable" range is the one that gets the high-pass coverage and is around two to twenty (I say twenty because it has been civilisational, though only in the past when what was needed of a base was much less strict, and might get defenders from misplaced nationalism or decimal compatibility).

Even further, when push comes to shove, the ones past 15 have a learning horizon problem, the ones below 7 have a number length problem, so while we can stay there longer we eventually need to pull out. It's like trying to sing at the very top or bottom of one's range for a while: it will work for a while (the human voice, just like the human mind, is amazingly tolerant of inefficient usage), but soon it will hurt. Furthermore, using an odd number base seems to be rather alien to our thinking because of the extreme importance of two as a prime. But when we get to {8, 10, 12, 14} part of me thinks that one could not only have a tour, but also an entire constructed world. Consider all the symbolism associated with the decimal digits, after all. How would that change? Would 7 still be a special, sacred number in tetradecimal when it's a divisor? What would take its role? (I suspect b would.) The richness available there is incredible and is, with the exception of decimal (obviously), almost totally unexplored. How would things be different with eight, twelve, or fourteen as a base?

It's an intriguing thought and perhaps comes closest to the idea of having a "tour".

Posted by: Oschkar Jan 3 2017, 10:56 PM
QUOTE (Double sharp @ Jan 3 2017, 01:46 PM)
But when we get to {8, 10, 12, 14} part of me thinks that one could not only have a tour, but also an entire constructed world. Consider all the symbolism associated with the decimal digits, after all. How would that change? Would 7 still be a special, sacred number in tetradecimal when it's a divisor? What would take its role? (I suspect b would.) The richness available there is incredible and is, with the exception of decimal (obviously), almost totally unexplored. How would things be different with eight, twelve, or fourteen as a base?

Ive actually been thinking about this. Notice that the numbers that have the most mystical symbolism associated with them are the smallest opaque coprimes of decimal: 7 and 13. Of course, 7 also gets its sacred quality from the fact that, mostly, only seven Solar System bodies can be seen with the naked eye from Earth, but the fact that there are seven, and not six or eight, seems to have been significant to many ancient cultures.

In an octal conworld, Id assume that most of this kind of symbolism will be associated with the "teens". The only single-digit opaque totative of octal is 5. Im not entirely sure what 5 would correspond to (maybe the planets, excluding the Sun and the Moon?), but there already seems to be a sort of symbolism associated with the pentagram and fivefold symmetry that we dont seem to give much importance to, as a decimal culture. Id imagine that in an octal world, the mystical significance of 5 would be seriously emphasized, with 13, 15 and 17 not too far behind.

Duodecimal has both 5 and 7 as opaque totatives, both leaning against the halfway point. Id imagine here that 5 and 7 would be seen as opposite in spirit, but exactly what the nature of the opposition is will probably be culturally dependent. Maybe 3 will represent the mundane and 7 the heavenly, with 5 being humanity mediating between them, the head and the limbs adding up to 5.

Tetradecimal has both 5 and 7 transparent; the two opaque totatives are 9 and b. By itself, 9 doesnt seem exclusively mystical because its 3 sets of 3, but Im sure that there will be some mythological explanation for its opacity anyway. On the other hand, b is completely inaccessible, and will probably be considered even more mysterious than 7 currently is in decimal.

Posted by: Double sharp Jan 4 2017, 06:08 AM
In the West this sort of thing seems to correlate pretty well with the relations of the numbers to the base, while in the East it seems to simply run on what the numbers sound like. (Hence the non-stop tetraphobia which I find incredibly annoying given how omnipresent it is. It is so often and consciously avoided that I've somewhat made it a trolling point IRL ever since I first read about it as a child to include the digit 4 as much as possible whenever it can be chosen for my own things, especially in forms such as 94 "long death", 84 "prosperity [then] death", 74 "death in anger", 14 "easy death", and 64 = 4 * 4 * 4.)

Part of this seems to overlap with more mathematically based reasons, but it can always be taken both ways. In Japan odd numbers are preferred because the evens can be seperated, but in China even numbers are preferred because good things supposedly tend to double. Nine is somewhat equivocal in Japan, because while it is odd, it is also 3*3 (but that usually gets thought of as lucky) and a homophone of "suffering". Somehow eight is lucky despite being even, perhaps because its kanji widens at the bottom (good things multiply, although that seems more like the Chinese version). Four just can't get a break because not only is it even, it also sounds like "death".

I think the first one gives more secure speculation because the second one would require word-construction for the transdecimals. Still, I do think the highest digit would gain some of the symbolism associated with 9 in Chinese culture today (so 7 in octal, b in duodecimal, and d in tetradecimal). In general, though, the homophonous thing may be more relevant for your tetradecimal conlang. happy.gif

Even among the two-digit numbers, it seems that a few get selected and it's hard to tell why. Why 23 and 47 instead of 29 and 41, for instance? Then you have 42 which was selected for looking unremarkable. I cannot begin to imagine how something like this could be ported to tetradecimal, so I think the heptadactyl conworld would need to choose some random numbers from scratch. (EDIT: Perhaps their "answer to the universe" would be an innocuous-looking opaque semitotative product in the line of six as well, so that we might instead get six times eleven, or 4a{e}.)

We would also have different bases being mentioned, perhaps fictionally. Somehow tetradecimal itself is unpopular, but in the heptadactyl conworld I think octal and duodecimal would be common choices (as would perhaps be hexadecimal), with decimal perhaps being a niche and clever choice falling in a sort of uncanny valley of similarity (2*5 vs 2*7). Perhaps the powers-of-two bases would feel "modern" and the highly divisible "c" would feel a little more old-timey, which is the impression I usually get about the views of most people who know a little about this about octal or hexadecimal vs duodecimal (it's a superficial opinion that isn't really true, even though there are legitimate reasons to prefer either eight or twelve as a base). And of course, we'd see octovigesimal vestiges (counting fingers and toes).

Posted by: Double sharp Jan 5 2017, 08:47 AM
The classification I'm currently thinking of works like this.

Trivial-scale: {2, 3}. The most fundamental of all number bases. Totally unsuitable for human use in everyday life, but very suitable for machines (hence binary and ternary computing).

Lower natural-scale or small-scale: {4, 5, 6, 7}. Slightly too small to effectively use Stevin's algorithms (because the numbers of digits spiral out of hand), but could be wielded almost as efficiently as the natural-scale bases through tricks like reformulating the multiplicands as sets of instructions and trying to think of two or three digits at a time.

Natural-scale: {8, 9, 10, 11, 12, (13), 14, 15}. (I give tridecimal the benefit of the doubt because at least its magnitude is reasonable, even if the difficulty of its facts is completely unreasonable.) This is the most efficient possible range, the "valley", where you want to settle down and build your civilisation up to today's level of technology. Of these, the even {8, 10, 12, 14} stand out as the most practical bases for a human-like civilisation, although very alien beings might also consider the odd and divisible {9, 15}.

Higher natural-scale or lower mid-scale: {16, 18, 20, 24, 28, 30}. These are the bases which are "too fast to walk, too slow to run". You can't use an alternating-base or reciprocal-divisor system on such bases because it's too slow, but you can't memorise the full tables. (The reason why it's also called the "higher natural-scale" is because the boundaries are fuzzy: the tables of {16, 18, 20} may be reachable by dedicated mnemonists.)

Mid-scale: {32, 36, 40, 42, 48, 50, 54, 56, 60}. These have passed out of the range of thinking of every digit as somehow "equal", but thinking using sub-bases and using complementary divisors or sub-bases work fairly well.

Higher mid-scale or lower large-scale: {64, 70, 72, 80, 84, 90, 96, 100, 108, 112, 120}. Now the complementary divisors themselves and the products you need to remember in the abbreviated multiplication table are starting to become "too fast to walk, too slow to run", and we are starting to need to use sub-bases instead (which works fairly well if you can keep track of both tables, but isn't really using the base; for instance, base 120 is really different from alternating 12 and 10, just like hexadecimal is not binary). These are starting to fall out of the realm of arithmetic and at best may be considered auxiliaries, though the ones up to 84 seem feasible for arithmetic. (That's why the boundaries are fuzzy.)

Large-scale: {144, 160, 168, 180, 192, 196, 210, 216, 240, 252}. This is about the limit of thinking about using two sub-bases. Beyond this, the bases are usable only as auxiliaries.

Higher large-scale: {300, 336, 360, 420, 480, 504}. Essentially, the main reason why you pick a base in this range is to harmonise with the number of days your planet has in a year.

Extra-large-scale: {540, 600, 630, 660, 672, 720, 840, 960}. The higher ones are getting even too fine to use as auxiliaries: once you need to use this kind of precision, you'll probably resort to powers of the base. The exceptions may be things like 672 (the tetradecimal version of 480) and 660 (which essentially is the only good choice for an undecimal auxiliary base).

Grand-scale: Everything else. Among lower grand bases we have things like {17, 19, 22, 23, 25, 26, 27, 29, 31}, which are in the same scale as the higher natural-scale but don't have any factors to help them and just fall out of usability. Among higher grand bases you have numbers like {1080, 1260, 1440, 1680, 2160, 2520, 3360, 3780, 3960, 4200, 4320, 4620, 4680, 5040}, where the number of factors is amazing, but the numbers are just too great and require too much effort to use even as auxiliaries (since they won't harmonise well with any natural-scale base).

Posted by: Double sharp Jan 31 2017, 08:20 AM
@Icarus: would you mind adding my new "guest posts" for bases http://z13.invisionfree.com/DozensOnline/index.php?showtopic=1631, http://z13.invisionfree.com/DozensOnline/index.php?showtopic=1597 and http://z13.invisionfree.com/DozensOnline/index.php?showtopic=1610 to the tour menu thread?

The ones I'm most interested to see your posts for at the moment are {22, 26, 27}, which seem to want the most engaging travelogues. I would also once again suggest {168, 180} as two of the most important grand bases (though some of Oschkar's suggestions are also very interesting.)

Posted by: Double sharp Feb 5 2017, 04:50 PM
What Bases Might be Included Past the Human Scale?

Looking at what bases (except for prime detectives) are already included in the tour, it seems to me that up to 36, we need at least five divisors:

Five divisors: 16 (tess)
Six divisors: 18 (dine), 20 (score), 28 (cadeff), 32 (twive)
Eight divisors: 24 (cadex), 30 (kinex)
Nine divisors: 36 (exent)

And up to 64 we need at least seven (I'm planning a guest post for 64):

Seven divisors: 64 (twex)
Eight divisors: 40 (kinoct), 42 (exeff), 54 (exove), 56 (sevoct)
Ten divisors: 48 (exoct)
Twelve divisors: 60 (shock)

And then up to 120 we need at least nine:

Nine divisors: 100 (kent)
Ten divisors: 80 (octess), 112 (setess)
Twelve divisors: 72 (octove), 84 (sezzen), 90 (novess), 96 (extess), 108 (catrine)
Sixteen divisors: 120 (hund)

There have then been so many numbers with 12 divisors that to continue, we seem to need at least fifteen up to 240:

Fifteen divisors: 144 (zenent)
Sixteen divisors: 168 (cadexeff), 210 (zeffchick), 216 (excue)
Eighteen divisors: 180 (scorove)
Twenty divisors: 240 (kinexoct)

and at least eighteen past that:

Eighteen divisors: 252 (zentress), 288 (notwive), 300 (zenquint)
Twenty divisors: 336 (exsevoct)
Twenty-four divisors: 360 (kinoctove)

and 360 is so hard to beat that in the range past that we really need to match it:

Twenty-four divisors: 420 (exsevess), 480 (exodess), 504 (sevoctove), 540 (exovess), 600 (cadexquint), 630 (senovess), 660 (exdessell), 672 (exeftess)

before we finally beat it.

Twenty-eight divisors: 960 (zenodess)
Thirty divisors: 720 (octovess), 1008 (senotess)
Thirty-two divisors: 840 (seveszen), 1080 (noveszen)

And now, only the actual largely composites seem to stay interesting, as the lanterns in Oschkar's http://z13.invisionfree.com/DozensOnline/index.php?showtopic=1281&view=findpost&p=40003345 flicker out and leave us groping in the dark.

Thirty-six divisors: 1260 (scorsenove), 1440 (novestess)
Forty divisors: 1680 (sechitess), 2160 (kintestrine)

And finally, all the companions of kinsevoctove:

Forty-eight divisors: 2520 (kinsevoctove), 3360 (sechitwive), 3780 (scorsetrine), 3960 (kinoctovell), 4200 (exsekent), 4320 (kintwivetrine), 4620 (exsevessell), 4680 (kinoctovithe)

before we exit to the roof of the skyscraper.

Sixty divisors: 5040 (sevoctovess)

All these are just "gut feelings", of course, fuelled by possibly inappropriate extrapolation.

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)