<div dir="ltr">big picture: improving floating point and friends is +1, and we can definitely have good quality newtypes, but lets make sure they're going to make everyone happy! <div><br></div><div>(one interesting question, what about playing wiht newtypes that use reflection tricks to embed a relative error distance tolerance for equality?)</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Dec 2, 2019 at 1:35 AM Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com">carter.schonwald@gmail.com</a>> 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"><div dir="ltr">@chess, <a class="gmail_plusreply" id="gmail-m_-1042966449054701018plusReplyChip-0" href="mailto:zemyla@gmail.com" target="_blank">@Zemyla</a> <div>the ieee standard actually defines the following total order (i can send you the standard wrt the 2008 version if need be)</div><div>negative nans, -inf, negative finite, 0's , positive finite, inf, positive nans (a very very different ordering than proposed here)</div><div><br></div><div>@Zem, i would love some collab getting some RTS support into ghc for signaling nans, been a bit too busy to do all the work myself!</div><div><br></div><div>so -1 on this proposal, and if you look back in the archives a few years ago you can see a pretty lengthy discussion around a bit more of a fleshed out proposal,</div><div>though some of the end state work requires some more work on the ghc RTS </div><div><br></div><div>the first piece needed to (subsequently implement the rest) appears in ghc 8.10, <a href="https://gitlab.haskell.org/ghc/ghc/commits/ghc-8.10.1-alpha1/compiler/cmm/CmmCallConv.hs" target="_blank">https://gitlab.haskell.org/ghc/ghc/commits/ghc-8.10.1-alpha1/compiler/cmm/CmmCallConv.hs</a> </div><div><a href="https://gitlab.haskell.org/ghc/ghc/commit/42504f4a575395a35eec5c3fd7c9ef6e2b54e68e" target="_blank">https://gitlab.haskell.org/ghc/ghc/commit/42504f4a575395a35eec5c3fd7c9ef6e2b54e68e</a> is the overall commit<br></div><div><br></div><div>it makes SSE2 the only floating point flavor on intel platform (no more x87), which simplifies a lot of 1) determinism in rounding issues that by default would plague 32bit intel platforms, and also cleaned up a pretty crufty corner of the NCG that created a lot of other spurious complexity in improving floating point stuff</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Nov 30, 2019 at 1:35 PM chessai . <<a href="mailto:chessai1996@gmail.com" target="_blank">chessai1996@gmail.com</a>> 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"><div dir="auto"><div dir="auto"></div>I would argue there is no "sensible" implementation of Eq and Ord for floating point. Better to have PartialEq [1] /PartialOrd [2].<div dir="auto"><br></div><div dir="auto">[1]: <a href="https://doc.rust-lang.org/std/cmp/trait.PartialEq.html" target="_blank">https://doc.rust-lang.org/std/cmp/trait.PartialEq.html</a></div><div dir="auto"><br></div><div dir="auto">[2]: <a href="https://doc.rust-lang.org/std/cmp/trait.PartialOrd.html" target="_blank">https://doc.rust-lang.org/std/cmp/trait.PartialOrd.html</a><br><div dir="auto"><br><div dir="auto"><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Sat, Nov 30, 2019, 11:21 AM Zemyla <<a href="mailto:zemyla@gmail.com" rel="noreferrer" target="_blank">zemyla@gmail.com</a>> 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"><p dir="ltr">There should be a newtype wrapper that wraps a RealFloat, keeps the Enum/Num/Fractional/so on instances, but gives it sensible ones for Eq and Ord, with the following order:</p>
<p dir="ltr">NaN < -Inf < negative < -0 < +0 < positive < +Inf</p>
<p dir="ltr">It may not belong in base, but if nothing else it definitely belongs in containers, because Set and Map depend critically on sensible instances of Ord.</p>
<p dir="ltr">(Also, it should newtype derive Read and Show, so that people using them with GHCi see "fromList [(NaN, yadda), (-1.5, yadda), (2.7, blah), (+Inf, blah)]" instead of "fromList [(FloatOrd { unwrapFloat :: NaN }, yadda), ...".)</p>
_______________________________________________<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></div></div>
_______________________________________________<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>
</blockquote></div>