> On May 3, 2016, at 11:26 PM, Gwendal Roué via swift-evolution > <swift-evolution@swift.org> wrote: > >> The review of "SE-0080: Failable Numeric Conversion Initializers" begins now >> and runs through May 9. The proposal is available here: >> >> >> https://github.com/apple/swift-evolution/blob/master/proposals/0080-failable-numeric-initializers.md > > Hello, > > I'm all for it, but I'd like a clarification about... the Integer / Floating > point interface. > > I once had to write a function that compares Int64 to Double for strict > equality, with all the sweats that come whenever you deal with floating point > representations and have to introduce two-complements representation of > integers as a mandatory precondition: > > /// Returns true if i and d hold exactly the same value, and if > converting one > /// type into the other does not lose any information. > private func int64EqualDouble1(_ i: Int64, _ d: Double) -> Bool { > return (d >= Double(Int64.min)) > && (d < Double(Int64.max)) > && (round(d) == d) > && (i == Int64(d)) > } > > As I understand well the proposal, I could write instead: > > private func int64EqualDouble2(_ i: Int64, _ d: Double) -> Bool { > guard let j = Int64(exact: d) else { return false } > return i == j > } > > But I may be wrong! > > The "without loss of information" in the proposal means that -0.0 (minus > zero) would *not* be convertible to Int64 (which would lose the sign). And > we'd get: > > int64EqualDouble1(0, -0.0) // true > int64EqualDouble2(0, -0.0) // false > > No problem with that. To know if int64EqualDouble1 has a bug, or if > int64EqualDouble2 should handle -0.0 explicitly, one needs to know how -0.0 > should be handled.
This is a good example to consider. I am not a numerics expert and hadn’t thought to consider -0.0. Intuitively I would expect that to convert to 0 when converted to an integer type, however your are right that this is technically a loss of information about the sign bit. I am happy to defer to those with more numerics expertise than I have about what an implementation should do in this case. I am also happy to defer to numerics experts about how to precisely define “loss of information” in general. As noted in the proposal, the primary use case I am concerned with is reading data from semi-structured sources such as JSON where there is only a single “number” type. In these cases the value will be received as a Double but our model may specify an Int, Uint, Int8, etc. Any implementation that allows for validating the conformance of a value to expectations of our model and extracting the valid value with the correct type will be sufficient for the use cases I can imagine. > > So I think that the proposal should make it very clear how it wants to handle > all the funny Float and Double values. Without such a clarification, as handy > as they look like, those functions would remain surprising, which means very > hard to use well, and we'll keep on sweating. Are there any values other than -0.0 we need to worry about? Clearly NaN, Infinity, and -Infinity cannot be represented by integer types and integer initializers would return nil when called with these floating point values. > > Gwendal Roué > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
