> On 15. Apr 2017, at 22:12, Philippe Hausler <phaus...@apple.com> wrote:
>
>
>
>> On Apr 14, 2017, at 22:51, Martin R <martinr...@gmail.com
>> <mailto:martinr...@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
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
>
>>
>> Regards, Martin
>>
>>> On 14. Apr 2017, at 23:23, Philippe Hausler <phaus...@apple.com
>>> <mailto:phaus...@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
>>>>>
>>>>> <https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md>
>>>>>
>>>>>> On Apr 14, 2017, at 11:30 AM, Ben Cohen <ben_co...@apple.com
>>>>>> <mailto:ben_co...@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
>>>>>>
>>>>>> <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
>>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>> <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
>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
