SE-0170: NSNumber bridging and Numeric types


(Ben Cohen) #1

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/0155-normalize-enum-case-representation.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
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/0155-normalize-enum-case-representation.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

Thank you,

Ben Cohen
Review Manager


(Ben Cohen) #2

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

···

On Apr 14, 2017, at 11:30 AM, Ben Cohen <ben_cohen@apple.com> 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

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
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

  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

Thank you,

Ben Cohen
Review Manager


(Matthew Johnson) #3

  • What is your evaluation of the proposal?

+1. I have run into problems with the current behavior a few times. This proposal brings the behavior in-line with what I believe is best.

  • Is the problem being addressed significant enough to warrant a change to Swift?

Yes.

  • Does this proposal fit well with the feel and direction of Swift?

Yes. It continues the trend of refining the behavior of Objetive-C and Cocoa bridging.

  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I have not worked in a language with the kind of first-class bridging Swift has.

  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I was the author of SE-0080 and wanted to include similar provisions in that proposal early on so I think it’s fair to say an in-depth study. I’m happy to see the Foundation side of this topic receiving attention.


(Martin R) #4

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))

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?

Regards, Martin

···

On 14. Apr 2017, at 20:45, Ben Cohen via swift-evolution <swift-evolution@swift.org> 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

On Apr 14, 2017, at 11:30 AM, Ben Cohen <ben_cohen@apple.com <mailto:ben_cohen@apple.com>> 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
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
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

  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

Thank you,

Ben Cohen
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Philippe Hausler) #5

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.

···

On Apr 14, 2017, at 2:11 PM, Martin R via swift-evolution <swift-evolution@swift.org> wrote:

Regards, Martin

On 14. Apr 2017, at 20:45, Ben Cohen via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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

On Apr 14, 2017, at 11:30 AM, Ben Cohen <ben_cohen@apple.com <mailto:ben_cohen@apple.com>> 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
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
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

  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

Thank you,

Ben Cohen
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto: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


(Martin R) #6

Thank you for the response, but I have more questions. Will

    Float(exactly: NSNumber(value: Double.pi))
    
fail because Float cannot represent the number Double.pi exactly? Or

    Double(exactly: NSDecimalNumber(string: "1.9"))
    
because Double cannot represent the decimal fraction 1.9 exactly?

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.

Regards, Martin

···

On 14. Apr 2017, at 23:23, Philippe Hausler <phausler@apple.com> wrote:

On Apr 14, 2017, at 2:11 PM, Martin R via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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

On Apr 14, 2017, at 11:30 AM, Ben Cohen <ben_cohen@apple.com <mailto:ben_cohen@apple.com>> 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
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
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

  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

Thank you,

Ben Cohen
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Philippe Hausler) #7

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.

···

On Apr 14, 2017, at 22:51, Martin R <martinr448@gmail.com> wrote:

Regards, Martin

On 14. Apr 2017, at 23:23, Philippe Hausler <phausler@apple.com <mailto:phausler@apple.com>> wrote:

On Apr 14, 2017, at 2:11 PM, Martin R via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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

On Apr 14, 2017, at 11:30 AM, Ben Cohen <ben_cohen@apple.com <mailto:ben_cohen@apple.com>> 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
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
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

  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

Thank you,

Ben Cohen
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Martin R) #8

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

Float has shorter mantissa than Double and can not represent Double.pi exactly. And it does fail when using the implementation which you provided below:

    extension Float {
        init?(exactly number: NSNumber) {
            let value = number.floatValue
            guard NSNumber(value: value) == number else { return nil }
            self = value
        }
    }

    print(Float(exactly: NSNumber(value: Double.pi)) as Any)
    // nil

On the other hand, a conversion from an Int64 exceeding the mantissa (for which you assumed in an earlier reply that it fails) actually succeeds:

    extension Double {
        init?(exactly number: NSNumber) {
            let value = number.doubleValue
            guard NSNumber(value: value) == number else { return nil }
            self = value
        }
    }

    print(Double(exactly: NSNumber(value: Int64(9000000000000000001))) as Any)
    // Optional(9e+18)

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)

But NSDecimalNumber is still a subclass of NSNumber, and can represent 1.9 exactly. Therefore the behavior of

    Double(exactly: someNumberWithIsActuallyAnNSDecimalNumber)

would be interesting.

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.

I agree that the current behavior is bad and should be improved, and I agree with the proprosal with respect to integer values.

What I still have problems with is how "loss of precision" is (and should be) handled for conversions from/to/between floating point values. The above examples show an inconsistent behaviour:

    print(Float(exactly: NSNumber(value: Double.pi)) as Any)
    // nil

    print(Double(exactly: NSNumber(value: Int64(9000000000000000001))) as Any)
    // Optional(9e+18)

but perhaps the real implementation will behave differently.

When obtaining a NSNumber from some API one cannot know if the number is internally represented as Double or Float or is actually a NSDecimalNumber. Therefore is seems impractical to me if Float(exactly: someNumber) failed if precision were lost during the conversion.

Regards, Martin

···

On 15. Apr 2017, at 22:12, Philippe Hausler <phausler@apple.com> wrote:

On Apr 14, 2017, at 22:51, Martin R <martinr448@gmail.com <mailto:martinr448@gmail.com>> wrote:

Regards, Martin

On 14. Apr 2017, at 23:23, Philippe Hausler <phausler@apple.com <mailto:phausler@apple.com>> wrote:

On Apr 14, 2017, at 2:11 PM, Martin R via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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

On Apr 14, 2017, at 11:30 AM, Ben Cohen <ben_cohen@apple.com <mailto:ben_cohen@apple.com>> 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
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
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

  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

Thank you,

Ben Cohen
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Philippe Hausler) #9

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.

···

On Apr 15, 2017, at 13:12, Philippe Hausler <phausler@apple.com> wrote:

On Apr 14, 2017, at 22:51, Martin R <martinr448@gmail.com <mailto:martinr448@gmail.com>> 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 <phausler@apple.com <mailto:phausler@apple.com>> wrote:

On Apr 14, 2017, at 2:11 PM, Martin R via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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

On Apr 14, 2017, at 11:30 AM, Ben Cohen <ben_cohen@apple.com <mailto:ben_cohen@apple.com>> 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
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
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

  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

Thank you,

Ben Cohen
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Xiaodi Wu) #10

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.

On Apr 15, 2017, at 13:12, Philippe Hausler <phausler@apple.com> wrote:

On Apr 14, 2017, at 22:51, Martin R <martinr448@gmail.com> 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 <phausler@apple.com> wrote:

On Apr 14, 2017, at 2:11 PM, Martin R via swift-evolution < > swift-evolution@swift.org> 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 < > swift-evolution@swift.org> 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

On Apr 14, 2017, at 11:30 AM, Ben Cohen <ben_cohen@apple.com> 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

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
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

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

Thank you,

Ben Cohen
Review Manager

_______________________________________________
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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Philippe Hausler) #11

The unit tests seem to show that is not needed due to the internal implementation of NSNumber.

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

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 Apr 17, 2017, at 17:56, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

On Mon, Apr 17, 2017 at 19:24 Philippe Hausler via swift-evolution <swift-evolution@swift.org <mailto: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.

On Apr 15, 2017, at 13:12, Philippe Hausler <phausler@apple.com <mailto:phausler@apple.com>> wrote:

On Apr 14, 2017, at 22:51, Martin R <martinr448@gmail.com <mailto:martinr448@gmail.com>> 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 <phausler@apple.com <mailto:phausler@apple.com>> wrote:

On Apr 14, 2017, at 2:11 PM, Martin R via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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

On Apr 14, 2017, at 11:30 AM, Ben Cohen <ben_cohen@apple.com <mailto:ben_cohen@apple.com>> 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
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
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

  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

Thank you,

Ben Cohen
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Joe Groff) #12

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:)).
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.

(+Steve Canon) What is the behavior of Float.init(exactly: Double)? NSNumber's behavior would ideally be consistent with that.

-Joe

···

On Apr 17, 2017, at 5:56 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:
On Mon, Apr 17, 2017 at 19:24 Philippe Hausler via swift-evolution <swift-evolution@swift.org> wrote:

On Apr 15, 2017, at 13:12, Philippe Hausler <phausler@apple.com> wrote:

On Apr 14, 2017, at 22:51, Martin R <martinr448@gmail.com> 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 <phausler@apple.com> wrote:

On Apr 14, 2017, at 2:11 PM, Martin R via swift-evolution <swift-evolution@swift.org> 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 <swift-evolution@swift.org> 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

On Apr 14, 2017, at 11:30 AM, Ben Cohen <ben_cohen@apple.com> 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

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
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

  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

Thank you,

Ben Cohen
Review Manager

_______________________________________________
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

_______________________________________________
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


(Stephen Canon) #13

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

···

On Apr 18, 2017, at 12:17 PM, Joe Groff <jgroff@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.

(+Steve Canon) What is the behavior of Float.init(exactly: Double)? NSNumber's behavior would ideally be consistent with that.


(Philippe Hausler) #14

Pretty much the same trick inside of CFNumber/NSNumber

···

On Apr 18, 2017, at 9:22 AM, Stephen Canon <scanon@apple.com> wrote:

On Apr 18, 2017, at 12:17 PM, Joe Groff <jgroff@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.

(+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


(Xiaodi Wu) #15

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.

···

On Tue, Apr 18, 2017 at 11:43 AM, Philippe Hausler <phausler@apple.com> wrote:

On Apr 18, 2017, at 9:22 AM, Stephen Canon <scanon@apple.com> wrote:

On Apr 18, 2017, at 12:17 PM, Joe Groff <jgroff@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.

(+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


(Martin R) #16

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.

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:)).
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.

···

On 19. Apr 2017, at 01:48, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
On Tue, Apr 18, 2017 at 11:43 AM, Philippe Hausler <phausler@apple.com <mailto:phausler@apple.com>> wrote:

On Apr 18, 2017, at 9:22 AM, Stephen Canon <scanon@apple.com <mailto:scanon@apple.com>> wrote:

On Apr 18, 2017, at 12:17 PM, Joe Groff <jgroff@apple.com <mailto:jgroff@apple.com>> wrote:

On Apr 17, 2017, at 5:56 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Mon, Apr 17, 2017 at 19:24 Philippe Hausler via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

(+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


(Philippe Hausler) #17

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:).

JSON does not claim 32 or 64 bit floating point, or for that matter 128 or infinite bit floating point :frowning:

After thinking about it more; it seems reasonable to restrict it to the behavior of Float(exactly: Double(…)). I am certain this will probably in the end cause more bugs for me to have to address and mark as “behaves correctly” and confuse a few new developers - but in the end they chose Swift and the consistent story would be the current behavior of Float(exactly: Double).

···

On Apr 19, 2017, at 3:23 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
On Wed, Apr 19, 2017 at 3:19 PM, Martin R <martinr448@gmail.com <mailto:martinr448@gmail.com>> wrote:

On 19. Apr 2017, at 01:48, Xiaodi Wu <xiaodi.wu@gmail.com <mailto:xiaodi.wu@gmail.com>> wrote:

On Tue, Apr 18, 2017 at 11:43 AM, Philippe Hausler <phausler@apple.com <mailto:phausler@apple.com>> wrote:

On Apr 18, 2017, at 9:22 AM, Stephen Canon <scanon@apple.com <mailto:scanon@apple.com>> wrote:

On Apr 18, 2017, at 12:17 PM, Joe Groff <jgroff@apple.com <mailto:jgroff@apple.com>> wrote:

On Apr 17, 2017, at 5:56 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org <mailto: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 <mailto: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


(Philippe Hausler) #18

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:).

JSON does not claim 32 or 64 bit floating point, or for that matter 128 or infinite bit floating point :frowning:

Oops, you're right. I see they've wanted to future-proof this. That said, RFC 7159 *does* say:

This specification allows implementations to set limits on the range
and precision of numbers accepted. Since software that implements
IEEE 754-2008 binary64 (double precision) numbers [IEEE754] is
generally available and widely used, good interoperability can be
achieved by implementations that expect no more precision or range
than these provide, in the sense that implementations will
approximate JSON numbers within the expected precision.

So JSON doesn't set limits on how numbers are represented, but JSON implementations are permitted to (and I'd imagine that all in fact do). A user of a JSON deserialization library can rightly expect to know the numeric limits of that implementation; for the purposes of bridging NSNumber, if the answer is that the implementation parses JSON numbers as double-precision values, Double(exactly:) would be the right choice; otherwise, if it's 80-bit values, then Float80(exactly:) would be the right choice, etc.

Float80 is not compatible with NSNumber; and is well out of scope for this proposal.

···

On Apr 19, 2017, at 16:17, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
On Wed, Apr 19, 2017 at 6:00 PM, Philippe Hausler <phausler@apple.com <mailto:phausler@apple.com>> wrote:

On Apr 19, 2017, at 3:23 PM, Xiaodi Wu <xiaodi.wu@gmail.com <mailto:xiaodi.wu@gmail.com>> wrote:
On Wed, Apr 19, 2017 at 3:19 PM, Martin R <martinr448@gmail.com <mailto:martinr448@gmail.com>> wrote:

On 19. Apr 2017, at 01:48, Xiaodi Wu <xiaodi.wu@gmail.com <mailto:xiaodi.wu@gmail.com>> wrote:

After thinking about it more; it seems reasonable to restrict it to the behavior of Float(exactly: Double(…)). I am certain this will probably in the end cause more bugs for me to have to address and mark as “behaves correctly” and confuse a few new developers - but in the end they chose Swift and the consistent story would be the current behavior of Float(exactly: Double).

On Tue, Apr 18, 2017 at 11:43 AM, Philippe Hausler <phausler@apple.com <mailto:phausler@apple.com>> wrote:

On Apr 18, 2017, at 9:22 AM, Stephen Canon <scanon@apple.com <mailto:scanon@apple.com>> wrote:

On Apr 18, 2017, at 12:17 PM, Joe Groff <jgroff@apple.com <mailto:jgroff@apple.com>> wrote:

On Apr 17, 2017, at 5:56 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org <mailto: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 <mailto: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


(Xiaodi Wu) #19

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 Wed, Apr 19, 2017 at 3:19 PM, Martin R <martinr448@gmail.com> wrote:

On 19. Apr 2017, at 01:48, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

On Tue, Apr 18, 2017 at 11:43 AM, Philippe Hausler <phausler@apple.com> > wrote:

On Apr 18, 2017, at 9:22 AM, Stephen Canon <scanon@apple.com> wrote:

On Apr 18, 2017, at 12:17 PM, Joe Groff <jgroff@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


(Xiaodi Wu) #20

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:).

JSON does not claim 32 or 64 bit floating point, or for that matter 128 or
infinite bit floating point :frowning:

Oops, you're right. I see they've wanted to future-proof this. That said,
RFC 7159 *does* say:

This specification allows implementations to set limits on the range

and precision of numbers accepted. Since software that implements

IEEE 754-2008 binary64 (double precision) numbers [IEEE754] is

generally available and widely used, good interoperability can be
achieved by implementations that expect no more precision or range
than these provide, in the sense that implementations will
approximate JSON numbers within the expected precision.

So JSON doesn't set limits on how numbers are represented, but JSON
implementations are permitted to (and I'd imagine that all in fact do). A
user of a JSON deserialization library can rightly expect to know the
numeric limits of that implementation; for the purposes of bridging
NSNumber, if the answer is that the implementation parses JSON numbers as
double-precision values, Double(exactly:) would be the right choice;
otherwise, if it's 80-bit values, then Float80(exactly:) would be the right
choice, etc.

After thinking about it more; it seems reasonable to restrict it to the

···

On Wed, Apr 19, 2017 at 6:00 PM, Philippe Hausler <phausler@apple.com> wrote:

On Apr 19, 2017, at 3:23 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
On Wed, Apr 19, 2017 at 3:19 PM, Martin R <martinr448@gmail.com> wrote:

On 19. Apr 2017, at 01:48, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

behavior of Float(exactly: Double(…)). I am certain this will probably in
the end cause more bugs for me to have to address and mark as “behaves
correctly” and confuse a few new developers - but in the end they chose
Swift and the consistent story would be the current behavior of
Float(exactly: Double).

On Tue, Apr 18, 2017 at 11:43 AM, Philippe Hausler <phausler@apple.com> w
rote:

On Apr 18, 2017, at 9:22 AM, Stephen Canon <scanon@apple.com> wrote:

On Apr 18, 2017, at 12:17 PM, Joe Groff <jgroff@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