Re: Numeric literals, take 3
[email protected] (James Mastros) Wed, 27 Nov 2002 20:28:42 -0500
| Newsgroups | perl.perl6.documentation |
|---|---|
| Message-ID | <[email protected]> |
On 11/27/2002 7:54 PM, Angel Faus wrote: > For example, the integer 30 can be written in base 16 > in two equivalent ways: > > my $x = 16#1D; > my $x = 16#1:14; > > These two representations are incompatible, so writing > something like C<16#D:13> will generate a compile-time > error. Ambiguity: Is C<my $x = 16#14;> equivlent to the digit "14", base-sixteen, or is it equivlent to 0x14? (This has been noted before, but I don't think anybody has decided. My vote is 0x14, you should say my $x=16#0:14 if you want the other meaning.) > =section *** Bin/Hex/Oct shorthands > > Since writing in binary, hexadecimal and octal is a > moderately common operation, Perl offers a shorthand > for them: > > 0b0110 # bin > 0c0123 # oct > 0x00ff # hex > 0x00fF # hex, == 0x00ff > 0x00FF # hex, == 0x00ff Loose specification: You should probably note that while the digits are case-insensitive, the shorthand-radix-specifier is case-sensitive -- IE 0B0110 isn't 2:110, it's a syntax error (invalid digit in decimal literal). Possible useful note: Should we note that the C and perl5 notation of 0777 being octal is /not/ supported? > This won't work for bases greater than 36, so we > have too: Grammar: I think this should be "so we also have:", or possibly "so we also have...". > In boolean context (see "Boolean Context") C<NaN> always > evaluates to false so. Missing end-of-setance: "to false so those last two examples are false". (IE both !(NaN!=NaN) and !(NaN==NaN).) Useful node: We should probably note that Inf and NaN are case sensitive (or are they)? > NOTE: are we going to have +-Inf too? Speculation: I don't think so. I don't think we're going to have -0 or +0 notations either (for underflow). Any parroters? > If you need to create typed C<Int> numbers without risking > to lose precision, you should write them as a string literals: I think Larry has mandated the oppisite -- that we Do The Right Thing with bigints automaticly -- IE that BigInt is a subclass of Int, with full automatic promotion. (I think this isn't going to be true of little-i int, though.) -=- James Mastros