> On Jun 29, 2016, at 1:00 PM, Stephen Canon <[email protected]> wrote:
>
>
>> On Jun 29, 2016, at 12:46 PM, Matthew Johnson <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> +1 to adding robust rounding to he standard library.
>>
>> I’m curious why we have both `up` and `down`, but only have `towardZero`
>> without `awayFromZero`.
>>
>> I’m also curious what the use case is for `toNearestOrEven` and why you
>> don’t include `toNearestOrOdd`.
>>
>> I think the name of `toNearestOrGreatest` could use improvement. The name
>> doesn’t indicate greatest magnitude and could easily be confused with some
>> `toNearestOrUp` (rounding towards positive infinity). Maybe you should call
>> it `toNearestOrAwayFromZero` (building on the convention implied by
>> `towardZero`). This also raises the question of why we don’t have other
>> similar rules such as `toNearestOrDown` and `toNearestOrTowardZero`.
>>
>> Maybe there are good reasons for covering a subset of the possible space of
>> rounding rules but not all of it. If there are you should provide rationale
>> in the proposal. If there aren’t, maybe you should consider including the
>> additional options.
>
>
> The rounding rules in the proposal are precisely the rounding rules required
> by IEEE 754. Not coincidentally, these are also the rounding rules that have
> fast hardware support for concrete types on common architectures, and the
> rounding rules that software expects to be able to use.
>
> Of your suggestions for symmetry, I’ve only ever seen `awayFromZero` used
> (e.g. I’ve never seen anyone use `toNearestOrOdd`). If we did want to extend
> the set of IEEE 754 rounding rules, I would add the following two rules:
>
> /// The result is the closest representable value whose magnitude is greater
> than or equal to that of the source.
> // Rationale: it’s actually used, though not as frequently as the operations
> in the proposal.
> case awayFromZero
>
> /// If the source is not exactly representable, the result is the closest odd
> number.
> // Rationale: although this is mostly useless for rounding-to-integer, it’s
> an extremely useful rounding rule to have for *other* floating-point
> operations, so if we’re going to extend the set, it makes sense to add it.
> case toOdd
>
> I have never seen a use case that would require extending the set any further
> than that.
>
> The thing that would actually be extremely useful is support for dithered or
> stochastic rounding, but that’s a can of API design worms that’s out of scope
> for Swift 3; you need to be able to describe not just the rule, but also a
> noise source and shape / spectrum.
(N.B. My recommendation is to *not* add any of these alternative modes at this
point in time. Let’s keep this small so that we can get it wrapped up as
quickly as possible).
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
