[math-fun] 3-smooth numbers #1
Hi, Sorry this is so long, if you hate 3-smooth numbers, run away now... I'm Steve Jacobs, the new kid on the block. I'm a retired electrical/computer engineer with a passion for Number Theory. In a prior life I spent a lot of time on probability and gambling stuff. Over the last several months, I've been playing with 3-smooth numbers. I've developed some new methods that I think are original, but perhaps I've merely reinvented an existing wheel. But, it has been great fun going down this particular rabbit hole. Sadly, formal proofs are not my strong suit, so I can't characterize my results as more than speculation or conjecture. I'm hoping that some of you will be able to easily (dis-)prove my conjectures, or point to prior work that I've reinvented. I actually started with 5-smooth numbers, and found the algorithm by Dijkstra for generating them in sequence by using queues to store prior results. I adapted this method for 3-smooth numbers, as well as other numbers that I cal {p,q}-smooth (with p,q prime and (p < q)). So {2,5}-smooth numbers and {3,5}-smooth numbers are obvious subsets of the Hamming numbers. It occurred to me that {p,q}-smooth numbers should be closely related to the continued-fraction expansion of log(q)/log(p), so I generated convergents and semi-convergents of log(3)/log(2) and started looking for them to show up when generating 3-smooth numbers. I like to reduce a(n) = A003586(n) = (2^i * 3^j) to the (i,j) pair of exponents, which corresponds to (A022328(n), A022329(n)). So I listed (i,j) pairs for 3-smooth numbers, and looked at how the exponents change when advancing from a(n) to a(n+1). So I generated the first million and looked for patterns in the results: Note: form [di dj]h is the change in (i,j) to go to a(n+1), followed by the "hop index" that I use to track how a(n) "hops around" the I-J plane. n i j [di dj]h ------------------------------------- 1: (0 0) [1 0]0 2: (1 0) [-1 1]1 3: (0 1) [2 -1]2 4: (2 0) [-1 1]1 5: (1 1) [2 -1]2 6: (3 0) [-3 2]4 7: (0 2) [2 -1]2 8: (2 1) [2 -1]2 9: (4 0) [-3 2]4 ... (lots deleted) 999991: (844 590) [485 -306]17 999992: (1329 284) [-1054 665]40 999993: (275 949) [485 -306]17 999994: (760 643) [485 -306]17 999995: (1245 337) [-1054 665]40 999996: (191 1002) [1539 -971]18 999997: (1730 31) [-1054 665]40 999998: (676 696) [485 -306]17 999999: (1161 390) [-1054 665]40 1000000: (107 1055) [1539 -971]18 So the hop from a(n) to a(n+1) is always either (di, -dj) or (-di, dj) corresponding the rational factors (2^di / 3^dj) or (3^dj / 2^di), which is sorta obvious, advancing always exchanges some power of 2 for some power of 3, or vice-versa. Perhaps less obvious is (conjecture) that |di / dj| is always a (semi-)convergent of CF of log(3)/log(2). Digging deeper, I found simple patterns in the points in I-J space that share the same hop when going from (i,j)=(A022328(n), A022329(n)) to (i,j)=(A022328(n+1), A022329(n+1)). For a given hop(h)==[di,dj] the sites that use hop(h) are covered by a rectangle in the I-J plane. Other than the trivial hop(0)=[1 0] case, each of these rectangles have one side that overlaps with the I axis. The other thing that jumps out is that these hop rectangles grow pretty quickly, so it doesn't take very many to cover huge chunks of the I-J plane. In fact, if all my calculations pan out, then a mere 569 distinct hops are sufficient to cover enough of the I-J plane to include (i,j) points up to and beyond a(10^100). It then dawned on me that a little bit of number crunching on the list of hops could create a lookup table to take (i,j) and find the right hop to propagate to the next 3-smooth number. So, I implemented a function that computes (di, dj) = hop(i, j) using a quick table lookup, to give the exponents of the next 3-smooth number (i+di, j+dj). This has obvious advantage over using the queues associated with the Dijkstra method, since those queues grow large the further one goes. Another obvious advantage is that no prior history is needed to compute the next 3-smooth number in the sequence. A small lookup table based on 569 (semi-)convergents is sufficient to hop from one (i,j) to the next, so the first googol or so 3-smooth numbers. The really fun part concerns A022330 and A022331. Can anyone confirm (or refute) any of the numbers below? I've done numerous Google searchs with no luck. Note: I use the "usual" est_count(n) = (log(sqrt(6)*N))^2 / (2*log(2)*log(3) to compare with my results. The error of this estimate (presuming my numbers are correct) is listed in the "err" column: err = est_count(n) - i_indx(n) k err i_indx(10^k) [speculative A022331(10^k) numbers] ------------------------------------------------------------------------- 1 -1 41 * '*' means confirmed by A022331 or comments/links 2 -1 3237 * 3 -1 316281 * 4 1 31554641 5 -1 3154730315 6 1 315465692250 7 -5 31546495833227 8 -1 3154648849403776 9 -5 315464877601193600 10 -3 31546487686727520626 11 -5 3154648767938833673181 12 -7 315464876786544183426556 13 -7 31546487678581026503744220 14 -2 3154648767857368731985314147 15 -5 315464876785729534014640342905 16 -7 31546487678572880009625123574432 17 -3 3154648767857287267044123250286679 18 -3 315464876785728719365228433957109149 19 -2 31546487678572871863131004484995329903 20 -3 3154648767857287185579182059392377143356 ------------------------------------------------------------------------- If my numbers hold up, then est_count(n) is incredibly accurate for an estimate. k err j_indx(10^k) [speculative A022330(10^k) numbers] ------------------------------------------------------------------------- 1 -1 93 * '*' means confirmed by A022330 or comments/links 2 -1 8055 * 3 -1 793775 * 4 -4 79261054 * 5 -3 7924941755 * 6 1 792482542841 * 7 -2 79248137960872 (failed Google search) 8 4 7924812632853902 9 -1 792481251653059342 10 4 79248125048982621572 11 7 7924812503735029032298 12 6 792481250361870571977224 13 2 79248125036070733885190551 14 6 7924812503605910155393730772 15 3 792481250360579383208119832549 16 3 79248125036057821997499450803169 17 -1 7924812503605781036516819755796893 18 -3 792481250360578092019350722334486348 19 1 79248125036057809085611759700996606344 20 0 7924812503605780907397942844775140352872 ------------------------------------------------------------------------- I'm perfectly willing to share my methods for computing these numbers, but this post is already too long, so I didn't want to get too bogged down in details, especially since I could be sadly but completely wrong. Any help is greatly appreciated.
participants (1)
-
jacobs@xmission.com