Skip to content
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

Feature Request - Constraining Covariates #1

Closed
michaelwhammer opened this issue Apr 18, 2017 · 4 comments
Closed

Feature Request - Constraining Covariates #1

michaelwhammer opened this issue Apr 18, 2017 · 4 comments
Assignees

Comments

@michaelwhammer
Copy link

@michaelwhammer michaelwhammer commented Apr 18, 2017

It would be useful if the functions in this package supported or provided arguments similar to glmnet::glmnet()'s lower.limits and upper.limits. I frequently run adaptive elastic nets using glmnet and regularly have to constrain covariates to be non-negative or non-positive.

@nanxstats nanxstats self-assigned this Apr 18, 2017
@nanxstats
Copy link
Owner

@nanxstats nanxstats commented Apr 18, 2017

@michaelwhammer -- that's a very good suggestion -- as I'm going to make more important vanilla glmnet/ncvreg arguments available for msaenet, this one could have a high priority.

@michaelwhammer
Copy link
Author

@michaelwhammer michaelwhammer commented Apr 18, 2017

Additionally, if it's possible to enable a ... argument to allow for any argument to passed on to glmnet/ncvreg. I don't know if this would cause confusion as many arguments in msaenet seem to be wrappers around arguments in glmnet/ncvreg.

@nanxstats
Copy link
Owner

@nanxstats nanxstats commented Apr 19, 2017

-- that is a very good point. I guess there is a certain balance between the flexibility and clarity for the API design:

  • ... was supported in the first versions, then it was removed on purpose to avoid possible confusions. If you look into the code, the internal parameter tuning functions support ..., while the current implementation does not expose this API to the user. This ensures clarity but sacrifices flexibility.
  • another design consideration would be keeping the high-level interface of different wrappers for glmnet and ncvreg as similar/consistent as possible -- so only a minimal but critical set of arguments was selected in the present implementation. This also increases clarity while decreases flexibility.

After these, we can consider adding more flexibility -- lower.limits/upper.limits can be a good start.

@nanxstats
Copy link
Owner

@nanxstats nanxstats commented Apr 24, 2017

@michaelwhammer -- this has been fixed by 5e10777. The new version (v2.6) has been submitted to CRAN. In the same time, you can try the GitHub version using

devtools::install_github("road2stat/msaenet")

Here is some code for testing:

library("msaenet")

dat = msaenet.sim.gaussian(
  n = 150, p = 500, rho = 0.6,
  coef = rep(2, 5), snr = 5, p.train = 0.7,
  seed = 1001)

fit0 = msaenet(
  dat$x.tr, dat$y.tr,
  alphas = seq(0.05, 0.95, 0.05),
  nsteps = 3L, seed = 1003)

print(fit0)
msaenet.nzv(fit0)
msaenet.fp(fit0, 1:5)
msaenet.tp(fit0, 1:5)
msaenet.pred = predict(fit0, dat$x.te)
msaenet.rmse(dat$y.te, msaenet.pred)
plot(fit0)

fit1 = msaenet(
  dat$x.tr, dat$y.tr,
  alphas = seq(0.05, 0.95, 0.05),
  nsteps = 3L, lower.limits = 0L,
  seed = 1003)

print(fit1)
msaenet.nzv(fit1)
msaenet.fp(fit1, 1:5)
msaenet.tp(fit1, 1:5)
msaenet.pred = predict(fit1, dat$x.te)
msaenet.rmse(dat$y.te, msaenet.pred)
plot(fit1)

Please feel free to let me know if it does not work as expected. Thanks!

-Nan

@nanxstats nanxstats closed this Apr 24, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.