-
-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix algorithms "newton", "gradient_descen" and "proximal_grad" with cupy inputs #87
Changes from 5 commits
fecd27f
fcb0d4d
a247c15
c16925a
6a369e7
1dcf6ad
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -97,7 +97,7 @@ def gradient_descent(X, y, max_iter=100, tol=1e-14, family=Logistic, **kwargs): | |
stepSize = 1.0 | ||
recalcRate = 10 | ||
backtrackMult = firstBacktrackMult | ||
beta = np.zeros(p) | ||
beta = np.zeros_like(X._meta, shape=(p)) | ||
|
||
for k in range(max_iter): | ||
# how necessary is this recalculation? | ||
|
@@ -161,7 +161,7 @@ def newton(X, y, max_iter=50, tol=1e-8, family=Logistic, **kwargs): | |
""" | ||
gradient, hessian = family.gradient, family.hessian | ||
n, p = X.shape | ||
beta = np.zeros(p) # always init to zeros? | ||
beta = np.zeros_like(X._meta, shape=(p)) | ||
Xbeta = dot(X, beta) | ||
|
||
iter_count = 0 | ||
|
@@ -387,7 +387,7 @@ def proximal_grad(X, y, regularizer='l1', lamduh=0.1, family=Logistic, | |
stepSize = 1.0 | ||
recalcRate = 10 | ||
backtrackMult = firstBacktrackMult | ||
beta = np.zeros(p) | ||
beta = np.zeros_like(X._meta, shape=(p)) | ||
regularizer = Regularizer.get(regularizer) | ||
|
||
for k in range(max_iter): | ||
|
@@ -406,8 +406,8 @@ def proximal_grad(X, y, regularizer='l1', lamduh=0.1, family=Logistic, | |
# Compute the step size | ||
lf = func | ||
for ii in range(100): | ||
beta = regularizer.proximal_operator(obeta - stepSize * gradient, stepSize * lamduh) | ||
step = obeta - beta | ||
beta = regularizer.proximal_operator(- stepSize * gradient + obeta, stepSize * lamduh) | ||
step = - beta + obeta | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm curious, why this change? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. When There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Maybe you could do There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It doesn't matter either way. Either way is fine. Can we report this upstream to cupy? Presumably they need to return NotImplemented somwhere? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I know, just providing a more Dask-like solution.
I don't know exactly what error we get, but would reporting it change anything? Would returning There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If a Python object doesn't know what to do with another operand in a binary operator, it can return NotIimplemented (or maybe it's raise?) and then Python will try the other order (calling There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks @mrocklin , I didn't know of that. I filed cupy/cupy#4118 to start the discussion on the CuPy side, I'm not sure but maybe there's a technical reason not to do that, so let's wait to hear from maintainers. |
||
Xbeta = X.dot(beta) | ||
|
||
Xbeta, beta = persist(Xbeta, beta) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that we probably don't need the extra parens around
p
here and below