On 11/18/05, adak <[EMAIL PROTECTED]> wrote:
Halfas, why is speed so important here? Any reasonable program would
rip through this task with blinding speed. Whether you can blink your
eyes once or twice before the work is done, who cares? Is this some
kind of a contest with other programmer's/students?
It seems to me that accessing the hard drive, (or heaven forbid, the
floppy/CD/optical drive), would itself take longer than the program
itself, to run.
In addition to Mayur's comments, I would add:
1) Make the data file a binary file (they're smaller than a text file
with the same data).
2) Open the file/access the file, also in binary mode (faster).
I believe Roman numerals are sensitive to position, because they don't
write "VIIII", for 9, they wrote it "IX". Same for 4, 49, 99, etc. So
where the 'I' is placed is important.
I didn't do this for my own program, but it seems like it would be very
fast to use a small array, which could probably be type char, 100 rows,
two columns, have the numbers in one colum, with the Roman numeral
equalling that arabic number, in the next column, and arranged so that
the array index IS the number, in every element of the array (a[1][0]
== '1', a[1][1] == 'I' , etc.).
Then every time you sprintf() through the input char array, to find the
numbers/numerals you want, you just use the number/numerals array to
find the correct answer. Arabic number finds are NOW, of course, and
Roman Numeral finds will be slower, but acceptable. I'm sure this will
be VERY FAST finds for the Arabic numbers, but for the RN's, it may be
faster to write a function to just translate them into arabic style,
without this array lookup, since they can't be indexed so favorably.
adak
--
=[ I don't have a solution, but i admire your problem ]=
