Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Taylor Swift via swift-evolution]

There was a sign error due to switching to an underlying approximation of
sin() to evaluate cos(). Here’s the actual output


On Fri, Aug 4, 2017 at 4:56 PM, Taylor Swift  wrote:

> update:
>
> I’ve managed to improve the algorithm to the point where it’s arguably
> more accurate than Glibc.cos(_:), and runs just as fast. Removing one term
> makes the Swift implementation faster than _cos(_:), but worses the
> divergence by like 23% (137 ULPs from 0° ..< 90°, as opposed to 111 ULPs).
>
> Relative time (lower is better)
>
> _cos(_:) instrinsic   : 3.096
> pure Swift implementation : 3.165
>
> Almost everywhere the pure Swift implementation is within ±1 ULP of the
> Glibc/llvm implementation. Adding more terms to the approximation actually
> worsens the divergence, so I guess we are in the range where we have to
> start talking about error in the Glibc implementation as well. Here’s an 
> output
> dump
> 
> with input from −360° to +360°.
>
> The _cos(_:) intrinsic seems to be asymmetric across the positive and
> negative halves of the function, which causes the divergence to rise to
> about 3–5 ULPs on the far side of the unit circle. This could be due to
> rounding differences in the arguments, since π/2 and 3π/2 are impossible to
> represent in floating point. However I don’t know which implementation is
> “wrong” here. The Swift one gives the “right” output for all special
> angles; i.e. cos(90°) == 0, cos(60°) == 0.5, etc , whereas _cos(_:) gives
> slightly fuzzy values.
>
> If anyone wants to try it, I put the cosine implementation in an actual
> module on github; and the given benchmark numbers are for cross-module
> calls. 
>
> On Thu, Aug 3, 2017 at 7:32 PM, Taylor Swift  wrote:
>
>>
>>
>> On Thu, Aug 3, 2017 at 7:12 PM, Karl Wagner via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>>
>>> On 3. Aug 2017, at 13:04, Stephen Canon via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>> On Aug 2, 2017, at 7:03 PM, Karl Wagner via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>>
>>> It’s important to remember that computers are mathematical machines, and
>>> some functions which are implemented in hardware on essentially every
>>> platform (like sin/cos/etc) are definitely best implemented as compiler
>>> intrinsics.
>>>
>>>
>>> sin/cos/etc are implemented in software, not hardware. x86 does have the
>>> FSIN/FCOS instructions, but (almost) no one actually uses them to implement
>>> the sin( ) and cos( ) functions; they are a legacy curiosity, both too slow
>>> and too inaccurate for serious use today. There are no analogous
>>> instructions on ARM or PPC.
>>>
>>> – Steve
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>>> Hah that’s pretty cool; I think I learned in EE years ago that it was
>>> implemented with a lookup table inside the CPU and never bothered to
>>> question it.
>>>
>>> The pure-Swift cosine implementation looks cool.
>>>
>>
>> I’m pretty sure it can be improved greatly, at least for Double.
>> Unfortunately performance falls off a cliff for Float for some reason, i
>> don’t know why.
>>
>>>
>>> As for the larger discussion about a Swift maths library: in general,
>>> it’s hard for any new Swift-only package to get off the ground without a
>>> more comprehensive package manager. The current version doesn’t support
>>> most of the Swift projects being worked on every day. Swift is also still a
>>> relatively young language - the new integer protocols have never even
>>> shipped in a stable release. Considering where we are, it’s not really
>>> surprising that most of the Swift maths libraries are still a bit
>>> rudimentary; I expect they will naturally evolve and develop in time, the
>>> way open-source code does.
>>>
>>>
>> Most of the SPM’s limitations have workarounds, the problem is it’s just
>> not very convenient, i.e. local and non-git dependencies. Other features
>> like gyb, I’m not sure if it’s a good idea to bring to the SPM. gyb is a
>> band-aid over deeper limitations of the language.
>>
>>
>>> It’s also worth considering that our excellent bridging with C removes
>>> some of the impetus to rewrite all your battle-tested maths code in Swift.
>>> The benefits are not obvious; the stage is set for pioneers to experiment
>>> and show the world why they should be writing their maths code in Swift.
>>>
>>>
>> The glibc/llvm functions are not generic. You cannot use _cos(_:) on a
>> protocol type like BinaryFloatingPoint. A pure Swift implementation
>> would allow generic programming with trig and other math 

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Taylor Swift via swift-evolution]

update:

I’ve managed to improve the algorithm to the point where it’s arguably more
accurate than Glibc.cos(_:), and runs just as fast. Removing one term makes
the Swift implementation faster than _cos(_:), but worses the divergence by
like 23% (137 ULPs from 0° ..< 90°, as opposed to 111 ULPs).

Relative time (lower is better)

_cos(_:) instrinsic   : 3.096
pure Swift implementation : 3.165

Almost everywhere the pure Swift implementation is within ±1 ULP of the
Glibc/llvm implementation. Adding more terms to the approximation actually
worsens the divergence, so I guess we are in the range where we have to
start talking about error in the Glibc implementation as well. Here’s an output
dump

with input from −360° to +360°.

The _cos(_:) intrinsic seems to be asymmetric across the positive and
negative halves of the function, which causes the divergence to rise to
about 3–5 ULPs on the far side of the unit circle. This could be due to
rounding differences in the arguments, since π/2 and 3π/2 are impossible to
represent in floating point. However I don’t know which implementation is
“wrong” here. The Swift one gives the “right” output for all special
angles; i.e. cos(90°) == 0, cos(60°) == 0.5, etc , whereas _cos(_:) gives
slightly fuzzy values.

If anyone wants to try it, I put the cosine implementation in an actual
module on github; and the given benchmark numbers are for cross-module
calls. 

On Thu, Aug 3, 2017 at 7:32 PM, Taylor Swift  wrote:

>
>
> On Thu, Aug 3, 2017 at 7:12 PM, Karl Wagner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> On 3. Aug 2017, at 13:04, Stephen Canon via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> On Aug 2, 2017, at 7:03 PM, Karl Wagner via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>
>> It’s important to remember that computers are mathematical machines, and
>> some functions which are implemented in hardware on essentially every
>> platform (like sin/cos/etc) are definitely best implemented as compiler
>> intrinsics.
>>
>>
>> sin/cos/etc are implemented in software, not hardware. x86 does have the
>> FSIN/FCOS instructions, but (almost) no one actually uses them to implement
>> the sin( ) and cos( ) functions; they are a legacy curiosity, both too slow
>> and too inaccurate for serious use today. There are no analogous
>> instructions on ARM or PPC.
>>
>> – Steve
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>> Hah that’s pretty cool; I think I learned in EE years ago that it was
>> implemented with a lookup table inside the CPU and never bothered to
>> question it.
>>
>> The pure-Swift cosine implementation looks cool.
>>
>
> I’m pretty sure it can be improved greatly, at least for Double.
> Unfortunately performance falls off a cliff for Float for some reason, i
> don’t know why.
>
>>
>> As for the larger discussion about a Swift maths library: in general,
>> it’s hard for any new Swift-only package to get off the ground without a
>> more comprehensive package manager. The current version doesn’t support
>> most of the Swift projects being worked on every day. Swift is also still a
>> relatively young language - the new integer protocols have never even
>> shipped in a stable release. Considering where we are, it’s not really
>> surprising that most of the Swift maths libraries are still a bit
>> rudimentary; I expect they will naturally evolve and develop in time, the
>> way open-source code does.
>>
>>
> Most of the SPM’s limitations have workarounds, the problem is it’s just
> not very convenient, i.e. local and non-git dependencies. Other features
> like gyb, I’m not sure if it’s a good idea to bring to the SPM. gyb is a
> band-aid over deeper limitations of the language.
>
>
>> It’s also worth considering that our excellent bridging with C removes
>> some of the impetus to rewrite all your battle-tested maths code in Swift.
>> The benefits are not obvious; the stage is set for pioneers to experiment
>> and show the world why they should be writing their maths code in Swift.
>>
>>
> The glibc/llvm functions are not generic. You cannot use _cos(_:) on a
> protocol type like BinaryFloatingPoint. A pure Swift implementation would
> allow generic programming with trig and other math functions; right now
> anything beyond sqrt() requires manual specialization.
>
>
>> - Karl
>>
>> ___
>> 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

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Taylor Swift via swift-evolution]

A math library should include vectorized operations as part of its vector
type support; i currently use this snippet
 to
cover that. Even though they are evaluated as scalars right now, if
simd/sse support ever comes to Linux it’ll be easy to switch to it since
all the vectorizable operations are already routed through the “vector”
functions.


On Thu, Aug 3, 2017 at 5:03 PM, Nicolas Fezans 
wrote:

> Interesting figures. I will not try to discuss the generics, inlineable,
> etc. there are certainly good observations and comments to make here, but
> most people in this list know certainly more about it than I do.
>
> I just want to point out that IMO a core math library for swift should
> comply with the IEEE 754 standard in terms of precision, domain, and
> special values. *On the long term*, it should ideally be able to use SIMD
> instructions when applied to arrays/matrices or when the compiler can
> autovectorize some loops.
>
> On Thu, Aug 3, 2017 at 8:52 PM, Taylor Swift via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> In an effort to get this thread back on track, I tried implementing
>> cos(_:) in pure generic Swift code, with the BinaryFloatingPoint protocol.
>> It deviates from the _cos(_:) intrinsic by no more than
>> 5.26362703423544e-11. Adding more terms to the approximation only has a
>> small penalty to the performance for some reason.
>>
>> To make the benchmarks fair, and explore the idea of distributing a Math
>> module without killing people on the cross-module optimization boundary, I
>> enabled some of the unsafe compiler attributes. All of these benchmarks are
>> cross-module calls, as if the math module were downloaded as a dependency
>> in the SPM.
>>
>> == Relative execution time (lower is better) ==
>>
>> llvm intrinsic   :  3.133
>> glibc cos()  :  3.124
>>
>> no attributes: 43.675
>> with specialization  :  4.162
>> with inlining:  3.108
>> with inlining and specialization :  3.264
>>
>> As you can see, the pure Swift generic implementation actually beats the
>> compiler intrinsic (and the glibc cos() but I guess they’re the same thing)
>> when inlining is used, but for some reason generic specialization and
>> inlining don’t get along very well.
>>
>> Here’s the source implementation. It uses a taylor series (!) which
>> probably isn’t optimal but it does prove that cos() and sin() can be
>> implemented as generics in pure Swift, be distributed as a module outside
>> the stdlib, and still achieve competitive performance with the llvm
>> intrinsics.
>>
>> @_inlineable
>> //@_specialize(where F == Float)
>> //@_specialize(where F == Double)
>> public
>> func cos(_ x:F) -> F where F:BinaryFloatingPoint
>> {
>> let x:F = abs(x.remainder(dividingBy: 2 * F.pi)),
>> quadrant:Int = Int(x * (2 / F.pi))
>>
>> switch quadrant
>> {
>> case 0:
>> return  cos(on_first_quadrant:x)
>> case 1:
>> return -cos(on_first_quadrant: F.pi - x)
>> case 2:
>> return -cos(on_first_quadrant: x - F.pi)
>> case 3:
>> return -cos(on_first_quadrant: 2 * F.pi - x)
>> default:
>> fatalError("unreachable")
>> }
>> }
>>
>> @_versioned
>> @_inlineable
>> //@_specialize(where F == Float)
>> //@_specialize(where F == Double)
>> func cos(on_first_quadrant x:F) -> F where F:BinaryFloatingPoint
>> {
>> let x2:F = x * x
>> var y:F  = -0.00114707451267755432394
>> for c:F in [0.2087675698165412591559,
>>-0.00275573192239332256421489,
>> 0.2480158730158702330045157,
>>-0.00138880310186415,
>> 0.0415319411988,
>>-0.41637437,
>> 0.99914771
>> ]
>> {
>> y = x2 * y + c
>> }
>> return y
>> }
>>
>> On Thu, Aug 3, 2017 at 7:04 AM, Stephen Canon via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> On Aug 2, 2017, at 7:03 PM, Karl Wagner via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>>
>>> It’s important to remember that computers are mathematical machines, and
>>> some functions which are implemented in hardware on essentially every
>>> platform (like sin/cos/etc) are definitely best implemented as compiler
>>> intrinsics.
>>>
>>>
>>> sin/cos/etc are implemented in software, not hardware. x86 does have the
>>> FSIN/FCOS instructions, but (almost) no one actually uses them to implement
>>> the sin( ) and cos( ) functions; they are a legacy curiosity, both too slow
>>> and too inaccurate for serious use today. There are no analogous
>>> instructions on ARM or PPC.
>>>
>>> – Steve
>>>
>>> ___
>>> swift-evolution mailing list
>>> 

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Taylor Swift via swift-evolution]

On Thu, Aug 3, 2017 at 7:12 PM, Karl Wagner via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On 3. Aug 2017, at 13:04, Stephen Canon via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Aug 2, 2017, at 7:03 PM, Karl Wagner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> It’s important to remember that computers are mathematical machines, and
> some functions which are implemented in hardware on essentially every
> platform (like sin/cos/etc) are definitely best implemented as compiler
> intrinsics.
>
>
> sin/cos/etc are implemented in software, not hardware. x86 does have the
> FSIN/FCOS instructions, but (almost) no one actually uses them to implement
> the sin( ) and cos( ) functions; they are a legacy curiosity, both too slow
> and too inaccurate for serious use today. There are no analogous
> instructions on ARM or PPC.
>
> – Steve
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> Hah that’s pretty cool; I think I learned in EE years ago that it was
> implemented with a lookup table inside the CPU and never bothered to
> question it.
>
> The pure-Swift cosine implementation looks cool.
>

I’m pretty sure it can be improved greatly, at least for Double.
Unfortunately performance falls off a cliff for Float for some reason, i
don’t know why.

>
> As for the larger discussion about a Swift maths library: in general, it’s
> hard for any new Swift-only package to get off the ground without a more
> comprehensive package manager. The current version doesn’t support most of
> the Swift projects being worked on every day. Swift is also still a
> relatively young language - the new integer protocols have never even
> shipped in a stable release. Considering where we are, it’s not really
> surprising that most of the Swift maths libraries are still a bit
> rudimentary; I expect they will naturally evolve and develop in time, the
> way open-source code does.
>
>
Most of the SPM’s limitations have workarounds, the problem is it’s just
not very convenient, i.e. local and non-git dependencies. Other features
like gyb, I’m not sure if it’s a good idea to bring to the SPM. gyb is a
band-aid over deeper limitations of the language.


> It’s also worth considering that our excellent bridging with C removes
> some of the impetus to rewrite all your battle-tested maths code in Swift.
> The benefits are not obvious; the stage is set for pioneers to experiment
> and show the world why they should be writing their maths code in Swift.
>
>
The glibc/llvm functions are not generic. You cannot use _cos(_:) on a
protocol type like BinaryFloatingPoint. A pure Swift implementation would
allow generic programming with trig and other math functions; right now
anything beyond sqrt() requires manual specialization.


> - Karl
>
> ___
> 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

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Taylor Swift via swift-evolution]

On Thu, Aug 3, 2017 at 7:17 PM, Karl Wagner  wrote:

>
> On 3. Aug 2017, at 20:52, Taylor Swift via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> In an effort to get this thread back on track, I tried implementing
> cos(_:) in pure generic Swift code, with the BinaryFloatingPoint protocol.
> It deviates from the _cos(_:) intrinsic by no more than
> 5.26362703423544e-11. Adding more terms to the approximation only has a
> small penalty to the performance for some reason.
>
> To make the benchmarks fair, and explore the idea of distributing a Math
> module without killing people on the cross-module optimization boundary, I
> enabled some of the unsafe compiler attributes. All of these benchmarks are
> cross-module calls, as if the math module were downloaded as a dependency
> in the SPM.
>
> == Relative execution time (lower is better) ==
>
> llvm intrinsic   :  3.133
> glibc cos()  :  3.124
>
> no attributes: 43.675
> with specialization  :  4.162
> with inlining:  3.108
> with inlining and specialization :  3.264
>
> As you can see, the pure Swift generic implementation actually beats the
> compiler intrinsic (and the glibc cos() but I guess they’re the same thing)
> when inlining is used, but for some reason generic specialization and
> inlining don’t get along very well.
>
> Here’s the source implementation. It uses a taylor series (!) which
> probably isn’t optimal but it does prove that cos() and sin() can be
> implemented as generics in pure Swift, be distributed as a module outside
> the stdlib, and still achieve competitive performance with the llvm
> intrinsics.
>
> @_inlineable
> //@_specialize(where F == Float)
> //@_specialize(where F == Double)
> public
> func cos(_ x:F) -> F where F:BinaryFloatingPoint
> {
> let x:F = abs(x.remainder(dividingBy: 2 * F.pi)),
> quadrant:Int = Int(x * (2 / F.pi))
>
> switch quadrant
> {
> case 0:
> return  cos(on_first_quadrant:x)
> case 1:
> return -cos(on_first_quadrant: F.pi - x)
> case 2:
> return -cos(on_first_quadrant: x - F.pi)
> case 3:
> return -cos(on_first_quadrant: 2 * F.pi - x)
> default:
> fatalError("unreachable")
> }
> }
>
> @_versioned
> @_inlineable
> //@_specialize(where F == Float)
> //@_specialize(where F == Double)
> func cos(on_first_quadrant x:F) -> F where F:BinaryFloatingPoint
> {
> let x2:F = x * x
> var y:F  = -0.00114707451267755432394
> for c:F in [0.2087675698165412591559,
>-0.00275573192239332256421489,
> 0.2480158730158702330045157,
>-0.00138880310186415,
> 0.0415319411988,
>-0.41637437,
> 0.99914771
> ]
> {
> y = x2 * y + c
> }
> return y
> }
>
> On Thu, Aug 3, 2017 at 7:04 AM, Stephen Canon via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> On Aug 2, 2017, at 7:03 PM, Karl Wagner via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>
>> It’s important to remember that computers are mathematical machines, and
>> some functions which are implemented in hardware on essentially every
>> platform (like sin/cos/etc) are definitely best implemented as compiler
>> intrinsics.
>>
>>
>> sin/cos/etc are implemented in software, not hardware. x86 does have the
>> FSIN/FCOS instructions, but (almost) no one actually uses them to implement
>> the sin( ) and cos( ) functions; they are a legacy curiosity, both too slow
>> and too inaccurate for serious use today. There are no analogous
>> instructions on ARM or PPC.
>>
>> – Steve
>>
>> ___
>> 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
>
>
>
> Just a guess, but I’d expect inlining implies specialisation. It would be
> weird if the compiler inlined a chunk of unoptimised generic code in to
> your function.
>
> Pretty cool figures, though.
>
> - Karl
>
>
The weird part is that generic specialization actually *hurt* performance.
I understand why inlining can be harmful sometimes, but I always assumed
specialization was always helpful. Weird. Can a core team member weigh in
here?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Karl Wagner via swift-evolution]

> On 3. Aug 2017, at 20:52, Taylor Swift via swift-evolution 
>  wrote:
> 
> In an effort to get this thread back on track, I tried implementing cos(_:) 
> in pure generic Swift code, with the BinaryFloatingPoint protocol. It 
> deviates from the _cos(_:) intrinsic by no more than 5.26362703423544e-11. 
> Adding more terms to the approximation only has a small penalty to the 
> performance for some reason.
> 
> To make the benchmarks fair, and explore the idea of distributing a Math 
> module without killing people on the cross-module optimization boundary, I 
> enabled some of the unsafe compiler attributes. All of these benchmarks are 
> cross-module calls, as if the math module were downloaded as a dependency in 
> the SPM.
> 
> == Relative execution time (lower is better) ==
> 
> llvm intrinsic   :  3.133
> glibc cos()  :  3.124
> 
> no attributes: 43.675
> with specialization  :  4.162
> with inlining:  3.108
> with inlining and specialization :  3.264
> 
> As you can see, the pure Swift generic implementation actually beats the 
> compiler intrinsic (and the glibc cos() but I guess they’re the same thing) 
> when inlining is used, but for some reason generic specialization and 
> inlining don’t get along very well.
> 
> Here’s the source implementation. It uses a taylor series (!) which probably 
> isn’t optimal but it does prove that cos() and sin() can be implemented as 
> generics in pure Swift, be distributed as a module outside the stdlib, and 
> still achieve competitive performance with the llvm intrinsics.
> 
> @_inlineable
> //@_specialize(where F == Float)
> //@_specialize(where F == Double)
> public
> func cos(_ x:F) -> F where F:BinaryFloatingPoint
> {
> let x:F = abs(x.remainder(dividingBy: 2 * F.pi)),
> quadrant:Int = Int(x * (2 / F.pi))
> 
> switch quadrant
> {
> case 0:
> return  cos(on_first_quadrant:x)
> case 1:
> return -cos(on_first_quadrant: F.pi - x)
> case 2:
> return -cos(on_first_quadrant: x - F.pi)
> case 3:
> return -cos(on_first_quadrant: 2 * F.pi - x)
> default:
> fatalError("unreachable")
> }
> }
> 
> @_versioned
> @_inlineable
> //@_specialize(where F == Float)
> //@_specialize(where F == Double)
> func cos(on_first_quadrant x:F) -> F where F:BinaryFloatingPoint
> {
> let x2:F = x * x
> var y:F  = -0.00114707451267755432394
> for c:F in [0.2087675698165412591559,
>-0.00275573192239332256421489,
> 0.2480158730158702330045157,
>-0.00138880310186415,
> 0.0415319411988,
>-0.41637437,
> 0.99914771
> ]
> {
> y = x2 * y + c
> }
> return y
> }
> 
> On Thu, Aug 3, 2017 at 7:04 AM, Stephen Canon via swift-evolution 
> > wrote:
>> On Aug 2, 2017, at 7:03 PM, Karl Wagner via swift-evolution 
>> > wrote:
>> 
>> It’s important to remember that computers are mathematical machines, and 
>> some functions which are implemented in hardware on essentially every 
>> platform (like sin/cos/etc) are definitely best implemented as compiler 
>> intrinsics.
> 
> sin/cos/etc are implemented in software, not hardware. x86 does have the 
> FSIN/FCOS instructions, but (almost) no one actually uses them to implement 
> the sin( ) and cos( ) functions; they are a legacy curiosity, both too slow 
> and too inaccurate for serious use today. There are no analogous instructions 
> on ARM or PPC.
> 
> – Steve
> 
> ___
> 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


Just a guess, but I’d expect inlining implies specialisation. It would be weird 
if the compiler inlined a chunk of unoptimised generic code in to your function.

Pretty cool figures, though.

- Karl

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Karl Wagner via swift-evolution]

> On 3. Aug 2017, at 13:04, Stephen Canon via swift-evolution 
>  wrote:
> 
>> On Aug 2, 2017, at 7:03 PM, Karl Wagner via swift-evolution 
>> > wrote:
>> 
>> It’s important to remember that computers are mathematical machines, and 
>> some functions which are implemented in hardware on essentially every 
>> platform (like sin/cos/etc) are definitely best implemented as compiler 
>> intrinsics.
> 
> sin/cos/etc are implemented in software, not hardware. x86 does have the 
> FSIN/FCOS instructions, but (almost) no one actually uses them to implement 
> the sin( ) and cos( ) functions; they are a legacy curiosity, both too slow 
> and too inaccurate for serious use today. There are no analogous instructions 
> on ARM or PPC.
> 
> – Steve
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

Hah that’s pretty cool; I think I learned in EE years ago that it was 
implemented with a lookup table inside the CPU and never bothered to question 
it.

The pure-Swift cosine implementation looks cool.

As for the larger discussion about a Swift maths library: in general, it’s hard 
for any new Swift-only package to get off the ground without a more 
comprehensive package manager. The current version doesn’t support most of the 
Swift projects being worked on every day. Swift is also still a relatively 
young language - the new integer protocols have never even shipped in a stable 
release. Considering where we are, it’s not really surprising that most of the 
Swift maths libraries are still a bit rudimentary; I expect they will naturally 
evolve and develop in time, the way open-source code does.

It’s also worth considering that our excellent bridging with C removes some of 
the impetus to rewrite all your battle-tested maths code in Swift. The benefits 
are not obvious; the stage is set for pioneers to experiment and show the world 
why they should be writing their maths code in Swift.

- Karl___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Nicolas Fezans via swift-evolution]

Interesting figures. I will not try to discuss the generics, inlineable,
etc. there are certainly good observations and comments to make here, but
most people in this list know certainly more about it than I do.

I just want to point out that IMO a core math library for swift should
comply with the IEEE 754 standard in terms of precision, domain, and
special values. *On the long term*, it should ideally be able to use SIMD
instructions when applied to arrays/matrices or when the compiler can
autovectorize some loops.

On Thu, Aug 3, 2017 at 8:52 PM, Taylor Swift via swift-evolution <
swift-evolution@swift.org> wrote:

> In an effort to get this thread back on track, I tried implementing
> cos(_:) in pure generic Swift code, with the BinaryFloatingPoint protocol.
> It deviates from the _cos(_:) intrinsic by no more than
> 5.26362703423544e-11. Adding more terms to the approximation only has a
> small penalty to the performance for some reason.
>
> To make the benchmarks fair, and explore the idea of distributing a Math
> module without killing people on the cross-module optimization boundary, I
> enabled some of the unsafe compiler attributes. All of these benchmarks are
> cross-module calls, as if the math module were downloaded as a dependency
> in the SPM.
>
> == Relative execution time (lower is better) ==
>
> llvm intrinsic   :  3.133
> glibc cos()  :  3.124
>
> no attributes: 43.675
> with specialization  :  4.162
> with inlining:  3.108
> with inlining and specialization :  3.264
>
> As you can see, the pure Swift generic implementation actually beats the
> compiler intrinsic (and the glibc cos() but I guess they’re the same thing)
> when inlining is used, but for some reason generic specialization and
> inlining don’t get along very well.
>
> Here’s the source implementation. It uses a taylor series (!) which
> probably isn’t optimal but it does prove that cos() and sin() can be
> implemented as generics in pure Swift, be distributed as a module outside
> the stdlib, and still achieve competitive performance with the llvm
> intrinsics.
>
> @_inlineable
> //@_specialize(where F == Float)
> //@_specialize(where F == Double)
> public
> func cos(_ x:F) -> F where F:BinaryFloatingPoint
> {
> let x:F = abs(x.remainder(dividingBy: 2 * F.pi)),
> quadrant:Int = Int(x * (2 / F.pi))
>
> switch quadrant
> {
> case 0:
> return  cos(on_first_quadrant:x)
> case 1:
> return -cos(on_first_quadrant: F.pi - x)
> case 2:
> return -cos(on_first_quadrant: x - F.pi)
> case 3:
> return -cos(on_first_quadrant: 2 * F.pi - x)
> default:
> fatalError("unreachable")
> }
> }
>
> @_versioned
> @_inlineable
> //@_specialize(where F == Float)
> //@_specialize(where F == Double)
> func cos(on_first_quadrant x:F) -> F where F:BinaryFloatingPoint
> {
> let x2:F = x * x
> var y:F  = -0.00114707451267755432394
> for c:F in [0.2087675698165412591559,
>-0.00275573192239332256421489,
> 0.2480158730158702330045157,
>-0.00138880310186415,
> 0.0415319411988,
>-0.41637437,
> 0.99914771
> ]
> {
> y = x2 * y + c
> }
> return y
> }
>
> On Thu, Aug 3, 2017 at 7:04 AM, Stephen Canon via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> On Aug 2, 2017, at 7:03 PM, Karl Wagner via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>
>> It’s important to remember that computers are mathematical machines, and
>> some functions which are implemented in hardware on essentially every
>> platform (like sin/cos/etc) are definitely best implemented as compiler
>> intrinsics.
>>
>>
>> sin/cos/etc are implemented in software, not hardware. x86 does have the
>> FSIN/FCOS instructions, but (almost) no one actually uses them to implement
>> the sin( ) and cos( ) functions; they are a legacy curiosity, both too slow
>> and too inaccurate for serious use today. There are no analogous
>> instructions on ARM or PPC.
>>
>> – Steve
>>
>> ___
>> 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
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Taylor Swift via swift-evolution]

In an effort to get this thread back on track, I tried implementing cos(_:)
in pure generic Swift code, with the BinaryFloatingPoint protocol. It
deviates from the _cos(_:) intrinsic by no more than 5.26362703423544e-11.
Adding more terms to the approximation only has a small penalty to the
performance for some reason.

To make the benchmarks fair, and explore the idea of distributing a Math
module without killing people on the cross-module optimization boundary, I
enabled some of the unsafe compiler attributes. All of these benchmarks are
cross-module calls, as if the math module were downloaded as a dependency
in the SPM.

== Relative execution time (lower is better) ==

llvm intrinsic   :  3.133
glibc cos()  :  3.124

no attributes: 43.675
with specialization  :  4.162
with inlining:  3.108
with inlining and specialization :  3.264

As you can see, the pure Swift generic implementation actually beats the
compiler intrinsic (and the glibc cos() but I guess they’re the same thing)
when inlining is used, but for some reason generic specialization and
inlining don’t get along very well.

Here’s the source implementation. It uses a taylor series (!) which
probably isn’t optimal but it does prove that cos() and sin() can be
implemented as generics in pure Swift, be distributed as a module outside
the stdlib, and still achieve competitive performance with the llvm
intrinsics.

@_inlineable
//@_specialize(where F == Float)
//@_specialize(where F == Double)
public
func cos(_ x:F) -> F where F:BinaryFloatingPoint
{
let x:F = abs(x.remainder(dividingBy: 2 * F.pi)),
quadrant:Int = Int(x * (2 / F.pi))

switch quadrant
{
case 0:
return  cos(on_first_quadrant:x)
case 1:
return -cos(on_first_quadrant: F.pi - x)
case 2:
return -cos(on_first_quadrant: x - F.pi)
case 3:
return -cos(on_first_quadrant: 2 * F.pi - x)
default:
fatalError("unreachable")
}
}

@_versioned
@_inlineable
//@_specialize(where F == Float)
//@_specialize(where F == Double)
func cos(on_first_quadrant x:F) -> F where F:BinaryFloatingPoint
{
let x2:F = x * x
var y:F  = -0.00114707451267755432394
for c:F in [0.2087675698165412591559,
   -0.00275573192239332256421489,
0.2480158730158702330045157,
   -0.00138880310186415,
0.0415319411988,
   -0.41637437,
0.99914771
]
{
y = x2 * y + c
}
return y
}

On Thu, Aug 3, 2017 at 7:04 AM, Stephen Canon via swift-evolution <
swift-evolution@swift.org> wrote:

> On Aug 2, 2017, at 7:03 PM, Karl Wagner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> It’s important to remember that computers are mathematical machines, and
> some functions which are implemented in hardware on essentially every
> platform (like sin/cos/etc) are definitely best implemented as compiler
> intrinsics.
>
>
> sin/cos/etc are implemented in software, not hardware. x86 does have the
> FSIN/FCOS instructions, but (almost) no one actually uses them to implement
> the sin( ) and cos( ) functions; they are a legacy curiosity, both too slow
> and too inaccurate for serious use today. There are no analogous
> instructions on ARM or PPC.
>
> – Steve
>
> ___
> 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

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Taylor Swift via swift-evolution]

On Thu, Aug 3, 2017 at 3:21 AM, Tino Heth <2...@gmx.de> wrote:

>
> You're welcome to join me in my endeavor to create a math library. I'd bet
> Karoly feels the same way about his project.
>
> See, exactly this is the big problem we are facing here — probably not in
> your specific case, but in general:
> It's not very appealing for most people to contribute to a small library
> that's rarely known, instead of starting their own project to collect
> github stars...
>
> - Tino
>
>
I agree. People tend to ignore the social factors present here and assume
that developers act perfectly rationally, then wonder why Swift library
support is so horrifically fragmented.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Taylor Swift via swift-evolution]

I don’t think we should be designing interfaces based off of what pure
mathematicians write. Scientists aren’t the only people who use sin(x).
It’s better to go with the “common sense” behavior than the esoteric
academic notation. And for the record, I think Matrix.map(sin(_:)) is the
best and most clear interface for elementwise sin.

On Thu, Aug 3, 2017 at 7:00 AM, Stephen Canon via swift-evolution <
swift-evolution@swift.org> wrote:

> On Aug 2, 2017, at 6:37 PM, Nicolas Fezans via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I am of course not talking about a syntax sugar to call a sin or cos
> function, but rather to manipulate other objects such as N-dimensional
> matrices, defining maths functions that can take such matrices as argument
> e.g. sin(A) with A as matrix produces a matrix of the same size where all
> elements are the sinus values of the elements of A (sorry but things like
> this calling map() with 'sin' looks quite ugly for scientists).
>
>
> You’re on very shaky ground here. It is not at all obvious that sin(A)
> should be the “elementwise” sine that you suggest, and not the matrix sine
> (defined by plugging A into the power series for sine, which is globally
> convergent). Depending on what branch of science/math you come from, one of
> these is “obviously” the right answer, but I assure you that it’s very much
> not obvious.
>
> Yes, we want libraries to build this sort of thing to exist.
>
> No, it’s not clear what the “right” way to expose some of these operations
> in the language/library are.
>
> It is better to be verbose but correct than to be terse and cause bugs.
>
> – Steve
>
> ___
> 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

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Jacob Williams via swift-evolution]

There’s also a PureSwift organization of GitHub that has several Swift PM 
packages built specifically with Linux support in mind

https://github.com/PureSwift 

It looks like it’s along the lines of SwiftBreezy, but it hasn’t died out…yet.

At the same time, this may just be another example of how without an Apple 
“backed”/supported repo, the community is very likely to become more and more 
fragmented as more and more people implement the same few frameworks with minor 
variations/improvements.

> On Aug 3, 2017, at 5:04 AM, Stephen Canon via swift-evolution 
>  wrote:
> 
>> On Aug 2, 2017, at 7:03 PM, Karl Wagner via swift-evolution 
>> > wrote:
>> 
>> It’s important to remember that computers are mathematical machines, and 
>> some functions which are implemented in hardware on essentially every 
>> platform (like sin/cos/etc) are definitely best implemented as compiler 
>> intrinsics.
> 
> sin/cos/etc are implemented in software, not hardware. x86 does have the 
> FSIN/FCOS instructions, but (almost) no one actually uses them to implement 
> the sin( ) and cos( ) functions; they are a legacy curiosity, both too slow 
> and too inaccurate for serious use today. There are no analogous instructions 
> on ARM or PPC.
> 
> – Steve
> ___
> 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

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Stephen Canon via swift-evolution]

> On Aug 2, 2017, at 7:03 PM, Karl Wagner via swift-evolution 
>  wrote:
> 
> It’s important to remember that computers are mathematical machines, and some 
> functions which are implemented in hardware on essentially every platform 
> (like sin/cos/etc) are definitely best implemented as compiler intrinsics.

sin/cos/etc are implemented in software, not hardware. x86 does have the 
FSIN/FCOS instructions, but (almost) no one actually uses them to implement the 
sin( ) and cos( ) functions; they are a legacy curiosity, both too slow and too 
inaccurate for serious use today. There are no analogous instructions on ARM or 
PPC.

– Steve___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Stephen Canon via swift-evolution]

> On Aug 2, 2017, at 6:37 PM, Nicolas Fezans via swift-evolution 
>  wrote:
> 
> I am of course not talking about a syntax sugar to call a sin or cos 
> function, but rather to manipulate other objects such as N-dimensional 
> matrices, defining maths functions that can take such matrices as argument 
> e.g. sin(A) with A as matrix produces a matrix of the same size where all 
> elements are the sinus values of the elements of A (sorry but things like 
> this calling map() with 'sin' looks quite ugly for scientists).


You’re on very shaky ground here. It is not at all obvious that sin(A) should 
be the “elementwise” sine that you suggest, and not the matrix sine (defined by 
plugging A into the power series for sine, which is globally convergent). 
Depending on what branch of science/math you come from, one of these is 
“obviously” the right answer, but I assure you that it’s very much not obvious.

Yes, we want libraries to build this sort of thing to exist.

No, it’s not clear what the “right” way to expose some of these operations in 
the language/library are.

It is better to be verbose but correct than to be terse and cause bugs.

– Steve___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Tino Heth via swift-evolution]

> Well that there is a rather defeatist attitude. If you are correct that 
> Apple-funded development is the only way to get core libraries built (and 
> maintained), and Apple has expressed they have no intention of doing so, then 
> we are all pretty much fd. 
I don't think Apple-funded development is the only way — it's just that the 
alternative takes much more time.
But ihmo the funding don't has to be large:
I wonder what would happen if Ted picked a random Swift developer, and gave him 
the maintainer credentials for an empty Result-repo on the official github 
page of Swift...___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Tino Heth via swift-evolution]

> You're welcome to join me in my endeavor to create a math library. I'd bet 
> Karoly feels the same way about his project.
See, exactly this is the big problem we are facing here — probably not in your 
specific case, but in general:
It's not very appealing for most people to contribute to a small library that's 
rarely known, instead of starting their own project to collect github stars...

- Tino

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Tino Heth via swift-evolution]

> The other point I'd make here is that I definitely think the core team is 
> right about encouraging any "entire API spec" for a math library to be based 
> on implementation experience from actually writing a math library that has 
> seen good adoption. Essentially, what they're saying is that any proposed 
> design here should have already proved itself in the field.
The things that are imho the most important to have don't need to be designed 
anymore — we only need to agree on a specific implementation.
A quick search for "Result Swift" on github yields 80 projects. I haven't 
looked at all of those, but I would be very surprised if the majority isn't 
more or less identical:
Names might be not all exactly the same, and some features won't exist 
everywhere… but I don't think it is a good idea to wait another two years to 
see if one of the implementations won the competition.
And even if one solution emerges to be the most popular: I bet it won't be 
because its quality, but some sort of marketing instead.

> I assume that you are well aware of Conway's law, which afaict has good 
> evidence to back it up; with that in mind, the end product that emerges from 
> a draft spec and an empty open-source repo is unlikely to be satisfactory, 
> let alone optimal.

That might be true for complicated stuff — but it took me some time to come up 
with examples for this category…

But there are at least three(!) implementations of quaternions in Apple 
libraries, and for this stupid reason, you can't directly take the data from 
the iPhones sensors and animate an object in scene kit with it. Is this 
satisfactory?

Imho it's not important for those missing "standard" libraries to have state of 
the art implementations for all established algorithms; it's much more valuable 
to agree on basics that are adopted by other libraries:
- I don't expect that Swift's dictionaries are optimal, but that isn't nearly 
as important as the fact that they are compatible with NSDictionary — or just 
imagine each library had it's own implementation of Array; it would be 
terrible, and a giant blocker for the adoption of Swift.
- A standard library for directed graphs doesn't need to have a version of A* 
or Dijkstras algorithm — it would already be a big step forward to declare the 
basic data structure, so that my variant of A* is compatible with someone 
else's graph visualisation toolkit.

- Tino___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Taylor Swift via swift-evolution]

On Wed, Aug 2, 2017 at 10:58 PM, Xiaodi Wu  wrote:

> On Wed, Aug 2, 2017 at 21:55 Taylor Swift  wrote:
>
>> Swift Breeze *was* on Github ,, i don’t
>> know whose argument that strengthens here :)
>>
>
> No, no, I mean, doesn't GitHub itself fit the roles you defined earlier?
> And by implication, why would a project on GitHub do any better than GitHub
> itself at being a collection of repositories and at facilitating
> collaboration?
>

Github is a big ocean, sis. Swift libraries would benefit from having a
smaller grouping that’s just Swift libraries. That’s not to say
cross-community collaboration isn’t beneficial — my library Noise
 benefited greatly from working with its
counterpart in the Rust community, but Swift libraries do need their own
space.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Xiaodi Wu via swift-evolution]

On Wed, Aug 2, 2017 at 21:55 Taylor Swift  wrote:

> Swift Breeze *was* on Github ,, i don’t
> know whose argument that strengthens here :)
>

No, no, I mean, doesn't GitHub itself fit the roles you defined earlier?
And by implication, why would a project on GitHub do any better than GitHub
itself at being a collection of repositories and at facilitating
collaboration?

Here was the original thread
> 
> it was introduced in. It got a lot of attention and +1’s but never
> attracted much involvement, possibly because the Swift FOSS community was
> much smaller back then, possibly because people on mailing lists are by
> nature all-talk, no-action. I’m also a library author so I understand the
> reluctance to give up your children to a collective repo lol.
>
> On Wed, Aug 2, 2017 at 10:47 PM, Xiaodi Wu  wrote:
>
>> Hmm, I'd never heard of Swift Breeze. Doesn't seem like it'd be a
>> successful model to follow. Is there a reason why GitHub itself doesn't
>> meet these criteria?
>>
>>
>>
>> On Wed, Aug 2, 2017 at 21:42 Taylor Swift  wrote:
>>
>>> Trying to gather together a bunch of unpaid people won’t automatically
>>> solve the problem. (We *can* agree that there *is* a problem, yes?) I
>>> think Swift Breeze demonstrated that. (Incidentally, throwing a bunch of
>>> money at the problem won’t automatically solve it either — look at the US
>>> government.) But then again, it can still *help*, and while it sounds
>>> cheesy, *how much* it can help depends entirely on the attitude of the
>>> contributors; whether they see themselves as solo authors listed on a
>>> package index, or as part of a bigger effort. I’m not really a fan of
>>> waiting for Apple to save the day. One of the things I’ve argued for that
>>> *can* be done without Apple’s help is setting up another Swift library
>>> incubator like Breeze. Obviously it won’t magically lead to a Swift math
>>> library but it does remove some of the obstacles I mentioned earlier:
>>>
>>> - it links together disparate solo projects and provides discoverability
>>> to users
>>> - it provides a package index and serves as a dashboard to check up on
>>> the “state of Swift library support”
>>> - it gives a venue for interested people to discuss the general topic of
>>> library support
>>> - it helps network people who are working on similar things (a “soft
>>> factor” but important!)
>>>
>>> tldr; self-organization isn’t a panacea, but it helps.
>>>
>>> On Wed, Aug 2, 2017 at 10:14 PM, Xiaodi Wu  wrote:
>>>
 That's not what I'm saying at all. I'm responding to your contention
 that no library without "backing" will see wide adoption: if, as you say,
 you would like to have a math library with sufficient "backing," then
 realize that you're arguing for someone to devote financial resources to
 the problem. Your proposed solution of getting together a bunch of unpaid
 people does not address your identified problem.

 On Wed, Aug 2, 2017 at 21:07 Taylor Swift  wrote:

>
>
> On Wed, Aug 2, 2017 at 9:18 PM, Xiaodi Wu  wrote:
>
>> On Wed, Aug 2, 2017 at 7:29 PM, Taylor Swift 
>> wrote:
>>
>>>
>>>
>>> On Wed, Aug 2, 2017 at 7:54 PM, Xiaodi Wu 
>>> wrote:
>>>
 On Wed, Aug 2, 2017 at 6:29 PM, Taylor Swift 
 wrote:

> See, my problem with statements like this one, is that the answer
> “should be supported as a third-party library” can also be 
> interpreted as
> “not my problem, go figure it out yourselves”. The idea that central 
> entity
> can only pay attention to what they want to, and the Community™ will
> magically take care of the rest is one of the most pervasive, and 
> untrue,
> myths about open source. What’s worse, is that Swift has the benefit 
> of
> hindsight, in the form of many, many examples of languages that came 
> before
> and fell victim to this fallacy, and now have 15 competing “private”
> classes for basic mathematical objects like *vectors*.
>
> I agree that a core math library, for example, *could* in theory
> be supported as a third-party library.
>

 The core team has said that they're open to a core math library
 being part of the Swift open source project; they just outlined that 
 the
 _process_ for doing so is best initiated with a third-party library as 
 a
 starting point.


> But this will never happen on its own, for reasons that I will
> reiterate here:
>
> - no one influential 

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Taylor Swift via swift-evolution]

Swift Breeze *was* on Github ,, i don’t
know whose argument that strengthens here :)

Here was the original thread

it was introduced in. It got a lot of attention and +1’s but never
attracted much involvement, possibly because the Swift FOSS community was
much smaller back then, possibly because people on mailing lists are by
nature all-talk, no-action. I’m also a library author so I understand the
reluctance to give up your children to a collective repo lol.

On Wed, Aug 2, 2017 at 10:47 PM, Xiaodi Wu  wrote:

> Hmm, I'd never heard of Swift Breeze. Doesn't seem like it'd be a
> successful model to follow. Is there a reason why GitHub itself doesn't
> meet these criteria?
>
>
>
> On Wed, Aug 2, 2017 at 21:42 Taylor Swift  wrote:
>
>> Trying to gather together a bunch of unpaid people won’t automatically
>> solve the problem. (We *can* agree that there *is* a problem, yes?) I
>> think Swift Breeze demonstrated that. (Incidentally, throwing a bunch of
>> money at the problem won’t automatically solve it either — look at the US
>> government.) But then again, it can still *help*, and while it sounds
>> cheesy, *how much* it can help depends entirely on the attitude of the
>> contributors; whether they see themselves as solo authors listed on a
>> package index, or as part of a bigger effort. I’m not really a fan of
>> waiting for Apple to save the day. One of the things I’ve argued for that
>> *can* be done without Apple’s help is setting up another Swift library
>> incubator like Breeze. Obviously it won’t magically lead to a Swift math
>> library but it does remove some of the obstacles I mentioned earlier:
>>
>> - it links together disparate solo projects and provides discoverability
>> to users
>> - it provides a package index and serves as a dashboard to check up on
>> the “state of Swift library support”
>> - it gives a venue for interested people to discuss the general topic of
>> library support
>> - it helps network people who are working on similar things (a “soft
>> factor” but important!)
>>
>> tldr; self-organization isn’t a panacea, but it helps.
>>
>> On Wed, Aug 2, 2017 at 10:14 PM, Xiaodi Wu  wrote:
>>
>>> That's not what I'm saying at all. I'm responding to your contention
>>> that no library without "backing" will see wide adoption: if, as you say,
>>> you would like to have a math library with sufficient "backing," then
>>> realize that you're arguing for someone to devote financial resources to
>>> the problem. Your proposed solution of getting together a bunch of unpaid
>>> people does not address your identified problem.
>>>
>>> On Wed, Aug 2, 2017 at 21:07 Taylor Swift  wrote:
>>>


 On Wed, Aug 2, 2017 at 9:18 PM, Xiaodi Wu  wrote:

> On Wed, Aug 2, 2017 at 7:29 PM, Taylor Swift 
> wrote:
>
>>
>>
>> On Wed, Aug 2, 2017 at 7:54 PM, Xiaodi Wu 
>> wrote:
>>
>>> On Wed, Aug 2, 2017 at 6:29 PM, Taylor Swift 
>>> wrote:
>>>
 See, my problem with statements like this one, is that the answer
 “should be supported as a third-party library” can also be interpreted 
 as
 “not my problem, go figure it out yourselves”. The idea that central 
 entity
 can only pay attention to what they want to, and the Community™ will
 magically take care of the rest is one of the most pervasive, and 
 untrue,
 myths about open source. What’s worse, is that Swift has the benefit of
 hindsight, in the form of many, many examples of languages that came 
 before
 and fell victim to this fallacy, and now have 15 competing “private”
 classes for basic mathematical objects like *vectors*.

 I agree that a core math library, for example, *could* in theory
 be supported as a third-party library.

>>>
>>> The core team has said that they're open to a core math library
>>> being part of the Swift open source project; they just outlined that the
>>> _process_ for doing so is best initiated with a third-party library as a
>>> starting point.
>>>
>>>
 But this will never happen on its own, for reasons that I will
 reiterate here:

 - no one influential enough has bothered to jump start any such
 project

>>>
>>> Karoly Lorentey has a wonderful, and quite mature, BigInt project: <
>>> https://github.com/lorentey/BigInt>. Also, as I mentioned, I just
>>> started a project for protocol-based additions to Swift's basic numeric
>>> types. These are just two examples.
>>>
>>>
 - there are no avenues to encourage members of the community to

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Xiaodi Wu via swift-evolution]

Hmm, I'd never heard of Swift Breeze. Doesn't seem like it'd be a
successful model to follow. Is there a reason why GitHub itself doesn't
meet these criteria?


On Wed, Aug 2, 2017 at 21:42 Taylor Swift  wrote:

> Trying to gather together a bunch of unpaid people won’t automatically
> solve the problem. (We *can* agree that there *is* a problem, yes?) I
> think Swift Breeze demonstrated that. (Incidentally, throwing a bunch of
> money at the problem won’t automatically solve it either — look at the US
> government.) But then again, it can still *help*, and while it sounds
> cheesy, *how much* it can help depends entirely on the attitude of the
> contributors; whether they see themselves as solo authors listed on a
> package index, or as part of a bigger effort. I’m not really a fan of
> waiting for Apple to save the day. One of the things I’ve argued for that
> *can* be done without Apple’s help is setting up another Swift library
> incubator like Breeze. Obviously it won’t magically lead to a Swift math
> library but it does remove some of the obstacles I mentioned earlier:
>
> - it links together disparate solo projects and provides discoverability
> to users
> - it provides a package index and serves as a dashboard to check up on the
> “state of Swift library support”
> - it gives a venue for interested people to discuss the general topic of
> library support
> - it helps network people who are working on similar things (a “soft
> factor” but important!)
>
> tldr; self-organization isn’t a panacea, but it helps.
>
> On Wed, Aug 2, 2017 at 10:14 PM, Xiaodi Wu  wrote:
>
>> That's not what I'm saying at all. I'm responding to your contention that
>> no library without "backing" will see wide adoption: if, as you say, you
>> would like to have a math library with sufficient "backing," then realize
>> that you're arguing for someone to devote financial resources to the
>> problem. Your proposed solution of getting together a bunch of unpaid
>> people does not address your identified problem.
>>
>> On Wed, Aug 2, 2017 at 21:07 Taylor Swift  wrote:
>>
>>>
>>>
>>> On Wed, Aug 2, 2017 at 9:18 PM, Xiaodi Wu  wrote:
>>>
 On Wed, Aug 2, 2017 at 7:29 PM, Taylor Swift 
 wrote:

>
>
> On Wed, Aug 2, 2017 at 7:54 PM, Xiaodi Wu  wrote:
>
>> On Wed, Aug 2, 2017 at 6:29 PM, Taylor Swift 
>> wrote:
>>
>>> See, my problem with statements like this one, is that the answer
>>> “should be supported as a third-party library” can also be interpreted 
>>> as
>>> “not my problem, go figure it out yourselves”. The idea that central 
>>> entity
>>> can only pay attention to what they want to, and the Community™ will
>>> magically take care of the rest is one of the most pervasive, and 
>>> untrue,
>>> myths about open source. What’s worse, is that Swift has the benefit of
>>> hindsight, in the form of many, many examples of languages that came 
>>> before
>>> and fell victim to this fallacy, and now have 15 competing “private”
>>> classes for basic mathematical objects like *vectors*.
>>>
>>> I agree that a core math library, for example, *could* in theory be
>>> supported as a third-party library.
>>>
>>
>> The core team has said that they're open to a core math library being
>> part of the Swift open source project; they just outlined that the
>> _process_ for doing so is best initiated with a third-party library as a
>> starting point.
>>
>>
>>> But this will never happen on its own, for reasons that I will
>>> reiterate here:
>>>
>>> - no one influential enough has bothered to jump start any such
>>> project
>>>
>>
>> Karoly Lorentey has a wonderful, and quite mature, BigInt project: <
>> https://github.com/lorentey/BigInt>. Also, as I mentioned, I just
>> started a project for protocol-based additions to Swift's basic numeric
>> types. These are just two examples.
>>
>>
>>> - there are no avenues to encourage members of the community to come
>>> together and organize a project (look how this thread got derailed!)
>>>
>>
>> You're welcome to join me in my endeavor to create a math library.
>> I'd bet Karoly feels the same way about his project.
>>
>
> You don’t know how happy reading that sentence just made me, i’d
> assumed no one was willing to team up to build such a thing. In which 
> case,
> it’s a good idea to start an incubator organization on Github. I think
> David Turnbull tried doing that 2 years ago, I’ll reach out to him if he
> wants to be a part of something like this.
>
> We should also maintain an index of promising pure swift libraries so
> they are discoverable (like docs.rs does for Rust).
>

 I 

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Xiaodi Wu via swift-evolution]

That's not what I'm saying at all. I'm responding to your contention that
no library without "backing" will see wide adoption: if, as you say, you
would like to have a math library with sufficient "backing," then realize
that you're arguing for someone to devote financial resources to the
problem. Your proposed solution of getting together a bunch of unpaid
people does not address your identified problem.
On Wed, Aug 2, 2017 at 21:07 Taylor Swift  wrote:

>
>
> On Wed, Aug 2, 2017 at 9:18 PM, Xiaodi Wu  wrote:
>
>> On Wed, Aug 2, 2017 at 7:29 PM, Taylor Swift 
>> wrote:
>>
>>>
>>>
>>> On Wed, Aug 2, 2017 at 7:54 PM, Xiaodi Wu  wrote:
>>>
 On Wed, Aug 2, 2017 at 6:29 PM, Taylor Swift 
 wrote:

> See, my problem with statements like this one, is that the answer
> “should be supported as a third-party library” can also be interpreted as
> “not my problem, go figure it out yourselves”. The idea that central 
> entity
> can only pay attention to what they want to, and the Community™ will
> magically take care of the rest is one of the most pervasive, and untrue,
> myths about open source. What’s worse, is that Swift has the benefit of
> hindsight, in the form of many, many examples of languages that came 
> before
> and fell victim to this fallacy, and now have 15 competing “private”
> classes for basic mathematical objects like *vectors*.
>
> I agree that a core math library, for example, *could* in theory be
> supported as a third-party library.
>

 The core team has said that they're open to a core math library being
 part of the Swift open source project; they just outlined that the
 _process_ for doing so is best initiated with a third-party library as a
 starting point.


> But this will never happen on its own, for reasons that I will
> reiterate here:
>
> - no one influential enough has bothered to jump start any such
> project
>

 Karoly Lorentey has a wonderful, and quite mature, BigInt project: <
 https://github.com/lorentey/BigInt>. Also, as I mentioned, I just
 started a project for protocol-based additions to Swift's basic numeric
 types. These are just two examples.


> - there are no avenues to encourage members of the community to come
> together and organize a project (look how this thread got derailed!)
>

 You're welcome to join me in my endeavor to create a math library. I'd
 bet Karoly feels the same way about his project.

>>>
>>> You don’t know how happy reading that sentence just made me, i’d assumed
>>> no one was willing to team up to build such a thing. In which case, it’s a
>>> good idea to start an incubator organization on Github. I think David
>>> Turnbull tried doing that 2 years ago, I’ll reach out to him if he wants to
>>> be a part of something like this.
>>>
>>> We should also maintain an index of promising pure swift libraries so
>>> they are discoverable (like docs.rs does for Rust).
>>>
>>
>> I believe there has been mention on this list that the core team would
>> like to revisit this idea at some point.
>>
>>
>>>

> - there is no “soft” infrastructure in place to support such
> collaboration (look at the fuss over discourse and mailing list spam!)
>

 The GitHub environment has excellent tools to support such
 collaboration, IMO. For example:

 Based on my experience implementing a library, I wrote a Gist to
 outline some lessons learned and suggestions for improvement. Not only did
 the document find an audience, these suggestions were in turn used to
 inform core team-driven revisions to the integer protocols. As a result of
 these revisions, it became possible to implement some initializers that
 could be useful for people writing generic numeric algorithms. Recently, I
 submitted a PR to the Swift project on GitHub to implement these
 initializers. Now, everyone will be able to use them. Collaboration,
 positive feedback loop, win-win for all involved.

 Likewise, Karoly used his experience updating BigInt for Swift 4 to
 inform certain improvements to the integer protocols. He implemented these
 improvements in a series of PRs. Now, as a result of these developments,
 Karoly's library will be better designed *and* everyone else will benefit
 from a better implementation of the integer protocols. Again,
 collaboration, positive feedback loop, win-win for all involved.

>>>
>>> Great!! can you link me to the gist?
>>>
>>
>> https://gist.github.com/xwu/d68baefaae9e9291d2e65bd12ad51be2
>>
>>
 - there are no positive feedback loops whereby a promising project can
> gain market share and mature
> - because there is no organization backing these projects, potential
> users 

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Taylor Swift via swift-evolution]

On Wed, Aug 2, 2017 at 9:18 PM, Xiaodi Wu  wrote:

> On Wed, Aug 2, 2017 at 7:29 PM, Taylor Swift  wrote:
>
>>
>>
>> On Wed, Aug 2, 2017 at 7:54 PM, Xiaodi Wu  wrote:
>>
>>> On Wed, Aug 2, 2017 at 6:29 PM, Taylor Swift 
>>> wrote:
>>>
 See, my problem with statements like this one, is that the answer
 “should be supported as a third-party library” can also be interpreted as
 “not my problem, go figure it out yourselves”. The idea that central entity
 can only pay attention to what they want to, and the Community™ will
 magically take care of the rest is one of the most pervasive, and untrue,
 myths about open source. What’s worse, is that Swift has the benefit of
 hindsight, in the form of many, many examples of languages that came before
 and fell victim to this fallacy, and now have 15 competing “private”
 classes for basic mathematical objects like *vectors*.

 I agree that a core math library, for example, *could* in theory be
 supported as a third-party library.

>>>
>>> The core team has said that they're open to a core math library being
>>> part of the Swift open source project; they just outlined that the
>>> _process_ for doing so is best initiated with a third-party library as a
>>> starting point.
>>>
>>>
 But this will never happen on its own, for reasons that I will
 reiterate here:

 - no one influential enough has bothered to jump start any such project

>>>
>>> Karoly Lorentey has a wonderful, and quite mature, BigInt project: <
>>> https://github.com/lorentey/BigInt>. Also, as I mentioned, I just
>>> started a project for protocol-based additions to Swift's basic numeric
>>> types. These are just two examples.
>>>
>>>
 - there are no avenues to encourage members of the community to come
 together and organize a project (look how this thread got derailed!)

>>>
>>> You're welcome to join me in my endeavor to create a math library. I'd
>>> bet Karoly feels the same way about his project.
>>>
>>
>> You don’t know how happy reading that sentence just made me, i’d assumed
>> no one was willing to team up to build such a thing. In which case, it’s a
>> good idea to start an incubator organization on Github. I think David
>> Turnbull tried doing that 2 years ago, I’ll reach out to him if he wants to
>> be a part of something like this.
>>
>> We should also maintain an index of promising pure swift libraries so
>> they are discoverable (like docs.rs does for Rust).
>>
>
> I believe there has been mention on this list that the core team would
> like to revisit this idea at some point.
>
>
>>
>>>
 - there is no “soft” infrastructure in place to support such
 collaboration (look at the fuss over discourse and mailing list spam!)

>>>
>>> The GitHub environment has excellent tools to support such
>>> collaboration, IMO. For example:
>>>
>>> Based on my experience implementing a library, I wrote a Gist to outline
>>> some lessons learned and suggestions for improvement. Not only did the
>>> document find an audience, these suggestions were in turn used to inform
>>> core team-driven revisions to the integer protocols. As a result of these
>>> revisions, it became possible to implement some initializers that could be
>>> useful for people writing generic numeric algorithms. Recently, I submitted
>>> a PR to the Swift project on GitHub to implement these initializers. Now,
>>> everyone will be able to use them. Collaboration, positive feedback loop,
>>> win-win for all involved.
>>>
>>> Likewise, Karoly used his experience updating BigInt for Swift 4 to
>>> inform certain improvements to the integer protocols. He implemented these
>>> improvements in a series of PRs. Now, as a result of these developments,
>>> Karoly's library will be better designed *and* everyone else will benefit
>>> from a better implementation of the integer protocols. Again,
>>> collaboration, positive feedback loop, win-win for all involved.
>>>
>>
>> Great!! can you link me to the gist?
>>
>
> https://gist.github.com/xwu/d68baefaae9e9291d2e65bd12ad51be2
>
>
>>> - there are no positive feedback loops whereby a promising project can
 gain market share and mature
 - because there is no organization backing these projects, potential
 users are reluctant to depend on these libraries, since they will logically
 bet that the library is more likely to fall out of maintenance than reach
 maturity.

>>>
>>> Addressing this point is clearly impossible. When Apple wishes to commit
>>> its own resources to the maintenance of a Swift math library,
>>> swift-corelibs-math will appear on GitHub. Suggestions such as opening an
>>> empty repo and letting people contribute to it would either give the
>>> illusion of organizational backing that doesn't exist or would in fact
>>> commit Apple to support a repo that it doesn't wish to support. I 

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Xiaodi Wu via swift-evolution]

On Wed, Aug 2, 2017 at 7:29 PM, Taylor Swift  wrote:

>
>
> On Wed, Aug 2, 2017 at 7:54 PM, Xiaodi Wu  wrote:
>
>> On Wed, Aug 2, 2017 at 6:29 PM, Taylor Swift 
>> wrote:
>>
>>> See, my problem with statements like this one, is that the answer
>>> “should be supported as a third-party library” can also be interpreted as
>>> “not my problem, go figure it out yourselves”. The idea that central entity
>>> can only pay attention to what they want to, and the Community™ will
>>> magically take care of the rest is one of the most pervasive, and untrue,
>>> myths about open source. What’s worse, is that Swift has the benefit of
>>> hindsight, in the form of many, many examples of languages that came before
>>> and fell victim to this fallacy, and now have 15 competing “private”
>>> classes for basic mathematical objects like *vectors*.
>>>
>>> I agree that a core math library, for example, *could* in theory be
>>> supported as a third-party library.
>>>
>>
>> The core team has said that they're open to a core math library being
>> part of the Swift open source project; they just outlined that the
>> _process_ for doing so is best initiated with a third-party library as a
>> starting point.
>>
>>
>>> But this will never happen on its own, for reasons that I will reiterate
>>> here:
>>>
>>> - no one influential enough has bothered to jump start any such project
>>>
>>
>> Karoly Lorentey has a wonderful, and quite mature, BigInt project: <
>> https://github.com/lorentey/BigInt>. Also, as I mentioned, I just
>> started a project for protocol-based additions to Swift's basic numeric
>> types. These are just two examples.
>>
>>
>>> - there are no avenues to encourage members of the community to come
>>> together and organize a project (look how this thread got derailed!)
>>>
>>
>> You're welcome to join me in my endeavor to create a math library. I'd
>> bet Karoly feels the same way about his project.
>>
>
> You don’t know how happy reading that sentence just made me, i’d assumed
> no one was willing to team up to build such a thing. In which case, it’s a
> good idea to start an incubator organization on Github. I think David
> Turnbull tried doing that 2 years ago, I’ll reach out to him if he wants to
> be a part of something like this.
>
> We should also maintain an index of promising pure swift libraries so they
> are discoverable (like docs.rs does for Rust).
>

I believe there has been mention on this list that the core team would like
to revisit this idea at some point.


>
>>
>>> - there is no “soft” infrastructure in place to support such
>>> collaboration (look at the fuss over discourse and mailing list spam!)
>>>
>>
>> The GitHub environment has excellent tools to support such collaboration,
>> IMO. For example:
>>
>> Based on my experience implementing a library, I wrote a Gist to outline
>> some lessons learned and suggestions for improvement. Not only did the
>> document find an audience, these suggestions were in turn used to inform
>> core team-driven revisions to the integer protocols. As a result of these
>> revisions, it became possible to implement some initializers that could be
>> useful for people writing generic numeric algorithms. Recently, I submitted
>> a PR to the Swift project on GitHub to implement these initializers. Now,
>> everyone will be able to use them. Collaboration, positive feedback loop,
>> win-win for all involved.
>>
>> Likewise, Karoly used his experience updating BigInt for Swift 4 to
>> inform certain improvements to the integer protocols. He implemented these
>> improvements in a series of PRs. Now, as a result of these developments,
>> Karoly's library will be better designed *and* everyone else will benefit
>> from a better implementation of the integer protocols. Again,
>> collaboration, positive feedback loop, win-win for all involved.
>>
>
> Great!! can you link me to the gist?
>

https://gist.github.com/xwu/d68baefaae9e9291d2e65bd12ad51be2


>> - there are no positive feedback loops whereby a promising project can
>>> gain market share and mature
>>> - because there is no organization backing these projects, potential
>>> users are reluctant to depend on these libraries, since they will logically
>>> bet that the library is more likely to fall out of maintenance than reach
>>> maturity.
>>>
>>
>> Addressing this point is clearly impossible. When Apple wishes to commit
>> its own resources to the maintenance of a Swift math library,
>> swift-corelibs-math will appear on GitHub. Suggestions such as opening an
>> empty repo and letting people contribute to it would either give the
>> illusion of organizational backing that doesn't exist or would in fact
>> commit Apple to support a repo that it doesn't wish to support. I fail to
>> see why the former is good for anybody; in fact, it's strictly inferior to
>> the same repo honestly representing itself as a third-party effort. And
>> asking for the latter 

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[David Sweeris via swift-evolution]

> On Aug 2, 2017, at 4:29 PM, Nicolas Fezans  wrote:
> 
> Your notation is indeed correct, even though using x on both side might 
> confuse some people, this is correct. But no I would not go that far,

I would, just not right now. There are more important issues to the larger 
community that need to be addressed before we (it might just be me ) can start 
worrying about how to turn the equations from a math textbook into value swift 
code.

- Dave Sweeris 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[David Sweeris via swift-evolution]

> On Aug 2, 2017, at 4:29 PM, Xiaodi Wu  wrote:
> 
>> On Wed, Aug 2, 2017 at 6:17 PM, David Sweeris  wrote:
>> 
>> 
>> 
>> Sent from my iPad
>> On Aug 2, 2017, at 3:43 PM, Xiaodi Wu via swift-evolution 
>>  wrote:
>> 
>>> 
 On Wed, Aug 2, 2017 at 17:37 Nicolas Fezans  
 wrote:
 I think that the items mentioned earlier in the list (just reminded below) 
 should not all be treated equally.
 
 - RNG and cryptography library (CryptoSwift could be a good base for this)
 - Generic Math library/Vector library
 - Basic data structures (Tree, Balanced Tree, Heap, Queue, SkipList, 
 graphs, etc)
 - Modern DateTime library
 - Modern String processing toolkit
 - 2D Graphics library (similar to cairo)
 - Windowing/UI library
 
 By that I mean that I see at least one distinction to make between:
 
 a) the libraries that would make Swift and the programmer experience with 
 these libraries under Swift significantly better if they are (or at least 
 feel) deeply integrated in the language (for instance with associated 
 syntax / syntax sugar)
 and 
 b) those that would not really benefit from such an integration to the 
 language.
 
 For me a core math library, clearly belongs to category a)
 I am of course not talking about a syntax sugar to call a sin or cos 
 function, but rather to manipulate other objects such as N-dimensional 
 matrices, defining maths functions that can take such matrices as argument 
 e.g. sin(A) with A as matrix produces a matrix of the same size where all 
 elements are the sinus values of the elements of A (sorry but things like 
 this calling map() with 'sin' looks quite ugly for scientists).
 Such a good math syntax should be compact enough to have complete 
 equations looking "close enough" to the maths equations you could have 
 written in a LaTeX or Word documentation of your scientific code. IMO a 
 well integrated swift core math library should feel a Julia or Matlab code 
 (while still having the power of Swift in terms of speed and modern 
 programming paradigms) instead of looking and feeling like 'numpy'. But 
 the latter is what you get if you just make a math library with no 
 integration to the language syntax, operators, and basic functions.
>>> 
>>> I agree that if this would require compiler support, then it needs to be 
>>> part of the standard library. However, I don't see anything about what you 
>>> describe that cannot be supported as a third-party library.
>> 
>> Getting the syntax right could possibly require some compiler changes. 
>> Maybe. Depends on what "right" means. Declaring a variable, x, to be "the 
>> set of all real numbers such that x*sin(x) is an integer" using syntax like 
>> this, "let x = {x ∈ ℝ | x * sin(x) ∈ ℕ}", would be neat (I'm a bit hazy on 
>> my set notation... that might not actually be correct).
>> We're actually not that far off from that, compiler-wise, I mean. Aside 
>> defining the relevant types, operators, and identifiers, that exact syntax 
>> pretty much just requires the compiler to allow using a certain types of 
>> variables in their own declaration and either one heck of an 
>> `ExpressibleByClosureLiteral` protocol, or improvements to the type 
>> inference engine.
> 
> We must prioritize features that make the biggest impact for the general 
> community, however. Swift still lacks ABI stability, ownership, concurrency, 
> etc. In terms of math facilities, we still don't have a model for dealing 
> with floating point errors. And, yes, there are improvements to be made in 
> terms of having consistent special functions (sin, cos) in Swift (Glibc and 
> Darwin don't always give you the same answer). All of these things represent 
> sorely needed yet large undertakings; none of these require more syntax.

Oh, I know. I wasn't claiming that we need massive compiler changes right now 
or anything, just providing an example of a syntax that a hypothetical 
"CoreMath" type of library might want to support which can't currently be made 
into legal swift code. 

- Dave Sweeris ___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Nicolas Fezans via swift-evolution]

Your notation is indeed correct, even though using x on both side might
confuse some people, this is correct. But no I would not go that far, but I
think the example I just replied before which should execute also on
octave/scilab (most people in the list probably do not have a matlab
license) should show how compact this syntax is.
I often need to rewrite in C or C++ algorithms that were developed and
validated first on Matlab and it occurs very frequently that the lack of
appropriated syntax (even when using libraries with a lot of functions)
makes the code extremely longer and very much less readable for me. Of
course, each line of C/C++ is simple to understand because in such cases
they do not do much things, but you rapidly get several levels of embedded
loops to do what was written in one or two lines of Matlab code, and in the
end you often do not see the main idea anymore or it is much harder to see
it.

On Thu, Aug 3, 2017 at 1:17 AM, David Sweeris  wrote:

>
>
>
> Sent from my iPad
> On Aug 2, 2017, at 3:43 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Wed, Aug 2, 2017 at 17:37 Nicolas Fezans 
> wrote:
>
>> I think that the items mentioned earlier in the list (just reminded
>> below) should not all be treated equally.
>>
>> - RNG and cryptography library (CryptoSwift could be a good base for this)
>> - Generic Math library/Vector library
>> - Basic data structures (Tree, Balanced Tree, Heap, Queue, SkipList,
>> graphs, etc)
>> - Modern DateTime library
>> - Modern String processing toolkit
>> - 2D Graphics library (similar to cairo)
>> - Windowing/UI library
>>
>> By that I mean that I see at least one distinction to make between:
>>
>> a) the libraries that would make Swift and the programmer experience with
>> these libraries under Swift significantly better if they are (or at least
>> feel) deeply integrated in the language (for instance with associated syntax
>> / syntax sugar)
>> and
>> b) those that would not really benefit from such an integration to the
>> language.
>>
>> For me a core math library, clearly belongs to category a)
>> I am of course not talking about a syntax sugar to call a sin or cos
>> function, but rather to manipulate other objects such as N-dimensional
>> matrices, defining maths functions that can take such matrices as argument
>> e.g. sin(A) with A as matrix produces a matrix of the same size where all
>> elements are the sinus values of the elements of A (sorry but things like
>> this calling map() with 'sin' looks quite ugly for scientists).
>> Such a good math syntax should be compact enough to have complete
>> equations looking "close enough" to the maths equations you could have
>> written in a LaTeX or Word documentation of your scientific code. IMO a
>> well integrated swift core math library should feel a Julia or Matlab code
>> (while still having the power of Swift in terms of speed and modern
>> programming paradigms) instead of looking and feeling like 'numpy'. But the
>> latter is what you get if you just make a math library with no integration
>> to the language syntax, operators, and basic functions.
>>
>
> I agree that if this would require compiler support, then it needs to be
> part of the standard library. However, I don't see anything about what you
> describe that cannot be supported as a third-party library.
>
>
> Getting the syntax right could possibly require some compiler changes.
> Maybe. Depends on what "right" means. Declaring a variable, x, to be "the
> set of all real numbers such that x*sin(x) is an integer" using syntax like
> this, "let x = {x ∈ ℝ | x * sin(x) ∈ ℕ}", would be neat (I'm a bit hazy
> on my set notation... that might not actually be correct).
> We're actually not that far off from that, compiler-wise, I mean. Aside
> defining the relevant types, operators, and identifiers, that exact syntax
> pretty much just requires the compiler to allow using a certain types of
> variables in their own declaration and either one heck of an
> `ExpressibleByClosureLiteral` protocol, or improvements to the type
> inference engine.
>
> - Dave Sweeris
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Xiaodi Wu via swift-evolution]

On Wed, Aug 2, 2017 at 6:17 PM, David Sweeris  wrote:

>
>
>
> Sent from my iPad
> On Aug 2, 2017, at 3:43 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Wed, Aug 2, 2017 at 17:37 Nicolas Fezans 
> wrote:
>
>> I think that the items mentioned earlier in the list (just reminded
>> below) should not all be treated equally.
>>
>> - RNG and cryptography library (CryptoSwift could be a good base for this)
>> - Generic Math library/Vector library
>> - Basic data structures (Tree, Balanced Tree, Heap, Queue, SkipList,
>> graphs, etc)
>> - Modern DateTime library
>> - Modern String processing toolkit
>> - 2D Graphics library (similar to cairo)
>> - Windowing/UI library
>>
>> By that I mean that I see at least one distinction to make between:
>>
>> a) the libraries that would make Swift and the programmer experience with
>> these libraries under Swift significantly better if they are (or at least
>> feel) deeply integrated in the language (for instance with associated syntax
>> / syntax sugar)
>> and
>> b) those that would not really benefit from such an integration to the
>> language.
>>
>> For me a core math library, clearly belongs to category a)
>> I am of course not talking about a syntax sugar to call a sin or cos
>> function, but rather to manipulate other objects such as N-dimensional
>> matrices, defining maths functions that can take such matrices as argument
>> e.g. sin(A) with A as matrix produces a matrix of the same size where all
>> elements are the sinus values of the elements of A (sorry but things like
>> this calling map() with 'sin' looks quite ugly for scientists).
>> Such a good math syntax should be compact enough to have complete
>> equations looking "close enough" to the maths equations you could have
>> written in a LaTeX or Word documentation of your scientific code. IMO a
>> well integrated swift core math library should feel a Julia or Matlab code
>> (while still having the power of Swift in terms of speed and modern
>> programming paradigms) instead of looking and feeling like 'numpy'. But the
>> latter is what you get if you just make a math library with no integration
>> to the language syntax, operators, and basic functions.
>>
>
> I agree that if this would require compiler support, then it needs to be
> part of the standard library. However, I don't see anything about what you
> describe that cannot be supported as a third-party library.
>
>
> Getting the syntax right could possibly require some compiler changes.
> Maybe. Depends on what "right" means. Declaring a variable, x, to be "the
> set of all real numbers such that x*sin(x) is an integer" using syntax like
> this, "let x = {x ∈ ℝ | x * sin(x) ∈ ℕ}", would be neat (I'm a bit hazy
> on my set notation... that might not actually be correct).
> We're actually not that far off from that, compiler-wise, I mean. Aside
> defining the relevant types, operators, and identifiers, that exact syntax
> pretty much just requires the compiler to allow using a certain types of
> variables in their own declaration and either one heck of an
> `ExpressibleByClosureLiteral` protocol, or improvements to the type
> inference engine.
>

We must prioritize features that make the biggest impact for the general
community, however. Swift still lacks ABI stability, ownership,
concurrency, etc. In terms of math facilities, we still don't have a model
for dealing with floating point errors. And, yes, there are improvements to
be made in terms of having consistent special functions (sin, cos) in Swift
(Glibc and Darwin don't always give you the same answer). All of these
things represent sorely needed yet large undertakings; none of these
require more syntax.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Taylor Swift via swift-evolution]

See, my problem with statements like this one, is that the answer “should
be supported as a third-party library” can also be interpreted as “not my
problem, go figure it out yourselves”. The idea that central entity can
only pay attention to what they want to, and the Community™ will magically
take care of the rest is one of the most pervasive, and untrue, myths about
open source. What’s worse, is that Swift has the benefit of hindsight, in
the form of many, many examples of languages that came before and fell
victim to this fallacy, and now have 15 competing “private” classes for
basic mathematical objects like *vectors*.

I agree that a core math library, for example, *could* in theory be
supported as a third-party library. But this will never happen on its own,
for reasons that I will reiterate here:

- no one influential enough has bothered to jump start any such project
- there are no avenues to encourage members of the community to come
together and organize a project (look how this thread got derailed!)
- there is no “soft” infrastructure in place to support such collaboration
(look at the fuss over discourse and mailing list spam!)
- there are no positive feedback loops whereby a promising project can gain
market share and mature
- because there is no organization backing these projects, potential users
are reluctant to depend on these libraries, since they will logically bet
that the library is more likely to fall out of maintenance than reach
maturity.
- everyone works on their own in-house “half-assed” implementation, and
people are not encouraged to come together and pool resources so instead
there is a lot of duplicated work

On Wed, Aug 2, 2017 at 6:42 PM, Xiaodi Wu  wrote:

>
> I agree that if this would require compiler support, then it needs to be
> part of the standard library. However, I don't see anything about what you
> describe that cannot be supported as a third-party library.
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[David Sweeris via swift-evolution]

Sent from my iPad
> On Aug 2, 2017, at 3:43 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> 
>> On Wed, Aug 2, 2017 at 17:37 Nicolas Fezans  wrote:
>> I think that the items mentioned earlier in the list (just reminded below) 
>> should not all be treated equally.
>> 
>> - RNG and cryptography library (CryptoSwift could be a good base for this)
>> - Generic Math library/Vector library
>> - Basic data structures (Tree, Balanced Tree, Heap, Queue, SkipList, graphs, 
>> etc)
>> - Modern DateTime library
>> - Modern String processing toolkit
>> - 2D Graphics library (similar to cairo)
>> - Windowing/UI library
>> 
>> By that I mean that I see at least one distinction to make between:
>> 
>> a) the libraries that would make Swift and the programmer experience with 
>> these libraries under Swift significantly better if they are (or at least 
>> feel) deeply integrated in the language (for instance with associated syntax 
>> / syntax sugar)
>> and 
>> b) those that would not really benefit from such an integration to the 
>> language.
>> 
>> For me a core math library, clearly belongs to category a)
>> I am of course not talking about a syntax sugar to call a sin or cos 
>> function, but rather to manipulate other objects such as N-dimensional 
>> matrices, defining maths functions that can take such matrices as argument 
>> e.g. sin(A) with A as matrix produces a matrix of the same size where all 
>> elements are the sinus values of the elements of A (sorry but things like 
>> this calling map() with 'sin' looks quite ugly for scientists).
>> Such a good math syntax should be compact enough to have complete equations 
>> looking "close enough" to the maths equations you could have written in a 
>> LaTeX or Word documentation of your scientific code. IMO a well integrated 
>> swift core math library should feel a Julia or Matlab code (while still 
>> having the power of Swift in terms of speed and modern programming 
>> paradigms) instead of looking and feeling like 'numpy'. But the latter is 
>> what you get if you just make a math library with no integration to the 
>> language syntax, operators, and basic functions.
> 
> I agree that if this would require compiler support, then it needs to be part 
> of the standard library. However, I don't see anything about what you 
> describe that cannot be supported as a third-party library.

Getting the syntax right could possibly require some compiler changes. Maybe. 
Depends on what "right" means. Declaring a variable, x, to be "the set of all 
real numbers such that x*sin(x) is an integer" using syntax like this, "let x = 
{x ∈ ℝ | x * sin(x) ∈ ℕ}", would be neat (I'm a bit hazy on my set notation... 
that might not actually be correct).
We're actually not that far off from that, compiler-wise, I mean. Aside 
defining the relevant types, operators, and identifiers, that exact syntax 
pretty much just requires the compiler to allow using a certain types of 
variables in their own declaration and either one heck of an 
`ExpressibleByClosureLiteral` protocol, or improvements to the type inference 
engine.

- Dave Sweeris___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Karl Wagner via swift-evolution]

> On 3. Aug 2017, at 00:43, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> 
> On Wed, Aug 2, 2017 at 17:37 Nicolas Fezans  > wrote:
> I think that the items mentioned earlier in the list (just reminded below) 
> should not all be treated equally.
> 
> - RNG and cryptography library (CryptoSwift could be a good base for this)
> - Generic Math library/Vector library
> - Basic data structures (Tree, Balanced Tree, Heap, Queue, SkipList, graphs, 
> etc)
> - Modern DateTime library
> - Modern String processing toolkit
> - 2D Graphics library (similar to cairo)
> - Windowing/UI library
> 
> By that I mean that I see at least one distinction to make between:
> 
> a) the libraries that would make Swift and the programmer experience with 
> these libraries under Swift significantly better if they are (or at least 
> feel) deeply integrated in the language (for instance with associated syntax 
> / syntax sugar)
> and 
> b) those that would not really benefit from such an integration to the 
> language.
> 
> For me a core math library, clearly belongs to category a)
> I am of course not talking about a syntax sugar to call a sin or cos 
> function, but rather to manipulate other objects such as N-dimensional 
> matrices, defining maths functions that can take such matrices as argument 
> e.g. sin(A) with A as matrix produces a matrix of the same size where all 
> elements are the sinus values of the elements of A (sorry but things like 
> this calling map() with 'sin' looks quite ugly for scientists).
> Such a good math syntax should be compact enough to have complete equations 
> looking "close enough" to the maths equations you could have written in a 
> LaTeX or Word documentation of your scientific code. IMO a well integrated 
> swift core math library should feel a Julia or Matlab code (while still 
> having the power of Swift in terms of speed and modern programming paradigms) 
> instead of looking and feeling like 'numpy'. But the latter is what you get 
> if you just make a math library with no integration to the language syntax, 
> operators, and basic functions.
> 
> I agree that if this would require compiler support, then it needs to be part 
> of the standard library. However, I don't see anything about what you 
> describe that cannot be supported as a third-party library.

It’s important to remember that computers are mathematical machines, and some 
functions which are implemented in hardware on essentially every platform (like 
sin/cos/etc) are definitely best implemented as compiler intrinsics.

That said, I don’t think N-dimensional matrices need to be part of the standard 
library. I still think there’s plenty of space for good library 
implementations. We can’t realistically expect anybody to implement a (fast) 
cosine function from scratch, though.

I think Swift should allow you to write a standard scientific calculator 
without downloading a mathematics library. Essentially, that means basic trig, 
exponentiation and logarithms. Possibly even factorials.

- Karl

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Xiaodi Wu via swift-evolution]

On Wed, Aug 2, 2017 at 17:37 Nicolas Fezans 
wrote:

> I think that the items mentioned earlier in the list (just reminded below)
> should not all be treated equally.
>
> - RNG and cryptography library (CryptoSwift could be a good base for this)
> - Generic Math library/Vector library
> - Basic data structures (Tree, Balanced Tree, Heap, Queue, SkipList,
> graphs, etc)
> - Modern DateTime library
> - Modern String processing toolkit
> - 2D Graphics library (similar to cairo)
> - Windowing/UI library
>
> By that I mean that I see at least one distinction to make between:
>
> a) the libraries that would make Swift and the programmer experience with
> these libraries under Swift significantly better if they are (or at least
> feel) deeply integrated in the language (for instance with associated syntax
> / syntax sugar)
> and
> b) those that would not really benefit from such an integration to the
> language.
>
> For me a core math library, clearly belongs to category a)
> I am of course not talking about a syntax sugar to call a sin or cos
> function, but rather to manipulate other objects such as N-dimensional
> matrices, defining maths functions that can take such matrices as argument
> e.g. sin(A) with A as matrix produces a matrix of the same size where all
> elements are the sinus values of the elements of A (sorry but things like
> this calling map() with 'sin' looks quite ugly for scientists).
> Such a good math syntax should be compact enough to have complete
> equations looking "close enough" to the maths equations you could have
> written in a LaTeX or Word documentation of your scientific code. IMO a
> well integrated swift core math library should feel a Julia or Matlab code
> (while still having the power of Swift in terms of speed and modern
> programming paradigms) instead of looking and feeling like 'numpy'. But the
> latter is what you get if you just make a math library with no integration
> to the language syntax, operators, and basic functions.
>

I agree that if this would require compiler support, then it needs to be
part of the standard library. However, I don't see anything about what you
describe that cannot be supported as a third-party library.


>
> I would personally place a crypto library in category b).
>
>
> For basic data structures, I would say probably something in between:
> maybe a few data structures are worth having a nicer syntax that typical
> method calls (just as [] are used for arrays and it looks and feels great)
> but it would be pointless IMHO to try extending that to too many of these
> data structures.
>
>
>
>
>
> On Wed, Aug 2, 2017 at 11:08 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>>
>> On Wed, Aug 2, 2017 at 12:23 PM, Taylor Swift 
>> wrote:
>>
>>>
>>>
>>> On Wed, Aug 2, 2017 at 12:45 PM, Gor Gyolchanyan <
>>> gor.f.gyolchan...@icloud.com> wrote:
>>>

 On Aug 2, 2017, at 4:35 AM, Xiaodi Wu via swift-evolution <
 swift-evolution@swift.org> wrote:

 On Tue, Aug 1, 2017 at 7:38 PM, Taylor Swift 
 wrote:

>
>
> On Tue, Aug 1, 2017 at 5:50 PM, Xiaodi Wu  wrote:
>
>>
>> On Tue, Aug 1, 2017 at 13:00 Taylor Swift via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> On Tue, Aug 1, 2017 at 1:51 PM, Michael Ilseman via swift-evolution
>>>  wrote:
>>>


 On Aug 1, 2017, at 10:44 AM, Tino Heth via swift-evolution <
 swift-evolution@swift.org> 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.


 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

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Nicolas Fezans via swift-evolution]

I think that the items mentioned earlier in the list (just reminded below)
should not all be treated equally.

- RNG and cryptography library (CryptoSwift could be a good base for this)
- Generic Math library/Vector library
- Basic data structures (Tree, Balanced Tree, Heap, Queue, SkipList,
graphs, etc)
- Modern DateTime library
- Modern String processing toolkit
- 2D Graphics library (similar to cairo)
- Windowing/UI library

By that I mean that I see at least one distinction to make between:

a) the libraries that would make Swift and the programmer experience with
these libraries under Swift significantly better if they are (or at least
feel) deeply integrated in the language (for instance with associated syntax
/ syntax sugar)
and
b) those that would not really benefit from such an integration to the
language.

For me a core math library, clearly belongs to category a)
I am of course not talking about a syntax sugar to call a sin or cos
function, but rather to manipulate other objects such as N-dimensional
matrices, defining maths functions that can take such matrices as argument
e.g. sin(A) with A as matrix produces a matrix of the same size where all
elements are the sinus values of the elements of A (sorry but things like
this calling map() with 'sin' looks quite ugly for scientists).
Such a good math syntax should be compact enough to have complete equations
looking "close enough" to the maths equations you could have written in a
LaTeX or Word documentation of your scientific code. IMO a well integrated
swift core math library should feel a Julia or Matlab code (while still
having the power of Swift in terms of speed and modern programming
paradigms) instead of looking and feeling like 'numpy'. But the latter is
what you get if you just make a math library with no integration to the
language syntax, operators, and basic functions.


I would personally place a crypto library in category b).


For basic data structures, I would say probably something in between: maybe
a few data structures are worth having a nicer syntax that typical method
calls (just as [] are used for arrays and it looks and feels great) but it
would be pointless IMHO to try extending that to too many of these data
structures.





On Wed, Aug 2, 2017 at 11:08 PM, Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
> On Wed, Aug 2, 2017 at 12:23 PM, Taylor Swift 
> wrote:
>
>>
>>
>> On Wed, Aug 2, 2017 at 12:45 PM, Gor Gyolchanyan <
>> gor.f.gyolchan...@icloud.com> wrote:
>>
>>>
>>> On Aug 2, 2017, at 4:35 AM, Xiaodi Wu via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>> On Tue, Aug 1, 2017 at 7:38 PM, Taylor Swift  w
>>> rote:
>>>


 On Tue, Aug 1, 2017 at 5:50 PM, Xiaodi Wu  wrote:

>
> On Tue, Aug 1, 2017 at 13:00 Taylor Swift via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> 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:
>>>
>>>
>>> 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/crypt
>>> o/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.
>>
>
> My understanding is that the server working group, and all such work
> groups, will be presenting their proposals 

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Xiaodi Wu via swift-evolution]

On Wed, Aug 2, 2017 at 12:23 PM, Taylor Swift  wrote:

>
>
> On Wed, Aug 2, 2017 at 12:45 PM, Gor Gyolchanyan <
> gor.f.gyolchan...@icloud.com> wrote:
>
>>
>> On Aug 2, 2017, at 4:35 AM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> On Tue, Aug 1, 2017 at 7:38 PM, Taylor Swift  w
>> rote:
>>
>>>
>>>
>>> On Tue, Aug 1, 2017 at 5:50 PM, Xiaodi Wu  wrote:
>>>

 On Tue, Aug 1, 2017 at 13:00 Taylor Swift via swift-evolution <
 swift-evolution@swift.org> wrote:

> 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:
>>
>>
>> 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/crypt
>> o/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.
>

 My understanding is that the server working group, and all such work
 groups, will be presenting their proposals here for approval, and that all
 API changes in the Swift open source project go through this list.

>>>
>>> That sounds like it would spam the general list a lot?
>>>
>>
>> On the contrary, core team members have confirmed that working proposals
>> such as those are the principal intended use for this list; it is *not*
>> meant to be a general forum for musings about Swift language design.
>>
>>
>>
>> My rule of thumb was that any post on the mailing list that I make has to
>> be aimed at providing a solution to a problem, or at the very least,
>> seeking help in providing a solution to a problem. If the discussion has no
>> definitive actionable outcome, then I consider it pointless.
>>
>
> At the same time, people should be able to float ideas here to see how
> well they would be received before investing the energy into writing up a
> proposal. I certainly wouldn’t spend time drafting up an entire API spec
> for a math library without first checking that this is something that the
> community actually wants.
>

I would mostly agree with that statement, except for the word "here." Swift
Evolution clearly isn't representative of the community of Swift users
generally; there are Slack channels, Reddit groups, and other forums which
are intended to be a place for general discussion, and which would probably
get you a good sense of what users want. I definitely agree with Gor that
the "actionable outcome" rule of thumb is a pretty good guideline for
what's most effective on this mailing list.

The other point I'd make here is that I definitely think the core team is
right about encouraging any "entire API spec" for a math library to be
based on implementation experience from actually writing a math library
that has seen good adoption. Essentially, what they're saying is that any
proposed design here should have already proved itself in the field. I
assume that you are well aware of Conway's law, which afaict has good
evidence to back it up; with that in mind, the end product that emerges
from a draft spec and an empty open-source repo is unlikely to be
satisfactory, let alone optimal.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Gor Gyolchanyan via swift-evolution]

> On Aug 2, 2017, at 8:23 PM, Taylor Swift  wrote:
> 
> 
> 
> On Wed, Aug 2, 2017 at 12:45 PM, Gor Gyolchanyan 
> > wrote:
> 
>> On Aug 2, 2017, at 4:35 AM, Xiaodi Wu via swift-evolution 
>> > wrote:
>> 
>> On Tue, Aug 1, 2017 at 7:38 PM, Taylor Swift > > wrote:
>> 
>> 
>> On Tue, Aug 1, 2017 at 5:50 PM, Xiaodi Wu > > wrote:
>> 
>> On Tue, Aug 1, 2017 at 13:00 Taylor Swift via swift-evolution 
>> > wrote:
>> On Tue, Aug 1, 2017 at 1:51 PM, Michael Ilseman via swift-evolution 
>> > wrote:
>> 
>> 
>>> On Aug 1, 2017, at 10:44 AM, Tino Heth via swift-evolution 
>>> > 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.
>>> 
>> 
>> 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.
>> 
>> My understanding is that the server working group, and all such work groups, 
>> will be presenting their proposals here for approval, and that all API 
>> changes in the Swift open source project go through this list.
>> 
>> That sounds like it would spam the general list a lot?
>> 
>> On the contrary, core team members have confirmed that working proposals 
>> such as those are the principal intended use for this list; it is *not* 
>> meant to be a general forum for musings about Swift language design.
>>  
> 
> My rule of thumb was that any post on the mailing list that I make has to be 
> aimed at providing a solution to a problem, or at the very least, seeking 
> help in providing a solution to a problem. If the discussion has no 
> definitive actionable outcome, then I consider it pointless.
> 
> At the same time, people should be able to float ideas here to see how well 
> they would be received before investing the energy into writing up a 
> proposal. I certainly wouldn’t spend time drafting up an entire API spec for 
> a math library without first checking that this is something that the 
> community actually wants.

Agreed. The problem with that is purely technical and will be resolved once the 
swift community migrates to discourse.
I alone have a myriad of thoughts and ideas and questions that would completely 
litter this mailing list, so I'm holding off until better times.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Taylor Swift via swift-evolution]

On Wed, Aug 2, 2017 at 12:45 PM, Gor Gyolchanyan <
gor.f.gyolchan...@icloud.com> wrote:

>
> On Aug 2, 2017, at 4:35 AM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Tue, Aug 1, 2017 at 7:38 PM, Taylor Swift  wrote:
>
>>
>>
>> On Tue, Aug 1, 2017 at 5:50 PM, Xiaodi Wu  wrote:
>>
>>>
>>> On Tue, Aug 1, 2017 at 13:00 Taylor Swift via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
 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:
>
>
> 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/crypt
> o/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.

>>>
>>> My understanding is that the server working group, and all such work
>>> groups, will be presenting their proposals here for approval, and that all
>>> API changes in the Swift open source project go through this list.
>>>
>>
>> That sounds like it would spam the general list a lot?
>>
>
> On the contrary, core team members have confirmed that working proposals
> such as those are the principal intended use for this list; it is *not*
> meant to be a general forum for musings about Swift language design.
>
>
>
> My rule of thumb was that any post on the mailing list that I make has to
> be aimed at providing a solution to a problem, or at the very least,
> seeking help in providing a solution to a problem. If the discussion has no
> definitive actionable outcome, then I consider it pointless.
>

At the same time, people should be able to float ideas here to see how well
they would be received before investing the energy into writing up a
proposal. I certainly wouldn’t spend time drafting up an entire API spec
for a math library without first checking that this is something that the
community actually wants.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Gor Gyolchanyan via swift-evolution]

> On Aug 2, 2017, at 4:35 AM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> On Tue, Aug 1, 2017 at 7:38 PM, Taylor Swift  > wrote:
> 
> 
> On Tue, Aug 1, 2017 at 5:50 PM, Xiaodi Wu  > wrote:
> 
> On Tue, Aug 1, 2017 at 13:00 Taylor Swift via swift-evolution 
> > wrote:
> On Tue, Aug 1, 2017 at 1:51 PM, Michael Ilseman via swift-evolution 
> > wrote:
> 
> 
>> On Aug 1, 2017, at 10:44 AM, Tino Heth via swift-evolution 
>> > 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.
>> 
> 
> 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.
> 
> My understanding is that the server working group, and all such work groups, 
> will be presenting their proposals here for approval, and that all API 
> changes in the Swift open source project go through this list.
> 
> That sounds like it would spam the general list a lot?
> 
> On the contrary, core team members have confirmed that working proposals such 
> as those are the principal intended use for this list; it is *not* meant to 
> be a general forum for musings about Swift language design.
>  

My rule of thumb was that any post on the mailing list that I make has to be 
aimed at providing a solution to a problem, or at the very least, seeking help 
in providing a solution to a problem. If the discussion has no definitive 
actionable outcome, then I consider it pointless.

> Wouldn’t a more decentralized model mitigate the “we don’t have the 
> energy/attention to devote to this” complaint?
> 
> Also as a gauge of interest, I’m wondering who here would like to work on a 
> core library if a campaign to build some was started now.
> 
> 
> 
>> 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
>> https://developer.apple.com/documentation/glkit/glkquaternion-pc6 
>> 
>> https://developer.apple.com/documentation/scenekit/scnquaternion 
>> 
>> https://developer.apple.com/documentation/coremotion/cmquaternion 
>> 
>> :-(
>> 
>> Tino
>> ___
>> 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 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> 

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[T.J. Usiyan via swift-evolution]

A thousand times yes to this.

On Tue, Aug 1, 2017 at 9:35 PM, Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> On Tue, Aug 1, 2017 at 7:38 PM, Taylor Swift  wrote:
>
>>
>>
>> On Tue, Aug 1, 2017 at 5:50 PM, Xiaodi Wu  wrote:
>>
>>>
>>> On Tue, Aug 1, 2017 at 13:00 Taylor Swift via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
 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:
>
>
> 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/crypt
> o/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.

>>>
>>> My understanding is that the server working group, and all such work
>>> groups, will be presenting their proposals here for approval, and that all
>>> API changes in the Swift open source project go through this list.
>>>
>>
>> That sounds like it would spam the general list a lot?
>>
>
> On the contrary, core team members have confirmed that working proposals
> such as those are the principal intended use for this list; it is *not*
> meant to be a general forum for musings about Swift language design.
>
>
>> Wouldn’t a more decentralized model mitigate the “we don’t have the
>> energy/attention to devote to this” complaint?
>>
>> Also as a gauge of interest, I’m wondering who here would like to work on
>> a core library if a campaign to build some was started now.
>>
>>
>>>
>>> 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
> https://developer.apple.com/documentation/glkit/glkquaternion-pc6
> https://developer.apple.com/documentation/scenekit/scnquaternion
> https://developer.apple.com/documentation/coremotion/cmquaternion
> :-(
>
> Tino
> ___
> 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
>
> ___
 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
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Xiaodi Wu via swift-evolution]

On Tue, Aug 1, 2017 at 7:38 PM, Taylor Swift  wrote:

>
>
> On Tue, Aug 1, 2017 at 5:50 PM, Xiaodi Wu  wrote:
>
>>
>> On Tue, Aug 1, 2017 at 13:00 Taylor Swift via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> 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:


 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/crypt
 o/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.
>>>
>>
>> My understanding is that the server working group, and all such work
>> groups, will be presenting their proposals here for approval, and that all
>> API changes in the Swift open source project go through this list.
>>
>
> That sounds like it would spam the general list a lot?
>

On the contrary, core team members have confirmed that working proposals
such as those are the principal intended use for this list; it is *not*
meant to be a general forum for musings about Swift language design.


> Wouldn’t a more decentralized model mitigate the “we don’t have the
> energy/attention to devote to this” complaint?
>
> Also as a gauge of interest, I’m wondering who here would like to work on
> a core library if a campaign to build some was started now.
>
>
>>
>> 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
 https://developer.apple.com/documentation/glkit/glkquaternion-pc6
 https://developer.apple.com/documentation/scenekit/scnquaternion
 https://developer.apple.com/documentation/coremotion/cmquaternion
 :-(

 Tino
 ___
 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

 ___
>>> 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

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Taylor Swift via swift-evolution]

On Tue, Aug 1, 2017 at 5:50 PM, Xiaodi Wu  wrote:

>
> On Tue, Aug 1, 2017 at 13:00 Taylor Swift via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> 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:
>>>
>>>
>>> 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.
>>
>
> My understanding is that the server working group, and all such work
> groups, will be presenting their proposals here for approval, and that all
> API changes in the Swift open source project go through this list.
>

That sounds like it would spam the general list a lot? Wouldn’t a more
decentralized model mitigate the “we don’t have the energy/attention to
devote to this” complaint?

Also as a gauge of interest, I’m wondering who here would like to work on a
core library if a campaign to build some was started now.


>
> 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
>>> https://developer.apple.com/documentation/glkit/glkquaternion-pc6
>>> https://developer.apple.com/documentation/scenekit/scnquaternion
>>> https://developer.apple.com/documentation/coremotion/cmquaternion
>>> :-(
>>>
>>> Tino
>>> ___
>>> 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
>>>
>>> ___
>> 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

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Tino Heth via swift-evolution]

> 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.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Taylor Swift via swift-evolution]

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:
>
>
> 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.


> 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
> https://developer.apple.com/documentation/glkit/glkquaternion-pc6
> https://developer.apple.com/documentation/scenekit/scnquaternion
> https://developer.apple.com/documentation/coremotion/cmquaternion
> :-(
>
> Tino
> ___
> 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
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Taylor Swift via swift-evolution]

On Tue, Aug 1, 2017 at 1:44 PM, Tino Heth <2...@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
> https://developer.apple.com/documentation/glkit/glkquaternion-pc6
> https://developer.apple.com/documentation/scenekit/scnquaternion
> https://developer.apple.com/documentation/coremotion/cmquaternion
> :-(
>
> Tino
>

Exactly.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Taylor Swift via swift-evolution]

On Tue, Aug 1, 2017 at 1:20 PM, Michael Ilseman  wrote:

>
>
> On Aug 1, 2017, at 8:14 AM, Taylor Swift via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I’ve noticed from this and older threads that everyone agrees on what core
> libraries we want, but they never actually get built. Perennial requests
> seem to be
>
> - RNG and cryptography library (CryptoSwift could be a good base for this)
>
>
> A new implementation of crypto is probably a very bad idea. A blessed
> wrapping around the platform’s preferred implementation of crypto, however,
> is certainly needed.
>

Good point, but then again CryptoSwift has already demonstrated a demand
for a new Swift implementation and we wouldn’t be starting from scratch.


>
> - Generic Math library/Vector library
>
>
> This is pretty compelling.
>
> - Basic data structures (Tree, Balanced Tree, Heap, Queue, SkipList,
> graphs, etc)
>
>
> Which flavor/implementation of tree, balanced tree, heap, graphs are
> desirable here? The desirability of many of these structures is often
> dependent on which of many competing tradeoffs were made. Implementation
> details can dramatically shape the general applicability of a data
> structure.
>
> For example, it might make sense to adopt something similar to
> https://github.com/lorentey/BTree as a general underlying representation
> for some kinds of higher level collections (or the mechanisms to easily
> adapt them).
>
>
The idea wouldn’t be to cover every possible permutation of these data
structures, but provide implementations for the most commonly used
varieties.


> - Modern DateTime library
>
>
> Foundation provides many of these, though I’m sure there are always
> opportunities for improvement. Do you see a specific need that cannot be
> addressed with improvements to corelibs-foundation? There’s a large amount
> of domain expertise in Foundation and they are pretty active on the mailing
> lists.
>

I’d be happy just with moving the datetime functionality from Foundation
into its own module. I’m really not a fan of the monolith pattern.


>
> - Modern String processing toolkit
>
>
> This is a huge gap in Swift’s current offerings, and I’m personally
> invested in improving the situation here. At the risk of hijacking this
> thread, do you have a good bullet list of the kinds of facilities you
> imagine useful? More specifically (and to keep the discussion scoped), are
> there any tools beyond something like good language support for regular
> expression matching and substitutions?
>
>
Pretty basic but most of what you have to import Foundation to do right
now, plus a few extras.

- trim whitespace from a string
- string formatting
- round float to n decimal places
- pad float to n 0s
- left/right/center pad string with spaces
- locale aware capitalization
- defined CharacterSetsfor things like alphabeticals, numerics, whitespace
chars, etc.
- regex support would be nice
- platform-abstracted terminal colors would be nice

plus a lot of things I’m probably forgetting


> - 2D Graphics library (similar to cairo)
>
> - Windowing/UI library
>
>
> By this, do you mean cross-platform pure Swift rethinks? This is certainly
> interesting, but a pure Swift rethink is likely a lower priority than
> exposing bindings for existing cross-platform approaches (e.g. you
> mentinoed cairo). Like crypto, it might make sense to establish blessed
> wrappers/apinotes/overlays on top of tried-and-true open source offerings.
>

Currently, calling Cairo code from Swift is extremely problematic for
reasons involving memory ownership and object lifetimes. Nothing an
experienced Swift dev can’t get around, but definitely far too ugly a hack
for such a common task. The C library is simply incompatible with Swift’s
memory safety model.


>
> I think David Turnbull tried to get something like this started years back
> but it fizzled out pretty quick, probably because the Swift foss community
> was much smaller back then. Time to try again?
>
> On Tue, Aug 1, 2017 at 8:29 AM, Georgios Moschovitis <
> george.moschovi...@icloud.com> wrote:
>
>> > That's what's happened with the Server APIs Project
>> > 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
>> > https://jcp.org/en/jsr/detail?id=310 and similar.
>>
>> + 1
>>
>> I would also love to see standard implementation of Graph data
>> structures, at least some common protocols.
>> Dunno why this versatile data structure is not included in standard
>> libraries (similar to Map/Dictionary), Set, etc.
>>
>> -g.
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Michael Ilseman via swift-evolution]

> On Aug 1, 2017, at 10:44 AM, Tino Heth via swift-evolution 
>  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.
> 

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.

> 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
> https://developer.apple.com/documentation/glkit/glkquaternion-pc6 
> 
> https://developer.apple.com/documentation/scenekit/scnquaternion 
> 
> https://developer.apple.com/documentation/coremotion/cmquaternion 
> 
> :-(
> 
> Tino
> ___
> 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

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Tino Heth via swift-evolution]

> 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
https://developer.apple.com/documentation/glkit/glkquaternion-pc6 

https://developer.apple.com/documentation/scenekit/scnquaternion 

https://developer.apple.com/documentation/coremotion/cmquaternion 

:-(

Tino___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Xiaodi Wu via swift-evolution]

On Tue, Aug 1, 2017 at 12:21 Michael Ilseman via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Aug 1, 2017, at 8:14 AM, Taylor Swift via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I’ve noticed from this and older threads that everyone agrees on what core
> libraries we want, but they never actually get built. Perennial requests
> seem to be
>
> - RNG and cryptography library (CryptoSwift could be a good base for this)
>
>
> A new implementation of crypto is probably a very bad idea. A blessed
> wrapping around the platform’s preferred implementation of crypto, however,
> is certainly needed.
>

My understanding was that this is already part of the Swift server working
group’s efforts, and a large part at that.

- Generic Math library/Vector library
>
>
> This is pretty compelling.
>
> - Basic data structures (Tree, Balanced Tree, Heap, Queue, SkipList,
> graphs, etc)
>
>
> Which flavor/implementation of tree, balanced tree, heap, graphs are
> desirable here? The desirability of many of these structures is often
> dependent on which of many competing tradeoffs were made. Implementation
> details can dramatically shape the general applicability of a data
> structure.
>
> For example, it might make sense to adopt something similar to
> https://github.com/lorentey/BTree as a general underlying representation
> for some kinds of higher level collections (or the mechanisms to easily
> adapt them).
>
> - Modern DateTime library
>
>
> Foundation provides many of these, though I’m sure there are always
> opportunities for improvement. Do you see a specific need that cannot be
> addressed with improvements to corelibs-foundation? There’s a large amount
> of domain expertise in Foundation and they are pretty active on the mailing
> lists.
>
> - Modern String processing toolkit
>
>
> This is a huge gap in Swift’s current offerings, and I’m personally
> invested in improving the situation here. At the risk of hijacking this
> thread, do you have a good bullet list of the kinds of facilities you
> imagine useful? More specifically (and to keep the discussion scoped), are
> there any tools beyond something like good language support for regular
> expression matching and substitutions?
>
> - 2D Graphics library (similar to cairo)
>
> - Windowing/UI library
>
>
> By this, do you mean cross-platform pure Swift rethinks? This is certainly
> interesting, but a pure Swift rethink is likely a lower priority than
> exposing bindings for existing cross-platform approaches (e.g. you
> mentinoed cairo). Like crypto, it might make sense to establish blessed
> wrappers/apinotes/overlays on top of tried-and-true open source offerings.
>
> I think David Turnbull tried to get something like this started years back
> but it fizzled out pretty quick, probably because the Swift foss community
> was much smaller back then. Time to try again?
>
> On Tue, Aug 1, 2017 at 8:29 AM, Georgios Moschovitis <
> george.moschovi...@icloud.com> wrote:
>
>> > That's what's happened with the Server APIs Project
>> > 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
>> > https://jcp.org/en/jsr/detail?id=310 and similar.
>>
>> + 1
>>
>> I would also love to see standard implementation of Graph data
>> structures, at least some common protocols.
>> Dunno why this versatile data structure is not included in standard
>> libraries (similar to Map/Dictionary), Set, etc.
>>
>> -g.
>
>
> ___
> 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
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Taylor Swift via swift-evolution]

Cool! When is this planned to implemented? Until then though, it’s probably
a good idea to design core libraries as submodules (preferably a single
file), not modules. You lose the ability to use the SPM to manage them, but
you don’t have to rummage through the files and change all the access
modifiers. Not ideal, but I’m glad this won’t be the situation forever.

On Tue, Aug 1, 2017 at 12:45 PM, Michael Ilseman  wrote:

>
> On Aug 1, 2017, at 8:02 AM, Taylor Swift via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I think the Server APIs project was pretty close to what I had in mind
> actually. I don’t see why more core libraries can’t be commissioned that
> way, things like Math and DateTime would probably draw a great deal more
> attention than Server APIs since they are used by more people. One thing
> that would have to be fixed though is the cross-module optimization
> problem; no one in their right mind should ever be making generic calls to
> sin(x). A feature in the SPM that would perform “injection” of core
> library code into the interior of modules would probably be enough to fix
> this problem for now. (If this sounds hacky just remember that right now
> everyone seems to be copying and pasting .swift files everywhere.)
> Everything internal would become fileprivate and everything public would
> become internal. A good Swift library should expose no more than 7 or 8
> symbols at the top level so this should play nice with most client projects.
>
>
> This is already planned as part of how Modules will be able to control
> what is and is not part of their ABI: https://github.com/apple/
> swift/blob/master/docs/LibraryEvolution.rst#inlineable-functions
>
>
> On Tue, Aug 1, 2017 at 4:50 AM, Ian Partridge  wrote:
>
>> 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.
>>
>> That's what's happened with the Server APIs Project
>> 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
>> https://jcp.org/en/jsr/detail?id=310 and similar.
>>
>> --
>> Ian Partridge
>>
>
> ___
> 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

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Michael Ilseman via swift-evolution]

> On Aug 1, 2017, at 8:14 AM, Taylor Swift via swift-evolution 
>  wrote:
> 
> I’ve noticed from this and older threads that everyone agrees on what core 
> libraries we want, but they never actually get built. Perennial requests seem 
> to be
> 
> - RNG and cryptography library (CryptoSwift could be a good base for this)

A new implementation of crypto is probably a very bad idea. A blessed wrapping 
around the platform’s preferred implementation of crypto, however, is certainly 
needed.

> - Generic Math library/Vector library

This is pretty compelling.

> - Basic data structures (Tree, Balanced Tree, Heap, Queue, SkipList, graphs, 
> etc)

Which flavor/implementation of tree, balanced tree, heap, graphs are desirable 
here? The desirability of many of these structures is often dependent on which 
of many competing tradeoffs were made. Implementation details can dramatically 
shape the general applicability of a data structure.

For example, it might make sense to adopt something similar to 
https://github.com/lorentey/BTree as a general underlying representation for 
some kinds of higher level collections (or the mechanisms to easily adapt them).

> - Modern DateTime library

Foundation provides many of these, though I’m sure there are always 
opportunities for improvement. Do you see a specific need that cannot be 
addressed with improvements to corelibs-foundation? There’s a large amount of 
domain expertise in Foundation and they are pretty active on the mailing lists.

> - Modern String processing toolkit

This is a huge gap in Swift’s current offerings, and I’m personally invested in 
improving the situation here. At the risk of hijacking this thread, do you have 
a good bullet list of the kinds of facilities you imagine useful? More 
specifically (and to keep the discussion scoped), are there any tools beyond 
something like good language support for regular expression matching and 
substitutions?

> - 2D Graphics library (similar to cairo)
> - Windowing/UI library
> 

By this, do you mean cross-platform pure Swift rethinks? This is certainly 
interesting, but a pure Swift rethink is likely a lower priority than exposing 
bindings for existing cross-platform approaches (e.g. you mentinoed cairo). 
Like crypto, it might make sense to establish blessed 
wrappers/apinotes/overlays on top of tried-and-true open source offerings.

> I think David Turnbull tried to get something like this started years back 
> but it fizzled out pretty quick, probably because the Swift foss community 
> was much smaller back then. Time to try again?
> 
> On Tue, Aug 1, 2017 at 8:29 AM, Georgios Moschovitis 
> > wrote:
> > That's what's happened with the Server APIs Project
> > 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
> > https://jcp.org/en/jsr/detail?id=310  
> > and similar.
> 
> + 1
> 
> I would also love to see standard implementation of Graph data structures, at 
> least some common protocols.
> Dunno why this versatile data structure is not included in standard libraries 
> (similar to Map/Dictionary), Set, etc.
> 
> -g.
> 
> ___
> 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

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Dave DeLong via swift-evolution]

> On Aug 1, 2017, at 9:14 AM, Taylor Swift via swift-evolution 
>  wrote:
> 
> I’ve noticed from this and older threads that everyone agrees on what core 
> libraries we want, but they never actually get built. Perennial requests seem 
> to be
> 
> - RNG and cryptography library (CryptoSwift could be a good base for this)
> - Generic Math library/Vector library
> - Basic data structures (Tree, Balanced Tree, Heap, Queue, SkipList, graphs, 
> etc)
> - Modern DateTime library

This may not be a popular opinion for the masses, but in reality, Foundation is 
a modern DateTime library. The core functionality provided by Calendar, Date, 
TimeZone, Locale, and DateFormatter are world-class APIs.

I suspect that what people are really asking for is simpler API to do things 
like “get the day of the month from a Date” and such. The proper way to do this 
seemingly involves more types than you’d think is reasonable, but it’s that way 
for very good reasons.

I’d encourage people who want to know more about this to go read through 
http://yourcalendricalfallacyis.com , and 
I’d be happy to disabuse anyone of false calendrical notions on a new thread.

Cheers,

Dave

> - Modern String processing toolkit
> - 2D Graphics library (similar to cairo)
> - Windowing/UI library
> 
> I think David Turnbull tried to get something like this started years back 
> but it fizzled out pretty quick, probably because the Swift foss community 
> was much smaller back then. Time to try again?
> 
> On Tue, Aug 1, 2017 at 8:29 AM, Georgios Moschovitis 
> > wrote:
> > That's what's happened with the Server APIs Project
> > 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
> > https://jcp.org/en/jsr/detail?id=310  
> > and similar.
> 
> + 1
> 
> I would also love to see standard implementation of Graph data structures, at 
> least some common protocols.
> Dunno why this versatile data structure is not included in standard libraries 
> (similar to Map/Dictionary), Set, etc.
> 
> -g.
> 
> ___
> 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

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Taylor Swift via swift-evolution]

I’ve noticed from this and older threads that everyone agrees on what core
libraries we want, but they never actually get built. Perennial requests
seem to be

- RNG and cryptography library (CryptoSwift could be a good base for this)
- Generic Math library/Vector library
- Basic data structures (Tree, Balanced Tree, Heap, Queue, SkipList,
graphs, etc)
- Modern DateTime library
- Modern String processing toolkit
- 2D Graphics library (similar to cairo)
- Windowing/UI library

I think David Turnbull tried to get something like this started years back
but it fizzled out pretty quick, probably because the Swift foss community
was much smaller back then. Time to try again?

On Tue, Aug 1, 2017 at 8:29 AM, Georgios Moschovitis <
george.moschovi...@icloud.com> wrote:

> > That's what's happened with the Server APIs Project
> > 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
> > https://jcp.org/en/jsr/detail?id=310 and similar.
>
> + 1
>
> I would also love to see standard implementation of Graph data structures,
> at least some common protocols.
> Dunno why this versatile data structure is not included in standard
> libraries (similar to Map/Dictionary), Set, etc.
>
> -g.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Taylor Swift via swift-evolution]

I think the Server APIs project was pretty close to what I had in mind
actually. I don’t see why more core libraries can’t be commissioned that
way, things like Math and DateTime would probably draw a great deal more
attention than Server APIs since they are used by more people. One thing
that would have to be fixed though is the cross-module optimization
problem; no one in their right mind should ever be making generic calls to
sin(x). A feature in the SPM that would perform “injection” of core library
code into the interior of modules would probably be enough to fix this
problem for now. (If this sounds hacky just remember that right now
everyone seems to be copying and pasting .swift files everywhere.)
Everything internal would become fileprivate and everything public would
become internal. A good Swift library should expose no more than 7 or 8
symbols at the top level so this should play nice with most client projects.

On Tue, Aug 1, 2017 at 4:50 AM, Ian Partridge  wrote:

> 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.
>
> That's what's happened with the Server APIs Project
> 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
> https://jcp.org/en/jsr/detail?id=310 and similar.
>
> --
> Ian Partridge
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Georgios Moschovitis via swift-evolution]

> That's what's happened with the Server APIs Project
> 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
> https://jcp.org/en/jsr/detail?id=310 and similar.

+ 1

I would also love to see standard implementation of Graph data structures, at 
least some common protocols.
Dunno why this versatile data structure is not included in standard libraries 
(similar to Map/Dictionary), Set, etc.

-g.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Ian Partridge via swift-evolution]

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.

That's what's happened with the Server APIs Project
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
https://jcp.org/en/jsr/detail?id=310 and similar.

-- 
Ian Partridge
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Xiaodi Wu via swift-evolution]

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:

https://github.com/xwu/NumericAnnex


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.zuba...@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 

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Taylor Swift via swift-evolution]

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.zuba...@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
 

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Jonathan Hull via swift-evolution]

+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.
> 

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Hooman Mehr via swift-evolution]

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 
 
>>> 
>>> 

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Hooman Mehr via swift-evolution]

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 
>>> 
>> 
>> ___
>> 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

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Taylor Swift via swift-evolution]

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.zuba...@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
>>
>>
> ___
> 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

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Hooman Mehr via swift-evolution]

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 
>> 
> 
> ___
> 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

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Stephen Canon via swift-evolution]

> 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.

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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Taylor Swift via swift-evolution]

On Mon, Jul 31, 2017 at 1:23 PM, Adrian Zubarev <
adrian.zuba...@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
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Taylor Swift via swift-evolution]

On Mon, Jul 31, 2017 at 1:19 PM, Benjamin Spratling 
wrote:

> 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.


>
> 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
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Adrian Zubarev via swift-evolution]

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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution