JuliaAI / MLJ.jl

A Julia machine learning framework
https://juliaai.github.io/MLJ.jl/
Other
1.78k stars 157 forks source link

Want Some Code? #233

Open caseykneale opened 5 years ago

caseykneale commented 5 years ago

I have a Julia package with a lot of methods, metrics, preprocessing, etc. I find them to be highly useful, maybe you all would too? Feel free to scrape my repo for recyclable code:

https://github.com/caseykneale/ChemometricsTools.jl

As much as I'd like to directly contribute to this package I think it's a little to large, and it's written in a way I'd have to spend a lot of time - that I don't have to help :/.

vollmersj commented 5 years ago

@caseykneale: thanks a lot for this. I might look into wrapping some of your preprocessing. It would be great if you could give us some feedback what we could improve to make this easier.

ablaom commented 5 years ago

Yes, many thanks for pointing out this excellent package, of which I was not aware.

I wonder if you could comment on which of the regression/classifier models are pure julia and which are wraps?

The list of regression methods currently includes: CLS, Ridge, Kernel Ridge, LS-SVM, PCR, PLS(1/2), ELM's, Regression Trees, Random Forest, Monotone Regression... More to come. Chemometricians love regressions!

LDA/PCA with Gaussian discriminants, also Hierchical LDA, multinomial softmax/logistic regression, PLS-DA, K-NN, Gaussian Naive Bayes, Classification Trees, Random Forest, Probabilistic Neural Networks, LinearPerceptrons, and more to come. You can also conveniently dump classification statistics to LaTeX/CSV reports!

caseykneale commented 5 years ago

All of them are in pure Julia - Cheers. Maybe technically the PCA/SVD is done via a wrapper, but, that's about it I think.

ablaom commented 5 years ago

Awesome!

Are you planning to maintain your existing package? If so a better plan might be for us to submit a PR, or series of PRs, to ChemometricsTools.jl which implement the MLJ interface for your models natively. The extra code could be an optional dependency using Requires.jl, and so have no impact on existing use of your pkg (but would add some testing overhead). Are you open to this?

ablaom commented 5 years ago

This would also possibly increase exposure for your package.

caseykneale commented 5 years ago

Interesting. Yes I am planning to continue maintaining and improving the package over time. It might help get some additional hands on deck to reduce my load. I've been fighting to find time to kick off a new package in a different field. I'm totally open to any form of collaboration, refactoring, you name it to make this more useful for everyone. I just don't have much time to learn another code-base right now. Just started a new job.