[Cfp-interest 1530] Re: Background on hypot(x, y) for INFINITY and NAN

[Damian McGuckin]

On Thu, 5 Mar 2020, Jim Thomas wrote:

> The general idea is that if an operation has the value k for all 
> numerical inputs then it should have the value k for a quiet NaN input 
> as well. This makes sense provided only that some numerical input was 
> intended but for some reason/error the input arrived as a quiet NaN. It 
> doesn?t matter if the input is erroneous, the result would be k no 
> matter what was intended.

I was aware of those reasons from my past investigation although your 
words and those of David are the clearest I have ever seen on paper (so to 
speak). Then again, there is no such thing as a commentary on the standard 
by those on the committee. I find fishing for problems in grouper.ieee.org
not so useful but then again, maybe my keyword search skills are less than
optimal.

> If the NaN input were the result of an invalid operation, an exception 
> would have been signaled when the NaN was created, which would allow 
> finding out that a NaN had appeared.

This is always the ideal but sometimes not quite as easy to do as we would 
all like, especially if we are using precompiled routines which themselves 
call library routines. Or worse, using packages where we have no access to 
the source.

> It?s thought that this is more helpful than the alternative of returning 
> a NaN.

The dilemma for a standard's body is the task of figuring out what is most 
helpful to the biggest audience. A daunting responsibility.

> This principle extends to two argument operations like hypot when for a 
> fixed value of one operand the operation is constant with respect to all 
> numerical values of the other operand.

The same reasoning now applies to the sumSquare routine as well.

Just as we now have maximum and minumum operation with two different NaN 
propogation/non-propogation behaviours, I think we may yet eventually see 
two different versions of such routines, one which does and one which does 
not. If not in IEEE754-2029, at least in IEEE754-2039!

I was amazed to discover the other day that a fundamental (approx) 2010 
design decision in the RISC-V ISA relied on the FMAX/FMIN definition from 
IEEE754-2008 which has now been effectively reversed. Even in 2000, 10 
years before that standard, there were arguments against it which the ISA 
designers did not take into account. ARM took the (wise and) pragmatic 
approach of having both. RISC-V's approach was very short-sighted.

All very interesting.

Thanks for the background - Damian

Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer