<div dir="ltr">On Fri, Oct 27, 2017 at 5:06 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"><div style="word-wrap:break-word"><br><div><span class=""><blockquote type="cite"><div>On Oct 26, 2017, at 11:44 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> wrote:</div><br class="m_6210641461793615536Apple-interchange-newline"><div><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></div></div></div></blockquote><div><br></div></span><div>We definitely have different world views. I see the handling of NaN as a legacy/compatibility issue due to committee/vendor politics from the 1980’s. I am pretty sure if they could do it over with modern tech, we would just have isNan() and NaN == NaN… or we might just have optionals instead.</div><div><br></div><div>Just to play devil’s advocate, there are actually much better and more accurate representations available using the same number of bits. The main issue is that there isn’t common hardware support for them. That is not what I am suggesting here however.</div><span class=""><div> </div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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></div></div></div></blockquote><div><br></div></span><div>What I am suggesting is identical to IEEE in every way except for NaN.</div></div></div></blockquote><div><br></div><div>The most recent edition of IEEE 754 is 70 pages long and mentions NaN on 40 of them. What you suggest is not an IEEE-compliant design for floating point.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>It is just an IEEE value that has been filtered so that we can guarantee it isn’t NaN. It still uses all the same hardware instructions. Basically, it semantically converts NaN to nil… and that lets us conform to Equatable/Comparable honestly. It also still technically adheres to IEEE… it just never comes up because we are careful to filter/handle NaN before the user ever has to deal with it.</div><div><br></div><div>If you want/need to use NaN for some reason, you still have the IEEE types. What you can’t do is use them generically for ==.</div><div><br></div><div>Can you give me an example of where you would want NaN in a generic context (that might also contain Ints), but an optional Float (which had been filtered not to have NaN) wouldn’t meet your needs? Remember, this is a generic context, not one that is special casing Floats.</div></div></div></blockquote><div><br></div><div>I'm not sure I understand the question. If you've already filtered out NaN values, then you wouldn't have any NaN values, so why would you need a generic algorithm that handles NaN?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span class=""><div></div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>This thread is meant to discuss how to reconcile this scenario with the semantics of Equatable.</div></div></div></div></div></blockquote><div><br></div></span><div>Yes it is… and this is one possible approach to doing it. We make it so Floats just don’t conform to Equatable, but we make a wrapper type that does conform (and can fully meet the guarantees).</div><span class=""><div><br></div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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.<wbr> 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>
</div></blockquote><br></span></div><div>Why is everything “impossible” or a “non-starter”? </div></div></blockquote><div><br></div><div>To have a focused discussion, we have to define the givens and the task to be accomplished. Here, the given constraint is that Swift floating point types are IEEE-compliant and conform to Equatable. The task is to design Equatable.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div></div><div>The wrapper version would adhere to Numeric and would be fully usable in generic contexts. You can wrap the IEEE Floats, and the NaNs get converted to optionals, where you can apply the generic algorithm. If your “generic” algorithm was depending on the bit representation of NaN or the fact that it breaks ==, then I would argue you really don’t want a generic algorithm after all… you have a Float specific algorithm.</div><div><br></div><div>Also, in terms of speed, we should find something with the semantics we want (that should be the main focus of our discussion)… and then we can figure out how to tweak it so it goes as fast as we need it to once we know what we are aiming for. Anything else is premature optimization.</div></div></blockquote></div><br></div></div>