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.
On Sun, Jan 15, 2017 at 19:21 Dave Abrahams <[email protected]> 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 < > > > [email protected]> wrote: > > > > > >> > > >> on Sun Jan 15 2017, Xiaodi Wu <[email protected]> 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 [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
