Ok. Thanks for the comments!
On Mon, Aug 8, 2016 at 6:22 PM, Gael Varoquaux <
gael.varoqu...@normalesup.org> wrote:
> On Mon, Aug 08, 2016 at 03:10:26PM +0200, Raghav R V wrote:
> > I felt we could rather have a clean build and wait for a few more
> minutes (if
> > that's the disadvantage of
On Mon, Aug 08, 2016 at 03:10:26PM +0200, Raghav R V wrote:
> I felt we could rather have a clean build and wait for a few more minutes (if
> that's the disadvantage of disabling caching) than have it pass / fail on old
> code...
Time of CI is a real problem. On our side because it slows down
Thanks for the pointers and papers. I'd definitely go through this approach
and see if it can be applied to my problem.
Thanks,
Amita
On Fri, Aug 5, 2016 at 4:40 PM, Albert Thomas
wrote:
> Hi,
>
> About your question on how to learn the parameters of anomaly detection
I realize this is in early stages and I'd like to help improve it, even if
just by testing on an actual cluster. All of the examples I've seen are
very small, and it's impossible for anyone to notice if they're really
running in parallel judging just by the execution time. None of them
mention how
I don't think they're too fast. I tried with slower models and bigger data
sets as well. I get the best results with n_jobs=20, which is the number of
cores on a single node. Anything below is considerably slower, anything
above is mostly the same, sometimes a little slower.
Is there a way to see