I'm happy to announce the birth of a new numerics library for the Swift ecosystem. Details are on the Swift.org blog:
From the blog post (and creator of the library), @scanon:
Swift Numerics will provide the building blocks of numerical computing in Swift, as a set of fine-grained modules bundled together into a single Swift package. My hope is that we can quickly fill some important gaps in the Standard Library’s existing APIs, and unlock new domains of programming to the Swift language.
All I can say is, awesome! This is a much needed addition to the Swift ecosystem. Thank you @scanon for all your hard work related to all things numeric in Swift!
There’s a definite need for improvements there. I haven’t thought through the details enough to say if it should go in SN or straight into the standard library or something else, but it’s on the radar.
(I think this would be a perfectly reasonable issue to open for SN, no matter where an implementation eventually lives.)
Very excited about this, and also the future directions!
The difficulty I see about this setup is that some of the language-level support will still have to come from the compiler (for instance, for BigInt to support correspondingly big literals). I could see this being much more straightforward if the design were going straight into the standard library; how will this separate library manage to accomplish these things?
To some extent, this is TBD. There are definitely some things that can be done better with compiler magic or in the standard library. But all of the work currently planned can be done, at least in part, in a package, and that can help make the case for changes to the compiler and standard library precisely for the pieces that cannot.
Swift doesn't really have a language model for thinking about heterogeneous computing (yet?), which maybe makes GPU acceleration premature (at least for the API currently in the library, which is too low-level to benefit).
Either a language-level heterogeneous compute model or higher-level API could put this in scope.
Swift Numerics doesn't use Accelerate at present, because it doesn't yet include API that would benefit from using Accelerate. It will likely use some pieces of Accelerate in the future, but only the pieces that have alternative open-source implementations available (BLAS, LAPACK, maybe FFTs, ...), because Swift Numerics is intended to provide a uniform cross-platform API.
I should note that the vDSP, vForce, and Quadrature API in Accelerate all became vastly easier to use from Swift in macOS 10.15 / iOS 13.0 / tvOS 13.0 / watchOS 6.0. There's further work to be done, but the Accelerate team has done a great job improving them already. E.g.:
import Accelerate
let a: [Float] = // ...
let b: [Float] = // ...
// Create new array with c[i] = a[i] + b[i]
var c = vDSP.add(a, b)
// Or update a contiguous collection with the right element type in-place
// (this works out of the box with Array and UnsafeBufferPointer and a
// Slice of any conforming type, but you can add your own conforming
// types to `AccelerateBuffer` too):
vDSP.subtract(a, b, result: &c)
Support for arbitrary-precision String -> Real parsing probably does belong in SN.
However, parsing for specific formats (IEEE Float, Double, etc) can exploit fixed-precision arithmetic in common cases. That makes it a lot faster but limits it to specific target formats, which is useful for the standard library types.
¹ If you are compiling with the nightly toolchain and want to experiment with Float16, select "branch" and specify "swift-5.3" (but note: this branch will fail to compile with released versions of Swift, so do not use it for anything except for experimentation).