Mec-iS
commented
2 years ago yes smartcore started as an attempt to follow Python libraries' naming and operational interfaces. So any improvement in this direction is welcome.
no it was decided initially as design principle to keep smartcore strictly a pure-Rust library. This implies considering a longer timeframe but a more consistent choice in terms of safety. So ideally we should bring in existing solutions when licenses allow or code from scratch. For example I was considering taking the backbone of kodama because it is a great library for clustering while keeping its C++ extensions out (ideally porting them to Rust eventually).
It would be great to put down a plan. Maybe we can organise a brief conf-call for bootstrapping the process and put down some milestones.
EDIT: IMO before doing anything relevant we should go through with #108 Also another design principle was to not use macros, so to keep things readable and accessible to newcomers.
One of the nice things about the python ecosystem is that many of the libraries have all adopted the same fit/predict interfaces as scikit, (e.g. xgboost, lightgbm), which allows 3rd party libraries to interact with them all in a more abstract manner. It would be nice if the smartcore api could similarly be extended in Rust for the xgboost bind gen project, but this would have to take place in one or the other library, since 3rd party crates can't impl traits.
Is there a plan to either implement bindings for some of the existing crates, or otherwise bindgen c/c++ implementations, or implement them from scratch, or just leave them as 3rd party?