0.0.4 Release Notes

There are two changes in this release to call out specifically:

  • Complex's conformance to Codable now uses an unkeyed container, so e.g. .zero gets encoded as [0,0] in JSON instead of the old {"x":0, "y":0}.

  • There's a new protocol, AlgebraicField refining Numeric by adding the /, /= operators, and a .reciprocal: Self? property. The Real protocol refines it and Complex<T> conforms to it, allowing you to write code that is generic over them. There are some additional operations that it probably makes sense to add to this protocol (e.g. square root); I expect to add them gradually as needed.

I also want to draw special attention to a change that I expect to make in the next tag. In order to make certain use patterns simpler, I intend to give the Complex module a name that doesn't conflict with the Complex type. If you have opinions about this change, or suggestions for a naming pattern to adopt for modules in Swift Numerics, please weigh in on that thread.


I don’t think square-root belongs on AlgebraicField. Not all fields have square roots (eg. ℚ), and we already have the ElementaryFunctions protocol which includes sqrt.

Either ElementaryFunctions should refine AlgebraicField, or we should encourage people to write algorithms against AlgebraicField & ElementaryFunctions. Perhaps we should introduce a typealias for the composition of those two protocols.


This is both absolutely true but also slightly uninteresting, since ℚ is very nearly the most useless computational abstraction :stuck_out_tongue: (also, like with Real you could simply return an indicator--0/0?--when one doesn't exist). The fact that square roots are kind of a pain to compute in arbitrary finite fields would also be a pretty reasonable objection, though, so sure.

Does this mean the Numerics package is unlikely to gain an arbitrary-precision Rational type?

It's not unthinkable, just lower-priority than more useful stuff.

Well that, and only half the non-zero elements in a finite field of odd characteristic are quadratic residues, hence the other half don’t have square roots.

Yeah, but that's also true of the reals, so not really a drawback.

After writing a bit of code, I find the constraint which I often want to use for generic algorithms is:

SignedNumeric & AlgebraicField & ElementaryFunctions

That allows all the basic arithmetic operations including negation and division, as well as powers, roots, and the basic transcendental functions.

Perhaps we should have a typealias for this composition?

Edit: Actually, fields are necessarily additive groups, which means they have negation. Should AlgebraicField refine SignedNumeric instead of Numeric?

1 Like

That seems reasonable to me. SignedNumeric was poorly named, in hindsight, so avoiding the need to reference it explicitly seems good. (Also: [SR-12078] Improve documentation of SignedNumeric · Issue #54514 · apple/swift · GitHub).

PR here: AlgebraicField should conform to SignedNumeric, not just Numeric. by stephentyrone · Pull Request #99 · apple/swift-numerics · GitHub

Please open an issue for adding a name for the AlgebraicField & ElementaryFunctions point, there's some bikeshedding to be done there.

1 Like