Proposal: New Eq and Ord instances for Double and Float

[Daniel Peebles]

Same. I'd still hate the instances, but my practical concerns would be
mostly covered by it.

On Mon, Sep 26, 2011 at 10:14 AM, Edward Kmett <ekmett at gmail.com> wrote:

> A proposal that made signaling NaN the default is something I could get
> behind.
>
> Sent from my iPad
>
> On Sep 26, 2011, at 9:57 AM, "Roman Leshchinskiy" <rl at cse.unsw.edu.au>
> wrote:
>
> > Paterson, Ross wrote:
> >> Roman Leshchinskiy writes:
> >>> Daniel Fischer wrote:
> >>>> Proposal: Provide Double and Float with Eq and Ord instances that
> >>>> introduce a total order.
> >>>
> >>> I'm strongly against this, for the reasons that have already been
> >>> mentioned.   and because there a good reasons for why the IEEE
> semantics
> >>> is the way it is.
> >>
> >> But compare cannot implement the IEEE semantics and be total, because
> >> the Ordering type cannot represent "unordered".  Something has to give.
> >> The nearest compare can do is to throw an exception if an argument is
> >> NaN (with compatible behaviour from the comparison operators).
> >
> > Why can't compare just specify that its results are undefined when
> applied
> > to NaN? As a matter of fact, the Haskell report already does this. It
> > explicitly says that the results of evaluating expressions like 0/0 are
> > undefined which means that applying compare to them produces undefined
> > results as well.
> >
> >> At least that would not be silent or subtle breakage.
> >
> > IMO, if we really want to avoid silent breakage we shouldn't have silent
> > NaNs by default. That is, evaluating 0/0 should throw an exception.
> Unless
> > I'm mistaken, this can be implemented by simply setting the appropriate
> > processor flag. Personally, I would be much more open to a proposal to
> > make this the default as long as there is no runtime cost and silent NaNs
> > can be turned back on somehow if a program needs them.
> >
> > Roman
> >
> >
> >
> >
> > _______________________________________________
> > Libraries mailing list
> > Libraries at haskell.org
> > http://www.haskell.org/mailman/listinfo/libraries
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20110926/f0e226c7/attachment.htm>