On Thu, Oct 26, 2017 at 07:52 Jonathan Hull <jh...@gbis.com> wrote: > On Oct 25, 2017, at 11:22 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > On Wed, Oct 25, 2017 at 11:46 PM, Jonathan Hull <jh...@gbis.com> wrote: > >> As someone mentioned earlier, we are trying to square a circle here. We >> can’t have everything at once… we will have to prioritize. I feel like the >> precedent in Swift is to prioritize safety/correctness with an option >> ignore safety and regain speed. >> >> I think the 3 point solution I proposed is a good compromise that follows >> that precedent. It does mean that there is, by default, a small >> performance hit for floats in generic contexts, but in exchange for that, >> we get increased correctness and safety. This is the exact same tradeoff >> that Swift makes for optionals! Any speed lost can be regained by >> providing a specific override for FloatingPoint that uses ‘&==‘. >> > > My point is not about performance. My point is that `Numeric.==` must > continue to have IEEE floating-point semantics for floating-point types and > integer semantics for integer types, or else existing uses of `Numeric.==` > will break without any way to fix them. The whole point of *having* > `Numeric` is to permit such generic algorithms to be written. But since > `Numeric.==` *is* `Equatable.==`, we have a large constraint on how the > semantics of `==` can be changed. > > > It would also conform to the new protocol and have it’s Equatable > conformance depreciated. Once we have conditional conformances, we can add > Equatable back conditionally. Also, while we are waiting for that, Numeric > can provide overrides of important methods when the conforming type is > Equatable or FloatingPoint. > > > For example, if someone wants to write a generic function that works both >> on Integer and FloatingPoint, then they would have to use the new protocol >> which would force them to correctly handle cases involving NaN. >> > > What "new protocol" are you referring to, and what do you mean about > "correctly handling cases involving NaN"? The existing API of `Numeric` > makes it possible to write generic algorithms that accommodate both integer > and floating-point types--yes, even if the value is NaN. If you change the > definition of `==` or `<`, currently correct generic algorithms that use > `Numeric` will start to _incorrectly_ handle NaN. > > > > #1 from my previous email (shown again here): > > Currently, I think we should do 3 things: >>> >>> 1) Create a new protocol with a partial equivalence relation with >>> signature of (T, T)->Bool? and automatically conform Equatable things to it >>> 2) Depreciate Float, etc’s… Equatable conformance with a warning that it >>> will eventually be removed (and conform Float, etc… to the partial >>> equivalence protocol) >>> 3) Provide an '&==‘ relation on Float, etc… (without a protocol) with >>> the native Float IEEE comparison >> >> > In this case, #2 would also apply to Numeric. You can think of the new > protocol as a failable version of Equatable, so in any case where it can’t > meet equatable’s rules, it returns nil. >
Again, Numeric makes possible the generic use of == with floating-point semantics for floating-point values and integer semantics for integer values; this design would not. If speed is super important in that particular case, then they can write >> overrides for the FloatingPoint case which uses &==, and for Equatable >> which uses ==. >> >> Because Float’s Equatable conformance is just being depreciated (with a >> warning/fixit), authors have at least a version to decide whether speed or >> correctness (or hopefully both) is most important to them. >> > > My point here is not about generic algorithms written to take any > Equatable value; it's about protocol-based numeric algorithms, which we in > SE-0104 devoted much time and energy to support in the first place. > > > See above. > > Thanks, > Jon > > > >> Thanks, >> Jon >> >> P.S. We really should not be comparing against the speed of algorithms >> which don’t correctly handle NaN. Let’s compare Apples to Apples. >> > > Again, what do you mean about "correctly handle NaN"? Most algorithms > today *do* correctly handle NaN, in that they are concordant with the > IEEE-specified behavior. Set *not* deduplicating NaN *is* correct handling > of NaN, for instance, for as long as NaN != NaN. > > On Oct 25, 2017, at 6:36 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: >> >> On Wed, Oct 25, 2017 at 8:26 PM, Jonathan Hull <jh...@gbis.com> wrote: >> >>> > On Oct 25, 2017, at 9:01 AM, David Sweeris via swift-dev < >>> swift-dev@swift.org> wrote: >>> > >>> > That said, I fully acknowledge that this is all above my pay grade >>> (also I hadn't realized that the issue was as settled as it apparently is). >>> If splitting the protocols is a no-go from the get go, I'll go back to >>> trying to figure out a better way to handle it without doing that. >>> >>> >>> I don’t think it is settled. The issue that Xiaodi mentioned was a >>> PartiallyEq protocol which still had a signature of (T,T)->Bool. People >>> just used that protocol instead of Equatable without taking into account >>> the difference in behavior. The signature of (T,T)->Bool? changes things >>> because people are forced to deal with the optional. >>> >>> Currently, I think we should do 3 things: >>> >>> 1) Create a new protocol with a partial equivalence relation with >>> signature of (T, T)->Bool? and automatically conform Equatable things to it >>> 2) Depreciate Float, etc’s… Equatable conformance with a warning that it >>> will eventually be removed (and conform Float, etc… to the partial >>> equivalence protocol) >>> 3) Provide an '&==‘ relation on Float, etc… (without a protocol) with >>> the native Float IEEE comparison >>> >>> I think this provides several benefits. #3 allows pure speed when >>> needed, but not in a generic context (and is appropriately scary to cause >>> some thought). #1 forces correct handling in generic contexts. #2 gives >>> people time to make the adjustment, but also eventually requires them to >>> switch to using #1 or #3. >>> >>> I think it will cause A LOT of currently incorrect code to be fixed. >>> >> >> One issue which occurred to me only recently, which I hadn't considered, >> renders my `&==` idea and all similar schemes untenable: >> >> Useful algorithms can and are written which operate on both >> floating-point and integer numeric types. In fact, the whole point of >> laboriously designing `Numeric` as part of SE-0104 was to make it possible >> to do so. If IEEE comparison is relegated to `FloatingPoint` and the only >> operator remaining on `Numeric` is `==`, then not only will there be a >> mandatory performance hit, but currently correct algorithms can be broken >> with absolutely no way to express a fix. >> >> >> >
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
