6 ms·
It only differs by a constant factor, so in the end it doesn't matter when you want the asymptotic complexity of storing all primes up to x.
by bonzini 9y ago
It only differs by a constant factor, so in the end it doesn't matter when you want the asymptotic complexity of storing all primes up to x.
- xyzzyz 9y agoSure, you would still get that the space needed grows linearly, but you're off by almost 50% in your storage requirements. More importantly, you're confusing people with explicitly wrong statement for no benefit, people who might not realize that it's actualy ln, not log_2, and spread the mistake to other people.
- jacobolus 9y agoThe bound we have is apparently: https://en.wikipedia.org/wiki/Prime-counting_function#Inequalities https://en.wikipedia.org/wiki/Prime-counting_function#Inequa... x/log x < π(x) < 1.25506x/log x If you want to rewrite that using log2, you get: 1.44270x/log2 x < π(x) < 1.81067x/log2 x I would hardly call the previous poster’s comment an “explicitly wrong statement for no benefit”. We’re talking about number of bits here.
- xyzzyz 9y agoYou're missing the point. Asymptotically, we have much better bound than 1.25506 -- the asymptotic bound is indeed 1+e for any e > 0, as the prime number theorem explicitly says that lim pi(n)/(n/log n)) = 1. The constant 1.25506... = 30 * log(113)/113 is only relevant because that's the the smallest global bound, which is there to take care of n = 113. If you rewrite it to log_2, you get the 1.442... constant, which throws your calculations off by "almost 50%" I mentioned in my comment above. And yeah, it doesn't change anything in the qualititative analysis of storage needs, but that's not my point -- my point is that in math, you should avoid saying things that are explicitly wrong, unless there are very good reasons to do so.