Newtype wrapper for Float/Double with sensible Eq/Ord instances

[Carter Schonwald]

@chess, @Zemyla <zemyla at gmail.com>
the ieee standard actually defines the following total order (i can send
you the standard wrt the 2008 version if need be)
negative nans, -inf, negative finite, 0's , positive finite, inf,
positive nans  (a very very different ordering than proposed here)

@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!

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,
though some of the end state work requires some more work on the ghc RTS

the first piece needed to (subsequently implement the rest) appears in ghc
8.10,
https://gitlab.haskell.org/ghc/ghc/commits/ghc-8.10.1-alpha1/compiler/cmm/CmmCallConv.hs

https://gitlab.haskell.org/ghc/ghc/commit/42504f4a575395a35eec5c3fd7c9ef6e2b54e68e
is
the overall commit

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

On Sat, Nov 30, 2019 at 1:35 PM chessai . <chessai1996 at gmail.com> wrote:

> I would argue there is no "sensible" implementation of Eq and Ord for
> floating point. Better to have PartialEq [1] /PartialOrd [2].
>
> [1]: https://doc.rust-lang.org/std/cmp/trait.PartialEq.html
>
> [2]: https://doc.rust-lang.org/std/cmp/trait.PartialOrd.html
>
> On Sat, Nov 30, 2019, 11:21 AM Zemyla <zemyla at gmail.com> wrote:
>
>> 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:
>>
>> NaN < -Inf < negative < -0 < +0 < positive < +Inf
>>
>> 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.
>>
>> (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),
>> ...".)
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20191202/93ca3013/attachment.html>