Clarify that the multiply() sign rules don't apply if the result is NaN

[asmeurer]

We should actually define "mathematical sign" somewhere (especially since it
really means "sign bit"), but I'm not sure where this definition should go.

[kgryte]

Re: mathematical sign. No, the intent is not the sign bit; that is an implementation detail. We mean by mathematical sign the sign attribute of a number. One way to check the sign of a floating-point number is by examining the binary representation of an IEEE 754 float, but this is not the only way. Comparison with zero and, for signed zero, division of one will also inform us as to the sign attribute.

Re: this PR. I am not in favor of including these changes as the phrasing is not correct. This PR indicates that a NaN result is the exception, or must obey alternative rules, but this is not required. As discussed elsewhere, an implementation could choose to returned a "signed" NaN for purposes of encoding the signed-ness of the operands.

The current spec is not contradictory in this regard, as both rules can be true at the same time. If there is ambiguity regarding how a NaN should be encoded, that is purposeful, as the signed-ness of NaN is implementation defined. While I am not in favor of the current changes, I am open to including a note or some such explanatory phrase indicating that how NaN values are encoded is implementation defined.

[asmeurer]

Well to me "mathematical sign" means the mathematical definition of sign, which is akin to what the sign() function returns (mathematically 0 and -0 are the same thing, and 0 is neither positive nor negative). So while perhaps "sign bit" suggests an implementation detail, "mathematical sign" isn't much better than what was here before. I would suggest finding a better term, and more importantly, actually defining it.

Re: this PR. I am not in favor of including these changes as the phrasing is not correct.

The current phrasing is also not correct if nan is allowed to not have a "mathematical sign", as it says that the result does have a sign (which is positive/negative). So if nan is allowed to not have a sign, it must be excluded from the rules that talk about mathematical sign. This doesn't preclude nan having a sign if the implementation choses that (although this is currently impossible to test in-spec as we don't have any functions that return the sign of a number).

[kgryte]

I've opened a PR for RFC 2119 compliance which also includes language which should address the concerns in this PR.

It is not that the rules for mathematical sign don't (or more precisely can't) apply to a NaN result, it is that we shouldn't require specification conforming implementations to follow any particular convention. In short, whether a NaN result is signed or not should be implementation-defined.

[rgommers]

I agree that NaN shouldn't be special-cased here, and I think gh-94 addressed the concern here. So I'll close this PR. Thanks @asmeurer and @kgryte