3 ms·

The software that HN runs on can handle arbitrarily large numbers. Check it out on http://tryarc.org/ http://tryarc.org/: arc> (expt 2 64) 184467440737

by zck 13y ago

The software that HN runs on can handle arbitrarily large numbers. Check it out on http://tryarc.org/ http://tryarc.org/: arc> (expt 2 64) 18446744073709551616 arc> (expt 2 65) 36893488147419103232 arc> (expt 2 165) 46768052394588893382517914646921056628989841375232 Note that this isn't converting the number to a floating-point; it's exact precision: arc> (+ (expt 2 165) 1) 46768052394588893382517914646921056628989841375233

sgy 13y ago
Perhaps my point wasn't very clear. I didn't mean that a computer won't be able to compute the value of 2^64 or 2^128 or 2^x. In a 64-bit architecture, the data bus or datapath width will be 64-bit long. That is, we only have 2^64 unique numbers to pass in the CPU at a time. What's the best to do when we need more unique figures? Use unsigned integers, for instance? 2^64 is the number of combinations not the the maximum number itself.
- dragonwriter 13y ago
  > In a 64-bit architecture, the data bus or datapath width will be 64-bit long. That is, we only have 2^64 unique numbers to pass in the CPU at a time. What's the best to do when we need more unique figures? Use data structures that are too big to fit in the CPU all at once. The same way that we did on 8-bit CPUs when we needed more than 256 unique ID values. The problem is vastly more rare with 64-bit machines, but the solution remains the same. Obviously, comparing such value takes more clock cycles than comparing values that fit in the CPU all at once, but that's the price you have to pay. > Use unsigned integers, for instance? Signed vs. unsigned, with the same width, provides the same number of unique values. Just different values. So that wouldn't help.
  - dllthomas 13y ago
    "Signed vs. unsigned, with the same width, provides the same number of unique values. Just different values. So that wouldn't help." Unless you had been reserving negative values to mark errors when returning ids, in which case making use of that top bit as id space lets you double the number of ids. Of course, you could still treat it as signed or unsigned... it's just a possibly related issue.

by zck 13y ago

sgy 13y ago

Perhaps my point wasn't very clear. I didn't mean that a computer won't be able to compute the value of 2^64 or 2^128 or 2^x. In a 64-bit architecture, the data bus or datapath width will be 64-bit long. That is, we only have 2^64 unique numbers to pass in the CPU at a time. What's the best to do when we need more unique figures? Use unsigned integers, for instance? 2^64 is the number of combinations not the the maximum number itself.

dragonwriter 13y ago
> In a 64-bit architecture, the data bus or datapath width will be 64-bit long. That is, we only have 2^64 unique numbers to pass in the CPU at a time. What's the best to do when we need more unique figures? Use data structures that are too big to fit in the CPU all at once. The same way that we did on 8-bit CPUs when we needed more than 256 unique ID values. The problem is vastly more rare with 64-bit machines, but the solution remains the same. Obviously, comparing such value takes more clock cycles than comparing values that fit in the CPU all at once, but that's the price you have to pay. > Use unsigned integers, for instance? Signed vs. unsigned, with the same width, provides the same number of unique values. Just different values. So that wouldn't help.
- dllthomas 13y ago
  "Signed vs. unsigned, with the same width, provides the same number of unique values. Just different values. So that wouldn't help." Unless you had been reserving negative values to mark errors when returning ids, in which case making use of that top bit as id space lets you double the number of ids. Of course, you could still treat it as signed or unsigned... it's just a possibly related issue.