This may have been asked before but I couldn't find anything on the topic. Is Vectors/Matrix (linear algebra) part of the roadmap for Swift Numerics? I've seen several implementations of Swift-only libraries which attempt to do this. However, most of them are not active. I'd be interested in an "official" library or one that at least is actively maintained (happy to contribute to as well).
EDIT: Yes, I know there are existing Apple libraries, but I'm hoping for a cross-platform open source library - such as Swift Numerics.
A multi-dimensional array type is definitely on the roadmap, as are linear algebra bindings for such a type. But a lot of people who ask about "vectors and matrices" actually mean concrete 2-, 3-, and 4-d types for doing geometry operations, which is probably out of scope for Numerics in the medium term (but is something I would encourage someone to take on, and would be happy to provide guidance for). Which are you asking about?
Yes, my primary use would be Graphics programming as I'm coming up with a cross-platform 3D rendering library. I'm currently using SwiftGL Math, but as mentioned before, I'd like to see better options (better API and active community) as currently I'm having to add several extensions to those types to make it nicer.
Swift Numerics is deliberately slow-moving, for multiple reasons:
It should be a stable collection of mature API.
I want to leave space for other numerics-focused packages in the ecosystem, because ultimately that is more interesting to me. Not everything related to numerics belongs in a single monolithic package.
With a couple exceptions (e.g. @markuswntr, @Nevin, @xwu, ...), very few people are interested in contributing either code or meaningful discussion of features that they'd like to have. There are generally more people interested in talking about talking about a numerics roadmap, which is not very interesting to me.
I have a lot of other things to work on: standard library features, performance improvements, helping teams like Accelerate provide better API in Apple's SDKs, ...
What's "holding it back" is primarily a lack of interest and contributions from people just like you. Be the change you want to see:
open an issue on the Swift Numerics page asking for the features you'd like to see. Sketch out the API you would like them to have. Discuss the tradeoffs with other choices. I may push back and argue that it's not a great fit for Numerics; that's OK, that doesn't mean that it isn't a good idea, just that it should go into a different package. You might also change my mind.
make a package that prototypes an API and shows why you think it's useful.
open a PR
write some high-level documentation
...
I don't mean for this to come across as scolding. "Hey, this would be useful" is fine, and other people have lots of stuff they have to do as well. But, if you really want a feature, any of the actions mentioned above are great ways to help make it happen.
For what it's worth, SubstrateMath is the library I've partially written/use for my graphics work, which originated as me cobbling together parts of SwiftGL Math and SwiftMath. It may have some of the extensions you've been needing to add already, and has more performant implementations of things like matrix inverses along with a native 3x4 matrix type (AffineMatrix).
Nifty is our team's temporary solution for linear algebra. It's not maintained, but here's a fork that works. We plan to get more deliberate about a solution in the medium term.
I would like to digress from the topic and ask a question that has been of interest to me for a recently time. If we have two variables of type SIMD3 - 'a' and 'b', and then we add them a + b. It means that all operations a.x + b.x, a.y + b.y and a.z + b.z are performing on separate thread simultaneously? That is, it is involved three cores on CPU?
Other people might be able to give a better, more correct and more interesting answer, but as a quick answer: no, it doesn’t use multiple threads. It instead uses specific instructions on CPUs that support them to add the 3 pairs of numbers using a single instruction after they’ve been loaded into registers. It’s usually quicker than using six instructions to load numbers from potentially different places in memory, three instructions to add them and three more to store them somewhere else.
No. A single addition is not nearly enough work to justify using multiple threads. Waving my hands somewhat, the minimum amount of work to reliably benefit from multiple threads on most systems is in the neighborhood of hundreds of thousands of cycles.
I'd like to chime in and contribute with another geometry library I've been working on for a little while now: GitHub - LuizZak/Geometria: Swift geometry-related types and algorithms. I've been attempting a more type-agnostic and generic approach to the definitions inspired in part by Swift Numerics. The idea is to be good on the foundations while not giving up on performance too much. If anyone wants to check out what's available and see if it fits your needs there's documentation available here: Reference.
