18629, "damianmoz", "IEEE 754 Predicates", "2021-10-27T03:34:30Z"
Currently, like most languages, Chapel implements the common predicates:
== or .eq.
!= or .ne.
> or .gt.
< or .lt.
>= or .ge.
<= or .le.
The first two never raise an exception if given an NaN.
The rest are implemented as calls to a routine or macro. This makes them hard to read.
We really need at least the following (none of which raise an IEEE exception). They have been recommended for the last 36 years but I have not seen them in any common language. It is about time that was rectified and Chapel can lead the way.
?? or unordered
!?? or not unordered
!> or not greater than
!>= or not greater than or equal to
!< or not less than
!<= or not less than or equal to
I took the liberty of changing the conventional ? for unordered because Chapel already uses a question mark as an operator.
There is also
<> or less or greater than but not equal to or unordered (raises an exception with an NaN in the mix)
!<> or equal to or unordered but neither less or greater than (never raises an exception)
although I am being a bit liberal in my symbol for this last one as some people use that as an alternative to != or not equal to.
Also the first is too close to the swap operator for my liking. In this era of optimizing compilers, I fail to see why swapping needs its own operator and cannot be done as the 58 year old concept of using a tuple for the task
(x, y) = (y, x)
I agree that <=> is extremely concise and makes optimization easier to implement. That said, for a generic language:
swap(x, y)
is pretty tight and very clear and should work for objects of any type.
The reservation of the symbols is urgent before somebody else claims/hijacks them. Especially in this era of lock down the language. So the discussion needs to be had.
On the other hand, their implementation is not urgent. Note than many of those predicates in the second bunch are just a variant of one of the predicates in the first bunch, the difference being that they do not raise an IEEE 754 exception if given an NaN. I think that LLVM handles them several of them already. GCC also did, but that was caused by a bug which did not raise an exception when it was supposed to!
Comments please?