Decouple IO train/predict

[pjankiewicz]

Hi @ankane. I was looking for some Rust based FM / FFM and I found your crate. Good job! It looks quite clean. I would like to test it on my problem. However I would like to skip serialization of my data before I call train/predict. If someone is using Rust and your crate as a library it could be easier to maybe pass the data itself than save it to disk first - which could be a lengthy process. In general it is almost always a good idea to decouple input and output from the actual algorithm.

I propose to change the signatures of the methods to something like this

pub fn train(&mut self, x: Vec<Vec<Node>>, y: Vec<f32>) // of course using references instead of Vec would be probably a good idea
pub fn predict(&self, x: Vec<Vec<Node>>) 
pub fn train_from_file(...)
pub fn predict_from_file(...)

Actually... when I think about it more it perhaps is more complicated than I thought because there should be some Iterator implemented to read the data from the disk. So in fact the signature for x would be more like

train(..., data: I)
where
    I: IntoIterator<Item = (&[Node], &f32)>

And then there should be an Iterator implemented for file based data.

If you are ok with such a change I could contribute this. Let me know your thoughts.

[ankane]

Hey @pjankiewicz, thanks for the suggestion! Agree it'd be nice to pass data directly to the library and the interface above makes sense to me, so happy to review a PR. I don't have a strong opinion on the slice vs iterator approach (the slice seems more straightforward and the iterator more flexible/better for large datasets).

[ankane]

Cleaning up issues, but still open to a PR.