Hi @all I've made this chat room for dask-glm conversation
With dask/dask-glm#21 I've now passed through all of @moody-marlin 's original routines and made them as fast as they're likely to get with the current systems. We have some super-basic testing in place. What's next? Some questions:
I have yet to look at the ADMM code. Is this in a ready state?
I made a dask/dask-glm#22 that puts the ADMM code in a ready state for anyone to review
that was supposed to say “pull request"
Also, @mcg1969 — you are correct that the line searches actually aren’t requiring as many function evaluations as I believed, so I don’t have anything to send you — however, the BFGS code is failing a high-level test (sum of predictions = sum of actuals) and I can’t seem to determine why, so any insights there would be helpful
@moody-marlin is there a reason why you alias lf = curr_val in compute_stepsize and never update it? It seemed like it might be the sort of thing that you would update lf = func from time to time.
@mrocklin sorry so late to this; i need a desktop app for gitter to send me notifications! lf is the base function value that we are comparing against for "sufficient decrease", so once the new func value is "sufficiently" smaller than lf we exit -- however, there was no reason why i chose to redefine curr_val to lf