# TrigonometricFloatingPoint/MathFloatingPoint protocol? **URL:** \ **Category:** Discussion\ **Created:** [July 31, 2017, 5:03pm UTC](https://forums.swift.org/t/trigonometricfloatingpoint-mathfloatingpoint-protocol/6415 "2017-07-31T17:03:37Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![taylorswift](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/taylorswift/32/43413_2.png) [@taylorswift](https://forums.swift.org/u/taylorswift)\ **Post date:** [July 31, 2017, 5:03pm UTC](https://forums.swift.org/t/trigonometricfloatingpoint-mathfloatingpoint-protocol/6415/1 "2017-07-31T17:03:37Z")
How would people feel about adding a protocol protocol MathFloatingPoint:FloatingPoint {     func sin() -\> Self     func cos() -\> Self     func tan() -\> Self     func asin() -\> Self     func acos() -\> Self     func atan() -\> Self     func ln() -\> Self     func log(base:Self) -\> Self     func pow(exponent:Self) -\> Self     func exp() -\> Self } to the standard library? Float and Double would then be made to conform by default using Swift implementations instead of having to import Glibc / Darwin and writing the extensions, depending on platform. ---
**Author:** ![taylorswift](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/taylorswift/32/43413_2.png) [@taylorswift](https://forums.swift.org/u/taylorswift)\ **Post date:** [July 31, 2017, 5:26pm UTC](https://forums.swift.org/t/trigonometricfloatingpoint-mathfloatingpoint-protocol/6415/2 "2017-07-31T17:26:08Z")
> 1) Why would cos, sin, ln, tan, asin, acos, atan and exp be functions and > not computed properties? > 2) For people who uses these features on paper and text books, writing > them as what we call global functions is standard. Seeing them the same in > both places reduces the translation they must do, and thus reduces > accidental errors, and reduces the difficulty of reading and validating > code. > > -Ben My first thought was to have them as free functions, but the trend in the Swift stdlib seems to be to go with namespaced protocol methods. For example, squareRoot() and signum() are methods, not toplevel functions. (I have no idea why abs() is a free function though.) Also, as to why they are functions and not computed properties, I would have suggested making them computed properties but I believe there was a big fuss a while back about why signum() had to be a method and not a property so I’m just going off of that. > **···** > > On Mon, Jul 31, 2017 at 1:19 PM, Benjamin Spratling \ wrote: > > > Sent from my iPhone. > > > > \> On Jul 31, 2017, at 1:03 PM, Taylor Swift via swift-evolution \< \> swift-evolution@swift.org\> wrote: > > \> > > \> How would people feel about adding a protocol > > \> > > \> protocol MathFloatingPoint:FloatingPoint > > \> { > > \> func sin() -\> Self > > \> func cos() -\> Self > > \> func tan() -\> Self > > \> func asin() -\> Self > > \> func acos() -\> Self > > \> func atan() -\> Self > > \> > > \> func ln() -\> Self > > \> func log(base:Self) -\> Self > > \> func pow(exponent:Self) -\> Self > > \> func exp() -\> Self > > \> } > > \> > > \> to the standard library? Float and Double would then be made to conform > > by default using Swift implementations instead of having to import Glibc / > > Darwin and writing the extensions, depending on platform. > > \> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > \> swift-evolution mailing list > > \> swift-evolution@swift.org > > \> [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![DevAndArtist](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/devandartist/32/287_2.png) [@DevAndArtist](https://forums.swift.org/u/DevAndArtist)\ **Post date:** [July 31, 2017, 5:23pm UTC](https://forums.swift.org/t/trigonometricfloatingpoint-mathfloatingpoint-protocol/6415/3 "2017-07-31T17:23:37Z")
I’m not sure how I would feel about this. To be honest I’d avoid such additional changes from the stdlib, because they really don’t belong there. Instead some `Math` module/package would be a better fit than clustering everything into stdlib until we end up also adding UI stuff. Furthermore, I don’t think a function would make any sense here. It really should be a computed property. > **···** > > Am 31. Juli 2017 um 19:03:49, Taylor Swift via swift-evolution (swift-evolution@swift.org) schrieb: > > How would people feel about adding a protocol > > protocol MathFloatingPoint:FloatingPoint > { > func sin() -\> Self > func cos() -\> Self > func tan() -\> Self > func asin() -\> Self > func acos() -\> Self > func atan() -\> Self > > ``` > func ln\(\) \-> Self > func log\(base:Self\) \-> Self > func pow\(exponent:Self\) \-> Self > func exp\(\) \-> Self > > ``` > > } > > to the standard library? Float and Double would then be made to conform by default using Swift implementations instead of having to import Glibc / Darwin and writing the extensions, depending on platform. > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > swift-evolution mailing list > swift-evolution@swift.org > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![hooman](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/hooman/32/43536_2.png) [@hooman](https://forums.swift.org/u/hooman)\ **Post date:** [July 31, 2017, 5:45pm UTC](https://forums.swift.org/t/trigonometricfloatingpoint-mathfloatingpoint-protocol/6415/4 "2017-07-31T17:45:36Z")
I prefer an approach that preserves how I am used to seeing math expressions. I use this myself: protocol FloatingPointMath: FloatingPoint {     static func sqrt(\_ value: Self) -\> Self     static func sin(\_ value: Self) -\> Self     static func cos(\_ value: Self) -\> Self     static func tan(\_ value: Self) -\> Self     static func asin(\_ value: Self) -\> Self     static func acos(\_ value: Self) -\> Self     static func atan(\_ value: Self) -\> Self          static func ln(\_ value: Self) -\> Self     static func log(\_ value: Self, base: Self) -\> Self     static func pow(\_ value: Self, exponent:Self) -\> Self     static func exp(\_ value: Self) -\> Self } It does not pollute the global namespace and gives nice contextual auto-completion. And I don’t want it in the standard library: I only add the file when I need it. (it is not a separate module for optimization reasons). > **···** > > > On Jul 31, 2017, at 10:29 AM, Taylor Swift via swift-evolution \ wrote: > > > > On Mon, Jul 31, 2017 at 1:23 PM, Adrian Zubarev \\> wrote: > > I’m not sure how I would feel about this. To be honest I’d avoid such additional changes from the stdlib, because they really don’t belong there. Instead some `Math` module/package would be a better fit than clustering everything into stdlib until we end up also adding UI stuff. > > > > Furthermore, I don’t think a function would make any sense here. It really should be a computed property. > > > > I think a standard Math module would be a good idea, but only if it benefits from the same inlining and specialization as the standard library. Also squareRoot() should be moved to the Math module if it is ever created. > > > > Am 31. Juli 2017 um 19:03:49, Taylor Swift via swift-evolution (swift-evolution@swift.org \) schrieb: > > > > > How would people feel about adding a protocol > > > > > > protocol MathFloatingPoint:FloatingPoint > > > { > > >     func sin() -\> Self > > >     func cos() -\> Self > > >     func tan() -\> Self > > >     func asin() -\> Self > > >     func acos() -\> Self > > >     func atan() -\> Self > > > > > >     func ln() -\> Self > > >     func log(base:Self) -\> Self > > >     func pow(exponent:Self) -\> Self > > >     func exp() -\> Self > > > } > > > > > > to the standard library? Float and Double would then be made to conform by default using Swift implementations instead of having to import Glibc / Darwin and writing the extensions, depending on platform. > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > swift-evolution mailing list > > > swift-evolution@swift.org \ > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![hooman](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/hooman/32/43536_2.png) [@hooman](https://forums.swift.org/u/hooman)\ **Post date:** [July 31, 2017, 6:02pm UTC](https://forums.swift.org/t/trigonometricfloatingpoint-mathfloatingpoint-protocol/6415/5 "2017-07-31T18:02:12Z")
I know. I hear you. I have some special arrangmnents to keep such things manageable, and I am not happy about how things stand right now. What I am hoping to open up stdlib special compiler mode to other (low-level) libraries and also letting such libraries gain optimizations similar to stdlib when included in a project. So, instead of putting things in stdlib, I want stdlib’s special privileges being made available to a certain category of third-party or internal modules. > **···** > > > On Jul 31, 2017, at 10:54 AM, Taylor Swift \ wrote: > > > > Isn’t the point of standard inlineable library module to prevent the need to copy and paste code like this into every project? Currently I have a “math.swift” file I copy and paste into all of my projects, and since I occasionally update it, there exists about 15 different versions of it floating around, so I know this is not a sustainable practice. > > > > On Mon, Jul 31, 2017 at 1:45 PM, Hooman Mehr \\> wrote: > > I prefer an approach that preserves how I am used to seeing math expressions. I use this myself: > > > > protocol FloatingPointMath: FloatingPoint > > { > >     static func sqrt(\_ value: Self) -\> Self > > > >     static func sin(\_ value: Self) -\> Self > >     static func cos(\_ value: Self) -\> Self > >     static func tan(\_ value: Self) -\> Self > >     static func asin(\_ value: Self) -\> Self > >     static func acos(\_ value: Self) -\> Self > >     static func atan(\_ value: Self) -\> Self > >      > >     static func ln(\_ value: Self) -\> Self > >     static func log(\_ value: Self, base: Self) -\> Self > >     static func pow(\_ value: Self, exponent:Self) -\> Self > >     static func exp(\_ value: Self) -\> Self > > } > > > > It does not pollute the global namespace and gives nice contextual auto-completion. And I don’t want it in the standard library: I only add the file when I need it. (it is not a separate module for optimization reasons). > > > > > On Jul 31, 2017, at 10:29 AM, Taylor Swift via swift-evolution \\> wrote: > > > > > > On Mon, Jul 31, 2017 at 1:23 PM, Adrian Zubarev \\> wrote: > > > I’m not sure how I would feel about this. To be honest I’d avoid such additional changes from the stdlib, because they really don’t belong there. Instead some `Math` module/package would be a better fit than clustering everything into stdlib until we end up also adding UI stuff. > > > > > > Furthermore, I don’t think a function would make any sense here. It really should be a computed property. > > > > > > I think a standard Math module would be a good idea, but only if it benefits from the same inlining and specialization as the standard library. Also squareRoot() should be moved to the Math module if it is ever created. > > > > > > Am 31. Juli 2017 um 19:03:49, Taylor Swift via swift-evolution (swift-evolution@swift.org \) schrieb: > > > > > > > How would people feel about adding a protocol > > > > > > > > protocol MathFloatingPoint:FloatingPoint > > > > { > > > >     func sin() -\> Self > > > >     func cos() -\> Self > > > >     func tan() -\> Self > > > >     func asin() -\> Self > > > >     func acos() -\> Self > > > >     func atan() -\> Self > > > > > > > >     func ln() -\> Self > > > >     func log(base:Self) -\> Self > > > >     func pow(exponent:Self) -\> Self > > > >     func exp() -\> Self > > > > } > > > > > > > > to the standard library? Float and Double would then be made to conform by default using Swift implementations instead of having to import Glibc / Darwin and writing the extensions, depending on platform. > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > swift-evolution mailing list > > > > swift-evolution@swift.org \ > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > swift-evolution mailing list > > > swift-evolution@swift.org \ > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![hooman](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/hooman/32/43536_2.png) [@hooman](https://forums.swift.org/u/hooman)\ **Post date:** [July 31, 2017, 6:22pm UTC](https://forums.swift.org/t/trigonometricfloatingpoint-mathfloatingpoint-protocol/6415/6 "2017-07-31T18:22:07Z")
Maybe we need more than one level of standard library: The core (which is most of what we have now (but maybe not all of it) and multiple opt-in standard modules for hash functions, math, specialized data structures, etc. > **···** > > > On Jul 31, 2017, at 11:10 AM, Taylor Swift \ wrote: > > > > I’m not sure why only the stdlib is inlineable and specializable, but I believe it has something to do with ABI. I’m not an ABI expert though. I strongly disagree that a Swift Math library should be delegated to a third party. Math is “common” enough that there should really only be one “standard” implementation of it, under the direction of the Swift Project; we don’t want 5 competing third party Vector standards. > > > > On Mon, Jul 31, 2017 at 2:02 PM, Hooman Mehr \\> wrote: > > I know. I hear you. I have some special arrangmnents to keep such things manageable, and I am not happy about how things stand right now. > > > > What I am hoping to open up stdlib special compiler mode to other (low-level) libraries and also letting such libraries gain optimizations similar to stdlib when included in a project. > > > > So, instead of putting things in stdlib, I want stdlib’s special privileges being made available to a certain category of third-party or internal modules. > > > > > On Jul 31, 2017, at 10:54 AM, Taylor Swift \\> wrote: > > > > > > Isn’t the point of standard inlineable library module to prevent the need to copy and paste code like this into every project? Currently I have a “math.swift” file I copy and paste into all of my projects, and since I occasionally update it, there exists about 15 different versions of it floating around, so I know this is not a sustainable practice. > > > > > > On Mon, Jul 31, 2017 at 1:45 PM, Hooman Mehr \\> wrote: > > > I prefer an approach that preserves how I am used to seeing math expressions. I use this myself: > > > > > > protocol FloatingPointMath: FloatingPoint > > > { > > >     static func sqrt(\_ value: Self) -\> Self > > > > > >     static func sin(\_ value: Self) -\> Self > > >     static func cos(\_ value: Self) -\> Self > > >     static func tan(\_ value: Self) -\> Self > > >     static func asin(\_ value: Self) -\> Self > > >     static func acos(\_ value: Self) -\> Self > > >     static func atan(\_ value: Self) -\> Self > > >      > > >     static func ln(\_ value: Self) -\> Self > > >     static func log(\_ value: Self, base: Self) -\> Self > > >     static func pow(\_ value: Self, exponent:Self) -\> Self > > >     static func exp(\_ value: Self) -\> Self > > > } > > > > > > It does not pollute the global namespace and gives nice contextual auto-completion. And I don’t want it in the standard library: I only add the file when I need it. (it is not a separate module for optimization reasons). > > > > > > > On Jul 31, 2017, at 10:29 AM, Taylor Swift via swift-evolution \\> wrote: > > > > > > > > On Mon, Jul 31, 2017 at 1:23 PM, Adrian Zubarev \\> wrote: > > > > I’m not sure how I would feel about this. To be honest I’d avoid such additional changes from the stdlib, because they really don’t belong there. Instead some `Math` module/package would be a better fit than clustering everything into stdlib until we end up also adding UI stuff. > > > > > > > > Furthermore, I don’t think a function would make any sense here. It really should be a computed property. > > > > > > > > I think a standard Math module would be a good idea, but only if it benefits from the same inlining and specialization as the standard library. Also squareRoot() should be moved to the Math module if it is ever created. > > > > > > > > Am 31. Juli 2017 um 19:03:49, Taylor Swift via swift-evolution (swift-evolution@swift.org \) schrieb: > > > > > > > > > How would people feel about adding a protocol > > > > > > > > > > protocol MathFloatingPoint:FloatingPoint > > > > > { > > > > >     func sin() -\> Self > > > > >     func cos() -\> Self > > > > >     func tan() -\> Self > > > > >     func asin() -\> Self > > > > >     func acos() -\> Self > > > > >     func atan() -\> Self > > > > > > > > > >     func ln() -\> Self > > > > >     func log(base:Self) -\> Self > > > > >     func pow(exponent:Self) -\> Self > > > > >     func exp() -\> Self > > > > > } > > > > > > > > > > to the standard library? Float and Double would then be made to conform by default using Swift implementations instead of having to import Glibc / Darwin and writing the extensions, depending on platform. > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > > swift-evolution mailing list > > > > > swift-evolution@swift.org \ > > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > swift-evolution mailing list > > > > swift-evolution@swift.org \ > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![taylorswift](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/taylorswift/32/43413_2.png) [@taylorswift](https://forums.swift.org/u/taylorswift)\ **Post date:** [July 31, 2017, 5:29pm UTC](https://forums.swift.org/t/trigonometricfloatingpoint-mathfloatingpoint-protocol/6415/7 "2017-07-31T17:29:47Z")
> I’m not sure how I would feel about this. To be honest I’d avoid such > additional changes from the stdlib, because they really don’t belong there. > Instead some `Math` module/package would be a better fit than clustering > everything into stdlib until we end up also adding UI stuff. > > Furthermore, I don’t think a function would make any sense here. It really > should be a computed property. I think a standard Math module would be a good idea, but only if it benefits from the same inlining and specialization as the standard library. Also squareRoot() should be moved to the Math module if it is ever created. > **···** > > On Mon, Jul 31, 2017 at 1:23 PM, Adrian Zubarev \< adrian.zubarev@devandartist.com\> wrote: > > > Am 31. Juli 2017 um 19:03:49, Taylor Swift via swift-evolution ( > > swift-evolution@swift.org) schrieb: > > > > How would people feel about adding a protocol > > > > protocol MathFloatingPoint:FloatingPoint > > { > >     func sin() -\> Self > >     func cos() -\> Self > >     func tan() -\> Self > >     func asin() -\> Self > >     func acos() -\> Self > >     func atan() -\> Self > > > >     func ln() -\> Self > >     func log(base:Self) -\> Self > >     func pow(exponent:Self) -\> Self > >     func exp() -\> Self > > } > > > > to the standard library? Float and Double would then be made to conform by > > default using Swift implementations instead of having to import Glibc / > > Darwin and writing the extensions, depending on platform. > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Stephen\_Canon](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/stephen_canon/32/7220_2.png) [@Stephen\_Canon](https://forums.swift.org/u/Stephen_Canon)\ **Post date:** [July 31, 2017, 5:31pm UTC](https://forums.swift.org/t/trigonometricfloatingpoint-mathfloatingpoint-protocol/6415/8 "2017-07-31T17:31:56Z")
No; square root is an IEEE-754 required basic operation, just like addition or multiplication. It is part of the FloatingPoint protocol for this reason—every floating-point type needs to have square root. – Steve > **···** > > > On Jul 31, 2017, at 1:29 PM, Taylor Swift via swift-evolution \ wrote: > > > > Also squareRoot() should be moved to the Math module if it is ever created. ---
**Author:** ![taylorswift](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/taylorswift/32/43413_2.png) [@taylorswift](https://forums.swift.org/u/taylorswift)\ **Post date:** [July 31, 2017, 5:54pm UTC](https://forums.swift.org/t/trigonometricfloatingpoint-mathfloatingpoint-protocol/6415/9 "2017-07-31T17:54:02Z")
Isn’t the point of standard inlineable library module to prevent the need to copy and paste code like this into every project? Currently I have a “math.swift” file I copy and paste into all of my projects, and since I occasionally update it, there exists about 15 different versions of it floating around, so I know this is not a sustainable practice. > **···** > > On Mon, Jul 31, 2017 at 1:45 PM, Hooman Mehr \ wrote: > > > I prefer an approach that preserves how I am used to seeing math > > expressions. I use this myself: > > > > protocol FloatingPointMath: FloatingPoint > > { > >     static func sqrt(\_ value: Self) -\> Self > > > >     static func sin(\_ value: Self) -\> Self > >     static func cos(\_ value: Self) -\> Self > >     static func tan(\_ value: Self) -\> Self > >     static func asin(\_ value: Self) -\> Self > >     static func acos(\_ value: Self) -\> Self > >     static func atan(\_ value: Self) -\> Self > > > >     static func ln(\_ value: Self) -\> Self > >     static func log(\_ value: Self, base: Self) -\> Self > >     static func pow(\_ value: Self, exponent:Self) -\> Self > >     static func exp(\_ value: Self) -\> Self > > } > > > > It does not pollute the global namespace and gives nice contextual > > auto-completion. And I don’t want it in the standard library: I only add > > the file when I need it. (it is not a separate module for optimization > > reasons). > > > > On Jul 31, 2017, at 10:29 AM, Taylor Swift via swift-evolution \< \> swift-evolution@swift.org\> wrote: > > > > On Mon, Jul 31, 2017 at 1:23 PM, Adrian Zubarev \< \> adrian.zubarev@devandartist.com\> wrote: > > > > > I’m not sure how I would feel about this. To be honest I’d avoid such > > > additional changes from the stdlib, because they really don’t belong there. > > > Instead some `Math` module/package would be a better fit than clustering > > > everything into stdlib until we end up also adding UI stuff. > > > > > > Furthermore, I don’t think a function would make any sense here. It > > > really should be a computed property. > > > > I think a standard Math module would be a good idea, but only if it > > benefits from the same inlining and specialization as the standard library. > > Also squareRoot() should be moved to the Math module if it is ever created. > > > > > Am 31. Juli 2017 um 19:03:49, Taylor Swift via swift-evolution ( > > > swift-evolution@swift.org) schrieb: > > > > > > How would people feel about adding a protocol > > > > > > protocol MathFloatingPoint:FloatingPoint > > > { > > >     func sin() -\> Self > > >     func cos() -\> Self > > >     func tan() -\> Self > > >     func asin() -\> Self > > >     func acos() -\> Self > > >     func atan() -\> Self > > > > > >     func ln() -\> Self > > >     func log(base:Self) -\> Self > > >     func pow(exponent:Self) -\> Self > > >     func exp() -\> Self > > > } > > > > > > to the standard library? Float and Double would then be made to conform > > > by default using Swift implementations instead of having to import Glibc / > > > Darwin and writing the extensions, depending on platform. > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > swift-evolution mailing list > > > swift-evolution@swift.org > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![taylorswift](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/taylorswift/32/43413_2.png) [@taylorswift](https://forums.swift.org/u/taylorswift)\ **Post date:** [July 31, 2017, 6:10pm UTC](https://forums.swift.org/t/trigonometricfloatingpoint-mathfloatingpoint-protocol/6415/10 "2017-07-31T18:10:32Z")
I’m not sure why only the stdlib is inlineable and specializable, but I believe it has something to do with ABI. I’m not an ABI expert though. I strongly disagree that a Swift Math library should be delegated to a third party. Math is “common” enough that there should really only be one “standard” implementation of it, under the direction of the Swift Project; we don’t want 5 competing third party Vector standards. > **···** > > On Mon, Jul 31, 2017 at 2:02 PM, Hooman Mehr \ wrote: > > > I know. I hear you. I have some special arrangmnents to keep such things > > manageable, and I am not happy about how things stand right now. > > > > What I am hoping to open up stdlib special compiler mode to other > > (low-level) libraries and also letting such libraries gain optimizations > > similar to stdlib when included in a project. > > > > So, instead of putting things in stdlib, I want stdlib’s special > > privileges being made available to a certain category of third-party or > > internal modules. > > > > On Jul 31, 2017, at 10:54 AM, Taylor Swift \ wrote: > > > > Isn’t the point of standard inlineable library module to prevent the need > > to copy and paste code like this into every project? Currently I have a > > “math.swift” file I copy and paste into all of my projects, and since I > > occasionally update it, there exists about 15 different versions of it > > floating around, so I know this is not a sustainable practice. > > > > On Mon, Jul 31, 2017 at 1:45 PM, Hooman Mehr \ wrote: > > > > > I prefer an approach that preserves how I am used to seeing math > > > expressions. I use this myself: > > > > > > protocol FloatingPointMath: FloatingPoint > > > { > > >     static func sqrt(\_ value: Self) -\> Self > > > > > >     static func sin(\_ value: Self) -\> Self > > >     static func cos(\_ value: Self) -\> Self > > >     static func tan(\_ value: Self) -\> Self > > >     static func asin(\_ value: Self) -\> Self > > >     static func acos(\_ value: Self) -\> Self > > >     static func atan(\_ value: Self) -\> Self > > > > > >     static func ln(\_ value: Self) -\> Self > > >     static func log(\_ value: Self, base: Self) -\> Self > > >     static func pow(\_ value: Self, exponent:Self) -\> Self > > >     static func exp(\_ value: Self) -\> Self > > > } > > > > > > It does not pollute the global namespace and gives nice contextual > > > auto-completion. And I don’t want it in the standard library: I only add > > > the file when I need it. (it is not a separate module for optimization > > > reasons). > > > > > > On Jul 31, 2017, at 10:29 AM, Taylor Swift via swift-evolution \< \>\> swift-evolution@swift.org\> wrote: > > > > > > On Mon, Jul 31, 2017 at 1:23 PM, Adrian Zubarev \< \>\> adrian.zubarev@devandartist.com\> wrote: > > > > > > > I’m not sure how I would feel about this. To be honest I’d avoid such > > > > additional changes from the stdlib, because they really don’t belong there. > > > > Instead some `Math` module/package would be a better fit than clustering > > > > everything into stdlib until we end up also adding UI stuff. > > > > > > > > Furthermore, I don’t think a function would make any sense here. It > > > > really should be a computed property. > > > > > > I think a standard Math module would be a good idea, but only if it > > > benefits from the same inlining and specialization as the standard library. > > > Also squareRoot() should be moved to the Math module if it is ever created. > > > > > > > Am 31. Juli 2017 um 19:03:49, Taylor Swift via swift-evolution ( > > > > swift-evolution@swift.org) schrieb: > > > > > > > > How would people feel about adding a protocol > > > > > > > > protocol MathFloatingPoint:FloatingPoint > > > > { > > > >     func sin() -\> Self > > > >     func cos() -\> Self > > > >     func tan() -\> Self > > > >     func asin() -\> Self > > > >     func acos() -\> Self > > > >     func atan() -\> Self > > > > > > > >     func ln() -\> Self > > > >     func log(base:Self) -\> Self > > > >     func pow(exponent:Self) -\> Self > > > >     func exp() -\> Self > > > > } > > > > > > > > to the standard library? Float and Double would then be made to conform > > > > by default using Swift implementations instead of having to import Glibc / > > > > Darwin and writing the extensions, depending on platform. > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > swift-evolution mailing list > > > > swift-evolution@swift.org > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > swift-evolution mailing list > > > swift-evolution@swift.org > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Jon\_Hull](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jon_hull/32/678_2.png) [@Jon\_Hull](https://forums.swift.org/u/Jon_Hull)\ **Post date:** [August 1, 2017, 12:25am UTC](https://forums.swift.org/t/trigonometricfloatingpoint-mathfloatingpoint-protocol/6415/11 "2017-08-01T00:25:37Z")
+1000 to this. > **···** > > > On Jul 31, 2017, at 11:22 AM, Hooman Mehr via swift-evolution \ wrote: > > > > Maybe we need more than one level of standard library: The core (which is most of what we have now (but maybe not all of it) and multiple opt-in standard modules for hash functions, math, specialized data structures, etc. > > > > > On Jul 31, 2017, at 11:10 AM, Taylor Swift \\> wrote: > > > > > > I’m not sure why only the stdlib is inlineable and specializable, but I believe it has something to do with ABI. I’m not an ABI expert though. I strongly disagree that a Swift Math library should be delegated to a third party. Math is “common” enough that there should really only be one “standard” implementation of it, under the direction of the Swift Project; we don’t want 5 competing third party Vector standards. > > > > > > On Mon, Jul 31, 2017 at 2:02 PM, Hooman Mehr \\> wrote: > > > I know. I hear you. I have some special arrangmnents to keep such things manageable, and I am not happy about how things stand right now. > > > > > > What I am hoping to open up stdlib special compiler mode to other (low-level) libraries and also letting such libraries gain optimizations similar to stdlib when included in a project. > > > > > > So, instead of putting things in stdlib, I want stdlib’s special privileges being made available to a certain category of third-party or internal modules. > > > > > > > On Jul 31, 2017, at 10:54 AM, Taylor Swift \\> wrote: > > > > > > > > Isn’t the point of standard inlineable library module to prevent the need to copy and paste code like this into every project? Currently I have a “math.swift” file I copy and paste into all of my projects, and since I occasionally update it, there exists about 15 different versions of it floating around, so I know this is not a sustainable practice. > > > > > > > > On Mon, Jul 31, 2017 at 1:45 PM, Hooman Mehr \\> wrote: > > > > I prefer an approach that preserves how I am used to seeing math expressions. I use this myself: > > > > > > > > protocol FloatingPointMath: FloatingPoint > > > > { > > > >     static func sqrt(\_ value: Self) -\> Self > > > > > > > >     static func sin(\_ value: Self) -\> Self > > > >     static func cos(\_ value: Self) -\> Self > > > >     static func tan(\_ value: Self) -\> Self > > > >     static func asin(\_ value: Self) -\> Self > > > >     static func acos(\_ value: Self) -\> Self > > > >     static func atan(\_ value: Self) -\> Self > > > >      > > > >     static func ln(\_ value: Self) -\> Self > > > >     static func log(\_ value: Self, base: Self) -\> Self > > > >     static func pow(\_ value: Self, exponent:Self) -\> Self > > > >     static func exp(\_ value: Self) -\> Self > > > > } > > > > > > > > It does not pollute the global namespace and gives nice contextual auto-completion. And I don’t want it in the standard library: I only add the file when I need it. (it is not a separate module for optimization reasons). > > > > > > > > > On Jul 31, 2017, at 10:29 AM, Taylor Swift via swift-evolution \\> wrote: > > > > > > > > > > On Mon, Jul 31, 2017 at 1:23 PM, Adrian Zubarev \\> wrote: > > > > > I’m not sure how I would feel about this. To be honest I’d avoid such additional changes from the stdlib, because they really don’t belong there. Instead some `Math` module/package would be a better fit than clustering everything into stdlib until we end up also adding UI stuff. > > > > > > > > > > Furthermore, I don’t think a function would make any sense here. It really should be a computed property. > > > > > > > > > > I think a standard Math module would be a good idea, but only if it benefits from the same inlining and specialization as the standard library. Also squareRoot() should be moved to the Math module if it is ever created. > > > > > > > > > > Am 31. Juli 2017 um 19:03:49, Taylor Swift via swift-evolution (swift-evolution@swift.org \) schrieb: > > > > > > > > > > > How would people feel about adding a protocol > > > > > > > > > > > > protocol MathFloatingPoint:FloatingPoint > > > > > > { > > > > > >     func sin() -\> Self > > > > > >     func cos() -\> Self > > > > > >     func tan() -\> Self > > > > > >     func asin() -\> Self > > > > > >     func acos() -\> Self > > > > > >     func atan() -\> Self > > > > > > > > > > > >     func ln() -\> Self > > > > > >     func log(base:Self) -\> Self > > > > > >     func pow(exponent:Self) -\> Self > > > > > >     func exp() -\> Self > > > > > > } > > > > > > > > > > > > to the standard library? Float and Double would then be made to conform by default using Swift implementations instead of having to import Glibc / Darwin and writing the extensions, depending on platform. > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > > > swift-evolution mailing list > > > > > > swift-evolution@swift.org \ > > > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > > swift-evolution mailing list > > > > > swift-evolution@swift.org \ > > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![taylorswift](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/taylorswift/32/43413_2.png) [@taylorswift](https://forums.swift.org/u/taylorswift)\ **Post date:** [August 1, 2017, 12:37am UTC](https://forums.swift.org/t/trigonometricfloatingpoint-mathfloatingpoint-protocol/6415/12 "2017-08-01T00:37:44Z")
I’d be completely in favor of this. Structs for priority queues, skiplists, trees, binary search and more sorting functions would also be on my wishlist. I think Python made a very good choice in choosing to vend separate standard modules for stuff like that instead of bloating its builtin namespace. > **···** > > On Mon, Jul 31, 2017 at 2:22 PM, Hooman Mehr \ wrote: > > > Maybe we need more than one level of standard library: The core (which is > > most of what we have now (but maybe not all of it) and multiple opt-in > > standard modules for hash functions, math, specialized data structures, etc. > > > > On Jul 31, 2017, at 11:10 AM, Taylor Swift \ wrote: > > > > I’m not sure why only the stdlib is inlineable and specializable, but I > > believe it has something to do with ABI. I’m not an ABI expert though. I > > strongly disagree that a Swift Math library should be delegated to a third > > party. Math is “common” enough that there should really only be one > > “standard” implementation of it, under the direction of the Swift Project; > > we don’t want 5 competing third party Vector standards. > > > > On Mon, Jul 31, 2017 at 2:02 PM, Hooman Mehr \ wrote: > > > > > I know. I hear you. I have some special arrangmnents to keep such things > > > manageable, and I am not happy about how things stand right now. > > > > > > What I am hoping to open up stdlib special compiler mode to other > > > (low-level) libraries and also letting such libraries gain optimizations > > > similar to stdlib when included in a project. > > > > > > So, instead of putting things in stdlib, I want stdlib’s special > > > privileges being made available to a certain category of third-party or > > > internal modules. > > > > > > On Jul 31, 2017, at 10:54 AM, Taylor Swift \ wrote: > > > > > > Isn’t the point of standard inlineable library module to prevent the need > > > to copy and paste code like this into every project? Currently I have a > > > “math.swift” file I copy and paste into all of my projects, and since I > > > occasionally update it, there exists about 15 different versions of it > > > floating around, so I know this is not a sustainable practice. > > > > > > On Mon, Jul 31, 2017 at 1:45 PM, Hooman Mehr \ wrote: > > > > > > > I prefer an approach that preserves how I am used to seeing math > > > > expressions. I use this myself: > > > > > > > > protocol FloatingPointMath: FloatingPoint > > > > { > > > >     static func sqrt(\_ value: Self) -\> Self > > > > > > > >     static func sin(\_ value: Self) -\> Self > > > >     static func cos(\_ value: Self) -\> Self > > > >     static func tan(\_ value: Self) -\> Self > > > >     static func asin(\_ value: Self) -\> Self > > > >     static func acos(\_ value: Self) -\> Self > > > >     static func atan(\_ value: Self) -\> Self > > > > > > > >     static func ln(\_ value: Self) -\> Self > > > >     static func log(\_ value: Self, base: Self) -\> Self > > > >     static func pow(\_ value: Self, exponent:Self) -\> Self > > > >     static func exp(\_ value: Self) -\> Self > > > > } > > > > > > > > It does not pollute the global namespace and gives nice contextual > > > > auto-completion. And I don’t want it in the standard library: I only add > > > > the file when I need it. (it is not a separate module for optimization > > > > reasons). > > > > > > > > On Jul 31, 2017, at 10:29 AM, Taylor Swift via swift-evolution \< \>\>\> swift-evolution@swift.org\> wrote: > > > > > > > > On Mon, Jul 31, 2017 at 1:23 PM, Adrian Zubarev \< \>\>\> adrian.zubarev@devandartist.com\> wrote: > > > > > > > > > I’m not sure how I would feel about this. To be honest I’d avoid such > > > > > additional changes from the stdlib, because they really don’t belong there. > > > > > Instead some `Math` module/package would be a better fit than clustering > > > > > everything into stdlib until we end up also adding UI stuff. > > > > > > > > > > Furthermore, I don’t think a function would make any sense here. It > > > > > really should be a computed property. > > > > > > > > I think a standard Math module would be a good idea, but only if it > > > > benefits from the same inlining and specialization as the standard library. > > > > Also squareRoot() should be moved to the Math module if it is ever created. > > > > > > > > > Am 31. Juli 2017 um 19:03:49, Taylor Swift via swift-evolution ( > > > > > swift-evolution@swift.org) schrieb: > > > > > > > > > > How would people feel about adding a protocol > > > > > > > > > > protocol MathFloatingPoint:FloatingPoint > > > > > { > > > > >     func sin() -\> Self > > > > >     func cos() -\> Self > > > > >     func tan() -\> Self > > > > >     func asin() -\> Self > > > > >     func acos() -\> Self > > > > >     func atan() -\> Self > > > > > > > > > >     func ln() -\> Self > > > > >     func log(base:Self) -\> Self > > > > >     func pow(exponent:Self) -\> Self > > > > >     func exp() -\> Self > > > > > } > > > > > > > > > > to the standard library? Float and Double would then be made to conform > > > > > by default using Swift implementations instead of having to import Glibc / > > > > > Darwin and writing the extensions, depending on platform. > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > > swift-evolution mailing list > > > > > swift-evolution@swift.org > > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > swift-evolution mailing list > > > > swift-evolution@swift.org > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\ **Post date:** [August 1, 2017, 1:11am UTC](https://forums.swift.org/t/trigonometricfloatingpoint-mathfloatingpoint-protocol/6415/13 "2017-08-01T01:11:16Z")
So, this has been discussed before on the list many times in the past. The core team has stated that their preferred process for this is to have individuals write their own libraries, get real-world adoption, then (as consensus emerges) propose their inclusion as a core library. Keep in mind that the \_standard\_ library is what's available by default without importing anything; it is deliberately small and includes only the most basic types that need compiler support. This is different to be distinguished from core libraries like Foundation and Dispatch. With that exhortation in mind, I have written a math library that provides protocol-based trigonometry. For expediency it wraps Darwin or Glibc at the moment. It is intended to be an exercise in creating a plausible design that respects existing Swift conventions. On top of that, it includes implementations for complex and rational numbers, as well as pseudorandom number generators (unfinished at the moment); I include the link here as a reply regarding what I feel would be the optimal design (in terms of free function vs. members) for such a math protocol: > **[GitHub - xwu/NumericAnnex: Numeric facilities for Swift](https://github.com/xwu/NumericAnnex)** > > Numeric facilities for Swift. Contribute to xwu/NumericAnnex development by creating an account on GitHub. > **···** > > On Mon, Jul 31, 2017 at 7:37 PM, Taylor Swift via swift-evolution \< swift-evolution@swift.org\> wrote: > > > I’d be completely in favor of this. Structs for priority queues, > > skiplists, trees, binary search and more sorting functions would also be on > > my wishlist. I think Python made a very good choice in choosing to vend > > separate standard modules for stuff like that instead of bloating its > > builtin namespace. > > > > On Mon, Jul 31, 2017 at 2:22 PM, Hooman Mehr \ wrote: > > > > > Maybe we need more than one level of standard library: The core (which is > > > most of what we have now (but maybe not all of it) and multiple opt-in > > > standard modules for hash functions, math, specialized data structures, etc. > > > > > > On Jul 31, 2017, at 11:10 AM, Taylor Swift \ wrote: > > > > > > I’m not sure why only the stdlib is inlineable and specializable, but I > > > believe it has something to do with ABI. I’m not an ABI expert though. I > > > strongly disagree that a Swift Math library should be delegated to a third > > > party. Math is “common” enough that there should really only be one > > > “standard” implementation of it, under the direction of the Swift Project; > > > we don’t want 5 competing third party Vector standards. > > > > > > On Mon, Jul 31, 2017 at 2:02 PM, Hooman Mehr \ wrote: > > > > > > > I know. I hear you. I have some special arrangmnents to keep such things > > > > manageable, and I am not happy about how things stand right now. > > > > > > > > What I am hoping to open up stdlib special compiler mode to other > > > > (low-level) libraries and also letting such libraries gain optimizations > > > > similar to stdlib when included in a project. > > > > > > > > So, instead of putting things in stdlib, I want stdlib’s special > > > > privileges being made available to a certain category of third-party or > > > > internal modules. > > > > > > > > On Jul 31, 2017, at 10:54 AM, Taylor Swift \ wrote: > > > > > > > > Isn’t the point of standard inlineable library module to prevent the > > > > need to copy and paste code like this into every project? Currently I have > > > > a “math.swift” file I copy and paste into all of my projects, and since I > > > > occasionally update it, there exists about 15 different versions of it > > > > floating around, so I know this is not a sustainable practice. > > > > > > > > On Mon, Jul 31, 2017 at 1:45 PM, Hooman Mehr \ wrote: > > > > > > > > > I prefer an approach that preserves how I am used to seeing math > > > > > expressions. I use this myself: > > > > > > > > > > protocol FloatingPointMath: FloatingPoint > > > > > { > > > > >     static func sqrt(\_ value: Self) -\> Self > > > > > > > > > >     static func sin(\_ value: Self) -\> Self > > > > >     static func cos(\_ value: Self) -\> Self > > > > >     static func tan(\_ value: Self) -\> Self > > > > >     static func asin(\_ value: Self) -\> Self > > > > >     static func acos(\_ value: Self) -\> Self > > > > >     static func atan(\_ value: Self) -\> Self > > > > > > > > > >     static func ln(\_ value: Self) -\> Self > > > > >     static func log(\_ value: Self, base: Self) -\> Self > > > > >     static func pow(\_ value: Self, exponent:Self) -\> Self > > > > >     static func exp(\_ value: Self) -\> Self > > > > > } > > > > > > > > > > It does not pollute the global namespace and gives nice contextual > > > > > auto-completion. And I don’t want it in the standard library: I only add > > > > > the file when I need it. (it is not a separate module for optimization > > > > > reasons). > > > > > > > > > > On Jul 31, 2017, at 10:29 AM, Taylor Swift via swift-evolution \< \>\>\>\> swift-evolution@swift.org\> wrote: > > > > > > > > > > On Mon, Jul 31, 2017 at 1:23 PM, Adrian Zubarev \< \>\>\>\> adrian.zubarev@devandartist.com\> wrote: > > > > > > > > > > > I’m not sure how I would feel about this. To be honest I’d avoid such > > > > > > additional changes from the stdlib, because they really don’t belong there. > > > > > > Instead some `Math` module/package would be a better fit than clustering > > > > > > everything into stdlib until we end up also adding UI stuff. > > > > > > > > > > > > Furthermore, I don’t think a function would make any sense here. It > > > > > > really should be a computed property. > > > > > > > > > > I think a standard Math module would be a good idea, but only if it > > > > > benefits from the same inlining and specialization as the standard library. > > > > > Also squareRoot() should be moved to the Math module if it is ever created. > > > > > > > > > > > Am 31. Juli 2017 um 19:03:49, Taylor Swift via swift-evolution ( > > > > > > swift-evolution@swift.org) schrieb: > > > > > > > > > > > > How would people feel about adding a protocol > > > > > > > > > > > > protocol MathFloatingPoint:FloatingPoint > > > > > > { > > > > > >     func sin() -\> Self > > > > > >     func cos() -\> Self > > > > > >     func tan() -\> Self > > > > > >     func asin() -\> Self > > > > > >     func acos() -\> Self > > > > > >     func atan() -\> Self > > > > > > > > > > > >     func ln() -\> Self > > > > > >     func log(base:Self) -\> Self > > > > > >     func pow(exponent:Self) -\> Self > > > > > >     func exp() -\> Self > > > > > > } > > > > > > > > > > > > to the standard library? Float and Double would then be made to > > > > > > conform by default using Swift implementations instead of having to import > > > > > > Glibc / Darwin and writing the extensions, depending on platform. > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > > > swift-evolution mailing list > > > > > > swift-evolution@swift.org > > > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > > swift-evolution mailing list > > > > > swift-evolution@swift.org > > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![taylorswift](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/taylorswift/32/43413_2.png) [@taylorswift](https://forums.swift.org/u/taylorswift)\ **Post date:** [August 1, 2017, 3:46am UTC](https://forums.swift.org/t/trigonometricfloatingpoint-mathfloatingpoint-protocol/6415/14 "2017-08-01T03:46:23Z")
> So, this has been discussed before on the list many times in the past. The > core team has stated that their preferred process for this is to have > individuals write their own libraries, get real-world adoption, then (as > consensus emerges) propose their inclusion as a core library. While I respect the free-market idealism, I think there’s a reason no one has ever seriously proposed their library to be included as a core library. To be completely honest, I think core libraries are a lot like highways. They’ll never get built if you wait for people to do it themselves. A lot of people (including myself) release their own toolkit on Github; it tends to be just good enough and comprehensive enough to serve their own needs. Each one has maybe 1% adoption and none of them really stand out or are seen as the “best” choice so people just write their own \<[https://xkcd.com/927/>](https://xkcd.com/927/>); in-house solution. There’s no Swift package index (like docs.rs) so even if someone tries to start a core library project (or any library project at all!), no one will ever know about it. There’s also no positive feedback loop whereby if a core library project gets off the ground \<[https://github.com/PureSwift>](https://github.com/PureSwift>), it’ll actually make it to maturity. I’m not gonna get into subjective opinions about having strong open source traditions or lack thereof. Add the fact that we don’t have cross module optimizations yet, and it’s no wonder why the community has never produced a “consensus” core library. I’m not saying the Swift team should devote any time or resources to writing these things, but it’d be a huge benefit if someone were to say “okay we are commissioning a core library that does X, the code will live in Y Github repository, we’ve set up Z mailing list for this, and anyone who is willing to invest time in this is welcome to help make this a reality”. Then everyone with an interest in seeing these things get built would be able to coordinate. > Keep in mind that the \_standard\_ library is what's available by default > without importing anything; it is deliberately small and includes only the > most basic types that need compiler support. This is different to be > distinguished from core libraries like Foundation and Dispatch. I think we’re getting tripped up on two different uses of the word “standard”. Python’s math \<[math — Mathematical functions — Python 3.12.0 documentation](https://docs.python.org/3/library/math.html#module-math>); module isn’t part of its stdlib, but it basically “comes with” the interpreter. > With that exhortation in mind, I have written a math library that provides > protocol-based trigonometry. For expediency it wraps Darwin or Glibc at the > moment. It is intended to be an exercise in creating a plausible design > that respects existing Swift conventions. On top of that, it includes > implementations for complex and rational numbers, as well as pseudorandom > number generators (unfinished at the moment); I include the link here as a > reply regarding what I feel would be the optimal design (in terms of free > function vs. members) for such a math protocol: > > [GitHub - xwu/NumericAnnex: Numeric facilities for Swift](https://github.com/xwu/NumericAnnex) That’s a great project, thank you for sharing! If we ever got an “official” math module started, I think it would make a great seed. > **···** > > On Mon, Jul 31, 2017 at 9:11 PM, Xiaodi Wu \ wrote: > > > On Mon, Jul 31, 2017 at 7:37 PM, Taylor Swift via swift-evolution \< \> swift-evolution@swift.org\> wrote: > > > > > I’d be completely in favor of this. Structs for priority queues, > > > skiplists, trees, binary search and more sorting functions would also be on > > > my wishlist. I think Python made a very good choice in choosing to vend > > > separate standard modules for stuff like that instead of bloating its > > > builtin namespace. > > > > > > On Mon, Jul 31, 2017 at 2:22 PM, Hooman Mehr \ wrote: > > > > > > > Maybe we need more than one level of standard library: The core (which > > > > is most of what we have now (but maybe not all of it) and multiple opt-in > > > > standard modules for hash functions, math, specialized data structures, etc. > > > > > > > > On Jul 31, 2017, at 11:10 AM, Taylor Swift \ wrote: > > > > > > > > I’m not sure why only the stdlib is inlineable and specializable, but I > > > > believe it has something to do with ABI. I’m not an ABI expert though. I > > > > strongly disagree that a Swift Math library should be delegated to a third > > > > party. Math is “common” enough that there should really only be one > > > > “standard” implementation of it, under the direction of the Swift Project; > > > > we don’t want 5 competing third party Vector standards. > > > > > > > > On Mon, Jul 31, 2017 at 2:02 PM, Hooman Mehr \ wrote: > > > > > > > > > I know. I hear you. I have some special arrangmnents to keep such > > > > > things manageable, and I am not happy about how things stand right now. > > > > > > > > > > What I am hoping to open up stdlib special compiler mode to other > > > > > (low-level) libraries and also letting such libraries gain optimizations > > > > > similar to stdlib when included in a project. > > > > > > > > > > So, instead of putting things in stdlib, I want stdlib’s special > > > > > privileges being made available to a certain category of third-party or > > > > > internal modules. > > > > > > > > > > On Jul 31, 2017, at 10:54 AM, Taylor Swift \ \>\>\>\> wrote: > > > > > > > > > > Isn’t the point of standard inlineable library module to prevent the > > > > > need to copy and paste code like this into every project? Currently I have > > > > > a “math.swift” file I copy and paste into all of my projects, and since I > > > > > occasionally update it, there exists about 15 different versions of it > > > > > floating around, so I know this is not a sustainable practice. > > > > > > > > > > On Mon, Jul 31, 2017 at 1:45 PM, Hooman Mehr \ wrote: > > > > > > > > > > > I prefer an approach that preserves how I am used to seeing math > > > > > > expressions. I use this myself: > > > > > > > > > > > > protocol FloatingPointMath: FloatingPoint > > > > > > { > > > > > >     static func sqrt(\_ value: Self) -\> Self > > > > > > > > > > > >     static func sin(\_ value: Self) -\> Self > > > > > >     static func cos(\_ value: Self) -\> Self > > > > > >     static func tan(\_ value: Self) -\> Self > > > > > >     static func asin(\_ value: Self) -\> Self > > > > > >     static func acos(\_ value: Self) -\> Self > > > > > >     static func atan(\_ value: Self) -\> Self > > > > > > > > > > > >     static func ln(\_ value: Self) -\> Self > > > > > >     static func log(\_ value: Self, base: Self) -\> Self > > > > > >     static func pow(\_ value: Self, exponent:Self) -\> Self > > > > > >     static func exp(\_ value: Self) -\> Self > > > > > > } > > > > > > > > > > > > It does not pollute the global namespace and gives nice contextual > > > > > > auto-completion. And I don’t want it in the standard library: I only add > > > > > > the file when I need it. (it is not a separate module for optimization > > > > > > reasons). > > > > > > > > > > > > On Jul 31, 2017, at 10:29 AM, Taylor Swift via swift-evolution \< \>\>\>\>\> swift-evolution@swift.org\> wrote: > > > > > > > > > > > > On Mon, Jul 31, 2017 at 1:23 PM, Adrian Zubarev \< \>\>\>\>\> adrian.zubarev@devandartist.com\> wrote: > > > > > > > > > > > > > I’m not sure how I would feel about this. To be honest I’d avoid such > > > > > > > additional changes from the stdlib, because they really don’t belong there. > > > > > > > Instead some `Math` module/package would be a better fit than clustering > > > > > > > everything into stdlib until we end up also adding UI stuff. > > > > > > > > > > > > > > Furthermore, I don’t think a function would make any sense here. It > > > > > > > really should be a computed property. > > > > > > > > > > > > I think a standard Math module would be a good idea, but only if it > > > > > > benefits from the same inlining and specialization as the standard library. > > > > > > Also squareRoot() should be moved to the Math module if it is ever created. > > > > > > > > > > > > > Am 31. Juli 2017 um 19:03:49, Taylor Swift via swift-evolution ( > > > > > > > swift-evolution@swift.org) schrieb: > > > > > > > > > > > > > > How would people feel about adding a protocol > > > > > > > > > > > > > > protocol MathFloatingPoint:FloatingPoint > > > > > > > { > > > > > > >     func sin() -\> Self > > > > > > >     func cos() -\> Self > > > > > > >     func tan() -\> Self > > > > > > >     func asin() -\> Self > > > > > > >     func acos() -\> Self > > > > > > >     func atan() -\> Self > > > > > > > > > > > > > >     func ln() -\> Self > > > > > > >     func log(base:Self) -\> Self > > > > > > >     func pow(exponent:Self) -\> Self > > > > > > >     func exp() -\> Self > > > > > > > } > > > > > > > > > > > > > > to the standard library? Float and Double would then be made to > > > > > > > conform by default using Swift implementations instead of having to import > > > > > > > Glibc / Darwin and writing the extensions, depending on platform. > > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > > > > swift-evolution mailing list > > > > > > > swift-evolution@swift.org > > > > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > > > swift-evolution mailing list > > > > > > swift-evolution@swift.org > > > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > swift-evolution mailing list > > > swift-evolution@swift.org > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Tino](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/tino/32/1073_2.png) [@Tino](https://forums.swift.org/u/Tino)\ **Post date:** [August 1, 2017, 5:44pm UTC](https://forums.swift.org/t/trigonometricfloatingpoint-mathfloatingpoint-protocol/6415/15 "2017-08-01T17:44:30Z")
> So, this has been discussed before on the list many times in the past. The core team has stated that their preferred process for this is to have individuals write their own libraries, get real-world adoption, then (as consensus emerges) propose their inclusion as a core library. I already opened a new mail to write my answer, but than I thought "wait, scroll down, and look if Xiaodi did already post links" ;-) [But where have those potential core libraries been mentioned?] Anyways, my perception hasn't change much: I think it would be enough if someone from Apple would say "here's an empty github-repo called [math/statistics/algebra/crypto/graphic/image/audio/music/video/smtp/http…]; feel free to fork and create pull requests" and adding some democratic mechanism for acceptance on top of it. But as long as no one with enough reputation starts Swifts equivalent of boost, there won't be a set of established libraries for basic data structures and algorithms outside the stdlib. For anyone who thinks there's no need for a standard lib that is not the stdlib, have a look at > **[GLKQuaternion | Apple Developer Documentation](https://developer.apple.com/documentation/glkit/glkquaternion-pc6)** > > There's never been a better time to develop for Apple platforms. > **[SCNQuaternion | Apple Developer Documentation](https://developer.apple.com/documentation/scenekit/scnquaternion)** > > A representation of a quaternion. > **[CMQuaternion | Apple Developer Documentation](https://developer.apple.com/documentation/coremotion/cmquaternion)** > > The type for a quaternion representing a measurement of attitude. :-( Tino ---
**Author:** ![IanPartridge](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/ianpartridge/32/434_2.png) [@IanPartridge](https://forums.swift.org/u/IanPartridge)\ **Post date:** [August 1, 2017, 8:50am UTC](https://forums.swift.org/t/trigonometricfloatingpoint-mathfloatingpoint-protocol/6415/16 "2017-08-01T08:50:53Z")
That's what's happened with the Server APIs Project [https://swift.org/server-apis/](https://swift.org/server-apis/) I would like to see more of this, and math/BigNum seems like a good candidate. Another is a modern date/time package, standing on the shoulders of [The Java Community Process(SM) Program - JSRs: Java Specification Requests - detail JSR# 310](https://jcp.org/en/jsr/detail?id=310) and similar. > **···** > > On 1 August 2017 at 04:46, Taylor Swift via swift-evolution \ wrote: > > > I’m not saying the Swift team should devote any time or resources to writing > > these things, but it’d be a huge benefit if someone were to say “okay we are > > commissioning a core library that does X, the code will live in Y Github > > repository, we’ve set up Z mailing list for this, and anyone who is willing > > to invest time in this is welcome to help make this a reality”. Then > > everyone with an interest in seeing these things get built would be able to > > coordinate. > > -- > Ian Partridge ---
**Author:** ![Michael\_Ilseman](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/michael_ilseman/32/44640_2.png) [@Michael\_Ilseman](https://forums.swift.org/u/Michael_Ilseman)\ **Post date:** [August 1, 2017, 5:51pm UTC](https://forums.swift.org/t/trigonometricfloatingpoint-mathfloatingpoint-protocol/6415/17 "2017-08-01T17:51:26Z")
> > So, this has been discussed before on the list many times in the past. The core team has stated that their preferred process for this is to have individuals write their own libraries, get real-world adoption, then (as consensus emerges) propose their inclusion as a core library. > > I already opened a new mail to write my answer, but than I thought "wait, scroll down, and look if Xiaodi did already post links" ;-) > [But where have those potential core libraries been mentioned?] > > Anyways, my perception hasn't change much: > I think it would be enough if someone from Apple would say "here's an empty github-repo called [math/statistics/algebra/crypto/graphic/image/audio/music/video/smtp/http…]; feel free to fork and create pull requests" and adding some democratic mechanism for acceptance on top of it. What would be your compatibility and stability expectations of such APIs? If there are any expectations, then the APIs would need careful design and thought. The Swift project faces a lot of design bandwidth limitations, so prioritize is always tricky. > **···** > > > On Aug 1, 2017, at 10:44 AM, Tino Heth via swift-evolution \ wrote: > > > But as long as no one with enough reputation starts Swifts equivalent of boost, there won't be a set of established libraries for basic data structures and algorithms outside the stdlib. > > > > For anyone who thinks there's no need for a standard lib that is not the stdlib, have a look at > > [GLKQuaternion | Apple Developer Documentation](https://developer.apple.com/documentation/glkit/glkquaternion-pc6) > > [SCNQuaternion | Apple Developer Documentation](https://developer.apple.com/documentation/scenekit/scnquaternion) > > [CMQuaternion | Apple Developer Documentation](https://developer.apple.com/documentation/coremotion/cmquaternion) > > :-( > > > > Tino > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![taylorswift](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/taylorswift/32/43413_2.png) [@taylorswift](https://forums.swift.org/u/taylorswift)\ **Post date:** [August 1, 2017, 5:57pm UTC](https://forums.swift.org/t/trigonometricfloatingpoint-mathfloatingpoint-protocol/6415/18 "2017-08-01T17:57:28Z")
Exactly. > **···** > > On Tue, Aug 1, 2017 at 1:44 PM, Tino Heth \<2th@gmx.de\> wrote: > > > So, this has been discussed before on the list many times in the past. The > > core team has stated that their preferred process for this is to have > > individuals write their own libraries, get real-world adoption, then (as > > consensus emerges) propose their inclusion as a core library. > > > > I already opened a new mail to write my answer, but than I thought "wait, > > scroll down, and look if Xiaodi did already post links" ;-) > > [But where have those potential core libraries been mentioned?] > > > > Anyways, my perception hasn't change much: > > I think it would be enough if someone from Apple would say "here's an > > empty github-repo called [math/statistics/algebra/ > > crypto/graphic/image/audio/music/video/smtp/http…]; feel free to fork and > > create pull requests" and adding some democratic mechanism for acceptance > > on top of it. > > > > But as long as no one with enough reputation starts Swifts equivalent of > > boost, there won't be a set of established libraries for basic data > > structures and algorithms outside the stdlib. > > > > For anyone who thinks there's no need for a standard lib that is not the > > stdlib, have a look at > > [GLKQuaternion | Apple Developer Documentation](https://developer.apple.com/documentation/glkit/glkquaternion-pc6) > > [SCNQuaternion | Apple Developer Documentation](https://developer.apple.com/documentation/scenekit/scnquaternion) > > [CMQuaternion | Apple Developer Documentation](https://developer.apple.com/documentation/coremotion/cmquaternion) > > :-( > > > > Tino ---
**Author:** ![taylorswift](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/taylorswift/32/43413_2.png) [@taylorswift](https://forums.swift.org/u/taylorswift)\ **Post date:** [August 1, 2017, 6:00pm UTC](https://forums.swift.org/t/trigonometricfloatingpoint-mathfloatingpoint-protocol/6415/19 "2017-08-01T18:00:09Z")
> So, this has been discussed before on the list many times in the past. The > core team has stated that their preferred process for this is to have > individuals write their own libraries, get real-world adoption, then (as > consensus emerges) propose their inclusion as a core library. > > I already opened a new mail to write my answer, but than I thought "wait, > scroll down, and look if Xiaodi did already post links" ;-) > [But where have those potential core libraries been mentioned?] > > Anyways, my perception hasn't change much: > I think it would be enough if someone from Apple would say "here's an > empty github-repo called [math/statistics/algebra/ > crypto/graphic/image/audio/music/video/smtp/http…]; feel free to fork and > create pull requests" and adding some democratic mechanism for acceptance > on top of it. > > What would be your compatibility and stability expectations of such APIs? > If there are any expectations, then the APIs would need careful design and > thought. The Swift project faces a lot of design bandwidth limitations, so > prioritize is always tricky. The point of spinning off separate core library working groups would be so that library feature requests and proposals can stop clogging up swift-evolution. Then the swift-evolution core team could focus on the compiler and the standard library and the community would take stewardship of the core libraries through separate channels. > **···** > > On Tue, Aug 1, 2017 at 1:51 PM, Michael Ilseman via swift-evolution \< swift-evolution@swift.org\> wrote: > > > On Aug 1, 2017, at 10:44 AM, Tino Heth via swift-evolution \< \> swift-evolution@swift.org\> wrote: > > > But as long as no one with enough reputation starts Swifts equivalent of > > boost, there won't be a set of established libraries for basic data > > structures and algorithms outside the stdlib. > > > > For anyone who thinks there's no need for a standard lib that is not the > > stdlib, have a look at > > [GLKQuaternion | Apple Developer Documentation](https://developer.apple.com/documentation/glkit/glkquaternion-pc6) > > [SCNQuaternion | Apple Developer Documentation](https://developer.apple.com/documentation/scenekit/scnquaternion) > > [CMQuaternion | Apple Developer Documentation](https://developer.apple.com/documentation/coremotion/cmquaternion) > > :-( > > > > Tino > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Tino](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/tino/32/1073_2.png) [@Tino](https://forums.swift.org/u/Tino)\ **Post date:** [August 1, 2017, 6:16pm UTC](https://forums.swift.org/t/trigonometricfloatingpoint-mathfloatingpoint-protocol/6415/20 "2017-08-01T18:16:30Z")
> What would be your compatibility and stability expectations of such APIs? Very low for the first two (or more — depending on how much attention the specific topic receives) years ;-) — but still better than nothing in the long run. Actually, some libraries (or at least parts of them) might become reliable quite quick if there would be a nucleus of crystallisation: Result, Quaternion, Color, Point and other basic structures already exist, and I'd really loose faith in the community if it would manage to start long discussions about how a Point should be represented. For some algorithms, it might be even easier if people don't insist on how the internal variables should be called and just translate a reference implementation. [Next page](https://forums.swift.org/t/trigonometricfloatingpoint-mathfloatingpoint-protocol/6415.md?page=2)