In article <············@mughi.cs.ubc.ca>, Lowell Kirsh wrote:
> how can I convert an integer to a string?
>
> Lowell
>
PRINC-TO-STRING
PRIN1-TO-STRING
WRITE-TO-STRING
(FORMAT nil "~D" int)
(FORMAT nil "~R" int)
There are probably 20 more.
Andrew Philpot wrote:
> In article <············@mughi.cs.ubc.ca>, Lowell Kirsh wrote:
>
>>how can I convert an integer to a string?
>>
>>Lowell
>
> PRINC-TO-STRING
> PRIN1-TO-STRING
> WRITE-TO-STRING
> (FORMAT nil "~D" int)
> (FORMAT nil "~R" int)
>
> There are probably 20 more.
BTW, what do the abbreviations "1" and "C" mean in PRIN1 and PRINC?
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
From: Christopher C. Stacy
Subject: Re: convert an integer to a string
Date:
Message-ID: <uy8wa94q2.fsf@dtpq.com>
>>>>> On Fri, 26 Sep 2003 10:30:47 +0200, Pascal Costanza ("Pascal") writes:
Pascal> Andrew Philpot wrote:
>> In article <············@mughi.cs.ubc.ca>, Lowell Kirsh wrote:
>>
>>> how can I convert an integer to a string?
>>>
>>> Lowell
>> PRINC-TO-STRING
>> PRIN1-TO-STRING
>> WRITE-TO-STRING
>> (FORMAT nil "~D" int)
>> (FORMAT nil "~R" int)
>> There are probably 20 more.
Pascal> BTW, what do the abbreviations "1" and "C" mean in PRIN1 and PRINC?
I bet that when the original implementation of LISP was being coded,
there was at first a subroutine called PRINT. The first time that
someone wanted to print something without a Newline after it, they
added another entrypoint labeled PRIN1 (which set some kludgey flag
and then dropped or skipped into the mainline PRINT code).
That style of coding was very common, but I'm just making that up!
The MACLISP (PDP-10) "New IO" source code is roughly in that style,
where PRIN1 sets a flag bit and jumps into the common printing
code (whose labels include, for example: PRINT3, PRINT5, PRIN7A).
But by this time, PRIN1 was already invented, so that's not really
a causal explanation - it's just faintly suggestive.
On the other hand, the code for PDP-1 LISP has comments like
"print, sub one" for the label pn1, but that's not PRIN1!
PRIN1 is label pr1, and doesn't share code with PRINT except
at the lowest (print character) routine.
Another explanation I've heard is that PRIN1 means "print one atom".
This historical theory says that Newline was originally not a break
character for READ, but Space was. (A few more details about IO would
have to be filled in before I would entirely believe this, though.)
It is possible that both (or neither) of those explanations is true.
PRINC is a much more recent function: I think it may have first
appeared in MACLISP. The "C" almost certainly refers to "character",
but the exact connotation escapes me, as it were.
This would be a good question to ask McCarthy at the Lisp conference.
* Pascal Costanza:
| BTW, what do the abbreviations "1" and "C" mean in PRIN1 and PRINC?
* Christopher C. Stacy:
| I bet that when the original implementation of LISP was being coded,
| there was at first a subroutine called PRINT. The first time that
| someone wanted to print something without a Newline after it, they
| added another entrypoint labeled PRIN1 (which set some kludgey flag
| and then dropped or skipped into the mainline PRINT code).
:
| Another explanation I've heard is that PRIN1 means "print one atom".
| This historical theory says that Newline was originally not a break
| character for READ, but Space was. (A few more details about IO would
| have to be filled in before I would entirely believe this, though.)
|
| It is possible that both (or neither) of those explanations is true.
|
| PRINC is a much more recent function: I think it may have first
| appeared in MACLISP. The "C" almost certainly refers to "character",
| but the exact connotation escapes me, as it were.
I was under the impression that PRINC abbreviates `PRINt without
esCape characters' or `PRINt without escape Characters'.
Btw, Interlisp knew PRIN1, PRIN2, PRIN3 and PRIN4, where PRIN2 was an
equivalent to MacLisp's PRINC.
--
"Hurry if you still want to see something. Everything is vanishing."
-- Paul C�zanne (1839-1906)
* Pascal Costanza:
| BTW, what do the abbreviations "1" and "C" mean in PRIN1 and PRINC?
* Christopher C. Stacy:
| I bet that when the original implementation of LISP was being coded,
| there was at first a subroutine called PRINT. The first time that
| someone wanted to print something without a Newline after it, they
| added another entrypoint labeled PRIN1 (which set some kludgey flag
| and then dropped or skipped into the mainline PRINT code).
:
| Another explanation I've heard is that PRIN1 means "print one atom".
| This historical theory says that Newline was originally not a break
| character for READ, but Space was. (A few more details about IO would
| have to be filled in before I would entirely believe this, though.)
|
| It is possible that both (or neither) of those explanations is true.
|
| PRINC is a much more recent function: I think it may have first
| appeared in MACLISP. The "C" almost certainly refers to "character",
| but the exact connotation escapes me, as it were.
* Wolfhard:
| I was under the impression that PRINC abbreviates `PRINt without
| esCape characters' or `PRINt without escape Characters'.
|
| Btw, Interlisp knew PRIN1, PRIN2, PRIN3 and PRIN4, where PRIN2 was an
| equivalent to MacLisp's PRINC.
No. Interlisp's equivalent to PRINC was PRIN1.
Interlisp's equivalent to MacLisp's PRIN1 was PRIN2 which took a
readtable as its third argument.
PRIN3 and PRIN4 differed from PRIN1 and PRIN2 with respect to end of
line handling.
--
"Hurry if you still want to see something. Everything is vanishing."
-- Paul C�zanne (1839-1906)
In article <··············@buss-14250.user.cis.dfn.de>,
Wolfhard Bu� <·····@gmx.net> wrote:
>* Christopher C. Stacy:
>| PRINC is a much more recent function: I think it may have first
>| appeared in MACLISP. The "C" almost certainly refers to "character",
>| but the exact connotation escapes me, as it were.
>
>I was under the impression that PRINC abbreviates `PRINt without
>esCape characters' or `PRINt without escape Characters'.
My theory is that it's "PRINt Characters", i.e. it just prints the
characters in the symbol's name, not.
BTW, my theory about why they're PRIN1 and PRINC rather than PRINT1 and
PRINTC is because the PDP-10 had 36-bit words and Lisp used 7-bit
characters. So 5-character names avoided overflowing into a second word.
--
Barry Margolin, ··············@level3.com
Level(3), Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
From: Christopher C. Stacy
Subject: Re: convert an integer to a string
Date:
Message-ID: <u8yo43cmw.fsf@dtpq.com>
Well, I asked McCarthy about the names PRIN1 and PRINC.
He thinks he probably invented them, but can't remember
at all how they came to be named that, or whether any
of the stories proposed here would be true.
So, there's a piece of historical trivia that we may never really know!
(Maybe it was ancient astronauts...)
Pascal Costanza wrote:
> BTW, what do the abbreviations "1" and "C" mean in PRIN1 and PRINC?
This thread started by Eric Naggum contains some plausible explanations:
<http://groups.google.com/groups?q=princ+lisp+history&hl=en&lr=&ie=UTF-8&selm=3216868380267773%40naggum.net&rnum=1>
Among them this one passed along by Kent Pitman:
> JonL passed along this reply:
>> Over the years, I've modified my "recall" of the print issues.
>> But it seemed clear to me that the princ/prin1/print series were a
>> staged effort at writing the text-representation-printer in Lisp.
>> (1) "PRINt the Characters"
>> of some object,
>> (2) PRINt the characters of 1 particular object in
>> suuch a way that the "identity" of the object can be preserved if
>> possible,
>> (3) PRINT compound object allowing for the need to return the
>> "carriage" of type keys and advance the line/paper-feed on thes old
>> Model 33 and 35 TTY units.
--
Jens Axel S�gaard
thanks. I also just realised i can do (format nil "~A" 42)
Kenny Tilton wrote:
>
>
> Lowell Kirsh wrote:
>
>> how can I convert an integer to a string?
>>
>> Lowell
>>
>
> (princ-to-string 42) -> "42"
>
> kt
>
In article <············@mughi.cs.ubc.ca>,
Lowell Kirsh <······@cs.ubc.ca> wrote:
> thanks. I also just realised i can do (format nil "~A" 42)
If you care about speed and consing, be sure to benchmark the effects of
which you choose, and the binding of *print-pretty* when you print. For
example, on SBCL/Darwin:
(progn
(time (loop repeat 100 do (princ-to-string 42)))
(time (loop repeat 100 do (format nil "~A" 42)))
(let ((*print-pretty* nil))
(time (loop repeat 100 do (princ-to-string 42)))
(time (loop repeat 100 do (format nil "~A" 42)))))
80 bytes consed.
80080 bytes consed.
80 bytes consed.
21680 bytes consed.
-bcd
--
*** Brian Downing <bdowning at lavos dot net>
Brian Downing <·············@lavos.net> writes:
> In article <············@mughi.cs.ubc.ca>,
> Lowell Kirsh <······@cs.ubc.ca> wrote:
> > thanks. I also just realised i can do (format nil "~A" 42)
>
> If you care about speed and consing, be sure to benchmark the effects of
> which you choose, and the binding of *print-pretty* when you print. For
> example, on SBCL/Darwin:
>
> (progn
> (time (loop repeat 100 do (princ-to-string 42)))
> (time (loop repeat 100 do (format nil "~A" 42)))
> (let ((*print-pretty* nil))
> (time (loop repeat 100 do (princ-to-string 42)))
> (time (loop repeat 100 do (format nil "~A" 42)))))
>
> 80 bytes consed.
> 80080 bytes consed.
> 80 bytes consed.
> 21680 bytes consed.
In clisp, the differences in space seem to be smaller:
[2]> (progn
(time (loop repeat 100 do (princ-to-string 42)))
(time (loop repeat 100 do (format nil "~A" 42)))
(let ((*print-pretty* nil))
(time (loop repeat 100 do (princ-to-string 42)))
(time (loop repeat 100 do (format nil "~A" 42)))))
Real time: 0.001228 sec.
Run time: 0.0 sec.
Space: 66372 Bytes
Real time: 0.002438 sec.
Run time: 0.01 sec.
Space: 73172 Bytes
Real time: 9.6E-4 sec.
Run time: 0.0 sec.
Space: 34372 Bytes
Real time: 0.044416 sec.
Run time: 0.04 sec.
Space: 41172 Bytes
GC: 1, GC time: 0.04 sec.
NIL
--
__Pascal_Bourguignon__
http://www.informatimago.com/
Do not adjust your mind, there is a fault in reality.
Brian Downing <·············@lavos.net> writes:
> (time (loop repeat 100 do (princ-to-string 42)))
> 80 bytes consed.
This number is highly suspicious as 100 strings of "42" were
supposed to be constructed. With Debian SBCL 0.8.3-2 on i386, I
steadily get 0 bytes consed, even with MOST-POSITIVE-FIXNUM
(=#x1FFFFFFF) iterations. It looks like the compiler is
optimizing out the entire call. If I thwart that with:
(defun discard (arg)
(declare (ignore arg)))
(compile 'discard)
(time (loop repeat 100000 do (discard (princ-to-string 42))))
I get 62478264 bytes consed, which means 625 bytes per iteration.
With *PRINT-PRETTY* bound to nil, the sum drops to 4836728, or 48
bytes per iteration.
In article <··············@Astalo.kon.iki.fi>,
Kalle Olavi Niemitalo <···@iki.fi> wrote:
> This number is highly suspicious as 100 strings of "42" were
> supposed to be constructed. With Debian SBCL 0.8.3-2 on i386, I
> steadily get 0 bytes consed, even with MOST-POSITIVE-FIXNUM
> (=#x1FFFFFFF) iterations. It looks like the compiler is
> optimizing out the entire call. If I thwart that with:
>
> (defun discard (arg)
> (declare (ignore arg)))
> (compile 'discard)
> (time (loop repeat 100000 do (discard (princ-to-string 42))))
>
> I get 62478264 bytes consed, which means 625 bytes per iteration.
> With *PRINT-PRETTY* bound to nil, the sum drops to 4836728, or 48
> bytes per iteration.
True, I wasn't entirely awake when I posted those numbers. I just
remember seeing people bitten and suprised by how much overhead (both
time and space) *PRINT-PRETTY* added to their print operations when they
didn't care about "prettyness".
-bcd
From: Joe Marshall
Subject: Re: convert an integer to a string
Date:
Message-ID: <7k3vpsok.fsf@ccs.neu.edu>
Lowell Kirsh <······@cs.ubc.ca> writes:
> how can I convert an integer to a string?
Technically speaking, you cannot: both are abstractions over unrelated
domains.
There is, however, a popular mapping between the two. I'd suggest
PRIN1-TO-STRING or PRINC-TO-STRING
If you need performance on a limited range of integers,
put the strings in an array:
(defun digit-to-string (n)
(svref #("0" "1" "2" "3" "4" "5" "6" "7" "8" "9") n))
"Joe Marshall" <···@ccs.neu.edu> wrote in message
·················@ccs.neu.edu...
> Lowell Kirsh <······@cs.ubc.ca> writes:
>
> If you need performance on a limited range of integers,
> put the strings in an array:
>
> (defun digit-to-string (n)
> (svref #("0" "1" "2" "3" "4" "5" "6" "7" "8" "9") n))
But be careful not to modify the string you get...
> (digit-to-string 3)
"3"
> (let ((s (digit-to-string 3)))
(setf (aref s 0) #\A))
#\1
> (digit-to-string 3)
"1"
--
Matthieu Villeneuve
From: Joe Marshall
Subject: Re: convert an integer to a string
Date:
Message-ID: <4qyzpiht.fsf@ccs.neu.edu>
"Matthieu Villeneuve" <········@nospam.matthieu-villeneuve.net> writes:
> "Joe Marshall" <···@ccs.neu.edu> wrote in message
> ·················@ccs.neu.edu...
>> Lowell Kirsh <······@cs.ubc.ca> writes:
>>
>> If you need performance on a limited range of integers,
>> put the strings in an array:
>>
>> (defun digit-to-string (n)
>> (svref #("0" "1" "2" "3" "4" "5" "6" "7" "8" "9") n))
>
> But be careful not to modify the string you get...
``That would be bad.''
(not to mention illegal because that vector is embedded)
"Matthieu Villeneuve" <········@nospam.matthieu-villeneuve.net> wrote in
message ·····························@news.free.fr...
> "Joe Marshall" <···@ccs.neu.edu> wrote in message
> ·················@ccs.neu.edu...
> > Lowell Kirsh <······@cs.ubc.ca> writes:
> >
> > If you need performance on a limited range of integers,
> > put the strings in an array:
> >
> > (defun digit-to-string (n)
> > (svref #("0" "1" "2" "3" "4" "5" "6" "7" "8" "9") n))
>
> But be careful not to modify the string you get...
>
> > (digit-to-string 3)
> "3"
>
> > (let ((s (digit-to-string 3)))
> (setf (aref s 0) #\A))
Oops... Replace #\A with #\1 (sorry)...
> #\1
>
> > (digit-to-string 3)
> "1"
--
Matthieu Villeneuve