Sent from my iPhone
> On Jun 29, 2016, at 12:00 PM, Stephen Canon <[email protected]> wrote: > > >> On Jun 29, 2016, at 12:46 PM, Matthew Johnson <[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. I was guessing there was a rationale like this that I wasn't aware of. :). Thanks for providing it! That's all I was looking for. I do think it would be a good idea to add it to the proposal. My criticism of the 'toNearestOrGreatest' still stands though. I think this name is misleading given the stated semantics. The name indicates "greater value" not "greater magnitude" which are opposites in the case of negative numbers. > > 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. > > – Steve
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
