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
There's a new protocol,
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
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.
Does this mean the
Numerics package is unlikely to gain an arbitrary-precision
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
SignedNumeric instead of
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.