My primary objection is that currently all operators have ieee semantics on Float/Double. This change would mean that basic arithmatic operators would have ieee semantics but comparisons would not. I consider this a significant added burden on users who are used to thinking in the current semantics (it makes Eq more uniform at the cost of making Float/Double less so). Of course I do concede that it's probably much simpler for people using Eq to assume reflexivity. On Thu, Sep 25, 2014 at 11:51 AM, David Feuer wrote:

I'm not sure what you're saying. What I'm saying is that we can make Eq faster for some things *other* than Float/Double in some contexts if we take away the ability of Eq to deal with the messiness of IEEE requirements, which also happens to have the advantage of making sure that (a==b) /= _|_ -> (a==b) == not (a /= b). I have my own opinions about the numerical typeclass hierarchy (Num et al), but I think this issue is pretty much orthogonal.

On Wed, Sep 24, 2014 at 11:43 PM, John Lato wrote:

...

This strikes me as a halfway measure between those who want arithmatic operations on Float/Double to be fast (i.e. IEEE754 semantics/machine ops) and those who want more exacting laws associated with arithmatic classes. As such, I think it's a bad idea. I think it's better that all operations follow the same philosophy.

On Thu, Sep 25, 2014 at 11:25 AM, David Feuer wrote:

...

As Edward Kmett explained to me, (/=) is currently needed in Eq to support IEEE floating point semantics for (==) and (/=). As I see it, those semantics are badly broken from the perspective of what Eq is supposed to mean, and really should be supported using special functions (eqIEEE and neqIEEE or whatever), whereas the most appropriate Eq instance for floating point would be something more like

instance Eq Double where x == y = decodeFloat x == decodeFloat y

If this is (eventually) done, that would allow us to remove (/=) from Eq, reducing its dictionary to a single member, (==), improving efficiency when the type is not statically known.

David

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

i'm strongly -1 on doing ANYTHING resembling instance Eq Double where x == y = decodeFloat x == decodeFloat y floating point is odd because it kinda has to be, and changes to the defaults for that need a lot of discussion about the implications (even before they got to the libraries list). On Thu, Sep 25, 2014 at 1:05 AM, Johan Tibell wrote:

-1

This would make floating point values a pain to work with for seemingly little gain.

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

On Thu, Sep 25, 2014 at 5:38 AM, Herbert Valerio Riedel wrote:

On 2014-09-25 at 05:25:02 +0200, David Feuer wrote:

...

As Edward Kmett explained to me, (/=) is currently needed in Eq to support IEEE floating point semantics for (==) and (/=). As I see it, those semantics are badly broken from the perspective of what Eq is supposed to mean, and really should be supported using special functions (eqIEEE and neqIEEE or whatever), whereas the most appropriate Eq instance for floating point would be something more like

If the Eq instance for Double is changed, what about its Ord instance then? Right now, (0/0::Double) is handled poorly for both Eq and Ord, resulting in Data.Map and other operations relying on Eq/Ord to behave weirdly when (0/0::Double) happens to be used as key.

If you go to use Doubles for keys in a Data.Map you'd have a whole host of other problems. Even if you had the instance proposed here, which makes it harder to work nicely with underflow/overflow conditions on doubles, which are a far more common going concern and motivate the IEEE design, you have an issue. Notably, that if you compute the same number twice in different parts of your program or even the same part at different times you can get different answers due to intermediate value promotion in the FPU, etc. That pretty much damns any attempt to use doubles for exact value-match key lookup to unreliability or failure. FWIW- I'm -1 on this proposal. -Edward

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries