So far my best idea is to build two tables, and then look at the key when a retrieval is attempted to figure out which table it's in. That would probably work, but it feels like a kludge.
I'm trying to figure out how to construct an associative array whose
keys will be a combination of strings and immutable int[]'s, but every
approach I've looked at has run into problems. It should be relatively
easy, as strings are really just an immutable list of ints, but I
haven't been able to find how strings are hashed. (It's looking as if
the details are handled in C...which makes it difficult.) I could
define my own hash code, but I don't find it at all clear what would be
appropriate given that I don't know the size. The data is rather
sparse, so a hash table seems appropriate. (My only other alternative
is a database, and that imposes the heavy slowdown of I/O ... even
though it does automate persistence it doesn't seem like a good tradeoff.)
- hash design problem: both string and int[] keys Charles Hixson
- Re: hash design problem: both string and int[] keys Ali Çehreli
- Re: hash design problem: both string and int[] ... Charles Hixson
- Re: hash design problem: both string and in... Jonathan M Davis
- Re: hash design problem: both string and in... Charles Hixson
- Re: hash design problem: both string an... Charles Hixson