Implement a generic read_csv method

[titoeb]

Looking into implementing #66.

[codecov-commenter]

Codecov Report

Merging #147 (10f18ea) into development (d305406) will increase coverage by 0.36%.
The diff coverage is 93.36%.

@@               Coverage Diff               @@
##           development     #147      +/-   ##
===============================================
+ Coverage        83.90%   84.26%   +0.36%     
===============================================
  Files               81       84       +3     
  Lines             8724     8989     +265     
===============================================
+ Hits              7320     7575     +255     
- Misses            1404     1414      +10     

Impacted Files	Coverage Δ
src/readers/io_testing.rs	84.44% <84.44%> (ø)
src/readers/error.rs	94.11% <94.11%> (ø)
src/linalg/mod.rs	62.63% <95.23%> (+4.05%)	⬆️
src/readers/csv.rs	95.68% <95.68%> (ø)
src/math/num.rs	82.69% <100.00%> (-1.40%)	⬇️
src/algorithm/neighbour/cover_tree.rs	84.29% <0.00%> (-0.42%)	⬇️
src/preprocessing/numerical.rs	89.62% <0.00%> (+0.74%)	⬆️
src/metrics/recall.rs	92.50% <0.00%> (+18.42%)	⬆️
src/metrics/precision.rs	92.50% <0.00%> (+18.42%)	⬆️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[Mec-iS]

hey. Thanks again for contributing.

Some notes:

• take a look to the warnings and linting, always run cargo fmt --all -- --check and cargo clippy --all-features -- -Drust-2018-idioms -Dwarnings.
• always add a dosctring on top of a new module using //! when you explain the content and objectives for the module: in this case for example

//! Load a `Matrix` from CSV file
//! * ...
//! * only accepting commas as separators
//! ...
//! Example:
//! ```
//! ...
//! matrix_from_csv::<f64, Vec<_>, DenseMatrix<_>>(
                    test_csv_file
                        .expect("Temporary file could not be written.")
                        .path()
                )
//!

"Example" part is important as code snippets are also compiled and used as tests.
The best examples of documentation are in files like src/linalg/cholesky.rs, we would like to stick to that standard.

• Adding the FromStr trait to RealNumber is for sure the rustucean way of doing it 👍🏼 maybe adding a test for RealNumber::from_str in src/math/num.rs would be an additional control, the more tests the better
• The convention for generic type in Rust and in this crate is T (not Type)

Great work, especially with the test coverage and error handling 💯

[titoeb]

hey. Thanks again for contributing.

Some notes:

• take a look to the warnings and linting, always run cargo fmt --all -- --check and cargo clippy --all-features -- -Drust-2018-idioms -Dwarnings.
• always add a dosctring on top of a new module using //! when you explain the content and objectives for the module: in this case for example

//! Load a `Matrix` from CSV file
//! * ...
//! * only accepting commas as separators
//! ...
//! Example:
//! ```
//! ...
//! matrix_from_csv::<f64, Vec<_>, DenseMatrix<_>>(
                    test_csv_file
                        .expect("Temporary file could not be written.")
                        .path()
                )
//!

"Example" part is important as code snippets are also compiled and used as tests. The best examples of documentation are in files like src/linalg/cholesky.rs, we would like to stick to that standard.

• Adding the FromStr trait to RealNumber is for sure the rustucean way of doing it 👍🏼 maybe adding a test for RealNumber::from_str in src/math/num.rs would be an additional control, the more tests the better
• The convention for generic type in Rust and in this crate is T (not Type)

Great work, especially with the test coverage and error handling 💯

Hi @Mec-iS !
Thanks for already looking into this, your comments make sense 👍 This is still a Draft PR so there is still a lot of work for me to do until it is ready to opened. Feel free to continue to comment on the progress of course, but also take into consideration that the implementation will probably change quite alot until then. I mainly opened the PR to make visible that I work on the issue and give you already a sense of the direction in which I am heading, I am very happy that you are overall like the changes.

[titoeb]

hey. Thanks again for contributing.

Some notes:

• take a look to the warnings and linting, always run cargo fmt --all -- --check and cargo clippy --all-features -- -Drust-2018-idioms -Dwarnings.
• always add a dosctring on top of a new module using //! when you explain the content and objectives for the module: in this case for example

//! Load a `Matrix` from CSV file
//! * ...
//! * only accepting commas as separators
//! ...
//! Example:
//! ```
//! ...
//! matrix_from_csv::<f64, Vec<_>, DenseMatrix<_>>(
                    test_csv_file
                        .expect("Temporary file could not be written.")
                        .path()
                )
//!

"Example" part is important as code snippets are also compiled and used as tests. The best examples of documentation are in files like src/linalg/cholesky.rs, we would like to stick to that standard.

• Adding the FromStr trait to RealNumber is for sure the rustucean way of doing it 👍🏼 maybe adding a test for RealNumber::from_str in src/math/num.rs would be an additional control, the more tests the better
• The convention for generic type in Rust and in this crate is T (not Type)

Great work, especially with the test coverage and error handling 100

• Linting now runs through
• I added docstrings when it was applicable.
• I replaced Type with T.