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]
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.
Kent M Pitman (pit...@world.std.com) wrote: : barranqu...@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.
In article <sfwwvye9x8x....@world.std.com>, 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.
>>>> In message <sfwwvye9x8x....@world.std.com> >>>> 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.
-- 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.
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:
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:
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.
Juanma Barranquero <barranqu...@laley-actualidad.es> wrote: >And another pet peeve of mine: in the FORMAT-COMMA-INTERVAL issue, the >following example is given:
>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:
>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.
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.
-- 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.
<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 :(
On 18 May 1999 15:57:40 +0000, Erik Naggum <e...@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).
* barranqu...@laley-actualidad.es (Juanma Barranquero) | 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
