[swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Taylor Swift]

There was a sign error due to switching to an underlying approximation of
sin() to evaluate cos(). Here’s the actual output
<https://github.com/kelvin13/swift-math/blob/5867fc8e151ab0dcc2460a24123fededc6d81f12/tests/output.txt>

On Fri, Aug 4, 2017 at 4:56 PM, Taylor Swift <kelvin13ma at gmail.com> 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
> <https://github.com/kelvin13/swift-math/blob/d82e8b1df848879ba6ac6071883fde7f9a15c967/tests/output.txt>
> 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. <https://github.com/kelvin13/swift-math>
>
> On Thu, Aug 3, 2017 at 7:32 PM, Taylor Swift <kelvin13ma at gmail.com> wrote:
>
>>
>>
>> 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/20170804/01265110/attachment.html>