> On Mar 31, 2016, at 11:16 AM, Rainer Brockerhoff via swift-evolution > <swift-evolution@swift.org> wrote: > > On 3/31/16 15:06, Dave Abrahams via swift-evolution wrote: >> >> on Thu Mar 31 2016, Xiaodi Wu <xiaodi.wu-AT-gmail.com> wrote: >> >>> Thoughts on an edge case: so long as it's possible to use >>> `stride(from:to:by:)` with Double, we'll need to figure out what >>> happens when you have `stride(from: 0.0, to: DBL_MAX, by: DBL_MIN)`. >>> Bounds may be unknown at compile time, obviously. >>> >>> Currently (this is by reasoning through the code, not actually >>> observing it run), `for i in stride(from: 0.0, to: DBL_MAX, by: >>> DBL_MIN) { }` degenerates into an infinite loop once you reach >>> sufficient large values such that `current + stride == current`, which >>> for a stride of DBL_MIN should happen pretty quickly. >>> >>> In Erica's proposed floating point Stride, an Int is used to count >>> iterations (and iterations need to be counted in order to avoid >>> accumulating error). Thus, one must break from `for i in stride(from: >>> 0.0, to: DBL_MAX, by: DBL_MIN) { }` before the iteration counter >>> overflows or it will trap. IMO, trapping at some point is fine, but I >>> think a limit of Int.max iterations might be rather arbitrary for a >>> StrideTo<Double> (or whatever it will be named) and I'm not sure how >>> one can justify why the behavior of StrideTo<Double> would change from >>> machine to machine based on the size of Int. >>> >>> I've been waffling between using an Int counter as Erica does or a >>> counter of type Strideable.Stride in `StrideTo<Strideable where >>> Strideable.Stride : FloatingPoint>`. In the latter alternative, no >>> trapping occurs, but error begins to accumulate when the iteration >>> counter is too large to represent integers exactly (e.g., 2^53 for >>> Double). In that case, `for i in stride(from: 0.0, to: DBL_MAX, by: >>> DBL_MIN) { }` degenerates into an infinite loop eventually (once >>> `iterationCount + 1.0 == iterationCount`) and never traps, which I'm >>> not sure I like, but a limit of 2^53 iterations bears at least a >>> rational connection to Double and is known at compile time independent >>> of the supplied bounds. We could alternatively return nil on reaching >>> 2^53 iterations, trap, etc. >>> >>> Comments? >> >> I think I want to hear Steve Canon's input on this one. I defer to him >> on most things numeric. > > In particular, should Steve confirm that the IEEE754 Decimal128 format > is being worked on, and if simple decimal constants like those in > `for i in stride(from: 0.0, to: DBL_MAX, by: DBL_MIN) { }` > will be type-inferred as Decimal128, all that would "just work".
Decimal is something that I would like to see happen. However, I would not expect any such proposal to result in that loop being type inferred to Decimal, since the to: and by: values are explicitly (binary floating-point) Doubles. I also don’t think that such a loop is particularly useful. For floating-point types, something like stride(from: T, to: T, steps: Int) seems safer and more workable to me (this is just my immediate reaction, I haven’t thought this through in detail, and am likely to change my mind if someone makes a good case). – Steve _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution