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