Q. for sublanguage lawyers: (format nil "~@D" 0) ==> ?
Pierpaolo Bernardi
what should be the result of
(format nil "~@D" 0)
?
The Hyperspec says:
HS> The @ modifier causes the number's sign to be printed always; the
HS> default is to print it only if the number is negative.
But zero has no sign, right?
The two implementations that I have handy return a different value:
LW "4.1.16 Beta" returns "+0"
Clisp "1998-08-05 (August 1998)" returns "0"
Is one of them buggy, or are both correct?
TYA.
Pierpaolo
Juanma Barranquero
Hash: SHA1
On 12 May 1999 08:41:08 GMT, bern...@cli.di.unipi.it (Pierpaolo
Bernardi) wrote:
>HS> The @ modifier causes the number's sign to be printed always;
>HS> the default is to print it only if the number is negative.
Well, "always" means always, I'd say.
>But zero has no sign, right?
So the problem is not if a sign must be printed, but "what sign?" Both
+0 and -0 seem valid answers.
>The two implementations that I have handy return a different value:
>
>LW "4.1.16 Beta" returns "+0"
>Clisp "1998-08-05 (August 1998)" returns "0"
Allegro 5.0 for Windows:
USER(90): (format nil "~@D" 0)
"+0"
/L/e/k/t/u
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.0.2i
iQA/AwUBNzk6EP4C0a0jUw5YEQJo3ACeIDPHc9fRAmoGWbX60KdWume2a5cAoMve
NxLh2MAWFJetSsUnu/tLQXN8
=Ab7K
-----END PGP SIGNATURE-----
Nick Levine
Guess I'd agree with you there.
> >But zero has no sign, right?
>
> So the problem is not if a sign must be printed, but "what sign?" Both
> +0 and -0 seem valid answers.
I think +0 is less damaged.
> >The two implementations that I have handy return a different value:
> >
> >LW "4.1.16 Beta" returns "+0"
> >Clisp "1998-08-05 (August 1998)" returns "0"
>
> Allegro 5.0 for Windows:
>
> USER(90): (format nil "~@D" 0)
> "+0"
Liquid CL:
> (format nil "~@D" 0)
"0"
>
<sigh>
- nick
Marco Antoniotti
Nick Levine <ni...@harlequin.co.uk> writes:
Of course...
CMU Common Lisp 18b, running on copernico
* (format nil "~@D" 0)
"+0"
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
Juanma Barranquero
Hash: SHA1
On Wed, 12 May 1999 10:21:57 +0100, Nick Levine <ni...@harlequin.co.uk>
wrote:
>I think +0 is less damaged.
Yes, I agree. But -0 wouldn't be noncompliant, I think. Just annoying
:)
/L/e/k/t/u
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.0.2i
iQA/AwUBNzlPXv4C0a0jUw5YEQIKmACgxtCZJli/JoMn6k1QDiJvyJyvPjkAoKTX
qC2T50lSaTjNnnCFJ2I11tZP
=EpKh
-----END PGP SIGNATURE-----
Jens Kilian
> >But zero has no sign, right?
IIRC, whether zero has a sign is implementation dependent.
Jens.
--
mailto:j...@acm.org phone:+49-7031-14-7698 (HP TELNET 778-7698)
http://www.bawue.de/~jjk/ fax:+49-7031-14-7351
PGP: 06 04 1C 35 7B DC 1F 26 As the air to a bird, or the sea to a fish,
0x555DA8B5 BB A2 F0 66 77 75 E1 08 so is contempt to the contemptible. [Blake]
Pierpaolo Bernardi
: IIRC, whether zero has a sign is implementation dependent.
For the float zeroes is implementation dependent.
Not so for integer zero.
Tschues
Pierpaolo
Kent M Pitman
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 12 May 1999 08:41:08 GMT, bern...@cli.di.unipi.it (Pierpaolo
> Bernardi) wrote:
>
> >HS> The @ modifier causes the number's sign to be printed always;
> >HS> the default is to print it only if the number is negative.
>
> Well, "always" means always, I'd say.
>
> >But zero has no sign, right?
>
> So the problem is not if a sign must be printed, but "what sign?" Both
> +0 and -0 seem valid answers.
>
> >The two implementations that I have handy return a different value:
> >
> >LW "4.1.16 Beta" returns "+0"
> >Clisp "1998-08-05 (August 1998)" returns "0"
>
> Allegro 5.0 for Windows:
>
> USER(90): (format nil "~@D" 0)
> "+0"
I'd say the dominant reason you want to use this is to have the columns
line up. Either +0 or -0 would make sense, since there is no distinction
between those for integers. +0 makes is more common sensical, so seems
the obvious choice. But absent language in the standard to require it
(which I assume you researched, because I didn't just now other than read
the original post here) certainly neither could be said to be nonconforming.
I would argue for clarifying this as "+0" in a future standard.
Pierpaolo Bernardi
: barra...@laley-actualidad.es (Juanma Barranquero) writes:
: I'd say the dominant reason you want to use this is to have the columns
: line up.
In my case, I was printing a localtime. Last time I used this program
(with no DST) I obtained GMT+1. Today I obtained GMT0 when I was
expecting a GMT+0 (ok, ok, bad assumption on my part). I had to use a
special case for a zero timezone.
: Either +0 or -0 would make sense, since there is no distinction
: between those for integers. +0 makes is more common sensical, so seems
: the obvious choice.
Agreed.
: But absent language in the standard to require it
: (which I assume you researched, because I didn't just now other than read
: the original post here)
The only relevant passages I was able to find is the one that I
quoted, and the 'sign' glossary entry.
: certainly neither could be said to be nonconforming.
: I would argue for clarifying this as "+0" in a future standard.
Thank you for clarifying this.
P.
Thomas A. Russ
MCL: "+0"
--
Thomas A. Russ, USC/Information Sciences Institute t...@isi.edu
Barry Margolin
Kent M Pitman <pit...@world.std.com> wrote:
>I would argue for clarifying this as "+0" in a future standard.
Me too. The obvious (to me) intent was that ~@D should include an explicit
plus sign in cases where ~D would omit it because it's assumed.
--
Barry Margolin, bar...@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, 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.
Paul Rudin
>
> On 12 May 1999 08:41:08 GMT, bern...@cli.di.unipi.it (Pierpaolo
> Bernardi) wrote:
>
> >HS> The @ modifier causes the number's sign to be printed always;
> >HS> the default is to print it only if the number is negative.
>
> Well, "always" means always, I'd say.
>
But "...number's sign to be printed always." doesn't necessarily mean
print something when the number has no sign.
Unless the spec requires that 0 has a sign it doesn't seem to be wrong
to omit a sign.
(Although common sense would suggest +0 is best.)
Sam Steingold
>>>> On the subject of "Re: Q. for sublanguage lawyers: (format nil "~@D" 0) ==> ?"
>>>> Sent on Wed, 12 May 1999 14:30:06 GMT
>>>> Honorable Kent M Pitman <pit...@world.std.com> writes:
>>
>> I would argue for clarifying this as "+0" in a future standard.
Thanks. In tomorrow's CLISP snapshot
(ftp://cellar.goems.com/pub/clisp/),
(format nil "~@D" 0) ==> "+0"
--
Sam Steingold (http://www.goems.com/~sds) running RedHat6.0 GNU/Linux
Micros**t is not the answer. Micros**t is a question, and the answer is Linux,
(http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation.
MS Windows: error: the operation completed successfully.
Juanma Barranquero
Hash: SHA1
On Wed, 12 May 1999 14:30:06 GMT, Kent M Pitman <pit...@world.std.com>
wrote:
>+0 makes is more common sensical, so seems the obvious choice. But
>absent language in the standard to require it (which I assume you
>researched, because I didn't just now other than read the original
>post here) certainly neither could be said to be nonconforming.
The only reference I've found is the one already quoted by Pierpaolo
Bernardi:
(22.3.2.2 Tilde D: Decimal): "The @ modifier causes the number's sign
to be printed always; the default is to print it only if the number is
negative."
>I would argue for clarifying this as "+0" in a future standard.
Another of the Absolutely-Minor-Issues I'd like to see clarified (I've
discussed it a bit in the allegro-cl mailing list) is the behavior of
(loop repeat n do ...)
for those cases where (typep n '(and real (not integer))) == t, but I
suppose the LOOP macro will be revisited anyway (as I've read comments
about it being underspecified).
And another pet peeve of mine: in the FORMAT-COMMA-INTERVAL issue, the
following example is given:
(format nil "~19,0,' ,4:B" 3333) => "0000 1101 0000 0101"
Once repaired the small typo of 0 for '0, that seems like a very
useful behavior that the current standard doesn't support. For
example, Allegro (using the default comma-interval of 3, because it
doesn't yet implement the comma-interval parameter) produces:
USER(13): (format nil "~19,'0,' :B" 3333)
"0000110 100 000 101"
instead of "000 110 100 000 101". The standard reads: "The : modifier
causes commas to be printed between groups of digits; commachar may be
used to change the character used as the comma. comma-interval must be
an integer and defaults to 3. When the : modifier is given to any of
these directives, the commachar is printed between groups of
comma-interval digits."
The characters added by the padchar parameter aren't "digits", but
"pad characters" ("~mincol,padcharD uses padchar as the pad character
instead of space."), so the reading of the standard made by Allegro
seems the right one. Otherwise, the following form:
(format nil "~19:B" 3333)
should produce
" ,110,100,000,101"
So, we're left without a way to format a number in a given width with
proper comma-char/comma-interval. That, though very minor, would be
useful to have, I think.
/L/e/k/t/u
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.0.2i
iQA/AwUBNzmQc/4C0a0jUw5YEQKjWACg7PVSuC3wJXPUPfFW+Ld5PBWcyoYAmwY0
sa3gqdb1rLVZBXDE+33m+myI
=fT9a
-----END PGP SIGNATURE-----
Juanma Barranquero
Hash: SHA1
On 12 May 1999 20:15:34 +0100, Paul Rudin <pa...@shodan.demon.co.uk>
wrote:
>But "...number's sign to be printed always." doesn't necessarily
>mean print something when the number has no sign.
You're right.
Juanma
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.0.2i
iQA/AwUBNzpzS/4C0a0jUw5YEQKFugCg8K/bSZVWJTWDyZFlIfIv5nnHikAAoK0b
JofKcDGbd8xEYPGzIlJzhySG
=zhKR
-----END PGP SIGNATURE-----
Barry Margolin
How would you suggest this be fixed? The simplest solution I can think of
would be to specify that if the pad character is a valid digit character in
the radix being used for the output, then the pad characters should be
considered digits for purposes of inserting commas.
Juanma Barranquero
Hash: SHA1
On Sat, 15 May 1999 06:55:37 GMT, Barry Margolin
<bar...@bbnplanet.com> wrote:
>How would you suggest this be fixed? The simplest solution I can
>think of would be to specify that if the pad character is a valid
>digit character in the radix being used for the output, then the
>pad characters should be considered digits for purposes of
>inserting commas.
That would be incompatible with the current spec. Format strings that
now work would start to act differently.
As I see it, the standard offers a way to print a number using the
width it has in the specified radix (similar to C's "%d"), but no way
to do a "%05d", for example. The two very different meanings of "print
number X and pad to width Y with character Z" and "print a number X
with width Y" have been mixed. So we need a flag to specify this
second behavior...
...the problem being, of course, that : and @ have already meanings
for ~D and friends.
The only simple way I can think of is having a fifth parameter (let's
call it numwidth for now) for indicating number-width, independent of
mincol's "column-width". So ~D would first format the number to
numwidth size, and then, if necessary, fill up to mincol with
padchars. The commachar and comma-interval parameters would affect the
numwidth characters of the number, but no the padchars up to mincol.
That forces the numwidth "fill" character to be 0, but I would argue
that's the only meaningful use of numwidth, or otherwise we would be
printing another number. Or, alternatively, a *sixth* (ugh!)
parameter, numchar, should have to be included :(
Thanks for your answer.
/L/e/k/t/u
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.0.2i
iQA/AwUBNz0vZP4C0a0jUw5YEQKVPQCeN3iBoIV3x8Xb9MouXoOmx8hP2mcAoKNE
YxPYnCXxJs+/UY9coBUQ/iPZ
=nk7Z
-----END PGP SIGNATURE-----
Juanma Barranquero
Hash: SHA1
On 18 May 1999 15:57:40 +0000, Erik Naggum <er...@naggum.no> wrote:
> a format string of "~5,'0D" does this for me all the time.
You're right. I was not precise enough. What I meant (but did not
write) was a combination of commachar/comma-interval and "%05d".
> I don't think people expect (format <stream> "~23,'0,':,2:X"
> <number>) to produce a bunch of colon-separated pairs of leading
> 0's, like the Ethernet address formatter it could have been in an
> ideal world, and simply don't do this to begin with, which means
> we're not encroaching on people who have reasonable expectations.
Not only for Ethernet addresses; often when I want to print a number
in a non-decimal radix (binary masks, hexadecimal pointer values,
etc.) I'd like to print it full-length, zero-padded *but* have
comma-chars between groups of (a sensible number of) digits.
> so, I think Barry's suggestion (to treat digit pad-chars specially)
> is the most sensible because it would make it possible to use this
> facility in ways that are currently producing undesirable results.
OK, *if* compatibility with current behavior is deemed not important.
I didn't object to Barry's idea, only suggested an alternative. In
fact, I like his idea because I don't find any use for the current
behavior (when 0 is the padchar, not in the general case of ~D).
/L/e/k/t/u
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.0.2i
iQA/AwUBN0GZ2P4C0a0jUw5YEQJfmgCgzbmT9YGzDAJd0WBvZp8d4tm9FrcAoMlg
/Jfs6J54fN7O7Q0tr80zGqXP
=eNcN
-----END PGP SIGNATURE-----
Erik Naggum
| As I see it, the standard offers a way to print a number using the width
| it has in the specified radix (similar to C's "%d"), but no way to do a
| "%05d", for example.
a format string of "~5,'0D" does this for me all the time.
I don't think people expect (format <stream> "~23,'0,':,2:X" <number>) to
produce a bunch of colon-separated pairs of leading 0's, like the
Ethernet address formatter it could have been in an ideal world, and
simply don't do this to begin with, which means we're not encroaching on
people who have reasonable expectations. so, I think Barry's suggestion
(to treat digit pad-chars specially) is the most sensible because it
would make it possible to use this facility in ways that are currently
producing undesirable results.
#:Erik
--
@1999-07-22T00:37:33Z -- pi billion seconds since the turn of the century