[Cfp-interest] quantexp (or .) for Part 3

[Mike Cowlishaw]

> At the May CFP teleconference we decided for Part 3 to add 
> quantum-exponent functions that return in a decimal type and 
> for Part 2 to retain its current quantexpd[32|64|128] 
> functions that return int. What to name the new functions?
> 
> Following the naming pattern of using a prefix to reflect the 
> return type, we might have dquantexp or decquantexp. In other 
> <math.h> cases, this prefix convention is used to indicate 
> integer type returns (ilogb, lrint, etc.), instead of the 
> presumed floating type returns (logb, rint, etc.) for 
> <math.h> functions. Ideally, we would have used iquantexp for 
> the ones returning int and quantexp for the ones return 
> decimal types. qexp won't work because it's used as the name 
> of a function in statistics.

Perhaps it _should_ be named iquantexp: implementations that already use the TR
names (are there any?) could provide backwards compatibility by means of a macro
or wrapper function.
 
> A different approach. We might define a function that returns 
> the quantum as defined in IEC 60559: the value of a unit in 
> the last position of the significand (i.e., 10^q where q is 
> the quantum exponent). We could call the function quantum. 
> The quantum exponent could be obtained by, for example, 
> logbdN(quantumdN(arg)). Would a quantum function be more or 
> less useful than the quantexp function?

I have been surprised how useful the quantum function is; in particular its
result displays and formats well alongside associated data, so it is easy to
handle and (for common quanta) is readily understood (e.g., 0.01 for cents).

By there way, there's no reason not to provide it for binary types: woodworkers
in the USA (for example) commonly work with inches to some binary quantum (e.g.,
1/32nds).

Mike