how about toEngineering and toHexExponential formats for Number

How about a couple of new formats for Number ...

Number.prototype.toEngineering
This is similar to the normalised 'toExponential', but the exponent is a 
multiple of 3 and there are 1, 2, or 3 digits before the decimal point.  The 
format makes it visually easy to relate a string representation of a number 
to SI scaling prefixes ("mega", "giga", "milli", etc).

Many newer pocket calculators provide this format and it seems to be gaining 
ground in formatters generally.  It is useful in engineering, say if one is 
working with microwatts, megaohms, ...

Number.prototype.toHexExponential
This is similar to 'toExponential' but is in the normalised hexadecimal form 
instead of decimal.
E.g.  1.4A2p+4
The letter 'p' corresponds to decimal's 'e', and means "times 2 to the power 
of".
The *binary* exponent is represented in signed *decimal*.
The hex representation should probably be in lowercase to match that of 
'toString(16)'.

GNU's printf provides this format with its %a and %A conversions.  The 
format is useful for transferring arbitrary binary floating-point values 
exactly, whereas decimal formats round them.

Following on from Number.prototype.toHexExponential, it would be nice if 
parseFloat could then convert this format back to Number.

And parseFloat should ignore a "0x" or "0X" between the leading sign (if 
any) and the main string.
E.g.  "-0x123.B4p+12"

> Number.prototype.toHexExponential
> This is similar to 'toExponential' but is in the normalised hexadecimal
> form instead of decimal.
> E.g. 1.4A2p+4
> The letter 'p' corresponds to decimal's 'e', and means "times 2 to the
> power of".
> The *binary* exponent is represented in signed *decimal*.
> The hex representation should probably be in lowercase to match that of
> 'toString(16)'.
>
> GNU's printf provides this format with its %a and %A conversions. The
> format is useful for transferring arbitrary binary floating-point values
> exactly, whereas decimal formats round them.

Number.prototype.toString() generates as many digits as needed for the 
number to be representable unambiguously.

(if I wanted packed binary number representation, then rather some form 
of base32 - it packs more)

Herby

>> Number.prototype.toHexExponential
>> This is similar to 'toExponential' but is in the normalised hexadecimal
>> form instead of decimal.
>> E.g. 1.4A2p+4
>> The letter 'p' corresponds to decimal's 'e', and means "times 2 to the
>> power of".
>> The *binary* exponent is represented in signed *decimal*.
>> The hex representation should probably be in lowercase to match that of
>> 'toString(16)'.
>>
>> GNU's printf provides this format with its %a and %A conversions. The
>> format is useful for transferring arbitrary binary floating-point values
>> exactly, whereas decimal formats round them.
>
> Number.prototype.toString() generates as many digits as needed for the 
> number to be representable unambiguously.
>
> (if I wanted packed binary number representation, then rather some form of 
> base32 - it packs more)

True about the decimal representation - the case for unambiguous transfer is 
weak.

The objective of hexadecimal exponential representation is not to achieve 
dense packing; rather to represent a binary64 value in a common 
programmer-friendly (i.e. hexadecimal) form.  Note the natural match with 
the binary64 sign-significand-exponent fields.

Some Prior Art:
1)  GNU's printf does this with %a and %A conversions, (other printf 
versions too?).
2)  C (after C99) has hexadecimal exponential literals (see my new post 
"hexadecimal literals for floating-point").
3)  (I believe) IEEE 754-2008 specifies it.