[Cfp-interest 3145] midpoint function
David Hough CFP
pcfp at oakapple.net
Thu Jul 18 12:34:40 PDT 2024
C++ has adopted a midpoint function; what about C?
There's a vast array of numerical functions that could be added to language
standards; what's worthwhile?
In my view, the usual criterion is that the function is simple enough to be
put into hardware that produces a correctly rounded result at a cost smaller
than its value to applications. If it's not critical to performance, or if
it can't be correctly rounded in hardware at reasonable cost, it's not a
good candidate.
Midpoint (a+b)/2 is a good example in binary floating point. Such an
instruction can be easily implemented as a slight variation of normal
addition - namely by biasing the exponent by -1, either of both unpacked
operands before addition, or of the result before rounding.
The picture for decimal floating point is not so cheerful. Thinking of
(5*a+5*b)/10, correct rounding
would require two extra precise products of 5*a and 5*b - needing an extra
digit of precision, and an extra exponent digit (digits?), for those products -
and then the addition of those extra-precise products, followed by
rounding to the original precision. Again an
exponent bias of -1 is needed, this time representing a division by 10.
It's hard to imagine an application that runs in decimal that would justify
the hardware expense - so it would be implemented in software, either slowly
or incorrectly rounded, and that would be good enough. A pretty weak
case for language standardization.
For z system hexadecimal, (8*a+8*b)/16 raises the same issues.
C++ is also considering linear interpolation. Midpoint is a special case
of that, so a more general case might be even harder to justify for a language
standard. Binary probably doesn't have any advante over other radices.
Note that the 754 floating-point standards have never included these
functions.
More information about the Cfp-interest
mailing list