[swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

[Xiaodi Wu]

We will be proposing exactly that which you've put in parentheses, i.e.
floating point types will get their own strides, and it will be a
precondition failure to try to stride from or to infinity or nan :)

On Sun, Apr 10, 2016 at 4:47 AM <davesweeris at mac.com> wrote:

> It’s not a matter of floating point error accumulation… At least on my
> machine, once a Double hits +/-∞, there’s no way that I know of to get back
> to normal floating point numbers. That is to say, for *all* normal, finite
> values of x, "-Double.infinity + x" will just return “-inf". If x is to
> equal Double.infinity, Double.NaN, or Double.quietNaN, then it’ll return
> “nan” (which, incidentally, will fail the regular equality test… Double.NaN
> isn’t even equal to itself; I think checking the floating point class is
> the way to do it).
>
> I could easily be missing something, but AFAICT the only way to always get
> the correct sequence (without splitting the floating point types off into
> their own thing) is either have a negative stride swap start and end
> *before* the StrideTo starts generating values (that is, *not* by just
> calling `.reverse()` on something with a positive stride), or to allow “0
> ..< -Double.infinity” to be a valid range (with the negative stride being
> implied).
>
> - Dave Sweeris
>
> On Apr 9, 2016, at 6:59 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
> Yikes. Not too concerned about the infinite loop issue, as floating point
> strides when fixed to avoid error accumulation will necessarily enforce a
> finite number of steps. However, you're talking a regular, not-at-all-lazy
> Array being returned? That would be not good at all...
>
> On Sun, Apr 10, 2016 at 12:29 AM Dave via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>>
>> On Apr 9, 2016, at 4:33 AM, Haravikk via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> While I’m in favour of the basic idea I think the operator selection is
>> too complex, and I’m not sure about the need for negative strides. Really
>> all I want are the following:
>>
>> (0 ... 6).striding(by: 2) // [0, 2, 4, 6] x from 0 to 6
>> (0 ..< 6).striding(by: 2) // [0, 2, 4] x from 0 while <6
>> (6 ... 0).striding(by: 2) // [6, 4, 2, 0] x from 6 to 0
>> (6 ..> 0).striding(by: 2) // [6, 4, 2] x from 6 while >0
>>
>> Everything else should be coverable either by flipping the order, or
>> using .reverse(). The main advantage is that there’s only one new operator
>> to clarify the 6 ..> 0 case, though you could always just reuse the
>> existing operator if you just interpret it as “x from 6 to, but not
>> including, 0"
>>
>>
>> `.reverse()` returns an array, though, not a StrideTo<>, which means
>> it’ll get in an infinite loop on infinite sequences. This works fine:
>> for i in stride(from: 0.0, to: Double.infinity, by: M_PI) {
>>     if someTestInvolving(i) { break }
>>     ...
>> }
>>
>> But this never even starts executing the loop because of the infinite
>> loop inside `.reverse()`:
>> for i in stride(from: -Double.infinity, to: 0.0, by: M_PI).reverse() {
>>     if someTestInvolving(i) { break }
>>     ...
>> }
>>
>> - Dave Sweeris
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160410/26bb4e3c/attachment.html>