On Thu, 9 Nov 2017, Hal Finkel wrote:
-------- Forwarded Message --------
...
From Jim Thomas. I???ll leave it to you to forward this to Austin Group.
Hal is correct, and I think the response to him misses the
point that he raised.
Agreed.
What Hal was talking about was the fact that cabs(a + I*b) ==
sqrt(a*a + b*b), and the squaring done by cabs() is what causes the
overflow.
The C expressions cabs(a + I*b) and sqrt(a*a + b*b) aren???t equivalent
because the computation of the argument to sqrt overflows in many cases where
the corresponding cabs does not (e.g., a = DBL_MAX, b = 0, a+a + b*b = inf,
sqrt = inf, cabs = DBL_MAX). However, cabs can overflow in extreme cases,
like the one mentioned below: cabs(1.7e308+I*1.7e308).
Most of those who are interested in optimization would really
like for errno to go away, and I don't see any problem with POSIX
specifying that it isn't set for cases where the C standard leaves
it unspecified.
I think this gets to Hal???s point. The only problem I see (with the C-POSIX
difference) is for implementation of cabs(a + bi) as hypot(a, b) if hypot
sets errno. G.6#6 says
Each of the functions cabs and carg is specified by a formula in
terms of a real function (whose special cases are covered in annex F):
cabs(x + iy) = hypot(x, y)
carg(x + iy) = atan2(y, x)
Maybe one could argue that this specification does not apply to errno.
No, it is well known that hypot() can't be evaluated by the simple formula
without large loss of accuracy and spurious overflow, and even C99 without
Annex F forbids overrides its own suggestion of a low quality implemenation
by discouraging overflow:
7.12.7.3 The hypot functions
...
[#2] The hypot functions compute the square root of the sum
of the squares of x and y, without undue overflow or
underflow. A range error may occur.
This apparently uses the ancient hard to read mathematical style of
writing formulas in words because it doesn't want to give a hint that
sqrt(x*x+y*y) is evaluated in any particular precision or accuracy.
Everyone knows that it means large enough precision and accuracy, but
I think it allows even 0-bit precision and accuracy provided "undue"
overflow doesn't occur. This is more than required for most functions.
It is only required here since otherwise the simplistic formula would
be the specification, and then only the fuzzy wording for "compute"
allows avoiding overflow.
Complex arithmetic has related problems. The simplistic formulas for
multiplication and division don't work if overflow or cancelation
occurs, and the specification has to have complications like the above
(but larger) to specify the behaviour without using the formulas.
Bruce
