Re:A happy numeric coincidence
by Aardwolf on Wednesday January 02, 2019 @11:54AM
(#18807591)
Neat, but why is for example 163^16 such a coincidence? It's not that unlikely for digits to add up to 163, and given that you can choose both a base and an exponent, there's bound to be many that work out like this. 163^16 has 36 digits, so expected sum (average expected value of a random digit 0-9 being 4.5) be 162. So that's even pretty close to 163.
Also, why limit this to base 10? Anything with base 10 digits is not the purest possible math imho because it depends on the arbitrary value 10 while you could generalize to any other value.
Re:A happy numeric coincidence
by Aardwolf on Wednesday January 02, 2019 @12:18PM
(#18807870)
You can speed up brute force search by starting somewhere before where log10(x^y) * 4.5 is roughly equal to x. For example 2222^140 is 2110 which is close to 2222. Then brute force search from there and you get:
Re:A happy numeric coincidence
by klodolph on Wednesday January 02, 2019 @03:09PM
(#18809673)
How much does this speed up brute force search, though? You have to actually compute the exponent and digit sums. If I iterate over the powers of N from N^I to N^J, I do something like O((J-I)^2*log N) work doing multiplications the naive way.
Re:A happy numeric coincidence
by Asooka on Thursday January 03, 2019 @06:16AM
(#18814324)
Rewrite
log(x^y)*4.5 = x
y*log(x)*4.5 = x
y = x/(4.5*log x)
So picking a random number like 234, we get y=21.94819 and the digit sum of 234^22 == 234. In this case we actually just had to compute one exponent and one digit sum.
Re:A happy numeric coincidence
by sephoric on Wednesday January 02, 2019 @03:51PM
(#18810061)
I think one reason to limit to base 10 is because we don't have an arbitrary number of digits, we only have maybe 36 if we use the full alphabet. And it will be difficult for people to follow along with if it's something they aren't used to calculating in. But I'm also guessing the results will become a lot less "rare" which is part of the cool factor here.
Re:A happy numeric coincidence
by enedil on Wednesday January 02, 2019 @06:46PM
(#18811483)
Omg, you're not thinking he's done all this by hand, right? People here can code such simple things. And you don't need no specific symbols, just arrays of ints (or any suitable type).
Re:A happy numeric coincidence
by hinkley on Wednesday January 02, 2019 @11:50AM
(#18807553)
All multiples of 9 have digits that add up to 9. This is something kids learn. Why does it work? 9 is 10 - 1, so every time you add another nine the tens digit goes up by one and the ones digit down by one, maintaining the sum of digits. Similar thing happens at three digits, four digits, etc, because 9 < 10, no digit other than the ones digit ever goes up by more than 1, and a 9 becomes a 0 when you carry a one.
That this pattern didn’t swamp the results makes me wonder what kind of bug the author has in the scanning code.
[edit: seems I forgot about situations like 9 x 11 x N, where the digits can add up to 18, 27, etc due to all the 8 and 9 digits, so the algorithm will only find multiples of 9 with lots of small digits in it.]
Re:A happy numeric coincidence
by gweinberg on Wednesday January 02, 2019 @04:41PM
(#18810515)
Something lie that happens in all bases e.g. in base 8 all multiples of 7 add up to 7 (if you keep adding), in hex all multiples of f add up to f, and in binary everything eventually adds up to 1 (except zero).
Similarly, in base 8 7^2 is 61 and in hex f^2 is e1.
(n-1)^2 = n^2 - 2*n + 1 = n(n-2) + 1
which in base n is written with n-2 as the fist digit and 1 as the second digit.
Re:A happy numeric coincidence
by white-flame on Wednesday January 02, 2019 @06:40PM
(#18811446)
The omission is that it's simply recursive.
You might add the digits up to 36, whose digits then add up to 9. Simply reapply to the sum if the sum has more than 1 digit, and you'll still arrive at 9.
Re:A happy numeric coincidence
by klodolph on Wednesday January 02, 2019 @03:17PM
(#18809756)
Just curious how fast brute force search is. Found some larger numbers like 7793^451. Computing the exponents in base 10 seems to be a fairly fast way of doing things, since this is not very hard and radix conversion is a comparatively slow operation.
Re:A happy numeric coincidence
by sonofgod on Wednesday January 02, 2019 @11:07AM
(#18807089)
def test(x, y, debug=True):
num = x**y
digitalsum = sum(int(a) for a in str(num))
if x == digitalsum and debug:
print x, y, num
return x == digitalsum
for i in range(1,1000):
for j in range(1,100):
if test(i, j):
print i, j
Re:A happy numeric coincidence
by kazinator on Wednesday January 02, 2019 @06:43PM
(#18811471)
You will find here that the run-time is swamped by the digit breakdown and summing, so that exponentiation versus accumulated product doesn't make a palpable difference.
http://recursed.blogspot.com/2007/09/mathematics-in-jack-rea... Base 10: https://oeis.org/A023106 Base 2: https://oeis.org/A256590
> Extra credit: explain why nobody cares.
Also, why limit this to base 10? Anything with base 10 digits is not the purest possible math imho because it depends on the arbitrary value 10 while you could generalize to any other value.
2222 ^ 145
That this pattern didn’t swamp the results makes me wonder what kind of bug the author has in the scanning code.
[edit: seems I forgot about situations like 9 x 11 x N, where the digits can add up to 18, 27, etc due to all the 8 and 9 digits, so the algorithm will only find multiples of 9 with lots of small digits in it.]
Similarly, in base 8 7^2 is 61 and in hex f^2 is e1.
(n-1)^2 = n^2 - 2*n + 1 = n(n-2) + 1 which in base n is written with n-2 as the fist digit and 1 as the second digit.
You might add the digits up to 36, whose digits then add up to 9. Simply reapply to the sum if the sum has more than 1 digit, and you'll still arrive at 9.
digitalsum(999^75) = 999
Nerdy enough (and well written enough) that I'll add this blog to my RSS reader. 2019 is off to a good start!