[swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Jonathan Hull]

+1000 to this.

> On Jul 31, 2017, at 11:22 AM, Hooman Mehr via swift-evolution <swift-evolution at swift.org> 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 <kelvin13ma at gmail.com <mailto:kelvin13ma at gmail.com>> 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 <hooman at mac.com <mailto:hooman at mac.com>> 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 <kelvin13ma at gmail.com <mailto:kelvin13ma at gmail.com>> 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 <hooman at mac.com <mailto:hooman at mac.com>> 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 at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> 
>>>> 
>>>> 
>>>> On Mon, Jul 31, 2017 at 1:23 PM, Adrian Zubarev <adrian.zubarev at devandartist.com <mailto:adrian.zubarev at 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 at swift.org <mailto:swift-evolution at 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 at swift.org <mailto:swift-evolution at swift.org>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>> 
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> 
>>> 
>> 
>> 
> 
> _______________________________________________
> 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/20170731/3e408d5b/attachment.html>