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 (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.
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.
(also, like with