The unit tests seem to show that is not needed due to the internal implementation of NSNumber.
> On Apr 17, 2017, at 17:56, Xiaodi Wu <[email protected]> wrote: > > It seems Float.init(exactly: NSNumber) has not been updated to behave > similarly? > > I would have to say, I would naively expect "exactly" to behave exactly as it > says, exactly. I don't think it should be a synonym for > Float(Double(exactly:)). There are a few outliers with that: +/-infinity, nan, and values exceeding +/-Double(Float.greatestFiniteMagnitude) iiuc will trap in that expression. If you take a peek at my unit tests; https://github.com/phausler/swift/blob/safe_nsnumber/test/stdlib/NSNumberBridging.swift#L800 <https://github.com/phausler/swift/blob/safe_nsnumber/test/stdlib/NSNumberBridging.swift#L800> That should verify that float values are properly handled in terms of exactly per the casting rules - This is part of the assumption that both float and double values in swift are IEEE compliant since NSNumber itself stores accordingly. I have tests in place to verify from -1 mantissa bits to +1 mantissa bits conversions from UInt64 and Int64. That all being said: I would be happy to add any additional tests to verify the expected behavior. > On Mon, Apr 17, 2017 at 19:24 Philippe Hausler via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > I posted my branch and fixed up the Double case to account for your concerns > (with a few inspired unit tests to validate) > > https://github.com/phausler/swift/tree/safe_nsnumber > <https://github.com/phausler/swift/tree/safe_nsnumber> > > There is a builtin assumption here though: it does presume that the swift’s > representation of Double and Float are IEEE compliant. However that is a > fairly reasonable assumption in the tests. > >> On Apr 15, 2017, at 13:12, Philippe Hausler <[email protected] >> <mailto:[email protected]>> wrote: >> >> >> >>> On Apr 14, 2017, at 22:51, Martin R <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Thank you for the response, but I have more questions. Will >>> >>> Float(exactly: NSNumber(value: Double.pi)) >> >> This will succeed in that the value is representable without loosing mantissa >> >>> >>> fail because Float cannot represent the number Double.pi exactly? Or >>> >>> Double(exactly: NSDecimalNumber(string: "1.9”)) >> >> Again it would be representable without losing mantissa but… >> >>> >>> because Double cannot represent the decimal fraction 1.9 exactly? >> >> Neither can NSDecimalNumber btw ;X and NSDecimalNumber is not in the scope >> of this proposal (it is it’s own type and bridges to Decimal) >> >>> >>> I find it difficult to evaluate the proposal without a description of the >>> intended behavior of the "exact" conversions which covers all possible >>> combinations (integers, floating point values, booleans). At present, the >>> behavior is described only for stored integer types. >> >> I can post the patch but the real machinery is in NSNumber itself. The >> primary test is that if the value can round trip as the expected type and >> evaluate to equal to a NSNumber it will. >> >> The conversion roughy is a cast to and from the stored type; >> >> extension Double { >> init?(exactly number: NSNumber) { >> let value = number.doubleValue >> guard NSNumber(value: value) == number else { return nil } >> self = value >> } >> } >> >> The effective result of this is a verification of the stored type being >> equal to the fetched value. But specifically this only traverses via tagged >> pointers (if the are present). It is worth noting that this is not the exact >> implementation but an approximation with public apis. >> >> Overall this is by far a better behavior than just permissively allowing all >> conversions (which is the current alternative of doing nothing…). As one of >> the responsible maintainers for NSNumber I would claim that a generally >> permissive cast as it is today is incorrect usage of NSNumber. >> >>> >>> Regards, Martin >>> >>>> On 14. Apr 2017, at 23:23, Philippe Hausler <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>>> >>>>> On Apr 14, 2017, at 2:11 PM, Martin R via swift-evolution >>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>> >>>>> Apologies if I am overlooking something, but it seems to me that the >>>>> proposal does not clearly define the behavior of the "exact" conversions >>>>> between integer and floating point values. Does >>>>> >>>>> Int(exactly: NSNumber(value: 12.34)) >>>> >>>> The exact value of a float or double constructed NSNumber will only happen >>>> for integral values: e.g. 1.0, -32.0 etc >>>> >>>>> >>>>> fail because Int cannot represent the number exactly? Or are floating >>>>> point values truncated silently and the conversion to an integer fails >>>>> only if it overflows? And the other way around: Does >>>>> >>>>> Double(exactly: NSNumber(value: Int64(9000000000000000001))) >>>>> >>>>> fail because Double cannot represent the number exactly? >>>> >>>> I believe this will fail because the Int64 value will exceed the mantissa >>>> representation of the Double from my current implementation. >>>> >>>>> >>>>> Regards, Martin >>>>> >>>>>> On 14. Apr 2017, at 20:45, Ben Cohen via swift-evolution >>>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>>> >>>>>> Apologies, if you are reading this in HTML the links appear to be >>>>>> pointing to the incorrect proposal. >>>>>> >>>>>> Here is the corrected link: >>>>>> >>>>>> https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md >>>>>> >>>>>> <https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md> >>>>>> >>>>>>> On Apr 14, 2017, at 11:30 AM, Ben Cohen <[email protected] >>>>>>> <mailto:[email protected]>> wrote: >>>>>>> >>>>>>> Hello Swift community, >>>>>>> >>>>>>> The review of “SE-0170: NSNumber bridging and Numeric types" begins now >>>>>>> and runs through the Friday after next, April 14th. The proposal is >>>>>>> available here: >>>>>>> >>>>>>> https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md >>>>>>> >>>>>>> <https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md> >>>>>>> Reviews are an important part of the Swift evolution process. All >>>>>>> reviews should be sent to the swift-evolution mailing list at >>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>>>>> or, if you would like to keep your feedback private, directly to the >>>>>>> review manager. When replying, please try to keep the proposal link at >>>>>>> the top of the message: >>>>>>> >>>>>>> Proposal link: >>>>>>> https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md >>>>>>> >>>>>>> <https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md> >>>>>>> >>>>>>> Reply text >>>>>>> >>>>>>> Other replies >>>>>>> >>>>>>> What goes into a review? >>>>>>> >>>>>>> The goal of the review process is to improve the proposal under review >>>>>>> through constructive criticism and, eventually, determine the direction >>>>>>> of Swift. When writing your review, here are some questions you might >>>>>>> want to answer in your review: >>>>>>> >>>>>>> • What is your evaluation of the proposal? >>>>>>> • Is the problem being addressed significant enough to warrant >>>>>>> a change to Swift? >>>>>>> • Does this proposal fit well with the feel and direction of >>>>>>> Swift? >>>>>>> • If you have used other languages or libraries with a similar >>>>>>> feature, how do you feel that this proposal compares to those? >>>>>>> • How much effort did you put into your review? A glance, a >>>>>>> quick reading, or an in-depth study? >>>>>>> >>>>>>> More information about the Swift evolution process is available at >>>>>>> https://github.com/apple/swift-evolution/blob/master/process.md >>>>>>> <https://github.com/apple/swift-evolution/blob/master/process.md> >>>>>>> >>>>>>> Thank you, >>>>>>> >>>>>>> Ben Cohen >>>>>>> Review Manager >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> swift-evolution mailing list >>>>>> [email protected] <mailto:[email protected]> >>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>>> >>>>> _______________________________________________ >>>>> swift-evolution mailing list >>>>> [email protected] <mailto:[email protected]> >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
