[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