February 7 Information

What is the base where the biggest % of single digits divisions wont lead to repeating decimals (division by zero here count here as repeating decimals)?
Some example at base 3 the possible 1 digit divisions are 0/0, 0/1, 0/2, 1/0, 1/1, 1/2, 2/0, 2/1, 2/2.
The results are: 0/0 =(division by zero), 0/1 =(0), 0/2 = (0), 1/0 =(division by zero), 1/1 = (1), 1/2 = (0.1111111......), 2/0 = (division by zero), 2/1 = (2), 2/2 = (1).
The ones that aren't division by zero or repeating decimals are, 0/1, 0/2, 1/1, 2/1 and 2/2, so 5 out of 9 possible divisions aren't repeating decimals (or division by zero) so 55,5555555555555...% of all the divisions. 179.197.136.113 ( talk) 23:02, 7 February 2020 (UTC) reply

There won't be repeating "decimals" if the divisor exactly divides the number base. The number of divisors of the base can be computed from the base's prime factorization. Basically it can get as large as you want, if you can make the base as large as you want. 173.228.123.39 ( talk) 08:58, 8 February 2020 (UTC) reply

An " if and only if" criterion: There won't be repeating "basimals" iff the divisor, after simplifying the fraction, exactly divides an integral power of the number base. For example, in base 10, 1/4 = 0.25; 4 does not divide 10 evenly, but it divides 100 = 10². And while 6 does not divide a power of 10, the fraction 3/6, after simplifying, is 1/2, where 2 divides 10.  -- Lambiam 10:09, 8 February 2020 (UTC) reply

The highest percent I've found is with base 6 at 26/36 = 72.2%. Other values are:

Base #terminating proportion
 2     2            2/4 = 50%
 3     5            5/9 = 55.6%
 4    10          10/16 = 62.5%
 5    12          12/25 = 48%
 6    26          26/36 = 72.2%
 8    34          34/64 = 53.1%
12    94         94/144 = 65.3%
30   550        550/900 = 61.1%

In general the numerator is

${\displaystyle \sum _{1}^{k-1}\left\lceil {\frac {n}{P(n,k)}}\right\rceil }$

where k=P(n, k)Q(n, k), every prime dividing P(n, k) does not divide n, and every prime dividing Q(n, k) divides n. For larger numerators you want P to be small for as many values of k as possible, so you want n to have as many different prime factors as possible, so good candidates for n are primorials. But the ratio seems to decrease for primaorials after 6, so based on this heuristic and non-rigorous argument I'm going to guess the answer is 6. Note that for n prime, or if you want to find the proportion where the fraction is an integer, the numerator is

${\displaystyle \sum _{1}^{k-1}\left\lceil {\frac {n}{k}}\right\rceil }$

which is about n log n, and so the proportion would be about (log n)/n → 0. -- RDBury ( talk) 16:36, 8 February 2020 (UTC) reply

Strange, for base 4 I get 10/16 (0/1; 1/1; 2/1; 3/1; 0/2; 1/2; 2/3; 3/2; 0/3; 3/3) and for base 6 26/36. Experimental evidence suggests that the maximum is reached for base 6; I have tested that no other base up to 10,000 does as well. I imagine that a proof would not be deep, but I did not readily see one.  -- Lambiam 18:27, 8 February 2020 (UTC) reply

I noticed the base 4 error as well and corrected it, thanks. I also computed values for a few thousand likely candidates with the largest being 100⋅11# = 231000. If Term(n) is the number of terminating basimals for base n (i.e.), then from analysis of data it appears that Term(n) = O(n^3/2log(n)). If true this would imply that Term(n)/n² → 0 and reduce the problem to a finite calculation. I'm not sure how a proof would go, but I imagine estimates on the distribution of smooth numbers and the growth of the primorial function would enter into it; both of which go pretty deeply into analytic number theory. -- RDBury ( talk) 23:36, 8 February 2020 (UTC) reply

There is still a base 6 error.  -- Lambiam 17:32, 9 February 2020 (UTC) reply

Yep, fixed. I did the first few values by making a table and counting, which is prone to errors. The program that I wrote got the right answer but I never compared them with what I had for the starting values. Still no match on OEIS btw. -- RDBury ( talk) 18:37, 9 February 2020 (UTC) reply