<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">There was a proposal a little while ago to change Comparable to have an operator producing an enum (with ordered before, same and ordered after cases) which provides strict ordering requirements (unlike the current comparable methods). I think this would serve as a better basis for replacing Swift.min(), and was intended specifically to solve the floating point problem.</div><div class=""><br class=""></div><div class="">It doesn't look like it has a proposal though, maybe I'm not searching for the right terms?</div><br class=""><div><blockquote type="cite" class=""><div class="">On 3 Jul 2016, at 22:28, Pyry Jahkola via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">+1, and bumping this topic.</div><div class=""><br class=""></div><div class="">The background — which I'm sure Jens is aware of — is that IEEE-754 floating point numbers can't truly conform to <font face="Menlo" class="">Comparable</font>. (The problematic case being that neither of `<font face="Menlo" class="">x < .nan</font>`, `<font face="Menlo" class="">x == .nan</font>`, or `<font face="Menlo" class="">x > .nan</font>` can be `<font face="Menlo" class=""><b class="">true</b></font>`.)</div><div class=""><br class=""></div><div class="">But given that the <i class="">NaN-abolishing</i> semantics of `<font face="Menlo" class="">fmin</font>` is quite useful, and since we also want that <font face="Menlo" class="">Double</font> and <font face="Menlo" class="">Float</font> remain conforming to <font face="Menlo" class="">Comparable</font> (albeit brokenly), could we consider fixing this issue by moving `<font face="Menlo" class="">min(_:_:)</font>` and `<font face="Menlo" class="">max</font><span style="font-family: Menlo;" class="">(_:_:)</span>` into <font face="Menlo" class="">Comparable</font>?</div><div class=""><br class=""></div><div class="">The Comparable protocol would become:</div><div class=""><br class=""></div><div class=""><font face="Menlo" class=""> <b class="">public protocol</b> Comparable : Equatable {</font></div><div class=""><font face="Menlo" class=""> <b class="">func</b> < (lhs: Self, rhs: Self) -> Bool</font></div><div class=""><font face="Menlo" class=""> <b class="">func</b> <= (lhs: Self, rhs: Self) -> Bool</font></div><div class=""><font face="Menlo" class=""> <b class="">func</b> >= (lhs: Self, rhs: Self) -> Bool</font></div><div class=""><font face="Menlo" class=""> <b class="">func</b> > (lhs: Self, rhs: Self) -> Bool</font></div><div class=""><font face="Menlo" color="#9929bd" class=""> <b class="">static func</b> minimum(lhs: Self, rhs: Self) -> Self</font></div><div class=""><font face="Menlo" color="#9929bd" class=""> <b class="">static func</b> maximum(lhs: Self, rhs: Self) -> Self</font></div><div class=""><font face="Menlo" class=""> }</font></div><div class=""><br class=""></div><div class="">with default implementations added for the new static functions, and custom implementations for <font face="Menlo" class="">FloatingPoint</font> types. The `<font face="Menlo" class="">Swift.min</font>` and `<font face="Menlo" class="">Swift.max</font>` functions would then forward their logic to `<font face="Menlo" class="">Comparable.minimum</font>` and `<font face="Menlo" class="">Comparable.maximum</font>`.</div><div class=""><br class=""></div><div class="">— Pyry</div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 29 Jun 2016, Jens Persson wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_signature" data-smartmail="gmail_signature">Hi all!</div><div class="gmail_signature" data-smartmail="gmail_signature"><br class=""></div><div class="gmail_signature" data-smartmail="gmail_signature"><div class="gmail_signature" data-smartmail="gmail_signature">Swift.min (and Swift.max) propagates nan or not depending on the order of its args:</div><div class="gmail_signature" data-smartmail="gmail_signature"><br class=""></div><div class="gmail_signature" data-smartmail="gmail_signature">Swift.min(1.0, .nan) // 1.0</div><div class="gmail_signature" data-smartmail="gmail_signature">Swift.min(.nan, 1.0) // nan (!)</div><div class="gmail_signature" data-smartmail="gmail_signature"><br class=""></div><div class="gmail_signature" data-smartmail="gmail_signature">Double.minimum(1.0, .nan) // 1.0</div><div class="gmail_signature" data-smartmail="gmail_signature">Double.minimum(.nan, 1.0) // 1.0</div><div class="gmail_signature" data-smartmail="gmail_signature"><br class=""></div><div class="gmail_signature" data-smartmail="gmail_signature">fmin(1.0, .nan) // 1.0</div><div class="gmail_signature" data-smartmail="gmail_signature">fmin(.nan, 1.0) // 1.0</div><div class="gmail_signature" data-smartmail="gmail_signature"><br class=""></div></div><div class="gmail_signature" data-smartmail="gmail_signature">The new static minimum and maximum funcs on FloatingPoint in Swift 3 shows the expected behaviour (ie the same as fmin, fmax and IEEE-754), so what should happen with Swift.min and Swift.max?</div><div class="gmail_signature" data-smartmail="gmail_signature"><br class=""></div><div class="gmail_signature" data-smartmail="gmail_signature">Fix, remove or perhaps something else?</div><div class="gmail_signature" data-smartmail="gmail_signature"><br class=""></div><div class="gmail_signature" data-smartmail="gmail_signature"><a href="https://bugs.swift.org/browse/SR-1011" class="">https://bugs.swift.org/browse/SR-1011</a><br class=""></div></div></div></blockquote></div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>