Yes, it's possible that a particular data set has a lot of data, and data points can easily exceed MAX_INT.

I was looking for a speed/memory tradeoff. If the dataset is sparse, then a simple map of INT64->INT is okay. Once the data starts to become dense (which is pretty easy to do), then I'm storing a lot of INT64's, and using up a lot of memory.

This is for a digital simulator, and the base time is femto-seconds. There's nothing to stop a user from creating a design with a clock that has a 2ns period, and simulate for 10 seconds! As you can prolly tell, that's a LOT of data. Of course, I can "compress" the clock data (just store the clock's attributes). However, the user can have other signals in the design that are not necessarily clocks.

Doubles are out of the question. Computers stink at storing floating point numbers, and FP arithmatic is SLLLLLOOOOWWWW!

The map key is an unsigned integer.

A co-worker suggested a B-Tree, and I had thought of using one. But, when I sat down to think about it, a B-Tree is kinda overkill...

Viggy