> On Jul 1, 2016, at 7:44 AM, Joseph Lord via swift-evolution
> <swift-evolution@swift.org> wrote:
>
>
>> The review of "SE-0113: Add integral rounding functions to FloatingPoint"
>> begins now and runs through July 5. The proposal is available here:
>>
>>
>> https://github.com/apple/swift-evolution/blob/master/proposals/0113-rounding-functions-on-floatingpoint.md
>>
>> * What is your evaluation of the proposal?
>
> It is an improvement but would it be even better if the return type was Int
> (or possibly type inferred to Int16 etc.). If a float is really desired it
> can be initialised from the Int (or it could even infer float result is
> required).
This is a common thought, but it's precisely backwards from a numerics and
pragmatics perspective. The result is always representable as `Self`, and
generally not representable in any fixed-width integer type. If you have the
version that produces `Self`, getting an integer falls out trivially:
let y = Int(x.rounded(.up)) [1]
But if you only have the version that produces an integer result, you’re stuck
with a much more complex workaround when you actually need the result as `Self`
(which is more common than you think). In the best case scenario, where `Int`
is bigger than the significand of `Self`, it’s not *too* bad, but still
requires at least a conditional and two conversions. In the bad scenario, a
floating-point type whose significand doesn’t fit in `Int`, you end up needing
to write all the rounding logic yourself.
The idea of also having a set of Integer inits that round has been mentioned
once or twice in the past:
let y = Int(roundedUp: x)
I’m not sure if that’s really any cleaner than [1], but it could certainly be
considered as another proposal.
– Steve
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
