Sent from my moss-covered three-handled family gradunza
> On Jan 15, 2017, at 6:46 PM, Jacob Bandes-Storch <jtban...@gmail.com> wrote:
>
>> On Sun, Jan 15, 2017 at 6:13 PM, Xiaodi Wu via swift-evolution
>> <swift-evolution@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.
You really want this to work for any field, though. Rational numbers, for
example, would be excluded by those constraints
>>
>>
>>> On Sun, Jan 15, 2017 at 19:21 Dave Abrahams <dabrah...@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@swift.org> wrote:
>>>
>>> >
>>>
>>> >>
>>>
>>> >> on Sun Jan 15 2017, Xiaodi Wu <swift-evolution@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@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
