On Sat, Apr 22, 2017 at 7:37 PM, Stephen Canon <[email protected]> wrote:
> > On Apr 22, 2017, at 6:55 PM, Xiaodi Wu <[email protected]> wrote: > > Yes. Specifically, in floating point code. I guess that's the part about > shaping the rug not to cover the bump. IEEE does not require `==` to be the > spelling of the quiet equality comparison operator, and it does > specifically describe a comparison operator that behaves identically to > what I propose as the trapping `==` (which, I believe, is actually spelled > in the IEEE standard as `==`). > > > 754 does require a `==` that “raises exceptions", but “raise exception” > has a very specific meaning in the 754 standard that does not align up with > the Swift notion of “trap". In particular, “default exception handling” > under 754 is to set a sticky flag that may be queried later, not to halt > execution. This is exactly what the current Swift `==` operator does at the > hardware level on arm64 and x86, though the flags are not accurately > modeled by LLVM and there are no Swift bindings for manipulating the > floating-point environment [yet] either, so the hardware flag is not > especially useful. > > I’m just catching up with this discussion because my daughter was born a > couple days ago, > First of all, congratulations! Please get sleep instead of catching up on this discussion. but my quick reaction to `&==` is that it would make me quite nervous to > have `==` not bound to 754-equals as it is in essentially every other > language. In particular, I worry about the risk of people porting numerical > code that depends on isnan(x) <—> !(x < y) in non-obvious ways that they > are unlikely to test. I’ll try to follow up with more detailed thoughts > tomorrow. > Indeed, it makes me a little nervous too. That said, `==` being either bound or not bound to 754 depending on the context is what makes me even more nervous. I was once adamantly against a new spelling for `==`, but on reconsideration it's clear to me that few if any numerical recipes can be ported verbatim from C-like languages and we should probably not encourage people to do so. Already, `+` needs to be rewritten as `&+`, `<<` probably should be rewritten as `&<<` (I still haven't had enough time to think about this), and the bitwise operators have differing precedences that require careful proofreading. The idea here is to have floating point `<` trap in Swift just like integer `+` traps in Swift. Those who want the "C-like" version would then reach for `&<` and so on, just like they do for integer `+`, bitshifting `<<`, etc. Anyway, look forward to your continued thoughts.
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
