Hello All.
After a thoroughly enyoyable investigation with OmegaMan into the relative merits of different ways of converting a numeric value into its literal text representation, featuring his string-parse code and my old Basic digit-parse code, I managed to catch a pretty bad case of "feature fever," and decided to update and expand the cababilities of my old routine.
So, here it is. This .zip file contains the following files:
| NumberWriters.dll | The Library |
| NumberWriters.htm | The ReadMe file |
| NumberWriters.xml | The XML comments for Intellisense |
| NumberWritersDemo.exe | A short Windows Forms demo application |
Basically, this library contains classes which expose methods to convert numeric values into literal text, using enumerations to specify formatting options like capitalization and sign-handling. For example:
Given input of 23.45
| MoneyWriter.Verbose() would return: | Twenty-three Dollars And Forty-five Cents |
| NumberWriter.Verbose() would return: | twenty-three and forty-five hundredths |
| NumberWriter.Terse() would return: | two three point four five |
| NumberWriter.VerboseTerse() would return: | twenty-three point four five |
OmegaMan and I discovered rather promptly that using string literals and tightly coupling the data to the algorithms made our code at least an order of magnitude faster, but quite naturally at the cost of maintainability. My position has always been that if it's fast enough for the UI, then it's fast enough to suit me, so this library is not nearly as fast as the original routines OmegaMan and I were working with, but it is much more structured and maintainable. Still, the average time per call over random input size and data type ranges from 18 to 24 millionths of a second (3.07 GHz CPU).
OmegaMan and I both conceded that maintenance would be harder on the faster code we were working with, but since the only forseeable maintenance would involve adapting the code for different languages, with different number naming rules, maintenance would be a chore any way you slice it.
So, besides adding capability for different output styles, I tried to make it easier to maintain and adapt to different languages or output methods, like a LengthWriter class, for example, which would conceivably accept numeric input and return length in units.
Now, I tested for accuracy until I was blue-in-the-face, but that didn't take a really long time because, like most, my patience for testing is limited. Besides, testing something that mostly works is really, really, BORING!! So, I would very much appreciate any bug reports. Just post them here and I will look into it.
For those interested, I can post a link to the source code in a new thread for discussion of the object model I used and design considerations, but we'll have to corral a moderator's participation, because I don't want to start any flaming holy wars.
More converting numbers to text
Kuei-yang Lo