[swift-evolution] [Proposal] Decoupling Floating Point Strides from Generic Implementations

[Jonathan Tang]

On Mon, Feb 29, 2016 at 5:16 PM, Erica Sadun via swift-evolution <
swift-evolution at swift.org> wrote:
>
> Decoupling Floating Point Strides from Generic Implementations
>
>    - Proposal: SE-00XX
>    - Author(s): Erica Sadun <http://github.com/erica>
>    - Status: TBD
>    - Review manager: TBD
>
> Swift strides create progressions along "notionally continuous
> one-dimensional values" using a series of offset values. This proposal
> replaces the Swift's generic stride implementation with seperate algorithms
> for integer strides (the current implementation) and floating point strides.
>
<snip>


> If one were looking for a quick and dirty fix, the same kind of math used
> in this rough solution (let value = start + count * interval) could be
> adopted back into the current generic implementation.
>

I would rather see this solution adopted.  Yes, it's inexact, but it's
about as exact as you can get with floating point numbers, and anyone
working with floating point numbers knows that you're not going to get an
exact decimal back.  At least it avoids accumulated errors and guarantees
that the proper number of values will be returned, to the limits of
floating point precision.

The problem with de-generifying Strideable is that oftentimes you may start
out working with integers and then find you need to change to floats to
accommodate a new requirement.  That could have very inconvenient ripple
effects if stride, arithmetic, etc. are not generic.

>
> <https://gist.github.com/erica/cf50f3dc54bb3a090933#alternatives-considered>Alternatives
> Considered
> While precision math for decimal numbers would be better addressed by
> introducing a decimal type and/or warnings for at-risk floating point
> numbers, those features lie outside the scope of this proposal.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160229/ff9f3114/attachment.html>