[swift-evolution] [pitch] Comparison Reform

[Xiaodi Wu]

On Sun, Apr 23, 2017 at 1:46 AM, David Waite <david at alkaline-solutions.com>
wrote:

>
> > On Apr 22, 2017, at 10:58 PM, Chris Lattner via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> > I don’t think that this proposal is acceptable as written.  I think it
> is really bad that abstracting a concrete algorithm would change its
> behavior so substantially.  I don’t care about SNaNs, but I do care about
> the difference between +0/-1 and secondarily that of NaN handling.  It
> seems really bad that generalizing something like:
> >
> > func doThing(a : Double, b : Double) -> Bool {
> >   ….
> >   return a != b
> > }
> >
> > to:
> >
> > func doThing<T : FloatingPoint> (a : T, b : T) -> Bool {
> >   ….
> >   return a != b
> > }
> >
> > would change behavior (e.g. when a is -0.0 and b is +0.0).   Likewise,
> "T : Equatable”.
>
> Did I misunderstand the proposal? If T : FloatingPoint is not included in
> level 1 comparisons, then you cannot have classes of generic floating point
> algorithms.
>
> I personally feel sets/dictionaries of FloatingPoint keys to be more
> brittle than other types merely on the basis of the FloatingPoint numbers
> being an approximation within the real space. Different ways to compute a
> number may have different rounding errors, which makes container lookup
> less useful.
>

This is a very good practical point.

In my opinion this is much more about making generic algorithms relying on
> equatable/hashable/comparable able to make safe assumptions.
>
> -DW
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170423/51a13bcd/attachment.html>