tps@sdchem.UUCP (04/04/87)
In article <1283@dataio.Data-IO.COM> bright@dataio.UUCP (Walter Bright) writes: > How about allowing numbers to be specified in binary radix, > as in 0b00110101 ? ... > As a corollary, support %b in printf and scanf. Yes, by all means. > Also, support specifying floating numbers in hex radix.... > The syntax would be: > > double def = 0x1324.5E678e+0x12; > double abc = -0x.1B4F; > > def prescribes a mantissa of 0x12345E678 and an exponent of > (4*16+0x12). > > Note that a + or - would be required before the exponent, to > distinguish the e from the digit e. This is non-orthogonal with the current decimal floating point, in that the "." is required in order to avoid ambiguity. This is because 0x12e+0x34 could be 0x12e + 0x34 Also, your second example, double abc = -0x.1B4F; is just plain ambiguous -- you must require the exponent as well, or 0x.1b4e+0x23 could be 0x.1b4e + 0x23 If you use the "longest string that could be a token *is* the next token" disambiguating rule, then you might break some existing code which wanted to add to hex integers instead of creating one hex float. Given all these subtleties, I think this format is going to be confusing to read, no matter how you disambiguate. Perhaps a (standardized) include file defining a macro function could be devised made to work instead. You might then have # include <hexfloat.h> ... double def = Hexfloat( 0x1324.5E678, 0x12 ); where the first arg is the mantissa, and the 2nd, the exponent. An advantage here is that you might be able to allow octal and binary representations as well. || Tom Stockfisch, UCSD Chemistry tps%chem@sdcsvax.ucsd.edu or sdcsvax!sdchem!tps