On 09/10/2015 06:16 PM, Joel Nothman wrote:
> the documentation implies these are for advanced use by (generally)
> not referencing them in the narrative documentation. I think that's a
> fair way to keep them only for the sight of those who dig deeper, but
> this implicitness leaves some main
A reflective response without a clear opinion:
I'll admit to rarely-if-ever using function versions, and suspect they
frequently have limited utility over the estimator interface. Occasionally
they even wrap the estimator interface, so they're not going to provide the
efficiency advantages Gaël ta
On 09/10/2015 10:08 AM, Gael Varoquaux wrote:
>> >And your statement "they are for advanced users" is not manifested in
>> >the API or documentation.
> OK, but that's a bug of the documentation.
So you suggest adding to the docstring of every function "this is for
advanced users only"?
That is k
On Thu, Sep 10, 2015 at 09:52:44AM -0400, Andy wrote:
> I feel it is quite awkward if the function and the estimator have
> different requirements on X.
That's a point of view. But they are different things, so I am not sure
that this point of view is universal.
> And your statement "they are fo
On 09/10/2015 09:22 AM, Gael Varoquaux wrote:
>
> These functions are important for reuse in an algorithmic setting: if I
> am doing an algorithm that uses k-means or lars_path inside the
> algorithm, it is much more natural to use the functions, and they have
> less overhead.
>
> I think that the
On Wed, Sep 09, 2015 at 02:10:05PM -0400, Andreas Mueller wrote:
> I see two possible ways forward:
> a) Make the functions private and deprecate the public interface, like
> k_means, lars_path,
These functions are important for reuse in an algorithmic setting: if I
am doing an algorithm tha
I think all of the ones that I'm thinking of already have an estimator
interface.
On 09/09/2015 04:10 PM, Sebastian Raschka wrote:
> Might sound like a drastic step, but I would suggest a) making the functions
> private and deprecating the public interface. I think this would be easier on
> "n
Might sound like a drastic step, but I would suggest a) making the functions
private and deprecating the public interface. I think this would be easier on
"new" users, and more experienced people would still be able to use them on own
risk. And over time, some of those functions could optionally
Hi all.
A api issue that has been annoying me for some while is that we don't
have common tests for functions.
That means that incompatibilities are only fixed if someone points them
out in an issue, and API changes like
https://github.com/scikit-learn/scikit-learn/pull/5152
I see two possible w
