>> it was more a suggestion for a brave young contributor :)
>
> You mean the person that specifically needs such a documents :}
at least you'll know that the "how to contribute" page has been read
by one more person...
A
--
2012/9/18 Rob Zinkov :
> How much of
> http://scikit-learn.org/stable/developers/index.html#contributing-code
> is appropriate to
> port over and place in markdown?
I'd say as much as is necessary to submit a bugfix, and ideally not
more than fits on one (reasonably-sized) screen. The Git stuff h
> How much of
> http://scikit-learn.org/stable/developers/index.html#contributing-code
> is appropriate to port over and place in markdown?
I would suggest making a separate smaller file that would:
1. First point to the URL above and strongly push contributors to read
it.
2. Insist on the most
How much of
http://scikit-learn.org/stable/developers/index.html#contributing-code
is appropriate to
port over and place in markdown?
On Tue, Sep 18, 2012 at 7:50 AM, Gael Varoquaux
wrote:
>> it was more a suggestion for a brave young contributor :)
>
> You mean the person that specifically need
> it was more a suggestion for a brave young contributor :)
You mean the person that specifically needs such a documents :}
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security
> Yes. If you do so
it was more a suggestion for a brave young contributor :)
A
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how
2012/9/18 Alexandre Gramfort :
> hi,
>
> it can you missed it on github:
>
> https://github.com/blog/1184-contributing-guidelines
>
> shall we create such a contributing file based on the how to contribute page?
Yes. If you do so, please close this:
https://github.com/scikit-learn/scikit-learn/i
hi,
it can you missed it on github:
https://github.com/blog/1184-contributing-guidelines
shall we create such a contributing file based on the how to contribute page?
Alex
--
Live Security Virtual Conference
Exclusive
> Cannot you just replace
> self.coef_path_ = np.zeros((n_targets, n_features, max_iter + 1))
> by
> self.coef_path_ = np.zeros((n_targets, n_features, min(max_iter,
> n_features) + 1))
In the case of Lasso (not Lars) nothing garanties that the path only has
n_features kinks. In practice it wil
On Mon, Sep 17, 2012 at 11:37 PM, Gael Varoquaux
wrote:
> Indeed, you are right. I had a look at the code, and the reason why this
> happens is to support multiple output (i.e. y being a 2D matrix).
> The relevent code is around line 508 in least_angle.py
>
> That said, it is clearly suboptimal in
> I suggest that we:
>
> * Special case the situation with only one output
> * Trim the coef_path down in the case of multiple output
>
> What do people think? I can prepare a PR.
+1
A
--
Live Security Virtual Confer
> Not really: the normalization in linear models rescales the coefficients
> after the estimation, so that the linear model with estimated
> coefficients is true for the given data.
it is the same but it's just more efficient as it avoids modifying X_test
A
--
On Tue, Sep 18, 2012 at 09:14:46AM +0200, Alexandre Gramfort wrote:
> Thinking of it, having this normalization feature in the
> linear estimators is redundant with what the scalers in
> sklearn.preprocessing are doing...
Not really: the normalization in linear models rescales the coefficients
aft
> I just notice that the default values of the `normalize` argument for
> Lars and Lasso are different. For Lars it is set to True, while for
> Lasso is set to False. lasso_path also set the default value of
> `normalize` to False.
>
> Since Lars and Lasso are "close cousins", I would expect them t
14 matches
Mail list logo
