<div dir="ltr">On Fri, Oct 27, 2017 at 1:30 AM, Jonathan Hull <span dir="ltr"><<a href="mailto:jhull@gbis.com" target="_blank">jhull@gbis.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">One completely different idea, which I brought up a year or so ago, is to do what we do with pointers around this. That is you have your fast/unsafe IEEE Floats/Doubles/etc that have a scarier name. These do not conform to Equatable or Comparable, but have their own version of IEEE equality/comparison. Let’s spell it &== and &< to make it feel different so the users consider the possibility of NaN. They don’t have any notion of hashability.<br></blockquote><div><br></div><div>As I wrote in my reply to Greg, IEEE equality and comparison is _the_ best approximation of mathematical equality and comparison suitable for floating-point types. If another one were superior, then floating-point experts would have designated that as the standard.</div><div><br></div><div>Swift correctly exposes only one concept of equality for floating-point types. It is and should be IEEE equality. People should be encouraged and not scared to use it. NaN is and should continue to exist as a concept. Yes, IEEE-compliant floating point is hard; the only thing harder than IEEE-compliant floating point is non-IEEE-compliant floating point.</div><div><br></div><div>This thread is meant to discuss how to reconcile this scenario with the semantics of Equatable.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Then you have your safe/friendly Swift Floating point type(s) which just have no concept of NaN at all (and probably a single notion of zero). You have a failable initializer from the IEEE versions. These types conform to Equatable/Hashable/Comparable. Care is taken with internal methods so that NaN can’t creep into the type.<br>
<br>
How do we handle math functions which might fail? We do the same thing we do in the rest of Swift... those functions return an optional.<br>
<br>
When reading in data from the outside world or C code, you would use the IEEE versions and then either convert or do your calculations directly. They would probably also be used for things like accelerate. But most code, where the values come from user input or literals, would never even have to touch the IEEE version.<br>
<br>
The advantage here is that you get full speed all the time, even in generic contexts. You just can’t use the IEEE versions directly in generic contexts. You would have to convert them, which is a one-time cost (or use them non-generically).<br></blockquote><div><br></div><div>Again, generics and protocol-based numerics are important; that's what Numeric is all about. Any idea that doesn't make this possible is a non-starter.</div><div><br></div></div></div></div>