<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 3, 2017 at 7:12 PM, Karl Wagner via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span class=""><br><div><blockquote type="cite"><div>On 3. Aug 2017, at 13:04, Stephen Canon via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_2018249213978403257Apple-interchange-newline"><div><div style="word-wrap:break-word;line-break:after-white-space"><blockquote type="cite">On Aug 2, 2017, at 7:03 PM, Karl Wagner via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br></blockquote><div><blockquote type="cite"><div><br class="m_2018249213978403257Apple-interchange-newline"><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">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.</span></div></blockquote><br></div><div>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.</div><div><br></div><div>– Steve</div></div>______________________________<wbr>_________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br></div></blockquote></div><br></span><div>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.</div><div><br></div><div>The pure-Swift cosine implementation looks cool.</div></div></blockquote><div><br></div><div>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.<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>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.</div><div><br></div></div></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div></div><div>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.</div><span class="HOEnZb"><font color="#888888"><div><br></div></font></span></div></blockquote><div><br></div><div>The glibc/llvm functions are not generic. You cannot use _cos(_:) on a protocol type like <span style="font-family:monospace,monospace">BinaryFloatingPoint</span>. A pure Swift implementation would allow generic programming with trig and other math functions; right now anything beyond <span style="font-family:monospace,monospace">sqrt()</span> requires manual specialization.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span class="HOEnZb"><font color="#888888"><div></div><div>- Karl</div></font></span></div><br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div></div>