Project plans

Feature roadmap

Currently, the Swift Science package has only one module: Science. This module will be split into 2 (Statistics and Math) in the near future, with at least 3 more (Physics, Astronomy, and Chemistry) as the project grows. The purpose of this split is to allow for more fine-grained imports. But, for users that just want to easily import everything in Swift Science, there will still be an empty Science module that simply imports and re-exports the 5 modules.

The current status of (and potential future directions for) the modules are:

1. Statistics module: probability distributions and sample statistics are mostly implemented as of 0.1.0. Hypothesis testing is mostly implemented on main but is not yet on a package version. Future directions: random variables (including, if possible, support for arithmetic between random variables that follow different distributions) and stochastic processes.
2. Math module: this module is for various numerical utilities that are not (yet) in Swift Numerics. Future directions: fast Fourier transforms, solving linear systems, definite integration, and possibly an #integral macro for indefinite integration (that acts as a counterpart to the derivative operator from Differentiable Swift). Features from this module may be pitched for inclusion in Swift Numerics.
3. Physics module: currently nothing. Future directions: uncertainty propagation, unit-aware arithmetic (unless Swift Foundation implements this), and physical constants.
4. Astronomy module: currently nothing. Future directions: astronomical coordinates and working with FITS files. When we get to this module, it may be more appropriate to make it a separate package instead. (I am personally undecided.)
5. Chemistry module: currently nothing. Future directions: parsing formulae, balancing stoichiometry, and predicting pH. When we get to this module, it may be more appropriate to make it a separate package instead. (I am personally undecided.)

Integrating Swift Science with other packages

The 5 modules listed above cover a wide breadth of functionality, but keep in mind that we don't have to reinvent the wheel. If a free and open-source Swift package already implements features planned for Swift Science — or any other feature that would be a great fit for Swift Science — then we can consider including that package as a dependency, re-exporting it, and integrating other Swift Science features with that package. (For example, we currently do this with Swift Numerics, the official Swift package for numerical computing.) That said, we should only bundle an external package with Swift Science if the external package is relatively mature and implements the desired feature with multi-platform support, performance, and documentation that are all good and unambiguously better than what other packages (if any) offer. For example,

• LASwift is mature and high-quality, but it's not multi-platform. (This is because, currently, LASwift only supports using Accelerate as its backing BLAS/LAPACK framework, restricting its availability to Apple platforms.) So, even though a scientific computing package like Swift Science should come with linear algebra functionality, we should not bundle LASwift with Swift Science.
• There are multiple great Swift packages for arbitrary-precision integers and floats, but bundling one with Swift Science will have to wait until there's a clear, mature winner.

That said...

When deciding whether or not to:

• Add a new first-party feature to Swift Science, or
• Bundle an external package with Swift Science

We should keep in mind that we don't want Swift Science to become bloated or confusing. Linear algebra (from shaped arrays to solving linear systems), extended- or arbitrary-precision numerics, hypothesis testing, uncertainty propagation, and unit-aware arithmetic are just a few of the many examples of potential functionalities that are essential to a scientific computing package. But other features, while useful, may have too specific a use case to justify inclusion without risking feature bloat, and should be left as (or created as) a separate package.