Files

Lorenzo 52eb6ce023 Merge potential next release v0.4 (#187 ) Breaking Changes

* First draft of the new n-dimensional arrays + NB use case
* Improves default implementation of multiple Array methods
* Refactors tree methods
* Adds matrix decomposition routines
* Adds matrix decomposition methods to ndarray and nalgebra bindings
* Refactoring + linear regression now uses array2
* Ridge & Linear regression
* LBFGS optimizer & logistic regression
* LBFGS optimizer & logistic regression
* Changes linear methods, metrics and model selection methods to new n-dimensional arrays
* Switches KNN and clustering algorithms to new n-d array layer
* Refactors distance metrics
* Optimizes knn and clustering methods
* Refactors metrics module
* Switches decomposition methods to n-dimensional arrays
* Linalg refactoring - cleanup rng merge (#172)
* Remove legacy DenseMatrix and BaseMatrix implementation. Port the new Number, FloatNumber and Array implementation into module structure.
* Exclude AUC metrics. Needs reimplementation
* Improve developers walkthrough

New traits system in place at `src/numbers` and `src/linalg`
Co-authored-by: Lorenzo <tunedconsulting@gmail.com>

* Provide SupervisedEstimator with a constructor to avoid explicit dynamical box allocation in 'cross_validate' and 'cross_validate_predict' as required by the use of 'dyn' as per Rust 2021
* Implement getters to use as_ref() in src/neighbors
* Implement getters to use as_ref() in src/naive_bayes
* Implement getters to use as_ref() in src/linear
* Add Clone to src/naive_bayes
* Change signature for cross_validate and other model_selection functions to abide to use of dyn in Rust 2021
* Implement ndarray-bindings. Remove FloatNumber from implementations
* Drop nalgebra-bindings support (as decided in conf-call to go for ndarray)
* Remove benches. Benches will have their own repo at smartcore-benches
* Implement SVC
* Implement SVC serialization. Move search parameters in dedicated module
* Implement SVR. Definitely too slow
* Fix compilation issues for wasm (#202)

Co-authored-by: Luis Moreno <morenol@users.noreply.github.com>
* Fix tests (#203)

* Port linalg/traits/stats.rs
* Improve methods naming
* Improve Display for DenseMatrix

Co-authored-by: Montana Low <montanalow@users.noreply.github.com>
Co-authored-by: VolodymyrOrlov <volodymyr.orlov@gmail.com>

2022-10-31 10:44:57 +00:00

3.7 KiB

Raw Blame History

Contributing

When contributing to this repository, please first discuss the change you wish to make via issue, email, or any other method with the owners of this repository before making a change.

Please note we have a code of conduct, please follow it in all your interactions with the project.

Background

We try to follow these principles:

follow as much as possible the sklearn API to give a frictionless user experience for practitioners already familiar with it
use only pure-Rust implementations for safety and future-proofing (with some low-level limited exceptions)
do not use macros in the library code to allow readability and transparent behavior
priority is not on "big data" dataset, try to be fast for small/average dataset with limited memory footprint.

Pull Request Process

Open a PR following the template (erase the part of the template you don't need).
Update the CHANGELOG.md with details of changes to the interface if they are breaking changes, this includes new environment variables, exposed ports useful file locations and container parameters.
Pull Request can be merged in once you have the sign-off of one other developer, or if you do not have permission to do that you may request the reviewer to merge it for you.

generic guidelines

Take a look to the conventions established by existing code:

Every module should come with some reference to scientific literature that allows relating the code to research. Use the //! comments at the top of the module to tell readers about the basics of the procedure you are implementing.
Every module should provide a Rust doctest, a brief test embedded with the documentation that explains how to use the procedure implemented.
Every module should provide comprehensive tests at the end, in its mod tests {} sub-module. These tests can be flagged or not with configuration flags to allow WebAssembly target.
Run cargo doc --no-deps --open and read the generated documentation in the browser to be sure that your changes reflects in the documentation and new code is documented.

Issue Report Process

Go to the project's issues.
Select the template that better fits your issue.
Read carefully the instructions and write within the template guidelines.
Submit it and wait for support.

Reviewing process

After a PR is opened maintainers are notified
Probably changes will be required to comply with the workflow, these commands are run automatically and all tests shall pass:
- Coverage (optional): tarpaulin is used with command cargo tarpaulin --out Lcov --all-features -- --test-threads 1
- Formatting: run rustfmt src/*.rs to apply automatic formatting
- Linting: clippy is used with command cargo clippy --all-features -- -Drust-2018-idioms -Dwarnings
- Testing: multiple test pipelines are run for different targets
When everything is OK, code is merged.

Contribution Best Practices

Read this how-to about Github workflow here if you are not familiar with.
Read all the texts related to contributing for an OS community.
Read this how-to about writing a PR and this other how-to about writing a issue
read history: search past open or closed issues for your problem before opening a new issue.
PRs on develop: any change should be PRed first in development
testing: everything should work and be tested as defined in the workflow. If any is failing for non-related reasons, annotate the test failure in the PR comment.

3.7 KiB Raw Blame History