[swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Taylor Swift]

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

>
> On 3. Aug 2017, at 13:04, Stephen Canon via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> On Aug 2, 2017, at 7:03 PM, Karl Wagner via swift-evolution <
> swift-evolution at 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 at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170803/527f9921/attachment.html>