[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: My P754-150 comments
1. Given the recent discussion on detection of underflow, here is
another question.
page 48, subclause 7.5, lines 20 and 21:
change
"If the rounded result is exact, no flag is raised and no Inexact
exception is signaled."
to
"If the rounded result is exact, the underflow flag is not raised and
the inexact exception is
not signaled."
which clarifies the meaning of the text.
Does that part mean that the underflow exception is signaled (as
stated in the first line of 7.5: the underflow exception shall be
signaled when a tiny non-zero result is detected) but the flag is not
raised (as stated here)? If yes then how
is it "signaled" in the default exception handling? Is that part in
conflict with subclause 7.1,
line 7 on page 46, that says "the implementation shall provide a
status flag that shall be
raised when the corresponding exception is signaled."?
Yes, the latter is incorrect and requires a qualifying parenthetical
remark. I did not invent the idea that underflow flag should not be raised
for an exact subnormal result by default, but underflow should be signaled
if alternate exception handling is enabled and the default result would have
been exact subnormal.
But I have been trying to make the best of the situation by specifying
that underflow
is always signaled on tininess, but the default handling is to raise no flag
for an exact subnormal result. The existence of the signal is only
visible in alternate exception handling is enabled such as abrupt underflow.
2. The second concern that I have is about our dear pow(x,y)
page 55, line 2 (stating that pow(x,y) is invalid for negative x and
non-integer y)
The pow discussions over decades have reinforced my belief that what
should be standardized is powr whose exceptions can be deduced from
exp (y log(x)) without reading the standard... and which can be wrapped to
handle any exceptional case in any particular way that somebody wants.
The incremental value of the difference between pow and powr is vastly
exceeded by the energy lost in debating and defending any position on the
exceptional cases.
pown and rootn are intended to handle the cases of integral roots and powers of
negative numbers.
3. The third concern I have is about compound(x,n)
page 53, Table 13, entry for compound(x,n)
why is the domain restricted to [-1,+\infty]\times Z and it is not
[-\infty, +\infty]\times Z as in the pown(x,n) function?
compound has to do with growth rates, interest rates in particular,
and an interest rate of -100% is problematic enough and an interest rate
of -200% can only be connected with some kind of fraud OR a programming
error. The probability of the latter vastly exceed the probability
that somebody can think of an application for compound for x < -1.
If there is, go ahead and use pow; the cancellation in adding 1 to x will
not be an issue (unlike the important compound case where |x| << 1 )
In addition to those three main issues, I also suggest that we omit
the specific description of the hexadecimal representation grammar and
that we clearly define the words "identical" and "literal meaning".
Literal meaning is only used twice, and is spelled out in one case and
referred back to from the other, I think.