Todd McLaughlin wrote:
> Is there a function built in to Lisp that would return a symbol or string
> of a decimal number?
>
You can convert any output to string by using format on the nil stream:
(format nil "a" 123)
"123"
Todd McLaughlin <·····@waltz.rahul.net> writes:
< Is there a function built in to Lisp that would return a symbol or string
< of a decimal number?
<
< Todd
<
< --
You could use (princ-to-string 1), but I think from your title you
may want (format nil "~R" 1).
I just found out that you can have a number as a symbol in cl. Pretty
neat, but probably not a great idea.
(intern "1") => |1|
> < Is there a function built in to Lisp that would return a symbol or string
> < of a decimal number?
(format()"~,vF" 2 1.2345) -> "1.23"
3rd argument control deciaml places.
Marc Dzaebel (http://members.xoom.com/dzaebel)
Steve Gonedes <········@worldnet.att.net> writes:
> I just found out that you can have a number as a symbol in cl. Pretty
> neat, but probably not a great idea.
>
> (intern "1") => |1|
>
Maybe not, but where do you draw the line between numbers and letters?
USER(1): (setq *read-base* 36)
36
USER(2): z
35
USER(3): (|LIST| z (|INTERN| "z"))
(35 |z|)
USER(4):
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
Duane Rettig <·····@franz.com> writes:
> Steve Gonedes <········@worldnet.att.net> writes:
>
> > I just found out that you can have a number as a symbol in cl. Pretty
> > neat, but probably not a great idea.
> >
> > (intern "1") => |1|
> >
>
> Maybe not, but where do you draw the line between numbers and letters?
>
> USER(1): (setq *read-base* 36)
> 36
> USER(2): z
> 35
> USER(3): (|LIST| z (|INTERN| "z"))
> (35 |z|)
> USER(4):
Since *read-base* is not bound by LOAD and COMPILE-FILE (arguably a bug
we should fix), it's a bad idea to assume they'll be set right in code files
since code can't manipulate that in a structured way like it can manipulate
*package* and *readtable*.
You can always put \ in front of the first character to emphasize the
use as a symbol constituent character. e.g.,
(let ((\2 3)) (+ \2 \2)) => 6
Long ago, Lisp used to be defaultly base 8, and there was an enormous
war needed to convince certain parties that base 10 was the right default
base. Some of us were sick to death about bug reports saying that +
was broken because (+ 5 5) => 12 in Maclisp (on the PDP10) by default.
Fortunately, reason prevailed.
Kent M Pitman <······@world.std.com> writes:
> Duane Rettig <·····@franz.com> writes:
>
> > USER(1): (setq *read-base* 36)
> > 36
> > USER(2): z
> > 35
> > USER(3): (|LIST| z (|INTERN| "z"))
> > (35 |z|)
> > USER(4):
>
> Since *read-base* is not bound by LOAD and COMPILE-FILE (arguably a bug
> we should fix), it's a bad idea to assume they'll be set right in code files
> since code can't manipulate that in a structured way like it can manipulate
> *package* and *readtable*.
Yes, I suppose I should not have assumed anything about the initial
value of *read-base*, and said (minimally):
(\Setq *read-base* 36.)
followed by
(\List z (\Intern "z"))
> You can always put \ in front of the first character to emphasize the
> use as a symbol constituent character. e.g.,
>
> (let ((\2 3)) (+ \2 \2)) => 6
Excellent. Remember the old Obfuscated C code contests? ...
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
Yes, there is. Check out the hyperspec, Chapter 22.3 "Formatted Output"
Here are some cool examples, as a highlight to whet your appetite. I
suspect this was what you meant in your question, not just
reformatting the digits.
CL-USER 92 > (defun spellnum (x)
(format nil "~r" x))
SPELLNUM
CL-USER 93 > (spellnum 23)
"twenty-three"
CL-USER 94 >
CL-USER 96 > (defun ordinal (x)
(format nil "~:R" x))
ORDINAL
CL-USER 97 > (ordinal 5)
"fifth"
* Michael Tuchman wrote:
> Here are some cool examples, as a highlight to whet your appetite.
These examples are insufficiently cool! The *really* cool one is:
> (format t "~&·@R~%" 1234)
MCCXXXIV
Not only that but there are other flavours (well, one other flavour)
of roman numeral output!
It is a serious deficiency of CL that there is no printer control
variable which causes numbers to be printed in roman numerals by
default.
--tim
Tim Bradshaw <···@aiai.ed.ac.uk> writes:
> It is a serious deficiency of CL that there is no printer control
> variable which causes numbers to be printed in roman numerals by
> default.
In Maclisp, it used to be possible to set BASE and IBASE (the early
precursors of *print-base* and *read-base*, respectively) to ROMAN
instead of an integer and the reader would parse roman numerals. We
got rid of this for a variety of reasons, not the least of which is
that it didn't make a lot of sense to have and it complicated all
programs that deal with bases because you couldn't use numerical operations
on the values of *print-base* and *read-base*. (I think on the Lisp Machine
there are values you can set, like :roman and :english for *print-base*;
I'm not sure if read bases are still supported.)
But there were also visual problems. Consider:
(+ X X) => XX
but that means (lambda (x) (+ x 1)) is invalid syntax while
(lambda (y) (+ y 1)) is fine. Also, of course, roman doesn't
support negative, float, or large positive (for relatively small
values of "large", even) integers.
Bottom line: Been there, done that, too bad there was no t-shirt
to have gotten for it.
* Kent M Pitman wrote:
> (I think on the Lisp Machine
> there are values you can set, like :roman and :english for *print-base*;
> I'm not sure if read bases are still supported.)
In Genera 8.3 *print-base* = :roman definitely works, I don't think
*read-base* can do anything weird.
> Also, of course, roman doesn't
> support negative, float, or large positive (for relatively small
> values of "large", even) integers.
I obviously have too little to do, because I tried this in the 5 CLs I
have to hand: is the largest number that Roman numerals can deal with
really only 3999 (= MMMCMXCIX)? Should we start worrying about the
Y4k problem yet?
--tim
Tim Bradshaw wrote:
>
> * Kent M Pitman wrote:
> > (I think on the Lisp Machine
> > there are values you can set, like :roman and :english for *print-base*;
> > I'm not sure if read bases are still supported.)
>
> In Genera 8.3 *print-base* = :roman definitely works, I don't think
> *read-base* can do anything weird.
>
> > Also, of course, roman doesn't
> > support negative, float, or large positive (for relatively small
> > values of "large", even) integers.
>
> I obviously have too little to do, because I tried this in the 5 CLs I
> have to hand: is the largest number that Roman numerals can deal with
> really only 3999 (= MMMCMXCIX)?
Theorem: There are an unlimited number of Roman numerals.
Proof:
Assume MMMM is the largest Roman numeral.
By the definition of Roman numerals (omitted for space) any numeral N
may be increased by adding I to its end, then simplifying the entire
numeric
expression. Therefore MMMM + I is MMMMI. This contradicts the
original
assumption. We can generalize this to any chosen numeral, so there is
most
probably a number of Roman numerals which is equal to the number of
natural
numbers. The rest of the proof is left as an exercise.
Not quite rigorous, but you get the point.
Is 3999 the largest number that *Lisp* Roman numerals can deal with?
Almost always. In CLTL2:
#| For ·@R and ··@R , nearly all implementations produce Roman numerals
only for
#| integers in the range 1 to 3999 inclusive. Some implementations will
produce
#| old-style Roman numerals in the range 1 to 4999 inclusive. All other
integers
#| are printed in decimal notation, as if ~D had been used.
> Should we start worrying about the Y4k problem yet?
Let's put that off until 3000 or so. That gives us a whole millenium to
solve the problem, and it should be trivial because we would likely have
self-programming systems that wouldn't need explicit instructions to
work. Or whatever.
It shouldn't be that difficult to represent even larger roman numerals,
but the implementation would probably be better done in pure Lisp
instead of in FORMAT.
At one point I had a fn that converted numbers up to 5999 but I didn't
keep it around. The output was unreadable anyway. ;-)
I wonder what the difficulty of representing flonums in roman numerals
would be. I've never tried... Anyone who did would kinda have to make
it up as they go.
The reason why the standards committees never broached such topics is
because they knew that the actual representations were never formally
stated before and if they did decide to implement flonums or somesuch
that they'd have to make up some weird representation that nobody had
ever heard of before. If there were already a representation it would
probably have been made historically (like last century or earlier) and
so they'd come under fire from some kooky mathematician lor historian
lor number freak which would make them look silly. So they skipped it.
At least, that's what I think.
fnord,
james
"James A. Crippen" <········@saturn.math.uaa.alaska.edu> writes:
> Tim Bradshaw wrote:
> >
> > I obviously have too little to do, because I tried this in the 5 CLs I
> > have to hand: is the largest number that Roman numerals can deal with
> > really only 3999 (= MMMCMXCIX)?
>
> Theorem: There are an unlimited number of Roman numerals.
> Proof:
> Assume MMMM is the largest Roman numeral.
> By the definition of Roman numerals (omitted for space) any numeral N
> may be increased by adding I to its end, ...
Uh, I think this "definition" is an "assumption", and I'm not sure
it's valid. It's true that by a string of I's can be replicated
indefinitely, you can prove any number can be represented.
But that's not the same as saying the Romans did things that way.
I don't know if it's a rule but it seems an obvious truth that the
romans did not like there to be more than three of anything in a row.
Hence the absence of IIII in so-called "new style" roman numerals,
preferring IV. There is always a 5-marker in between any power of 10.
I II III IV V VI VII VIII IX X
X XX XXX XL L LX LXX LXXX XC C
C CC CCC CD D DC DCC DCCC CM M
M MM MMM M?
Sure, you can go higher by claiming the romans would have been happy
with lots of replicated M's, but I don't think it's so. As I recall,
and I didn't go look it up, they had larger numbers but they required
overbars on the existing letters to represent. As such, I think 3999
is the upper bound on what you can represent in roman numerals with the
character set CL is defined to use, since I think above that you need
characters like M-bar (or the ability to attach a non-letter "bar"
notation to the top of an M, which amounts to the same if you're
trying to use portable CL-style strings and output). [An implementation
might extend the behavior but is not required to.]
And there is a practical reason for not replicating I's. If someone
accidentally printed most-positive-fixnum through this mechanism,
especially if it was to a string, the amount of consing required
would be extreme. Most uses of roman numerals in practice are very
bounded--e.g., to talk about "outline" nodes at a given level, where
reaching 4000 would seem to suggest you forgot tome needed subheads;
or to talk about human years, where mankind is expected to kill itself
off in far less time with nuclear bombs, biological or chemical weapons,
or excessive use of C++.
> I wonder what the difficulty of representing flonums in roman numerals
> would be.
Did you program once in Maclisp? In 1984, Maclisp flonums were
replaced with CL floats.
When I was working on T (Yale Scheme), I remember running into the
funniness that if you aren't careful, floats can print out in the
prevailing integer base. 2.4 octal meaning 2.5 decimal, for example.
I never tried, but assume it would be a mess for roman numerals
because I don't think the Romans had a 0. Certainly their number
notation had no such placeholder. And so the difficulty is
representing 1.01 distinct from 1.1. The real problem being that
decimals convey additional, non-magnitude-related information
by "column", which is antithetical to what roman numerals do.
It's been years since I did math involving infinities, so I'm really
out on a limb with this one, but I seem to recall there are the same
number of natural numbers as rationals; and if that's so, I suppose
you could write a program to generate all rational numbers in a
certain order and then assign each a corresponding roman numeral.
So 1 would be I, 1-1/2 would be I.I, 1-1/3 would be I.II, 1-2/3
would be I.III, 1-1/4 would be I.IV, 1-3/4 would be I.V, etc.
But it seems a little tedious and would make virtually all operations
(including addition, subtraction, and comparison) pretty slow.
It's pretty easy to understand how early societies decided just to
make hours divided into minutes and then count integer numbers of
minutes rather than fractions of hours. And, I'm told, they had
to make a second minute to divide up minutes when they were too
big, which is how the word "second" supposedly happened.
Don't have a firm reference to that etymology, but it makes sense.
Kent Pitman wrote:
> I never tried, but assume it would be a mess for roman numerals
> because I don't think the Romans had a 0. Certainly their number
> notation had no such placeholder. And so the difficulty is
> representing 1.01 distinct from 1.1. The real problem being that
> decimals convey additional, non-magnitude-related information
> by "column", which is antithetical to what roman numerals do.
I think the way to go would be to work with the decimals in
*reverse*. In other words, 123.321 would become CXXIII.IIIXXC,
and 1.001 would become I.C . It might make it a bit clearer
if we used different cases for before and after the decimal
point: CXXIII.iiixxc .
Of course, this is mathematically quite elegant and therefore
not remotely something the Romans would ever have done. :-)
--
Gareth McCaughan Dept. of Pure Mathematics & Mathematical Statistics,
·····@dpmms.cam.ac.uk Cambridge University, England.