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

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

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

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

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

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

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

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>

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

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

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

> 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

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

> 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

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

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

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

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

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

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

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

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

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

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

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

> 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

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

> 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

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

> 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

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

> 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

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

> 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

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

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,

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

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

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

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

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

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

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

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.

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

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

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

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

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

> 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

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

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

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

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)

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

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

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

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

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

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

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

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

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

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

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

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,

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

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,

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

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

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

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

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

> 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

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

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

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

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

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

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

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

> 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

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

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

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

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 >

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

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

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

> 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

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

> 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

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

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

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

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

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

> 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

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

> 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

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

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

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

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

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

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

[swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

Even better would be something like the ‘Haskell Platform’ i.e. a curated collection of core packages that share the same ‘look’ with the stdlib. Or something similar to the boost libraries in C++. Or even something like the javax libraries. So the stdlib could stay fit, while we could still

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

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,

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

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

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

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

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

+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

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

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

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

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

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

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

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

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

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

> 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

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

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

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

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

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

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

[swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

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