<div dir="ltr">true enough<div><br></div><div>Another cool thing that was pointed out to me, is that for NanFree Floats, the Projective reals (err, floats) with a single infinity become a new type over float/double (subject to how reals and floats) release. (thanks to Wren for that point )</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 7, 2019 at 5:43 PM George Wilson <george@wils.online> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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" 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" 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" 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" target="_blank">Libraries@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>