On 3/23/22 1:10 PM, Thomas Koenig wrote:
> Ron Shepard <
nos...@nowhere.org> schrieb:
>> On 3/23/22 9:22 AM,
john.a...@jtekt.com wrote:
>> [...]
>>> I wish a standard constant for PI, E would be included,
>>> instead of everyone having to create their own every time it is
>>> needed. I have seen numeric definitions with not enough digits,
>>> with way too many digits, use of ACOS(-1D0) or 4*ATAN(1D0) and
>>> many more variants.
>
>>
>> Yes, the accuracy of these function references can sometimes be a
>> problem. For example, there is no guarantee that the two expressions you
>> give above are the same to the last bit,
>
> From a numerical standpoint, arctan makes a lot more sense because
> the derivative of acos(x) has a pole at x=-1.
>
> 4*atan(1.d0) is much better. This is also guaranteed to be evaluated
> at compile-time and suitable for a parameter.
Where in the standard is that required, either within an expression or
as part of a parameter definition? Isn't a compiler always allowed to
defer that evaluation until run time?
>> so if a programmer uses one in
>> one place and the other in another place, and later checks for equality,
>> chaos may ensue.
>
> As is usual for equality comparisons if it is indeed unknown that
> the values _are_ exact.
That was the point of the original post. Namely if there is a single
defined constant, then it should always be equal to itself, no matter
the optimization level, rounding mode, etc.
>
> You can reasonably compare 1 + 0.5 against 1.5 and expect equality,
> but otherwise floating point expressions should be treated with
> care (and +/- epsilon).
Normally yes, but in the case of PI and E and other such constants, the
simplest way to guarantee their value would be with an intrinsic
constant, not a run time or even a compile time expression. Even if you
specify the constant manually with a literal, you really need about
three more digits than the epsilon in order to guarantee correct
rounding to the last bit.
>
>> There is also the issue of rounding modes. If the
>> programmer sets one rounding mode in one place, and another rounding
>> mode in another, does he expect different values of PI to be returned
>> with those expressions?
>
> 4*atan(1.d0) is a constant expression, so I do not think that the
> IEEE rounding modes apply.
Why not? Is that part of the standard specification, or it it just the
way one compiler choose to do it?
>
>> However for the intrinsic constants approach, there would need to be
>> different versions of those constants for each real type, not just a
>> single version.
>
> Not necessarily. A constant of the longest available real mode
> could serve in principle, but could cause intermediate calculations
> in higher precision than anticipated, which might be problematic.
That would be one approach. However, as you say, the programmer would
always need to assign the long value to a parameter or variable of the
correct kind first, and then use that local entity rather than the long
intrinsic value in the expression. Otherwise, as you point out, the
programmer would lose control of the precision of the intermediate
results in the expression.
$.02 -Ron Shepard