I suppose because that’s what
“atan(1) * 4”
casts to double?
- I wonder if this cast is always correct in C [ie.: math.h], no matter the datatype and/or the number base?
“atan(1) * 4”
casts to double?
- I wonder if this cast is always correct in C [ie.: math.h], no matter the datatype and/or the number base?
Floating point arithmetic is deterministic. As long as it is implemented as specified atan(1) has to give the floating point number which is the closest approximation to the real number pi/4 (in the current rounding mode), the multiplication by 4 means that precision can be lost and potentially your result is no longer the closest possible approximation to pi.
What? This is not true at all. The standards specifies adherence to IEEE 754 arithmetic.
You can read the standard here: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
Page 507 for adherence to number formats. Page 517 for atan adhering to IEEE 754 specification for the functions defined therein, which guarantees best possible results for individual operations.
Any C implementation where atan gives a result which is inconsistent with IEEE 754 specification does not adhere to the standard.
> also, no OS provided libm produces correctly rounded results for all inputs.
Every IEEE 754 conforming library does adhere to the best possible rounding guarantee. If you have any evidence to the contrary that would be a disaster and should be reported to the vendor of that library ASAP.
Can you provide some function and some input which violates the IEEE 754 guarantee together with the specific library and version? Or are you just making stuff up?
Even beyond transcendental functions, 754 isn't deterministic in practice because implementations have choices that aren't always equivalent. Using FMA vs separate multiplication and addition leads to different results in real programs, even though both methods are individually deterministic.
But then it doesn't conform to the standard. It is pretty unambiguous on that point.
From Section 9.2:
"A conforming operation shall return results correctly rounded for the applicable rounding direction for all operands in its domain."
I do not see how two conforming implementations can differ in results.
>Using FMA vs separate multiplication and addition leads to different results in real programs, even though both methods are individually deterministic.
Obviously. I never claimed that the arithmetic was invariant under transformations which change floating point operations, but are equivalent for real numbers. That would be ridiculous.
Is there actually an example of two programs performing identical operations under the same environment that give different results where both implementations conform to the standard?
>Even beyond transcendental functions, 754 isn't deterministic in practice because implementations have choices that aren't always equivalent.
Could you give an example? Where are implementations allowed to differ? And are these cases relevant, in the sense that identical operations lead to differing results? Or do they just relate to error handling and signaling.
> 9. Recommended operations
> Clause 5 completely specifies the operations required for all supported arithmetic formats. This clause specifies additional operations, recommended for all supported arithmetic formats.
Hyperbolic tan is in the list of recommended functions, and yet: https://github.com/numpy/numpy/issues/9187
Who cares? The C standard for math.h requires these functions to be present as specified. They are specified to round correctly, the C standard specifies them to be present as specified, therefore the C standard specifies them as present and correctly rounded. I literally quoted the relevant sections, there are no conforming C specification which give different results.
>Hyperbolic tan is in the list of recommended functions, and yet: https://github.com/numpy/numpy/issues/9187
Any evidence whatsoever that this is caused by two differing implementations of tanh, which BOTH conform to the IEEE 754 standard?
Everyone is free to write their own tanh, it is totally irrelevant what numpy gives, unless there are calls to two standard confirming tanh function which for the same datatype produce different results.
Forgive me, but I cannot see that in the document sections you point out. The closest I can see is F.10-3, on page 517, but my reading of that is that it only applies to the Special cases (i.e values in Section 9.2.1), not the full domain.
In fact, my reading of F.10-10 (page 518) suggests that a conforming implementation does not even have to honor the rounding mode.
I'm not aware of any libm implementations that will guarantee correct rounding across all inputs for all types. I'm aware of a few libm's that will guarantee that for floats (e.g. rlibm: https://people.cs.rutgers.edu/~sn349/rlibm/ ), but these are not common.
Genuinely a bit shocked by this.
That's not the current version of C. The best document right now is https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf (which is C23 with one or two editorial fixes).
Note that Annex §F.3¶20 says
> However, correct rounding, which ISO/IEC 60559 specifies for its operations, is not required for the C functions in the table.
which proceeds to list most of the functions in IEEE 754-2008/2019 section 9.2.
A C compiler which claims conformance to IEEE 754 need not correctly round those functions. Most C libraries do not correctly round all of these functions: https://members.loria.fr/PZimmermann/papers/accuracy.pdf
(in summary, llvm-libc correctly rounds all functions, as it's explicitly borrowing from one of the correctly-rounded efforts; of the other implementations, Intel's library usually gets the closest, but not always).
(Insert long rant about icc enabling daz/ftz by default.)
It is a bit shift to the right, so where do the new bits come from? Why would the two new bits be the correct ones?
This is about the approximation to pi not the approximation to float(atan(1))*4, it is exact (but irrelevant) for the later, for the former you loose two bits, so you have a 25% chance of correctly rounding towards pi.