<div dir="auto"><div dir="auto"></div>Yes, quite. This is only about clarifications to the report. All this other stuff seems mostly tangential, and should probably be another thread.<div dir="auto"><br><div class="gmail_quote" dir="auto"><div dir="ltr">On Thu, Feb 7, 2019, 5:44 PM George Wilson <george@wils.online wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think we've gotten a bit off-track here. Certainly we have<br>
disagreements about what should be done regarding floating-point<br>
values in GHC over the longer term, but that shouldn't hold up the<br>
report.<br>
I would prefer to see the total order laws added as Daniel suggested,<br>
while documenting that Float and Double have non-lawful instances due<br>
to NaNs. If the handling of doubles is later improved we can simply<br>
delete that line of documentation.<br>
<br>
On Fri, 8 Feb 2019 at 08:34, Carter Schonwald<br>
<<a href="mailto:carter.schonwald@gmail.com" rel="noreferrer noreferrer" target="_blank">carter.schonwald@gmail.com</a>> wrote:<br>
><br>
> additionally (for posterity), merjin pointed out to me that we do want x/0 to not be an exception when abs(x)!= 0, because  +/- infinity are perfectly valid and useful mathematical objects<br>
><br>
> On Thu, Feb 7, 2019 at 5:31 PM Merijn Verstraaten <<a href="mailto:merijn@inconsistent.nl" rel="noreferrer noreferrer" target="_blank">merijn@inconsistent.nl</a>> wrote:<br>
>><br>
>><br>
>> > On 7 Feb 2019, at 22:41, David Feuer <<a href="mailto:david.feuer@gmail.com" rel="noreferrer noreferrer" target="_blank">david.feuer@gmail.com</a>> wrote:<br>
>> ><br>
>> > Even if Ord becomes lawful for floating point, there will still be massive problems reasoning about it because the Num instances can't support the ring laws, let alone the ordered ring laws. What should `compare NaN n` be?<br>
>><br>
>> Our goal is to make "compare NaN n" impossible to happen. You can only (try) to compare with NaN if you can *get* a NaN value. But IEEE-754 pretty clearly does *NOT* require computations that evaluate to NaN to be represented as values.<br>
>><br>
>> "Trap representations" (i.e., anything vaguely exception like) are an acceptable IEEE-754 compliant way of implementing NaN. All the major CPU platforms support trapping floating point exceptions, not many languages make use of this.<br>
>><br>
>> > If it's an exception, then the ordering is not total, you can't store NaN in a Set, etc.<br>
>><br>
>> I think this argument is without merit. Yes, it would mean you can't store NaN in a Set anymore (because you wouldn't even be able to have a NaN value...). But that's like complaining Int is broken because I can't store "(5 `div` 0)" in a Set. So far everyone seems perfectly ok with the exception raised by division by zero, so why not NaN?<br>
>><br>
>> > If it's LT or GT, then you get a total ordering, but a rather weird one. So yeah, you'd be able to store NaN in a Set and have an NaN key in a Map, but then as soon as you start looking at where these are coming from and where they're going, everything goes weird and you need type-specific code anyway.<br>
>><br>
>> If we accept value NaN's (as opposed to trapping NaNs) then we can't have Ord anyway, at least not without giving up on IEEE-754 compliance, as IEEE-754 demands "NaN" compares unequal with itself, which breaks any sort of ordering based function (even simple things like sort, as I painfully discovered in Python...)<br>
>><br>
>> Cheers,<br>
>> Merijn<br>
><br>
> _______________________________________________<br>
> Libraries mailing list<br>
> <a href="mailto:Libraries@haskell.org" rel="noreferrer noreferrer" target="_blank">Libraries@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" rel="noreferrer noreferrer" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div></div></div>