Todd Olson wrote: > At 12:35 +0200 2010-07-15, Moritz Lenz wrote: >>>If it ever were the case that $r + $l could produce an overflow >> >>Then we really have other problems. Remember that $r and $l are >>array indexes. If your machine has enough memory to hold an array >>and a hash of the same size in memory, but can't store integers long >>enough to index them, you're basically screwed. > > Still, I wonder about the cases > a) my machine can store integers long enough to index my arrays > yet not be able to store an integer twice that size
But you have enough memory to store two of them (one hash, one list), so in sum it should all work fine. > b) my array and hash are not in memory, rather the array is on disk > and the hash is over the network to some database, and the arrayness > and hashness are just roles. > > What assumptions should we be making about the underlying implementation > of the array and hash? Each array and hash implementation should make the assumptions that are valid for it. An on-disk array will have different assumptions and a different implementation. >> >>Also Int numbers are specified to transparently upgrade to bigints >>if necessary, so that's hardly a problem in Perl 6. > > On the one hand this is nice ... on the other hand it would be nice > to not be forced to take that performance hit. There are other types that don't have that performance hit, like int64. Cheers, Moritz
