Swift Numerics

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.

57 Likes

I am very excited about this. :clap::clap::clap:

@scanon Do you envision StringReal parsing as eventually part of this?

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!

1 Like

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.)

3 Likes

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?

2 Likes

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.

1 Like

:raised_hands:.

1 Like

@scanon would GPU acceleration of the functions in this package be considered, or would that entail a separate project?

2 Likes

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.

That would be very interesting! I had only considered approaching this as a higher-level API.

1 Like

The way that Julia has dealt with this is very instructive (https://github.com/JuliaGPU and related work).

4 Likes

Nice work @scanon & Team. Very exciting!

Moderator note: the negative hyperbole has been removed from this post.

Is this library using accelerate? We need some easy way to use accelerate.

this is great news!

:smiling_imp: (don‘t take my response serious)

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)
7 Likes

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.

Terms of Service

Privacy Policy

Cookie Policy