Le Tour Des Bases

This forum examines bases other than twelve and less than sixty.
icarus
Dozens Demigod
icarus
Dozens Demigod
Joined: Apr 11 2006, 12:29 PM

Jul 4 2013, 03:40 PM #73

The tour is expanded to cover the "prime detective" bases 34, 55, and 99. Check out the tour menu for other recently-added 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}.
Reply
Like
Share

anirudhk
Casual Member
anirudhk
Casual Member
Joined: Aug 8 2013, 11:58 AM

Aug 24 2013, 05:40 AM #74

Icarus, when will the tours for 2, 3, and 4 be over?

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

Oschkar
Dozens Disciple
Oschkar
Dozens Disciple
Joined: Nov 19 2011, 01:07 AM

Jun 6 2014, 05:15 AM #75

*bump*
Reply
Like
Share

icarus
Dozens Demigod
icarus
Dozens Demigod
Joined: Apr 11 2006, 12:29 PM

Jun 7 2014, 01:02 AM #76

We'll get to them when vacation is over.
Reply
Like
Share

PiotrGrochowski
PiotrGrochowski

Jul 17 2014, 12:20 PM #77

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

icarus
Dozens Demigod
icarus
Dozens Demigod
Joined: Apr 11 2006, 12:29 PM

Nov 19 2014, 10:22 PM #78

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).
Reply
Like
Share

Piotr
Piotr

Aug 9 2015, 07:02 PM #79

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.
Reply
Share

Kodegadulo
Obsessive poster
Kodegadulo
Obsessive poster
Joined: Sep 10 2011, 11:27 PM

Aug 9 2015, 07:23 PM #80

Piotr @ Aug 9 2015, 07:02 PM wrote: 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.
As of 1202/03/01[z]=2018/03/01[d] I use:
ten,eleven = ↊↋, ᘔƐ, ӾƐ, XE or AB.
Base-neutral 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)
Reply
Like
Share

Double sharp
Dozens Demigod
Double sharp
Dozens Demigod
Joined: Sep 19 2015, 11:02 AM

Oct 17 2015, 04:47 AM #81

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 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.
Reply
Like
Share

Double sharp
Dozens Demigod
Double sharp
Dozens Demigod
Joined: Sep 19 2015, 11:02 AM

Oct 17 2015, 09:52 AM #82

Double sharp @ Oct 17 2015, 04:47 AM wrote:
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 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 base 40. 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}.
Reply
Like
Share

wendy.krieger
Dozens Demigod
wendy.krieger
Dozens Demigod
Joined: Jul 11 2012, 09:19 AM

Oct 17 2015, 12:01 PM #83

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: 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
where 113 * 929 = 18^4 +1.
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.
Reply
Like
Share

Double sharp
Dozens Demigod
Double sharp
Dozens Demigod
Joined: Sep 19 2015, 11:02 AM

Oct 17 2015, 01:13 PM #84

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 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: 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
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.
Reply
Like
Share

icarus
Dozens Demigod
icarus
Dozens Demigod
Joined: Apr 11 2006, 12:29 PM

Oct 19 2015, 02:37 PM #85

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).
Reply
Like
Share

Double sharp
Dozens Demigod
Double sharp
Dozens Demigod
Joined: Sep 19 2015, 11:02 AM

Oct 19 2015, 02:51 PM #86

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).
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}.
Reply
Like
Share

icarus
Dozens Demigod
icarus
Dozens Demigod
Joined: Apr 11 2006, 12:29 PM

Oct 27 2015, 05:21 PM #87

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: 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[
 &nbsp; &nbsp; Which&#91;# < 10, # + 48, 9 < # < 36, # + 87, 
 &nbsp; &nbsp; &nbsp; &nbsp;True, # + 29 &#93; & /@ #&#93; &@ IntegerDigits&#91;m, n&#93;&#93;
regularUnitFractions&#91;b_, r_&#93; &#58;= Block&#91;{t = Rest@ regularSet&#91;b, r&#93;},
 &nbsp; Transpose@{enCode&#91;#, b&#93; & /@ t, 
 &nbsp; &nbsp; StringJoin&#91;".", 
 &nbsp; &nbsp; &nbsp; &nbsp;enCode&#91;#, b&#93; & /@ 
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; PadLeft&#91;First@ #, Length@ First@ # + Abs&#91;Last@ #&#93;&#93; &@
 &nbsp; &nbsp; &nbsp; &nbsp; RealDigits&#91;1/#, b&#93;&#93; & /@ t}&#93; // TableForm
Output:

Code: Select all

regularUnitFractions&#91;15, 4&#93;

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
Reply
Like
Share

icarus
Dozens Demigod
icarus
Dozens Demigod
Joined: Apr 11 2006, 12:29 PM

Oct 27 2015, 07:53 PM #88

Here is a roster of canonical colors used in the tour, extracted with the following code:

Code: Select all

colorCode&#91;
  w_&#93; &#58;= {Last@ #, RGBColor&#91;#&#93; &@ Take&#91;#, 3&#93;, 
     StringJoin&#91;
      FromCharacterCode&#91;If&#91;# < 10, # + 48, # + 87 &#93; & /@ #&#93; &@
           If&#91;Length@ # == 1, PadLeft&#91;#, 2&#93;, #&#93; &@
         IntegerDigits&#91;IntegerPart@ Times&#91;#, 256&#93;, 16&#93; & /@ 
       Take&#91;#, 3&#93;&#93;} & /@ 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.
Reply
Like
Share

icarus
Dozens Demigod
icarus
Dozens Demigod
Joined: Apr 11 2006, 12:29 PM

Oct 29 2015, 03:52 PM #89

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.
Reply
Like
Share

icarus
Dozens Demigod
icarus
Dozens Demigod
Joined: Apr 11 2006, 12:29 PM

Oct 29 2015, 09:54 PM #90


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:


Getting close to automating entries!
Reply
Like
Share

icarus
Dozens Demigod
icarus
Dozens Demigod
Joined: Apr 11 2006, 12:29 PM

Oct 29 2015, 10:04 PM #91

Test area: today: Base 224 showing intuitive divisibility tests, regular richness, prime period.

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

Reply
Like
Share

Oschkar
Dozens Disciple
Oschkar
Dozens Disciple
Joined: Nov 19 2011, 01:07 AM

Oct 29 2015, 10:52 PM #92

This is beautiful... Would it be possible for you to share the code so I can test it out?
Reply
Like
Share

icarus
Dozens Demigod
icarus
Dozens Demigod
Joined: Apr 11 2006, 12:29 PM

Oct 30 2015, 02:26 PM #93

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.
Reply
Like
Share

Double sharp
Dozens Demigod
Double sharp
Dozens Demigod
Joined: Sep 19 2015, 11:02 AM

Oct 30 2015, 02:31 PM #94

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}.
Reply
Like
Share

icarus
Dozens Demigod
icarus
Dozens Demigod
Joined: Apr 11 2006, 12:29 PM

Oct 30 2015, 10:31 PM #95

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: Select all

intuitive&#91;m_, n_&#93; &#58;=
  If&#91;IntegerQ&#91;m/Power @@ First@ FactorInteger@ &#40;n^2 - 1&#41;&#93;, False,
   Or&#91;Complement&#91;First /@ FactorInteger@ m, 
      First /@ FactorInteger@ n&#93; == {}, 
    Divisible&#91;Times&#91;n^2 - 1, If&#91;And&#91;Mod&#91;n, 6&#93; == 0, n <= 18&#93;, 5, 1&#93;&#93;, 
     Times @@ Select&#91;Power @@ Transpose@ FactorInteger@ m, CoprimeQ&#91;n, #&#93; &&#93;&#93;&#93;&#93;
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: Select all

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

Code: Select all

2 Regular&#58; Divisor.
 3 Regular&#58; Divisor.
 4 Regular&#58; Divisor.
 5 Coprime&#58; Alpha-2 Factor
 6 Regular&#58; Divisor.
 8 Regular&#58; Richness 2.
 9 Regular&#58; Richness 2.
 10 Semicoprime&#58; Use 2 5.
 11 Coprime&#58; Omega Factor.
 12 Regular&#58; Base.
 13 Coprime&#58; Alpha Factor.
 15 Semicoprime&#58; Use 3 5.
 16 Regular&#58; Richness 2.
 18 Regular&#58; Richness 2.
 20 Semicoprime&#58; Use 4 5.
 22 Semicoprime&#58; Use 2 11.
 24 Regular&#58; Richness 2.
 26 Semicoprime&#58; Use 2 13.
 27 Regular&#58; Richness 3.
 30 Semicoprime&#58; 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.
Reply
Like
Share

Double sharp
Dozens Demigod
Double sharp
Dozens Demigod
Joined: Sep 19 2015, 11:02 AM

Oct 31 2015, 01:57 AM #96

icarus @ Oct 30 2015, 10:31 PM wrote: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?)
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.
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.
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 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: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).
icarus @ Oct 30 2015, 10:31 PM wrote: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.
icarus @ Oct 30 2015, 10:31 PM wrote: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: Select all

intuitive&#91;m_, n_&#93; &#58;=
  If&#91;IntegerQ&#91;m/Power @@ First@ FactorInteger@ &#40;n^2 - 1&#41;&#93;, False,
   Or&#91;Complement&#91;First /@ FactorInteger@ m, 
      First /@ FactorInteger@ n&#93; == {}, 
    Divisible&#91;Times&#91;n^2 - 1, If&#91;And&#91;Mod&#91;n, 6&#93; == 0, n <= 18&#93;, 5, 1&#93;&#93;, 
     Times @@ Select&#91;Power @@ Transpose@ FactorInteger@ m, CoprimeQ&#91;n, #&#93; &&#93;&#93;&#93;&#93;
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: Select all

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

Code: Select all

2 Regular&#58; Divisor.
 3 Regular&#58; Divisor.
 4 Regular&#58; Divisor.
 5 Coprime&#58; Alpha-2 Factor
 6 Regular&#58; Divisor.
 8 Regular&#58; Richness 2.
 9 Regular&#58; Richness 2.
 10 Semicoprime&#58; Use 2 5.
 11 Coprime&#58; Omega Factor.
 12 Regular&#58; Base.
 13 Coprime&#58; Alpha Factor.
 15 Semicoprime&#58; Use 3 5.
 16 Regular&#58; Richness 2.
 18 Regular&#58; Richness 2.
 20 Semicoprime&#58; Use 4 5.
 22 Semicoprime&#58; Use 2 11.
 24 Regular&#58; Richness 2.
 26 Semicoprime&#58; Use 2 13.
 27 Regular&#58; Richness 3.
 30 Semicoprime&#58; 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!
Reply
Like
Share