We have the need to convert numberic values (integers only, fortunately!) into text, e.g. 90 to "ninety", 250 to "two hundred and fifty". A couple of questions:

1. Is there anything in OI that will do this for you? For example, is there some undocumented use of OConv() that will do this for you?

2. If not, does anyone out there have a program to do this?

We can write our own program, of course, but we don't want to reinvent the wheel if we don't need to.

Fred,

I have often wondered why there is no ICONV/OCONV for this. Well I have created one for myself. It is an UDC and works up to 999,999,999

I use it for check printing. An example of an OCONV of "1234" would be "TWELVE AND 34/100". If you are interested email me at rhunt@zzzttt.com

Fred,

We have the need to convert numberic values (integers only, fortunately!) into text, e.g. 90 to "ninety", 250 to "two hundred and fifty". A couple of questions: 1. Is there anything in OI that will do this for you? For example, is there some undocumented use of OConv() that will do this for you? 2. If not, does anyone out there have a program to do this? We can write our own program, of course, but we don't want to reinvent the wheel if we don't need to.

I think is the kind of program that programming students are told to reinvent all the time.

I remember it has been discussed before. There is at least one solution in this thread:

In this posting Glenn Bryant says he has a solution:

- Oystein -

Oystein ..

Absolutely right. I think I've written this routine in at least 4 languages over the years. It's a pretty simple task and is commonly assigned to CS students early on .. along with sorting strategies.

The posts you point to are pretty much the way it has to be done .. essentially a parser for the whole digits position and a way to handle the non-integer portion (cents for check printing, etc.).

The most efficient way to parse the integer portion is by using its length rather than doing numeric compares (which is much slower). I have a routine that will handle numbers up to 16 digits in the integer portion. The fun part is dealing with magnitude in the millions and up, but that's only a magnitude problem. One way to handle this is to do something like:

Oconv the number into a comma-separated value for the integer portion and use the comma's to index into the magnitude array so you can get "hundred million", etc., but I'm sure you know this as well as I do.

Don M.

Don,

Here's all I can manage tonight:

Text="
begin case
case Num=1
   Text=one"
case Num=2
   Text=two"
case Num ] 2
   Text=many"
end case

- Oystein -

Oystein ..

Now that's a good one on a weekend. Thanks, I needed that.

Don M.

I would suggest .. that if it is a good O/Iconv routine then send it off to RTI and see if Michael will make it available through the Knowledge base

dsig@sigafoos.org

DSigs Radio Free Oregon

DSig,

Yes, and remember to include versions for all languages.

And "eleventy-one", for Tolkien fans.

- Oystein -

oy] Yes, and remember to include versions for all languages.

Well .. now that you mention it ..

1) all of the worlds problems would be fixed if we just all used english

2) after a bit of time in England I must admint that #1 is to broad and should be changed to '.. all used American'

and

3) Of course .. being open source it would then allow those of use who speak multiple languages to enhance it ..

Ah .. the wonders of open source

Careful .. or I will slap on 200 Motels again

dsig@sigafoos.org

DSigs Radio Free Oregon

Ok, you have inspired me to comment.

I have no doubt that Mike will create his own UDC for number to text within the end of the week.

I also have no doubt that Revelation will not even consider fixing the select list fragmentation flaw for the release of 7.0

I keep thinking… thwarted priorities.

I would consider a deal… Revelation can spend the time fixing the select list fragmentation flaw and I will offer my source code, for the number to text UDC, to the "Revelation open source" group.

Richard,

I would consider a deal… Revelation can spend the time fixing the select list fragmentation flaw and I will offer my source code, for the number to text UDC, to the "Revelation open source" group.

I don't want to take anything away from your frustration or legitimate desire to see a core issue fixed. However, the above proposal (however tongue-in-cheek it was meant to be) is not always reality. Most likely the resource who might have worked on a new UDC wouldn't be the same resource who is/might be working on the select list fragmentation problem…unless they are both Basic+ solutions (which I'm not sure of.) My point is that Revelation can easily throw in a new UDC without affecting their work in the fragmentation issue because they have people who would otherwise be doing work other than what you want them to focus on.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Thank you everyone for both your advice and your humor. Our internet service has been down for the past few days, so I wasn't able to check all these postings, however, in the time that our service was down, I wrote my own program. (though it doesn't convert 111 to "eleventy one", unfortunately)

DSig,

Just remember to add in a cardinal/ordinal flag into the conversion code, then you can enjoy the TWO HUNDREDTH hotel as much as all TWO HUNDRED.

Steve

dsig@sigafoos.org

DSigs Radio Free Oregon

View this thread on the forum...