I vaguely remember that from time to time a come across mentions of some
specification that imposes more-or-less strict precision (or rounding)
guarantees onto functions from <math.h>. Something along the lines of
`pow(2, 2)` being guaranteed to produce 4.0, possibly under some set of
additional implementation-defined circumstances.

But I can't seem to find anything like that in the C standard. Do these
guarantees actually exist somewhere? IEE754? POSIX? The C standard?
Somewhere else?

--
Best regards,
Andrey Tarasevich

Andrey Tarasevich <andreytarasevich@hotmail.com> writes:

> I vaguely remember that from time to time a come across mentions of
> some specification that imposes more-or-less strict precision (or
> rounding) guarantees onto functions from <math.h>. Something along the
> lines of `pow(2, 2)` being guaranteed to produce 4.0, possibly under
> some set of additional implementation-defined circumstances.
>
> But I can't seem to find anything like that in the C standard. Do
> these guarantees actually exist somewhere? IEE754? POSIX? The C
> standard? Somewhere else?

IEEE 754 requires that the basic operations (add, subtract, etc) have
results as if they were done exactly and then correctly rounded to the
nearest representable value. Operations like x^y are optional in the
specification, but even when they are provided they are not required (in
general) to as accurate. If there are special rules for some cases
(like 2.0^2.0) I am unaware of them.

--
Ben.

On 4/13/22 18:04, Andrey Tarasevich wrote:
> I vaguely remember that from time to time a come across mentions of
> some specification that imposes more-or-less strict precision (or
> rounding) guarantees onto functions from <math.h>. Something along the
> lines of `pow(2, 2)` being guaranteed to produce 4.0, possibly under
> some set of additional implementation-defined circumstances.
>
> But I can't seem to find anything like that in the C standard. Do
> these guarantees actually exist somewhere? IEE754? POSIX? The C
> standard? Somewhere else?
>

Here's what the C standard says:
"The accuracy of the floating-point operations ( + , - , * , / ) and of
the library functions in <math.h> and <complex.h> that return
floating-point results is implementation-defined, as is the accuracy of
the conversion between floating-point internal representations and
string representations performed by the library functions in <stdio.h>,
<stdlib.h> , and <wchar.h> . The implementation may state that the
accuracy is unknown." (5.2.4.2.2p6).

Note that this does not apply to any of the other expression types that
can have operands of floating point type, all of which must therefore be
exact: () _Generic() ++ -- ! < > <= >= == != ?: ,
This doesn't help much, except for the relational operators.

Note that this means that an implementation can implement floating point
math so inaccurately that LDBL_MAX - LDBL_MIN < LDBL_MIN - LDBL_MAX, so
long as an implementation correctly documents that fact, or chooses to
say "the accuracy is unknown".

[Re: conversion of floating point constants to internal representations]
"For decimal floating constants, and also for hexadecimal floating
constants when FLT_RADIX is not a power of 2, the result is either the
nearest representable value, or the larger or smaller representable
value immediately adjacent to the nearest representable value, chosen in
an implementation-defined manner. For hexadecimal floating constants
when FLT_RADIX is a power of 2, the result is correctly rounded."
(6.4.4.2p3).

Since comparison operations on floating point numbers are required to be
exact, those requirement imply that you can compare floating point
constants with very high accuracy - but that's the most that you can
portably rely on when using C.

Recommended practice:
"The translation-time conversion of floating constants should match the
execution-time conversion of character strings by library functions,
such as strtod , given matching inputs suitable for both conversions,
the same result format, and default execution-time rounding." (6.5.5.3p7).

However, when __STDC_IEC_559__ or __STDC_IEC_559_COMPLEX__ are
pre#defined by the implementation, then the implementation must conform
to Annex F and Annex G, respectively, which impose requirements similar,
though not quite identical, to those of ISO/IEC 60559 (== IEEE 754).
That standard imposes much stricter requirements - pretty much the
strictest requirements that can reasonably be applied.

POSIX imposes no accuracy requirements of it's own. It mandates
conformance to the C standard's very minimal requirements, and allows,
but does not require, IEEE 754 conformance.

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 4/13/22 18:04, Andrey Tarasevich wrote:
>> I vaguely remember that from time to time a come across mentions of
>> some specification that imposes more-or-less strict precision (or
>> rounding) guarantees onto functions from <math.h>. Something along the
>> lines of `pow(2, 2)` being guaranteed to produce 4.0, possibly under
>> some set of additional implementation-defined circumstances.
>>
>> But I can't seem to find anything like that in the C standard. Do
>> these guarantees actually exist somewhere? IEE754? POSIX? The C
>> standard? Somewhere else?
>>
>
> Here's what the C standard says:
> "The accuracy of the floating-point operations ( + , - , * , / ) and of
> the library functions in <math.h> and <complex.h> that return
> floating-point results is implementation-defined, as is the accuracy of
> the conversion between floating-point internal representations and
> string representations performed by the library functions in <stdio.h>,
> <stdlib.h> , and <wchar.h> . The implementation may state that the
> accuracy is unknown." (5.2.4.2.2p6).
>
> Note that this does not apply to any of the other expression types that
> can have operands of floating point type, all of which must therefore be
> exact: () _Generic() ++ -- ! < > <= >= == != ?: ,
> This doesn't help much, except for the relational operators.

It does apply to ++ and --. For example:

The expression ++E is equivalent to (E+=1).

so if E is of floating-point type, the constant 1 is converted to that
type and the accuracy requirements are the same as for ordinary
addition.

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On 4/13/22 23:19, Keith Thompson wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
....
>> Here's what the C standard says:
>> "The accuracy of the floating-point operations ( + , - , * , / ) and of
>> the library functions in <math.h> and <complex.h> that return
>> floating-point results is implementation-defined, as is the accuracy of
>> the conversion between floating-point internal representations and
>> string representations performed by the library functions in <stdio.h>,
>> <stdlib.h> , and <wchar.h> . The implementation may state that the
>> accuracy is unknown." (5.2.4.2.2p6).
>>
>> Note that this does not apply to any of the other expression types that
>> can have operands of floating point type, all of which must therefore be
>> exact: () _Generic() ++ -- ! < > <= >= == != ?: ,
>> This doesn't help much, except for the relational operators.
>
> It does apply to ++ and --. For example:
Sorry - I was undergoing constant harassment by two seven-year olds
while trying to post that message.

On Wed, 13 Apr 2022 22:04:56 UTC, Andrey Tarasevich <andreytarasevich@hotmail.com> wrote:

> I vaguely remember that from time to time a come across mentions of some
> specification that imposes more-or-less strict precision (or rounding)
> guarantees onto functions from <math.h>. Something along the lines of
> `pow(2, 2)` being guaranteed to produce 4.0, possibly under some set of
> additional implementation-defined circumstances.
>
> But I can't seem to find anything like that in the C standard. Do these
> guarantees actually exist somewhere? IEE754? POSIX? The C standard?
> Somewhere else?
>

The international standard
ISO/IEC 10967-2
Language independent arithmetic -
Part 2: Elementary numerical functions
may have precision / accuracy requirements on math functions.
---
Fred J. Tydeman Tydeman Consulting
tydeman@tybor.com Testing, numerics, programming
+1 (702) 608-6093 Vice-chair of PL22.11 (ANSI "C")
Sample C99+FPCE tests: http://www.tybor.com
Savers sleep well, investors eat well, spenders work forever.

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 4/13/22 23:19, Keith Thompson wrote:
>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> ...
>>> Here's what the C standard says:
>>> "The accuracy of the floating-point operations ( + , - , * , / ) and of
>>> the library functions in <math.h> and <complex.h> that return
>>> floating-point results is implementation-defined, as is the accuracy of
>>> the conversion between floating-point internal representations and
>>> string representations performed by the library functions in <stdio.h>,
>>> <stdlib.h> , and <wchar.h> . The implementation may state that the
>>> accuracy is unknown." (5.2.4.2.2p6).
>>>
>>> Note that this does not apply to any of the other expression types that
>>> can have operands of floating point type, all of which must therefore be
>>> exact: () _Generic() ++ -- ! < > <= >= == != ?: ,
>>> This doesn't help much, except for the relational operators.
>>
>> It does apply to ++ and --. For example:
> Sorry - I was undergoing constant harassment by two seven-year olds
> while trying to post that message.

That definitely causes undefined behavior.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */