Math.NET Numerics is driven by the community and contributors like you. I'm excited that you're interested to help us move forward and improve Numerics. We usually accept contributions and try to attribute them properly, provided they keep the library consistent, focused and mathematically accurate. Have a look at the following tips to get started quickly. I'm looking forward to your pull requests! Thanks!
— *Christoph Rüegg (@cdrnet), Maintainer*
— *Christoph Rüegg (@cdrnet)*
## Getting Started
@ -13,16 +13,16 @@ Math.NET Numerics is driven by the community and contributors like you. I'm exci
We use the [Fork & Pull Model](https://help.github.com/articles/using-pull-requests/), as common for GitHub projects. If you've already contributed to another GitHub project then you're all set. If not, [here is another introduction](https://gun.io/blog/how-to-github-fork-branch-and-pull-request/).
**C# Solutions, Projects and Files**
**C# Solutions, Projects and Files**
We have two kind of C# projects: primary (*Numerics.csproj, UnitTests.csproj*) and secondary (*Numerics-xy.csproj, UnitTests-xy.csproj*). The primary ones are the common VisualStudio project files you usually work with. The secondary projects on the other hand are not intended to be modified and include all files automatically. Whenever you need to add, remove or move a file, please do so in the primary projects only. In most cases we recommend to work with the `MathNet.Numerics.sln` solution which only includes primary projects anyway - except when working on and testing portability/compatibility.
**F# Projects**
F# does not support the wildcard approach of the C# projects by design, so whenever you add, remove or move an F# file please manually update all F# projects accordingly, including the secondary platform specific ones in the `MathNet.Numerics.Portable.sln` solution. This is a bit tedious but we have not found a better solution yet.
**F# Projects**
F# does not support the wildcard approach of the C# projects by design, so whenever you add, remove or move an F# file please manually update all F# projects accordingly, including the secondary platform specific ones in the `MathNet.Numerics.All.sln` solution. This is a bit tedious but we have not found a better solution yet.
**Separate Branch per Pull Request**
**Separate Branch per Pull Request**
We recommend that you create a separate branch for each pull request, as opposed to using master. This makes it much easier to continue working on a pull request even after it has been opened on GitHub. Remember that GitHub automatically includes all future commits of the same branch to the pull request.
**Focused**
**Focused**
We prefer a couple small pull requests over a single large one that targets multiple things at once.
### When fixing a bug ...
@ -49,11 +49,11 @@ Should you stumble on weird English grammar or wording please do fix it - most o
## What to Avoid
**Code Reformatting and Refactoring:**
**Code Reformatting and Refactoring:**
Please avoid starting with a major refactoring or any code reformatting without talking to us first.
**Breaking Compatibility:**
**Breaking Compatibility:**
We try to follow [semantic versioning](http://semver.org/), meaning that we cannot break compatibility until the next major version. Since Numerics intentionally permits straight access to raw algorithms, a lot of member declarations are public and thus cannot be modified. Instead of breaking compatibility, it is often possible to create a new better version side by side though and mark the original implementation as obsolete and scheduled for removal on the next major version.
**Merges:**
**Merges:**
Please avoid merging mainline back into your pull request branch. If you need to leverage some changes recently added to mainline, consider to rebase instead. In other words, please make sure your commits sit directly on top of a recent mainline master.
* Reworked redundancies, inconsistencies and unfortunate past design choices.
* Significant namespace simplifications (-30%).
* Linear Algebra:
* Linear Algebra: Favor and optimize for generic types, e.g. `Vector<double>`.
* Linear Algebra: Drop the `.Generic` in the namespaces and flattened solver namespaces.
* Linear Algebra: F#: all functions in the modules now fully generic, including the `matrix` function.
* Linear Algebra: F#: `SkipZeros` instead of the cryptic `nz` suffix for clarity.
* Linear Algebra: Add missing scalar-matrix routines.
* Linear Algebra: Optimized mixed dense-diagonal and diagonal-dense operations (500x faster on 250k set).
* Linear Algebra: More reasonable choice of return structure on mixed operations (e.g. dense+diagonal).
* Linear Algebra: Add point-wise infix operators `.*`, `./`, `.%` where supported (F#)
* Linear Algebra: Vectors explicitly provide proper L1, L2 and L-infinity norms.
* Linear Algebra: All norms return the result as double (instead of the specific value type of the matrix/vector).
* Linear Algebra: Matrix L-infinity norm now cache-optimized (8-10x faster).
* Linear Algebra: Vectors have a `ConjugateDotProduct` in addition to `DotProduct`.
* Linear Algebra: `Matrix.ConjugateTransposeAndMultiply` and variants.
* Linear Algebra: Matrix Factorization types fully generic, easily accessed by new `Matrix<T>` member methods (replacing the extension methods). Discrete implementations no longer visible.
* Linear Algebra: QR factorization is thin by default.
* Favor and optimize for generic types, e.g. `Vector<double>`.
* Drop the `.Generic` in the namespaces and flattened solver namespaces.
* F#: all functions in the modules now fully generic, including the `matrix` function.
* F#: `SkipZeros` instead of the cryptic `nz` suffix for clarity.
* Add missing scalar-matrix routines.
* Optimized mixed dense-diagonal and diagonal-dense operations (500x faster on 250k set).
* More reasonable choice of return structure on mixed operations (e.g. dense+diagonal).
* Vectors explicitly provide proper L1, L2 and L-infinity norms.
* All norms return the result as double (instead of the specific value type of the matrix/vector).
* Matrix L-infinity norm now cache-optimized (8-10x faster).
* Vectors have a `ConjugateDotProduct` in addition to `DotProduct`.
* `Matrix.ConjugateTransposeAndMultiply` and variants.
* Matrix Factorization types fully generic, easily accessed by new `Matrix<T>` member methods (replacing the extension methods). Discrete implementations no longer visible.
* QR factorization is thin by default.
* Matrix factorizations no longer clone their results at point of access.
* Add direct factorization-based `Solve` methods to matrix type.
* Massive iterative solver implementation/design simplification, now mostly generic and a bit more functional-style.
@ -64,12 +64,12 @@
* Matrix RemoveRow/RemoveColumn; more efficient InsertRow/InsertColumn
* Native Linear Algebra/Intel MKL:
* Thin QR factorization uses MKL if enabled for all types (previously just `double`)
* MKL: Sparse matrix CSR storage format now uses the much more common row pointer convention and is fully compatible with MKL (so there is nothing in the way to add native provider support).
* MKL: Providers have been moved to a `Providers` namespace and are fully generic again.
* MKL: MKL native provider now supports capability querying (so we can extend it much more reliably without breaking your code).
* MKL: MKL native provider consistency, precision and accuracy now configurable (trade-off).
* MKL: Native Provider development has been reintegrated into the main repository; we can now directly run all unit tests against local native provider builds. Covered by FAKE builds.
* Sparse matrix CSR storage format now uses the much more common row pointer convention and is fully compatible with MKL (so there is nothing in the way to add native provider support).
* Providers have been moved to a `Providers` namespace and are fully generic again.
* MKL native provider now supports capability querying (so we can extend it much more reliably without breaking your code).
* MKL native provider consistency, precision and accuracy now configurable (trade-off).
* Native Provider development has been reintegrated into the main repository; we can now directly run all unit tests against local native provider builds. Covered by FAKE builds.
* Statistics:
* Pearson and Spearman correlation matrix of a set of arrays.
* Spearman ranked correlation optimized (4x faster on 100k set)
Christoph Ruegg
13 years ago