On Wed, Apr 19, 2017 at 3:19 PM, Martin R <martinr...@gmail.com> wrote:
> On 19. Apr 2017, at 01:48, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > So, as I understand it, `Float.init(exactly: Double.pi) == nil`. I would > expect NSNumber to behave similarly (a notion with which Martin disagrees, > I guess). I don't see a test that shows whether NSNumber behaves or does > not behave in that way. > > > At present they behave differently: > > print(Float(exactly: Double.pi) as Any) > // nil > print(Float(exactly: NSNumber(value: Double.pi)) as Any) > // Optional(3.14159274) > > I realize that identical behavior would be logical and least surprising. > My only concern was about cases like > > let num = ... // some NSNumber from a JSON deserialization > let fval = Float(exactly: num) > > where one cannot know how the number is represented internally and what > precision it needs. But then one could use the truncating conversion or > `.floatValue` instead. > JSON numbers are double-precision floating point, unless I'm misunderstanding something. If someone writes `Float(exactly: valueParsedFromJSON)`, surely, that can only mean that they *really, really* prefer nil over an imprecise value. I can see no other reason to insist on using both Float and .init(exactly:). > > On Tue, Apr 18, 2017 at 11:43 AM, Philippe Hausler <phaus...@apple.com> > wrote: > >> >> On Apr 18, 2017, at 9:22 AM, Stephen Canon <sca...@apple.com> wrote: >> >> >> On Apr 18, 2017, at 12:17 PM, Joe Groff <jgr...@apple.com> wrote: >> >> >> On Apr 17, 2017, at 5:56 PM, Xiaodi Wu via swift-evolution < >> swift-evolution@swift.org> 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:)). >> On Mon, Apr 17, 2017 at 19:24 Philippe Hausler via swift-evolution < >> swift-evolution@swift.org> 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 >> >> 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. >> >> >> > > Even with the updated code at https://github.com/phausler/swift/tree/safe_ > nsnumber > > print(Double(exactly: NSNumber(value: Int64(9000000000000000001))) as > Any) > // Optional(9e+18) > > still succeeds, however the reason seems to be an error in the > `init(exactly value: someIntegerType)` inititializers of Float/Double, I > have submitted a bug report: https://bugs.swift.org/browse/SR-4634. > > > (+Steve Canon) What is the behavior of Float.init(exactly: Double)? >> NSNumber's behavior would ideally be consistent with that. >> >> >> The implementation is essentially just: >> >> self.init(other) >> guard Double(self) == other else { >> return nil >> } >> >> i.e. if the result is not equal to the source when round-tripped back to >> double (which is always exact), the result is nil. >> >> – Steve >> >> >> Pretty much the same trick inside of CFNumber/NSNumber >> > > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution