DosTips.com

Hi,

you describe a way how to use a lookup table on your site about DOS - String Manipulation:

However, with that given method of accessing an item of a pair, you can just search for the left-sided item in order to return the right-sided item.

I wanted a way to access and return both items of a pair.

My first idea was to use a second table in which the order of the elements in a pair is inverted.
But that requires much work of coding and space or runtime for inverting the items.

So my next idea was to create an algorithm which uses just one table and looks up the right-sided element and returns the left-sided element of a pair.
Unfortunately didn't work for cutting of the end of the string so I had to find a different way for doing that and I found two further possibilities to do so:

and


After that, I just needed to cut the left side of the string until to the latest ; (semicolon) which I did with


All together, the code looks either like that

or like that


What do you think which of those two codes could be better?
Do you have suggestions for improving my code or better ideas to realize a bi-directional access to lookup tables?

When it's a small number of elements I've done what you described first, a second table with the pairs inverted. It's not fancy, but it works well, and that way the code that extracts the data from the map can be identical.

The alternate method you propose is nice because you don't have to declare the maps in both directions, but the tradeoff is it requires a different function to extract the left member of a pair instead of the right. For me personally, I'd never be able to remember whether I defined my maps with this part or that part on the right or left, so I'd never remember which codeblock to call to extract data.

For maps with a much larger number of elements a good alternative is a psuedo-array. If your elements are indexed numerically (not necessarily sequentially, though that helps a lot), such as the 12 months you used as your example, it's extremely easy to define the array pairs:Running this code gives this result:
I like this because instead of remembering the names of two maps, (ie: month2Num and num2Month) you only need the name of one array (monthMap). Also you don't need any function or special codeblock to do the extraction, it's a fairly intuitive variable expansion. Probably least relevant to the discussion, but another perk, is that the array structure is dynamic and easy to update. If for some reason you needed to re-map January to "7" instead of "1", it's a simple 'set monthMap[Jan]=7'. That can be done using the single long string maps, but it's a lot more cumbersome to parse and update them. Admittedly there's not that many situations where a map like this is going to be updated during program execution, but it's possible...

All that said, if you're trying to do a map between items that can't be indexed numerically, say a foreign language map, Green=Vert, White=Blanc, etc. it's going to take a lot of typing to get the psuedo-array defined such that you can extract via !toFrench[White]! There are better ways to skin that cat, but I'm fond of the array structure whenever I can make use of it, and I fall back on defining string maps in both directions otherwise.

Magialisk wrote:When it's a small number of elements I've done what you described first, a second table with the pairs inverted. It's not fancy, but it works well, and that way the code that extracts the data from the map can be identical.

But before you write two maps, it's better to condense those two maps into a single map. Then you don't have to think about which map contains which direction.
Before I wrote the code for accessing from right to left-side, I developed this:


which echos


The map actually works like this: item A points to item B and item B points to item C, where item C equals item A.
B should be those item, whose string is the longest of the given pair.

In order to keep the map small, I removed the pair separator sign. To keep the table consistent then, the beginning and end of an item must be identifiable, that's why item A and B have to begin and end in a dash character but item C don't.

Magialisk wrote:The alternate method you propose is nice because you don't have to declare the maps in both directions, but the tradeoff is it requires a different function to extract the left member of a pair instead of the right. For me personally, I'd never be able to remember whether I defined my maps with this part or that part on the right or left, so I'd never remember which codeblock to call to extract data.

You could write a function that decides which direction has to be used. If function month2number doesn't return a value then the function number2month should return a value, unless there was a request for an item which the map doesn't contain.


The pseudo-array is a really good idea. Especially the access to an item is distinctly quicker than the functions/macros for a map are.
You could save the pairs into a map - which is easy to code - and then convert them into a pseudo-array.
Of course, the process of conversion takes runtime, too, but after a certain amount of reading processes of the array the pseudo-array becomes faster than the map with its function concept would be.

Magialisk wrote:Probably least relevant to the discussion, but another perk, is that the array structure is dynamic and easy to update. If for some reason you needed to re-map January to "7" instead of "1", it's a simple 'set monthMap[Jan]=7'. That can be done using the single long string maps, but it's a lot more cumbersome to parse and update them. Admittedly there's not that many situations where a map like this is going to be updated during program execution, but it's possible...

There are advantages and disadventages everywhere, a pseudo-array is not easy to duplicate whereas a map is

So I would say it depends on situation what idea you would take.