Am 05.12.2019 um 23:22 schrieb Allin Cottrell: > I've been working lately on a lasso package for gretl. It's not at the > point of uploading for approval (among other things, it doesn't have a > GUI hook yet) but I'd be grateful if anyone is willing to try some > testing and give me feedback. Hi Allin, great news of course! I haven't tested yet, just looked at the pdf and code a little. Very interesting that you are doing a hansl package for that instead of pure C, at least as the middle layer.

One question about the syntax w.r.t. the hidden backend: err = _admm_lasso(X, Y, ret) apparently stuffs results into 'ret'. From a Hansl point of view it is of course strange that you can pass ret without pointerizing it then.

Another question concerning your speed discussion in the pdf: The numbers sound quite good. But you just say "glmnet is faster" without any number there. What factor are we roughly talking about - 50%? 100%?

Am 05.12.2019 um 23:22 schrieb Allin Cottrell: > I've been working lately on a lasso package for gretl. It's not at > the > point of uploading for approval (among other things, it doesn't > have a GUI hook yet) but I'd be grateful if anyone is willing to try > some testing and give me feedback. The sample script runs fine on Windows, and apparently uses MPI alright! From the code I understand that the full coeff vector (ret.b) is suppressed if a lambda sequence is used, because all those vectors are in ret.B. OK. I was still wondering, however, if it could make sense to have the full vector repeated for the optimized case in ret.b. That would be the analogue to the single set of non-zero coefficients provided in ret.nzb. But do I understand correctly that ret.B[, ret.idxmin] does give that optimized full coefficient set?

Apart from that on a meta level I was also wondering whether Artur's packages TsCrossValidation and/or CvDataSplitter could benefit from the cross validation approach used, or the other way around.