[SOLVED] DSRN (dog slow roman numerals)

[DavidM]

The algorithm in DM1/TK3 doesn't handle 0 or negative values properly. So as I'm in the mood of late to force myself to use the list-processing commands more, I thought I'd fix that. In the process I ran into yet another DOLIST quirk.

What would you expect the result of DOLIST to be when presented with the following? These are the values in the lists at that step when 0 is the original input value to the DM1/TK3 apps:

Code:

{ "M" "CM" "D" "CD" "C" "XC" "L" "XL" "X" "IX" "V" "IV" "I" }
{  0   0    0   0    0   0    0   0    0   0    0   0    0  }
2 \<< NDUPN DROP \>> DOLIST

My expectation was { }, since NDUPN would delete all the strings and DROP would get rid of all the resulting Ns. The actual result: nothing. No list, no error message, nothing.

So accommodating that scenario requires an additional list-processing workaround. The one I chose wasn't too involved: I added yet another list at the top of that step that was filled with empty strings. This guaranteed that there was always some kind of result for the DOLIST step, and that output won't adversely affect the final string. It also ended up negating the need to work around the \GSLIST quirk as well. But as expected, it made the code bigger, a bit slower, and somewhat uglier all at the same time.

I really want to like the list processing commands. This application is clearly not a good one for them, though.