If you define a range as range[i] = first + i * stride where i is an Int then this generates an error when there are more than Int_Max steps, see code previously posted. The error is generated when the range is formed, which is ideal since an error part way along an iteration or a never ending iteration would be difficult to track down. <br><br>On Friday, 1 April 2016, Stephen Canon via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On Mar 31, 2016, at 11:16 AM, Rainer Brockerhoff via swift-evolution <<a href="javascript:;" onclick="_e(event, 'cvml', 'swift-evolution@swift.org')">swift-evolution@swift.org</a>> wrote:<br>
><br>
> On 3/31/16 15:06, Dave Abrahams via swift-evolution wrote:<br>
>><br>
>> on Thu Mar 31 2016, Xiaodi Wu <<a href="http://xiaodi.wu-AT-gmail.com" target="_blank">xiaodi.wu-AT-gmail.com</a>> wrote:<br>
>><br>
>>> Thoughts on an edge case: so long as it's possible to use<br>
>>> `stride(from:to:by:)` with Double, we'll need to figure out what<br>
>>> happens when you have `stride(from: 0.0, to: DBL_MAX, by: DBL_MIN)`.<br>
>>> Bounds may be unknown at compile time, obviously.<br>
>>><br>
>>> Currently (this is by reasoning through the code, not actually<br>
>>> observing it run), `for i in stride(from: 0.0, to: DBL_MAX, by:<br>
>>> DBL_MIN) { }` degenerates into an infinite loop once you reach<br>
>>> sufficient large values such that `current + stride == current`, which<br>
>>> for a stride of DBL_MIN should happen pretty quickly.<br>
>>><br>
>>> In Erica's proposed floating point Stride, an Int is used to count<br>
>>> iterations (and iterations need to be counted in order to avoid<br>
>>> accumulating error). Thus, one must break from `for i in stride(from:<br>
>>> 0.0, to: DBL_MAX, by: DBL_MIN) { }` before the iteration counter<br>
>>> overflows or it will trap. IMO, trapping at some point is fine, but I<br>
>>> think a limit of Int.max iterations might be rather arbitrary for a<br>
>>> StrideTo<Double> (or whatever it will be named) and I'm not sure how<br>
>>> one can justify why the behavior of StrideTo<Double> would change from<br>
>>> machine to machine based on the size of Int.<br>
>>><br>
>>> I've been waffling between using an Int counter as Erica does or a<br>
>>> counter of type Strideable.Stride in `StrideTo<Strideable where<br>
>>> Strideable.Stride : FloatingPoint>`. In the latter alternative, no<br>
>>> trapping occurs, but error begins to accumulate when the iteration<br>
>>> counter is too large to represent integers exactly (e.g., 2^53 for<br>
>>> Double). In that case, `for i in stride(from: 0.0, to: DBL_MAX, by:<br>
>>> DBL_MIN) { }` degenerates into an infinite loop eventually (once<br>
>>> `iterationCount + 1.0 == iterationCount`) and never traps, which I'm<br>
>>> not sure I like, but a limit of 2^53 iterations bears at least a<br>
>>> rational connection to Double and is known at compile time independent<br>
>>> of the supplied bounds. We could alternatively return nil on reaching<br>
>>> 2^53 iterations, trap, etc.<br>
>>><br>
>>> Comments?<br>
>><br>
>> I think I want to hear Steve Canon's input on this one. I defer to him<br>
>> on most things numeric.<br>
><br>
> In particular, should Steve confirm that the IEEE754 Decimal128 format<br>
> is being worked on, and if simple decimal constants like those in<br>
> `for i in stride(from: 0.0, to: DBL_MAX, by: DBL_MIN) { }`<br>
> will be type-inferred as Decimal128, all that would "just work".<br>
<br>
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.<br>
<br>
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).<br>
<br>
– Steve<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="javascript:;" onclick="_e(event, 'cvml', 'swift-evolution@swift.org')">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote><br><br>-- <br>-- Howard.<br>