51–60 of 82 posts
Earlier quoted context omitted.
Cause that's how the math works. log_2(22,459,157,718,361) ~= 44.35. Powers of two get big really really fast after all. https://www.wolframalpha.com/input/?i=22,459,157,718,361+to+...
Shouldn't it be log_2(10^22,459,157,718,361)?
Earlier quoted context omitted.
THIN SPACE (U+2009) is also good to use to group digits, and is in fact the standard way to group digits in the SI system instead of "," or ".". That looks nice and gets rid of the confusion over number like "1,234" and "1.234". In the US, the former is the integer 1234 and the later is the rational number 1234/1000. In Germany or France, these would be the other way around. In SI, "1.234" and "1,234" would both be 1…
HN supports THIN SPACE just fine. I used it in my comment, and so did you. I’m not at all fond of the thin space digit grouping practice; to my Australian eyes it tends to look fairly terrible in most places, like bad kerning. Your comment also shows another catastrophic weakness of using a regular thin space for digit grouping without additional magic: you need a non-breaking thin space, but there isn’t one. On my c…
You earlier comment shows up with thin spaces on Chrome for me, but not on Safari or Firefox.
I know Firefox handles thin spaces, because it handles this Reddit comment just fine: https://www.reddit.com/r/Physics/comments/67g28i/because_gra...
I'm going to paste the examples from there here and see what happens:
1234567 (U+200B, ZERO WIDTH SPACE)
1 234 567 (U+200A, HAIR SPACE)
1 234 567 (U+202F, NARROW NO-BREAK SPACE)
1 234 567 (U+2009, THIN SPACE)
1 234 567 (U+2006, SIX-PER-EM SPACE)
1 234 567 (U+2008, PUNCTUATION SPACE)
1 234 567 (U+2005, FOUR-PER-EM SPACE)
1 234 567 (U+2004, THREE-PER-EM SPACE)
1 234 567 (U+0020, SPACE)
1 234 567 (U+2000, EN QUAD)
1 234 567 (U+2002, EN SPACE)
1 234 567 (U+2007, FIGURE SPACE)
1 234 567 (U+2003, EM SPACE)
1 234 567 (U+2001, EM QUAD)
Edit: they displayed with the various different space sizes in Chrome, and with fixed space sizes in Firefox (1 regular space for all except 200B and 202F which showed up with no space).
Unlike Reddit, editing does not lose information.
Also displays right in Edge, and in Firefox on Windows. So it looks like it is just Firefox Mac and Safari that are not handling the various space sizes for me.
Earlier quoted context omitted.
Any log base is just a multiple of the natural log. When you talk about asymptotic growth, those factors are irrelevant.
It wasn't clear to me that the problem as framed was about asymptotic growth. I was curious if/when the factors might become relevant, so I started sketching this out... The 63x64 binary canvas is made of integers on the order of 2^4032. (Please forgive my approximation notation.) ln(2^4032) ~= 2795 log_10(2^4032) ~= 1214 So, the difference between natural log (for this canvas size) and log base 10 is only one binary…
ln(2^n) = n * ln(2)
log_10(2^n) = n * log_10(2)
log_10(x) = ln(x) * (log_10(2) / ln(2))
log_10(x) / ln(x)
ln(10)
1214 * ln(10) ~= 2795,338Earlier quoted context omitted.
HN supports THIN SPACE just fine. I used it in my comment, and so did you. I’m not at all fond of the thin space digit grouping practice; to my Australian eyes it tends to look fairly terrible in most places, like bad kerning. Your comment also shows another catastrophic weakness of using a regular thin space for digit grouping without additional magic: you need a non-breaking thin space, but there isn’t one. On my c…
OK, this is odd. It looks like something browser dependent is going on. You earlier comment shows up with thin spaces on Chrome for me, but not on Safari or Firefox. I know Firefox handles thin spaces, because it handles this Reddit comment just fine: https://www.reddit.com/r/Physics/comments/67g28i/because_gra... I'm going to paste the examples from there here and see what happens: 1234567 (U+200B, ZERO WIDTH SPAC…
The last line of the picture contains some 'noise': 0000000000000000000000000000000000000000000000000001000101101001 So the idea is that you produce any 63x64 binary image then you find a number up to 2^64 so that added to the number represented by the first image gives a prime. It's not exactly amazing, but clever enough.
> The last line of the picture contains some 'noise' Note that if the picture is prime, then the last line must always contain noise... the last digit must be a 1! I also feel like it's slightly cheating that the first line doesn't contain noise, or a leading 1 digit... the number doesn't naturally fit into 64x64 bits because of all the leading zeroes.
The last line of the picture contains some 'noise': 0000000000000000000000000000000000000000000000000001000101101001 So the idea is that you produce any 63x64 binary image then you find a number up to 2^64 so that added to the number represented by the first image gives a prime. It's not exactly amazing, but clever enough.
Earlier quoted context omitted.
It wasn't clear to me that the problem as framed was about asymptotic growth. I was curious if/when the factors might become relevant, so I started sketching this out... The 63x64 binary canvas is made of integers on the order of 2^4032. (Please forgive my approximation notation.) ln(2^4032) ~= 2795 log_10(2^4032) ~= 1214 So, the difference between natural log (for this canvas size) and log base 10 is only one binary…
As the post you replied to said, it’s a constant factor. You’ll find: ln(2^n) = n * ln(2) log_10(2^n) = n * log_10(2) Which, substituting x for 2^n , gives log_10(x) = ln(x) * (log_10(2) / ln(2)) you can do replace 2 by any positive number here. So, the value of log_10(x) / ln(x) is independent of x. A bit of thinking will show it to be equal to ln(10) And indeed, 1214 * ln(10) ~= 2795,338
The subthread started when someone thought it was necessary to point out that the log everyone was talking about was the natural log.
Independent of what the actual problem is, say someone tells you that something is log(n). It is a safe assumption that they mean ln(n), but if you are are speaking out loud, that is still pronounced "log n".
What I'm looking for is better intuitions on F/ln(n) versus F/log_x(n) for some completely arbitrary function F. The intuitions for x > e are very different than the intuitions for x < e. (This is just the nature of exponents. Maybe there is no further intuition for me to develop here, other than to just practice more.)
Previously on HN, someone posted the The Corpus Christi Prime blog post [1], which was inspired by the Numerphile Trinity Hall Prime video [2]. See also Zachary Abel's Prime Portraits article [3]. [1]: https://news.ycombinator.com/item?id=15208317 [2]: https://www.youtube.com/watch?v=fQQ8IiTWHhg [3]: http://archive.bridgesmathart.org/2016/bridges2016-359.pdf
[0]: http://mathworld.wolfram.com/TuppersSelf-ReferentialFormula....
The last line of the picture contains some 'noise': 0000000000000000000000000000000000000000000000000001000101101001 So the idea is that you produce any 63x64 binary image then you find a number up to 2^64 so that added to the number represented by the first image gives a prime. It's not exactly amazing, but clever enough.
That may have been how the author came up with a prime number, but any extremely large odd number is probably prime, since the primes get further and further apart as you go further along the number line. So it may have been a lucky guess.
There are 25 primes in [1, 100]. There are 16 in [1001, 1100]. There are 6 in [1000001, 1000100].
Earlier quoted context omitted.
> The last line of the picture contains some 'noise' Note that if the picture is prime, then the last line must always contain noise... the last digit must be a 1! I also feel like it's slightly cheating that the first line doesn't contain noise, or a leading 1 digit... the number doesn't naturally fit into 64x64 bits because of all the leading zeroes.
If you "draw" with zeros instead of ones, then you don't have the last-digit-in-foreground problem.