Currently, no. mainly it’s because of 2 reasons
- Swift doesn’t have explicit loop vectorization and it’s probably a non-goal (though it tries to be aggressive about implicit vectorization). we do have SIMD types which presumably use SIMD instructions though you’d probably have to bend the type system to avoid copying matrices in order to use them.
- We don’t have fixed-size arrays. This has been discussed for years but has been effectively stalled for various reasons. avoiding dynamic memory allocations (for variable-size structures) in Swift is v difficult,, you can dodge it in simple programs if the lifetime of your array/matrix never exceeds a single scope (i.e. it never gets passed around), but of course this gets harder when you’re trying to expose an interface.
this doesn’t really count as a technical reason, but there are also unlikely to be many potential library authors who have the domain expertise to write a reliable linear algebra library. outside of official Apple Frameworks, there are only a handful of people who have the time to write these “infrastructure building blocks”, and most of them are concentrated around projects that benefit the most users, i.e. server infrastructure, tooling, etc.
Thanks for the answer. That's a pity. I see a lot of scientific computing code that's just awful, and I think part of that is because the languages scientists have to use are hard to learn to write in well. Swift might help them, and so the community should encourage these building blocks.
unfortunately, this forum is probably not the best place to try and change this, you would probably have better luck recruiting scientists who are currently using R/Python/C++, and trying to convince them to come to Swift and write scientific libraries in Swift. Swift isn’t easy to learn, but it’s a lot easier than linear algebra, and there are probably experienced swift users here (including myself) who’d be interested in collaborating with a domain expert to move the ecosystem off
A couple notes:
- a Swift "Eigen" would necessarily be quite different from Eigen. Protocols and generics look like templates, but they are very, very different in practice. This necessarily leads to very different choices in how to build such a library. Eigen is a C++ library through and through.
- Swift is still missing a bunch of language features that probably would be necessary to be competitive with Eigen:
- a finished design for control of cross-module specialization and inlining.
- a means to multi-version functions and dispatch according to CPU capabilities.
- a means to statically require that all heap allocations are optimized away in a section.
- compilerEvaluable or similar
- Eigen is decidedly not as magical as presented. It does very well on some benchmarks, but lags badly behind other implementations for some others. It isn't magic.
I disagree with @taylorswift about the difficulty of LA vs Swift; LA is easy. Programming in any language is harder. Designing good interfaces for LA is way harder than either. =)
Having worked with NLP scientists, mathematicians, etc. in the past, I believe that this is not the reason. Writing elegant Python, for example, is not that hard.
The bigger problem is that scientists usually have no training—and sometimes also not a lot of interest—in the craft of software engineering (this is fair; a lot of programmers don't have a lot of interest in the scientific domain, people have different interests and strengths). And it's also not always needed. If you write one-off batch scripts, it doesn't matter how ugly they are, software engineering practices start to matter when your code needs to be production ready and maintainable. I've had a lot of pushback because of things like "why does this matter, the code works", "it runs on my machine" etc. Changing these habits takes time but has IMHO nothing to do with the programming language used.
I definitely have to add my most extreme agreement of these statements.
I work at a company with a specialized search engine for medical data that includes a python library for interacting with the search engine. Most of our clients are hospital groups with teams of data scientists that use our software to write analytical reports using the python library. Frequently they write reports that "work" but take several days to complete (running over the weekend when general system usage is at its lowest) and so they call us to complain about how slow our software is (spoiler: it isn't. Our stuff is crazy fast).
The problem is that many of these people writing the reports are data scientists first and programmers second. I usually end up making only relatively minor changes to their reports which take the runtime from days down to hours. Small changes can have a bit impact when your report is analyzing hundreds of millions of medical records.
I experience a lot of this same pushback where our customers' data scientists will say things like, "well that looks basically the same so why does it matter?" and I end up having to explain the minutia of performant python programming principles (try saying that 10x fast).
As a result of these frequent issues there have been many discussions over the years about providing a C++ library for our search engine as well so that these reports could squeeze out even more performance, but the main issue is not the language. It's the lack of good programming practices that providing an interface in a new language wouldn't fix and would probably just make things worse.
While it may be useful to provide a similar interface in a new language that is easier to learn overall, if the people using the interface don't understand the new language or don't have an interest in learning the minutia of the language then it would be wasted time. If the people are already familiar with C++ and the Eigen framework then you would have to provide a very convincing argument for getting them to change languages and learn something new.
Worth noting that "people comfortable with C++ and Eigen" is actually the teeny-tiny tip of the iceberg. If you seriously want to convert a bulk of scientists, you're targeting "people familiar with Fortran and/or NumPy", not Eigen.
Yes, this is true. I was mainly referring to that niche as that was the OP's initial query.
We do use NumPy and Pandas a lot in our reports and it would probably be a huge benefit to have something like NumPy in swift to convince python data scientists that swift is a viable alternative. I haven't played around with the swift-python interop at all but I'd be interested to see how well swift interacts with a library like NumPy for data science stuff.
I’m working on a swift client for ROS 2 (Robot operating system) and this would help a lot. ROS currently supports c++ and python and c++ uses Eigen a lot. Having a well-designed eigen-like swift system would be really helpful. @scanon There’s also a potentially large audience to tap into as many robotics and autonomous vehicle companies use ROS and eigen.
I don’t see Swift suitable for robotics and autonomous driving domains until we have support for move semantics in the language.
This is why Rust is seen as a possible alternative to C++ in these fields.
@frameworklabs This is a bit of digression, but there's definitely a use case. Yes for core functionality it might not be as suitable as C++ in it its current state. But there's plenty of other fields such as visualization where it could be really useful. I've worked on multiple such projects and for quick prototyping Python is often the go-to, but Swift would make a compelling alternative. Plus there's room to grow, Swift is young and has plenty of areas for improvement. Chris Lattner has expressed also his desire to add move semantics to Swift.
Don’t get me wrong, I would love to see Swift capture the upcoming robotics domain.
Most of that development is on Linux and QNX though, not sure how even visualization in Swift would look like on these platforms.
What do you all thing about using a c/c++ backbone and a more elegant swift api on top? This is exactly how numpy works and it’s one of the most successful libraries of all time. It’s not as nice as a full swift implementation but it would solve the problem of swift missing certain features.