Add support for copysign to the specification

[kgryte]

This PR

• resolves Add copysign function to the standard #593 by adding support for composing a floating-point value having the magnitude of x1_i and the sign of x2_i for each element in x1_i.
• chooses to follow strict IEEE 754 semantics, in which the sign bit of NaN may be manipulated.
• limits to only real-valued floating-point data types.
• requires that input arguments participate in type promotion.

Questions

• Are we comfortable limiting to only floating-point data types? Libraries would be free, of course, to support other dtypes (e.g., NumPy), but this would not be considered portable according to the spec.
• Are we comfortable with embracing full IEEE 754 NaN semantics, namely signed NaNs?

[rgommers]

Are we comfortable limiting to only floating-point data types?

Yes, because real-valued floating-point dtypes is all that's in C99.

Are we comfortable with embracing full IEEE 754 NaN semantics, namely signed NaNs?

If it's supported by all libraries, then it should be fine I think. I quickly checked NumPy, PyTorch and JAX, all three seem to support it.

[seberg]

I see nothing wrong with "supporting" signed NaNs. In practice, I doubt libraries take care with having meaningful signs. Python float("nan") is always positive, np.nan I suspect is, but I am not 100% right now (I would be happy to ensure it though).

The C NAN macro does not have a defined sign though. If you really want to worry more about signs, you could specify the sign of namespace.nan (I would say its low prio until someone shouts).

EDIt: To be clear, the C macro is not just theoretical, a negative sign is actually typical

EDIT2: But if anyone has a problem with supporting it on some hardware, then I guess can just add a note for that.

[kgryte]

@seberg To clarify, while np.nan is a double whose signbit is 0, NumPy does support signed NaNs:

In [1]: np.signbit(-np.nan)
Out[1]: True

In [2]: np.signbit(np.nan)
Out[2]: False

In [3]: np.signbit(np.copysign(np.nan, -1.0))
Out[3]: True

In [4]: np.signbit(np.copysign(np.nan, 1.0))
Out[4]: False

In [5]: np.signbit(np.copysign(-np.nan, 1.0))
Out[5]: False

In [6]: np.signbit(np.copysign(np.nan, -np.nan))
Out[6]: True

In [7]: np.signbit(np.copysign(np.nan, np.nan))
Out[7]: False

[kgryte]

As this PR has been reviewed and discussed without objections, will go ahead and merge. Any subsequent revisions can be addressed in follow-up PRs...

[asmeurer]

Python float("nan") is always positive,

I'm curious, do you know if this is guaranteed by the language, or does it just happen to be true for all implementations?

[seberg]

CPython ensures this and I am pretty sure even tests for it (I has once looked at simplifying the code responsible). I.e., IIRC, we can rely on Mark Dickinson to ensure this.
I suppose other Python implementations may not, but I would guess that if you point out CPython does, you can ask them to change it (if it matters).