Giters

softmin / ReHLine

Regularized Composite ReLU-ReHU Loss Minimization with Linear Computation and Linear Convergence

Home Page:https://rehline.github.io/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Question: Version the C++ implementation under a dedicated repository

jjerphan opened this issue · comments

commented

Dear @yixuan and @statmlben,

Thank you for this truly magnificent piece of work.

Currently, both https://github.com/softmin/ReHLine-r and https://github.com/softmin/ReHLine-python vendor the C++ implementation.

I think having a third repository (for instance https://github.com/softmin/ReHLine-cpp) version the C++ implementation separately would allow it to:

What do you think of this proposal?

Best Regards,
Julien.

commented

Hi Julien, you can check out our ReHLine-SVM repository, which is a basically a single-header C++ library. Although it is tagged as an SVM solver, its core part is the function rehline::rehline_solver(), and the SVM solver is a simple wrapper of it. I'll try to add more documentation on the C++ interface, but most of the arguments should be straightforward.

commented

Thank you for your encouragement toward ReHLine! As you pointed out, we share the same rehline.h for both R and Python. Yixuan and I had a quick discussion on incorporating your comments: we are considering to update/expand the current ReHLine-SVM, containing only a single C++ header, into a version as ReHLine-cpp.

commented

Thank you for your prompt answers!

What do you think of having ReHLine be distributed on conda-forge?

It might be possible to distribute it under several packages, for instance:

  • rehline-cpp (or librehline or just even rehline) for the core C++ implementation
  • rehline-python for the Python bindings which would depend on rehline-cpp
  • rehline-r for the R bindings which would also depend on rehline-cpp

If you find it valuable, I can help when I get some time.

commented

Yeah, thanks for the kind help. We are still considering how to refactor the code and repository to make them more structured. Some current considerations are as follows:

  1. The core of rehline-cpp may be just one header file. Not sure if it is an overkill to distribute rehline.h as a separate package.
  2. Python and R packages have their own building system, so I feel that rehline-python and rehline-r do not need to depend on rehline-cpp. It would be easier to just include rehline.h in the Python/R source package.
  3. The Python and R packages are still in their early stages, and APIs may change a lot. It might be more responsible to first stabilize the interface before formally submitting to Conda/PyPI/CRAN.

If you have any thoughts or suggestions, feel free to leave comments here, and we really appreciate that.

commented
  1. The core of rehline-cpp may be just one header file. Not sure if it is an overkill to distribute rehline.h as a separate package.

This would allow people to use it via package manager's distribution.

  1. Python and R packages have their own building system, so I feel that rehline-python and rehline-r do not need to depend on rehline-cpp. It would be easier to just include rehline.h in the Python/R source package.

They indeed do not need to indeed. It might help having the implementation evolve independently from the interface, but this is slightly more involved from a packaging and maintenance point of view.

  1. The Python and R packages are still in their early stages, and APIs may change a lot. It might be more responsible to first stabilize the interface before formally submitting to Conda/PyPI/CRAN.

I agree.

I let you close this issue if you think it is resolved.