11-12-2022, 06:54 PM
There are a few libraries that do associative arrays and hash tables, but using them could be complicated for the ones who didn't create such libraries. I give away a simple method here.
The trick is to create a single-dimensional array of an UDT type:
TYPE datype
key as STRING * 37
num as _BYTE
END TYPE
REDIM aa(1 to 100) AS datype
The "aa" should be checked for length so it could be expanded with "REDIM _PRESERVE" as needed.
Say the double dimension at 16777216,202020202020 (picking ridiculous numbers on purpose).
Then internally the key should be put down as "00000000016777216,000000202020202020" so both subscripts are 18 figures long, which is about the written extent of a 64-bit integer. This key looks mind-boggling but it would make it easy for sorting and therefore employ a binary search on the keys which is way faster than searching the array sequentially.
Each new element of "aa" should be inserted so the whole array remains sorted by key. This is the only drawback of employing a binary search.
Also note that for a given subscript pair, it must be converted to string to a 37-digit monstrosity LOL as I've indicated above. Again, this makes it easy to sort. Maybe it could be done entirely with numbers but it requires the extra step of using "VAL()" on each subscript, then the additional job of sorting by "major" subscript then by minor subscript. Doing the whole thing as a string, as a fake entry to a real array and padded with zeroes makes it easier to code and to understand.
Unless the OP really requires 3^11 values or more, this associative array method would save a ton of memory, and it could be handled on 32-bit as well as 64-bit.
The trick is to create a single-dimensional array of an UDT type:
TYPE datype
key as STRING * 37
num as _BYTE
END TYPE
REDIM aa(1 to 100) AS datype
The "aa" should be checked for length so it could be expanded with "REDIM _PRESERVE" as needed.
Say the double dimension at 16777216,202020202020 (picking ridiculous numbers on purpose).
Then internally the key should be put down as "00000000016777216,000000202020202020" so both subscripts are 18 figures long, which is about the written extent of a 64-bit integer. This key looks mind-boggling but it would make it easy for sorting and therefore employ a binary search on the keys which is way faster than searching the array sequentially.
Each new element of "aa" should be inserted so the whole array remains sorted by key. This is the only drawback of employing a binary search.
Also note that for a given subscript pair, it must be converted to string to a 37-digit monstrosity LOL as I've indicated above. Again, this makes it easy to sort. Maybe it could be done entirely with numbers but it requires the extra step of using "VAL()" on each subscript, then the additional job of sorting by "major" subscript then by minor subscript. Doing the whole thing as a string, as a fake entry to a real array and padded with zeroes makes it easier to code and to understand.
Unless the OP really requires 3^11 values or more, this associative array method would save a ton of memory, and it could be handled on 32-bit as well as 64-bit.