Gah, anti-procrastination settings prevented me from correcting this, but it's too stupid to let stand. At least this post demonstrates once again the important principle that a smart (computer) calculator is no match for a dumb (human) calculator.
Of course, n bytes can store a number up to 2^(8n), not up to n. Thus, the number we'd be recording has order of magnitude (50 terabytes/bit)×log[2]/log[10] ≈ 1.20e+14, so we'd need to distinguish that many digits after the decimal point.
Conversely, as bayes pointed out (http://news.ycombinator.com/item?id=1585498), if we have a resolution of 10 digits after the decimal point, then we can handle about 10*log[10]/log[2] ≈ 33 bits.
(EDIT: To be clear, it's the same person posting; I just can't stand to wait 154 minutes to correct the error.)
Of course, n bytes can store a number up to 2^(8n), not up to n. Thus, the number we'd be recording has order of magnitude (50 terabytes/bit)×log[2]/log[10] ≈ 1.20e+14, so we'd need to distinguish that many digits after the decimal point.
Conversely, as bayes pointed out (http://news.ycombinator.com/item?id=1585498), if we have a resolution of 10 digits after the decimal point, then we can handle about 10*log[10]/log[2] ≈ 33 bits.
(EDIT: To be clear, it's the same person posting; I just can't stand to wait 154 minutes to correct the error.)