[swift-evolution] protocol-oriented integers (take 2)

[Jacob Bandes-Storch]

On Sun, Jan 15, 2017 at 6:13 PM, Xiaodi Wu via swift-evolution <
swift-evolution at swift.org> wrote:

> One example: earlier, it was demonstrated that a genetic lerp would not
> accommodate vector types. However, it _does_ work fine for any scalar (i.e.
> field) type; however, with the currently proposed integer protocols, one
> would constrain it to Arithmetic types, yet the algorithm would be bogus
> for integers.
>

I wouldn't say lerp<Int> is bogus (the results aren't wrong), just much
less useful.

On the other hand:

    extension Collection where Iterator.Element: Arithmetic {
        func mean() -> Iterator.Element {
            return self.reduce(Iterator.Element(), +) /
Iterator.Element(count)  // assuming these initializers exist
        }
    }

Now [6, 7].mean() returns 6, and *that* I would call bogus.

Of course, there are some alternative ways to implement this which avoid
the issue:

- Implement it only for Iterator.Element: FloatingPoint.
- Implement it as mean<T: FloatingPoint>() -> T, reducing by { $0 + T($1) }
or whatever the appropriate conversion initializer is, or simply converting
to floating point once *after* taking the sum.


>
> On Sun, Jan 15, 2017 at 19:21 Dave Abrahams <dabrahams at apple.com> wrote:
>
>>
>>
>> on Sun Jan 15 2017, Xiaodi Wu <xiaodi.wu-AT-gmail.com> wrote:
>>
>>
>>
>> > On Sun, Jan 15, 2017 at 3:27 PM, Dave Abrahams via swift-evolution <
>>
>> > swift-evolution at swift.org> wrote:
>>
>> >
>>
>> >>
>>
>> >> on Sun Jan 15 2017, Xiaodi Wu <swift-evolution at swift.org> wrote:
>>
>> >>
>>
>> >> > There _may_ be value in recognizing the distinction between rings and
>>
>> >> > fields, perhaps? Just as the FP protocols make room for people to
>>
>> >> implement
>>
>> >> > their own decimal FP types, and just as you're trying to make
>> Arithmetic
>>
>> >> > accommodate complex numbers, the distinction would allow someone to
>> write
>>
>> >> > algorithms generic over rationals and reals (i.e. fields). Being
>> able to
>>
>> >> > represent exact fractions isn't so terribly niche, and I think the
>> design
>>
>> >> > wouldn't be terribly complicated by its accommodation:
>>
>> >> >
>>
>> >> > ```
>>
>> >> > // rename Arithmetic to Ring
>>
>> >> > // it's acceptable to omit `.one` from Ring, though some may call
>> that a
>>
>> >> > Pseudoring
>>
>> >> > // consider omitting division from Ring and pushing it down to
>>
>> >> > BinaryInteger and Field
>>
>> >> >
>>
>> >> > protocol BinaryInteger : Ring { ... }
>>
>> >> >
>>
>> >> > protocol Field : Ring {
>>
>> >> >   static var one { get }
>>
>> >> >   static func / (Self, Self) -> Self
>>
>> >> >   static func /= (inout Self, Self)
>>
>> >> >   var inverted: Self { get } // default impl: .one / self
>>
>> >> > }
>>
>> >> >
>>
>> >> > protocol FloatingPoint : Field { ... }
>>
>> >> > // rational number types and complex number types
>>
>> >> > // would also conform to Field
>>
>> >> > ```
>>
>> >>
>>
>> >> What generic algorithms would this enable?
>>
>> >
>>
>> > For one, anything to do with dividing into equal parts
>>
>>
>>
>> For example...?
>>
>>
>>
>> > could be generic over floating point, rational, and even complex
>>
>> > numbers, but you probably wouldn't want to include integer types in
>>
>> > such an algorithm.
>>
>> >
>>
>> >> Would they be appropriate
>>
>> >> for the standard library (as opposed to some more specialized numerics
>>
>> >> library)?
>>
>> >>
>>
>> >
>>
>> > The issue is that it's not terribly ergonomic to relegate `Field` to a
>>
>> > specialized library because one cannot retroactively conform
>>
>> > `FloatingPoint` to `Field`.
>>
>>
>>
>> I don't think this is an important enough concern to justify adding
>>
>> protocols to the standard library.  The number of types one has to
>>
>> individually make conform to Field is probably going to remain small.
>>
>>
>>
>> Show-me-the-mone^Walgorithms-ly y'rs,
>>
>>
>>
>> --
>>
>> -Dave
>>
>>
> _______________________________________________
> 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/20170115/b9df1e48/attachment.html>