
icarusDozens Demigod
 Joined: 11 Apr 2006, 12:29
The tour is expanded to cover the "prime detective" bases 34, 55, and 99. Check out the tour menu for other recentlyadded bases like 17 and 19. This covers the "prime detectives" {15, 21, 34, 55, 99, 120, ...} and the primes {5, 7, 11, 13, 17, 19, ..., 173}.

PiotrGrochowski
Oh, i need a link for base 3!icarus @ May 1 2012, 05:04 PM wrote:

icarusDozens Demigod
 Joined: 11 Apr 2006, 12:29
I've updated the Multiplication Synopsis 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).
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).

Piotr
Posting it in category NonDozenal bases is completely misleading. This topic also describes bases larger than 60, so it would be better to post it in General category.

KodegaduloObsessive poster
 Joined: 10 Sep 2011, 23:27
Piotr, "Thread Necromancy"  bringing a longdead 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.)Piotr @ Aug 9 2015, 07:02 PM wrote: Posting it in category NonDozenal bases is completely misleading. This topic also describes bases larger than 60, so it would be better to post it in General category.
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.
As of 1202/03/01[z]=2018/03/01[d] I use:
ten,eleven = ↊↋, ᘔƐ, ӾƐ, XE or AB.
Baseneutral base annotations
Systematic Dozenal Nomenclature
Primel Metrology
Western encoding (not by choice)
Greasemonkey + Mathjax + PrimelDozenator
(Links to these and other useful topics are in my index post;
click on my user name and go to my "Website" link)
ten,eleven = ↊↋, ᘔƐ, ӾƐ, XE or AB.
Baseneutral base annotations
Systematic Dozenal Nomenclature
Primel Metrology
Western encoding (not by choice)
Greasemonkey + Mathjax + PrimelDozenator
(Links to these and other useful topics are in my index post;
click on my user name and go to my "Website" link)

Double sharpDozens Demigod
 Joined: 19 Sep 2015, 11:02
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:icarus @ Jun 19 2013, 09:09 PM wrote: 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 cutup 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.
{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 {230}. {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.

Double sharpDozens Demigod
 Joined: 19 Sep 2015, 11:02
As a first try at a "guest post" (since I haven't seen many very new entries on the tour), I've done base 40. Hopefully it's OK and I didn't miss anything very important.Double sharp @ Oct 17 2015, 04:47 AM wrote: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:icarus @ Jun 19 2013, 09:09 PM wrote: 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 cutup 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.
{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 {230}. {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.
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}.

wendy.kriegerDozens Demigod
 Joined: 11 Jul 2012, 09:19
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 7smooth approximation to pi, using numbers under 10^9.
So the ripple13 here contains in effect, pi, 2pi, 4pi, 56/pi, 28/pi and 14/pi.
Also, Icarus has been copying the sevenite entries into his tourdebases, 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
where 113 * 929 = 18^4 +1.
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 7smooth approximation to pi, using numbers under 10^9.
So the ripple13 here contains in effect, pi, 2pi, 4pi, 56/pi, 28/pi and 14/pi.
Also, Icarus has been copying the sevenite entries into his tourdebases, 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: Select all
[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
Twelfty is 120 dec, as 12 decades. V is teen, the '10' digit, E is elef, the '11' digit. A place is occupied by two staves (digits).
Digits group into 2's and 4's, and . , are comma points, : is the radix.
Numbers writen with a single point, in twelfty, like 5.3, means 5 dozen and 3. It is common to push 63 into 5.3 and viki verka.
Exponents (in dec): E = 10^x, Dx=12^x, H=120^x, regardless of base the numbers are in.
Digits group into 2's and 4's, and . , are comma points, : is the radix.
Numbers writen with a single point, in twelfty, like 5.3, means 5 dozen and 3. It is common to push 63 into 5.3 and viki verka.
Exponents (in dec): E = 10^x, Dx=12^x, H=120^x, regardless of base the numbers are in.

Double sharpDozens Demigod
 Joined: 19 Sep 2015, 11:02
I added a note about quadragesimal Wieferich primes (following Icarus' new preference in terminology).wendy.krieger @ Oct 17 2015, 12:01 PM wrote: 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 7smooth approximation to pi, using numbers under 10^9.
So the ripple13 here contains in effect, pi, 2pi, 4pi, 56/pi, 28/pi and 14/pi.
Also, Icarus has been copying the sevenite entries into his tourdebases, 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
where 113 * 929 = 18^4 +1.Code: Select all
[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
I can see that 40^{8} + 1 has many factors, but these are such highrank neighbours that I am not sure it is significant enough to mention. 10^{3} + 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 squareneighbours.
Next up will be {54, 56, 64}.
EDIT: Could you link to that thread on {54, 56}? I seem to have missed it.

icarusDozens Demigod
 Joined: 11 Apr 2006, 12:29
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).
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).

Double sharpDozens Demigod
 Joined: 19 Sep 2015, 11:02
You're welcome! Next will be {54, 64} as promised. I intend to return to {32, 50} also to complete the binarypower range and the even numbers flanked by composites up to 64.icarus @ Oct 19 2015, 02:37 PM wrote: 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).
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 highpass 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 6^{3}. But this is a job for automation! I wouldn't dare try for any but the lowest two, {180, 216}.

icarusDozens Demigod
 Joined: 11 Apr 2006, 12:29
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 3dimensional 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 ndimensional simplex, not the ndimensional 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 htmlwriting 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 selfcontained approach.
Might take a break and write a regularnumber  fraction table algorithm as seen at pentadecimal.
EDIT: regularUnitFraction function done. Just raw data:
Output:
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 3dimensional 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 ndimensional simplex, not the ndimensional 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 htmlwriting 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 selfcontained approach.
Might take a break and write a regularnumber  fraction table algorithm as seen at pentadecimal.
EDIT: regularUnitFraction function done. Just raw data:
Code: Select all
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
Code: Select all
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

icarusDozens Demigod
 Joined: 11 Apr 2006, 12:29
Here is a roster of canonical colors used in the tour, extracted with the following code:
The first group {d, dc, di, u, gi, gc, g} is the regular group. Positions 13 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 alpharelated semicoprime, Position {2, 2} codes alphaomega semicoprime, position {3, 3} codes omegarelated semicoprime. Position {4, 4} codes semicoprimes but does not take into account neighborfactor. (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 alphafactor totatives. Position {2, 2} codes alphaomega factor totatives (i.e., digit 2 in odd base). Position {3, 3} codes omegafactor totatives. Position 4 codes long prime totatives. Position 5 codes semimaximal prime totatives. Position 4 codes totatives without distinction. Positions 13 are the "accentuated" versions of {1, 3} when intuitive divisibility tests or simple view (regularsemicoprimetotative) maps are generated.
Code: Select all
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 second, {ha, hb, ho, h, hh, hoi, hbi, hai} is the semicoprime group. Position {1, 1} codes alpharelated semicoprime, Position {2, 2} codes alphaomega semicoprime, position {3, 3} codes omegarelated semicoprime. Position {4, 4} codes semicoprimes but does not take into account neighborfactor. (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 alphafactor totatives. Position {2, 2} codes alphaomega factor totatives (i.e., digit 2 in odd base). Position {3, 3} codes omegafactor totatives. Position 4 codes long prime totatives. Position 5 codes semimaximal prime totatives. Position 4 codes totatives without distinction. Positions 13 are the "accentuated" versions of {1, 3} when intuitive divisibility tests or simple view (regularsemicoprimetotative) maps are generated.

icarusDozens Demigod
 Joined: 11 Apr 2006, 12:29
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 neighborrelated 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.
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 neighborrelated 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.

icarusDozens Demigod
 Joined: 11 Apr 2006, 12:29
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 ifthen sort based on numbertheoretical properties.
Here is an example: base 180 digits:
Getting close to automating entries!

icarusDozens Demigod
 Joined: 11 Apr 2006, 12:29
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.
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.

Double sharpDozens Demigod
 Joined: 19 Sep 2015, 11:02
Is your choice of {180, 216} because I said I found them the most interesting of the notyet 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}.
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}.

icarusDozens Demigod
 Joined: 11 Apr 2006, 12:29
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 prevalidate 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 arithmeticbased but "soft". Regular tests with richness > 34 are considered impractical and labeled such, but still shown.
Neighborfactor 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 primedivisorpowers of n (for n = 12, the "silos" are {4, 3}. Decimally, 4 has a 2richness 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:
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 SPDuseful 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:
Dozenal:
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 rangefolding 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 primedivisorpowers 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 colorcoded 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 autogenerated. The autogeneration 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.
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 prevalidate 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 arithmeticbased but "soft". Regular tests with richness > 34 are considered impractical and labeled such, but still shown.
Neighborfactor 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 primedivisorpowers of n (for n = 12, the "silos" are {4, 3}. Decimally, 4 has a 2richness 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: Select all
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, #] &]]]]
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: Select all
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: AlphaOmega Factor.
30 Semicoprime: Use 2 3 5.
Code: Select all
2 Regular: Divisor.
3 Regular: Divisor.
4 Regular: Divisor.
5 Coprime: Alpha2 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.
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 colorcoded 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 autogenerated. The autogeneration 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.

Double sharpDozens Demigod
 Joined: 19 Sep 2015, 11:02
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.icarus @ Oct 30 2015, 10:31 PM wrote:Yes! (Now I changed it to 641 ; ) )
(Although: why's 256 shaded like the alphaomega compounds? Its test doesn't work that way; it gets the squareomega test, doesn't it?)
That makes sense. Thirty fits well on my phone as well. When doing the divisibility test map for octal I extended it to thirtytwo as 36_{o} is a little weird in octal, but then it went a little off the screen on my phone IIRC.icarus @ Oct 30 2015, 10:31 PM wrote: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 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).icarus @ Oct 30 2015, 10:31 PM wrote: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 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 digitsequences to learn, so it may well be practical (though pretty useless). OTOH, 16 has richness 4 as well, but there are 625 digitsequences to learn, so it's completely impractical (and being two levels up from the highest memorisable binarypower test for 4, the rangefolding algorithm is incredibly baroque and difficult to use).icarus @ Oct 30 2015, 10:31 PM wrote: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 prevalidate 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 arithmeticbased but "soft". Regular tests with richness > 34 are considered impractical and labeled such, but still shown.
Those for 7 would be divisors of (b^6  1) in the worstcase 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 digitsequences we need to remember to use the test, and then impose a threshold beyond which the test is considered impractical.icarus @ Oct 30 2015, 10:31 PM wrote:Neighborfactor 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.
Looking forward to see how this works out  it looks really good even now!icarus @ Oct 30 2015, 10:31 PM wrote:Inherited tests. The algorithm determines impracticality of the regular part and the mutually coprime "silos" of primedivisorpowers of n (for n = 12, the "silos" are {4, 3}. Decimally, 4 has a 2richness 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: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 SPDuseful 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.Code: Select all
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, #] &]]]]
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:Dozenal:Code: Select all
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: AlphaOmega Factor. 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 rangefolding 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 primedivisorpowers of x. Then I'll have the algorithm add the <ul>, <li> tags, catenate the language, etc. and the component will be complete.Code: Select all
2 Regular: Divisor. 3 Regular: Divisor. 4 Regular: Divisor. 5 Coprime: Alpha2 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.
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 colorcoded 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 autogenerated. The autogeneration 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.