Hey guys,
I'm looking for a program or an algorithm that could tell me how to convert
roman numbers to integers and vice versa.
I would really appreciate your help.
Thanks,
Yourik
"Yourik Hacoupian" <·········@sympatico.ca> wrote in message news:<······················@news20.bellglobal.com>...
> Hey guys,
> I'm looking for a program or an algorithm that could tell me how to convert
> roman numbers to integers and vice versa.
> I would really appreciate your help.
>
> Thanks,
> Yourik
Common Lisp has built-in capability to convert from integer to Roman,
in the format function. And there is a quirk of Roman Numerals that
makes it fairly easy to use that one-way conversion to covert the
other way too.
I'm curious to know what you're going to use such conversions for. I
only see a use for the built-in conversion and not the opposite
direction. If this is homework you have to tell us what you tried and
where you're stuck, not just ask us to do all the work for you without
even trying it yourself.
In article <······················@news20.bellglobal.com>,
Yourik Hacoupian wrote:
> Hey guys,
> I'm looking for a program or an algorithm that could tell me how to convert
> roman numbers to integers and vice versa.
> I would really appreciate your help.
Is this homework? It sure looks like homework. Post what you have
done and let people comment on it.
marc
>
> Thanks,
> Yourik
>
>
"Yourik Hacoupian" <·········@sympatico.ca> writes:
> Hey guys,
> I'm looking for a program or an algorithm that could tell me how to convert
> roman numbers to integers and vice versa.
> I would really appreciate your help.
(defun integer-to-roman (n &optional (modern t))
(if modern
(format nil ··@R" n)
(format nil ···@R" n)))
(defun roman-to-integer (r)
;; Romans didn't believe in 0 and Roman numerals bigger than 3999
;; are not possible in ASCII because there is no overbar character.
;;
;; I seem to be the only one who is concerned so far, but the movie
;; industry is due to suffer a Y4K bug if they are still by that
;; time relying on ASCII renditions of their copyright date...
;;
(or (loop for i from 1 to 3999
when (or (string-equal r (integer-to-roman i t))
(string-equal r (integer-to-roman i nil)))
return i)
(error "Not roman numerals: ~A" r)))
Kent M Pitman <······@world.std.com> writes:
> ;; I seem to be the only one who is concerned so far, but the movie
> ;; industry is due to suffer a Y4K bug if they are still by that
> ;; time relying on ASCII renditions of their copyright date...
Well, have you not thought of the Y10K bug. How do you thing many of
the Y2K bugs have been fixed? :)
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Marco Antoniotti <·······@cs.nyu.edu> writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > ;; I seem to be the only one who is concerned so far, but the movie
> > ;; industry is due to suffer a Y4K bug if they are still by that
> > ;; time relying on ASCII renditions of their copyright date...
>
> Well, have you not thought of the Y10K bug. How do you thing many of
> the Y2K bugs have been fixed? :)
Yes, of course I've thought of the Y10K bug. Someone proposed a fix
in some Teco code I'd written at MIT ages ago that repaired a Y2K bug
by adding a Y10K bug. I narrowly averted a disaster by suggesting a
more general solution that was Y10K compliant...
But the Y10K bug is both far afield and something that most people are
easily aware of after the hassle of Y2K. Y4K, on the other hand, is
much closer, and this bug is more obscure. Even after the problems of
Y2K, and even after the rollover into an extremely boring run of
numerals with the change of millenium, the movie industry insists on
labeling its movies with roman numeraled dates ... very ill-advised if
you ask me. Not that they do.
"Kent M Pitman" <······@world.std.com> wrote in message
····················@shell01.TheWorld.com...
> But the Y10K bug is both far afield and something that most people are
> easily aware of after the hassle of Y2K. Y4K, on the other hand, is
> much closer, and this bug is more obscure. Even after the problems of
> Y2K, and even after the rollover into an extremely boring run of
> numerals with the change of millenium, the movie industry insists on
> labeling its movies with roman numeraled dates ... very ill-advised if
> you ask me. Not that they do.
It's not a problem -- they are so good at rewriting history that they will just
invent their own roman digits...
--
Martin Simmons, Xanalys Software Tools
······@xanalys.com
rot13 to reply
"Kent M Pitman" <······@world.std.com> wrote:
> But the Y10K bug is both far afield and something that most people are
> easily aware of after the hassle of Y2K. Y4K, on the other hand, is
> much closer, and this bug is more obscure. Even after the problems of
> Y2K, and even after the rollover into an extremely boring run of
> numerals with the change of millenium, the movie industry insists on
> labeling its movies with roman numeraled dates ... very ill-advised if
> you ask me. Not that they do.
Actually, this looks like an interesting case of older technology being
better. While the "modern" Roman numeral system runs into problems in
ASCII at Y4K, the "old style" Roman numerals get an extra 1000 years.
Instead of being limited merely to MMMCMXCIX you get all the way to
MMMMDCCCCLXXXXVIIII.
Of course, if it hadn't been for Common Lisp and the : modifier to the
Roman number printing, I wouldn't even have been aware that there were
two different styles for Roman numerals. Who would expect cultural
edification from a programming language specification?
--
Thomas A. Russ, USC/Information Sciences Institute ···@isi.edu
The world rejoiced as ···@sevak.isi.edu (Thomas A. Russ) wrote:
> "Kent M Pitman" <······@world.std.com> wrote:
>> But the Y10K bug is both far afield and something that most people are
>> easily aware of after the hassle of Y2K. Y4K, on the other hand, is
>> much closer, and this bug is more obscure. Even after the problems of
>> Y2K, and even after the rollover into an extremely boring run of
>> numerals with the change of millenium, the movie industry insists on
>> labeling its movies with roman numeraled dates ... very ill-advised if
>> you ask me. Not that they do.
>
> Actually, this looks like an interesting case of older technology being
> better. While the "modern" Roman numeral system runs into problems in
> ASCII at Y4K, the "old style" Roman numerals get an extra 1000 years.
> Instead of being limited merely to MMMCMXCIX you get all the way to
> MMMMDCCCCLXXXXVIIII.
>
> Of course, if it hadn't been for Common Lisp and the : modifier to the
> Roman number printing, I wouldn't even have been aware that there were
> two different styles for Roman numerals. Who would expect cultural
> edification from a programming language specification?
... And as we get towards Y10K, I would think it _entirely_ reasonable
to look at some of the other 19 letters of the Latin alphabet to
augment the numbering system.
--
(concatenate 'string "cbbrowne" ·@acm.org")
http://www.ntlug.org/~cbbrowne/spreadsheets.html
The English exam was a piece of cake---which was a bit of a surprise,
actually, because I was expecting some questions on a sheet of paper.
Christopher Browne <········@acm.org> writes:
> The world rejoiced as ···@sevak.isi.edu (Thomas A. Russ) wrote:
> > "Kent M Pitman" <······@world.std.com> wrote:
> >> But the Y10K bug is both far afield and something that most people are
> >> easily aware of after the hassle of Y2K. Y4K, on the other hand, is
> >> much closer, and this bug is more obscure. Even after the problems of
> >> Y2K, and even after the rollover into an extremely boring run of
> >> numerals with the change of millenium, the movie industry insists on
> >> labeling its movies with roman numeraled dates ... very ill-advised if
> >> you ask me. Not that they do.
> >
> > Actually, this looks like an interesting case of older technology being
> > better. While the "modern" Roman numeral system runs into problems in
> > ASCII at Y4K, the "old style" Roman numerals get an extra 1000 years.
> > Instead of being limited merely to MMMCMXCIX you get all the way to
> > MMMMDCCCCLXXXXVIIII.
> >
> > Of course, if it hadn't been for Common Lisp and the : modifier to the
> > Roman number printing, I wouldn't even have been aware that there were
> > two different styles for Roman numerals. Who would expect cultural
> > edification from a programming language specification?
>
> ... And as we get towards Y10K, I would think it _entirely_ reasonable
> to look at some of the other 19 letters of the Latin alphabet to
> augment the numbering system.
The other 19 letters? I'm afraid there aren't 19 more latin letters.
Maybe you want to just willy-nilly throw in greek letters like K, X,
and Y, and odd vulgarizations like J -- but why stop with kappa? If
we can have ypsilon, why not thorn? If we can have a lunging I, why
not I-hat? I think it's obvious where this sort of overly-broad
interpretation of the latin alphabet leads: chaos. No, I think we'll
be just fine using only actually latin letters.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Tim Bradshaw
Subject: Re: newbie: roman number conversion
Date:
Message-ID: <ey3n0yc5l17.fsf@cley.com>
* Kent M Pitman wrote:
> (defun roman-to-integer (r)
> ;; Romans didn't believe in 0 and Roman numerals bigger than 3999
> ;; are not possible in ASCII because there is no overbar character.
> ;;
> ;; I seem to be the only one who is concerned so far, but the movie
> ;; industry is due to suffer a Y4K bug if they are still by that
> ;; time relying on ASCII renditions of their copyright date...
> ;;
> (or (loop for i from 1 to 3999
> when (or (string-equal r (integer-to-roman i t))
> (string-equal r (integer-to-roman i nil)))
> return i)
> (error "Not roman numerals: ~A" r)))
I think this is the most brilliant solution to this problem I could
imagine. Noticing that the problem is small enough that what looks,
superficially, like a terrible solution is actually completely
tractable is wonderful!
--tim