[cfp-interest 3388] Re: Math Functions in Programming Languages Standards

[Damian McGuckin]

David,

Here are my suggestions but feel free to disagree.

As for formatting, I would put a blank line after each heading.

On Thu, 13 Feb 2025, David Hough CFP wrote:

> Question:
>
> C++ proposes to standardize midpoint and linear interpolation functions.
> Should C follow?
>
> General comments:
>
> Programming language standards are big and getting bigger.  It seems 
> likely that not all standards groups have equal expertise in what 
> functions applications require.
>
> If they are going to put additional functions in programming language
> standards, how do they decide which ones are worthwhile?
>
> Perhaps they should limit themselves to new functions that can be
> implemented in a single instruction no more complex than an FMA.

FIX implemented in a single instruction no MUCH more complex than an FMA.

>> give people some wiggle room (especially as I want to propose a double 
>> FMA that will mean a complex multiply (or a 2 element dot product such 
>> as done currently by Intel's DPPS) can be done in a single assembler 
>> instruction.

> Or to new functions that are the solutions to very simple differential 
> equations (e.g. exp/sin/cos), and their inverses - especially avoiding 
> new transcendental functions - note that in floating-point arithmetic, 
> the results of x**y and kindred functions are always algebraic numbers 
> rather than transcendental numbers.
>
> LAPACK, or even the BLAS, are very widely used, but that doesn't make 
> them good candidates for language standardization.  There are other 
> groups better equipped to do that work.
>
> Specific comments:

> If I had been present at Creation, I would have advised putting gamma or 
> lgamma or bessel functions in C.  But here they are, and there's little 
> to be gained by taking them out.

FIX .... I would NOT have advised putting gamma or

David, you omitted the word 'NOT'.

Damian's extra comments: I agree that gamma, lgamma, the bessel functions, 
and erf do NOT belong in the C Math library but that is a whole new ball 
game and I am not remotely proposing a change to what is in Annex F today.

> Note that midpoint, in binary, is hardly different from a normal 
> subtraction, and would easily make a simple machine instruction.  But 
> that ease does not apply to any other radix, 10 or 16 in particular.
>
> That case against linear interpolation is even stronger.
>
> One benefit of standardization is uniformity of syntax.  But uniformity 
> of semantics is even more important, especially for exceptions.  But 
> different application areas have vastly different requirements for 
> exceptions. Perhaps the semantics are best specified by 
> application-oriented groups rather than language committees.
>
> Conclusion:
>
> My suggestion for C would be to not standardize midpoint and linear
> interpolation, but if it is done, limit the specification to syntax and
> just those semantics that all stakeholders can agree on.

FIX: just those semantics ON which all stakeholders can agree.

(sorry about my slightly picky English).

Thanks - Damian