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!
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
## 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/).
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.
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# 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# 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.
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.
We prefer a couple small pull requests over a single large one that targets multiple things at once.
### When fixing a bug ...
### 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
## 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.
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.
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.
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.
* Linear Algebra: Vectors explicitly provide proper L1, L2 and L-infinity norms.
* 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).
* 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).
* Matrix L-infinity norm now cache-optimized (8-10x faster).
* Linear Algebra: Vectors have a `ConjugateDotProduct` in addition to `DotProduct`.
* Vectors have a `ConjugateDotProduct` in addition to `DotProduct`.
* Linear Algebra: `Matrix.ConjugateTransposeAndMultiply` and variants.
* `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.
* 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.
* QR factorization is thin by default.
* Matrix factorizations no longer clone their results at point of access.
* Matrix factorizations no longer clone their results at point of access.
* Add direct factorization-based `Solve` methods to matrix type.
* Add direct factorization-based `Solve` methods to matrix type.
* Massive iterative solver implementation/design simplification, now mostly generic and a bit more functional-style.
* 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
* Matrix RemoveRow/RemoveColumn; more efficient InsertRow/InsertColumn
* Native Linear Algebra/Intel MKL:
* Native Linear Algebra/Intel MKL:
* Thin QR factorization uses MKL if enabled for all types (previously just `double`)
* 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).
* 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.
* 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 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 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.
* 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:
* Statistics:
* Pearson and Spearman correlation matrix of a set of arrays.
* Pearson and Spearman correlation matrix of a set of arrays.
* Spearman ranked correlation optimized (4x faster on 100k set)
* Spearman ranked correlation optimized (4x faster on 100k set)
Christoph Ruegg
13 years ago