On Mon, Nov 18, 2002 at 10:57:10AM -0800, Michael Lazzaro wrote: > > --- Numeric Literals --- > > bin/oct/hex notation: > > 0b0110 # bin > 0c0123 # oct > 0x00ff # hex > 0x00fF # hex, == 0x00ff > 0x00FF # hex, == 0x00ff
I would assume that 0B0110, 0C0123, and 0X00FF are all equivalent to the forms with lower-case base markers, right? > -0xff # ok > -0x00ff # ok Are these two identical? Is 0x-ff an error? (I would say yes.) If not, is it the same as -0xff? > 0xf_f # ok Ok. > 0x_ff # ok Wait a minute...the rule is that underscore can only appear between digits. Here, the 'x' is not a digit, it is a base marker. Therefore, shouldn't this be an error? > explicit radix: > > (radix 2-32) > > 20:1gj # base 20 > 20:1GJ # base 20 (identical) > 20:1.G.J # base 20 (identical) > 20:1_G_J # base 20 (identical) > 20:1.16.19 # base 20 (identical) > 20:1_16_19 # NOT identical; == 20:11619 > 20:1.1_6.19 # WRONG: dotted form may not have underlines > -20:1GJ # base 20 (negative) > -20:1.16.19 # base 20 (negative) The more I think on it, the more it seems like the negative sign should really go to the right of the colon (20:-1GJ)...otherwise, it really does look like you're using a negative radix (is that even possible?). I realize this is out of step with the traditional -0xff, but it still seems like The Right Thing to me...what do other people think? > 62:zZ # base 62 (?) > 62:z.Z # base 62 (identical?) > 62:z_Z # base 62 (identical?) > 62:Zz # base 62 (not identical?) Why is that last one not identical? > (radix 33-RADIX_MAX) > > 256:0.253.254.255 # base 256 > 256:0_253_254_255 # base 256 Are these two intended to be identical or not? I expect not...the first should be a 4 digit number and the second a 10 digit number. > Other issues w/ literals: > > - radix <= 32, alpha digits may be upper or lowercase Implying that in radii > 32, case matters? I thought we had decided it was better to go the other way, and have case never matter, which meant that for radii higher than 32, you had to use dotted notation? --Dks
