[swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Taylor Swift]

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 <hooman at mac.com> 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> 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> 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> 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> 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> wrote:
>>>
>>>
>>>
>>> On Mon, Jul 31, 2017 at 1:23 PM, Adrian Zubarev <
>>> 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) 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
>>>> 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/eb1fccc1/attachment.html>