Re: proposal to shut down apache-mxnet.slack.com

there are several private channels on apache-mxnet.slack.com, how we are going to deal with it? On Mon, Oct 16, 2017 at 10:19 PM, Hen wrote: > +1. > > On Mon, Oct 16, 2017 at 10:01 PM, Chris Olivier > wrote: > > > +1. Nuke it. > > > > > > On Mon, Oct

Re: proposal to shut down apache-mxnet.slack.com

+1. On Mon, Oct 16, 2017 at 10:01 PM, Chris Olivier wrote: > +1. Nuke it. > > > On Mon, Oct 16, 2017 at 8:23 AM Steffen Rochel > wrote: > > > As we have now migrated the majority of people from > apache-mxnet.slack.com > > to the-asf.slack.com I

Build failed in Jenkins: mxnet_incubator_master » ubuntu-17.04 #136

See -- Started by upstream project "mxnet_incubator_master" build number 136 originally caused by: Started by an SCM change Building in workspace

Re: Improving and rationalizing unit tests

This thread is very timely, as it relates to issues I've been trying to solve with my coding of the last week. I think it simplest just to present the code and detailed PR description as the clearest form of my thinking. Happy to discuss further. Please see:

Build failed in Jenkins: mxnet_incubator_master » armv6 #136

See -- Started by upstream project "mxnet_incubator_master" build number 136 originally caused by: Started by an SCM change Building in workspace

Re: Improving and rationalizing unit tests

This thread is very timely, as it relates to issues I've been trying to solve with my coding of the last week.  I think it simplest just to present the code (and detailed PR description) as the clearest form of my thinking.  Happy to discuss further.  Please see:

Jenkins build is back to normal : mxnet_incubator_master » armv7 #137

See

Jenkins build is back to normal : mxnet_incubator_master » armv6 #137

See

Build failed in Jenkins: mxnet_incubator_master » cmake.ubuntu-17.04 #136

See -- Started by upstream project "mxnet_incubator_master" build number 136 originally caused by: Started by an SCM change Building in

Build failed in Jenkins: mxnet_incubator_master » android.armv7 #136

See -- Started by upstream project "mxnet_incubator_master" build number 136 originally caused by: Started by an SCM change Building in workspace

Jenkins build is back to normal : mxnet_incubator_master » ubuntu-16.04-cuda_8.0_cudnn5 #137

See

Jenkins build is back to normal : mxnet_incubator_master » arm64 #137

See

Build failed in Jenkins: mxnet_incubator_master » armv7 #136

See -- Started by upstream project "mxnet_incubator_master" build number 136 originally caused by: Started by an SCM change Building in workspace

Jenkins build is back to normal : mxnet_incubator_master » android.armv7 #137

See

Jenkins build is back to normal : mxnet_incubator_master » ubuntu-17.04 #137

See

Build failed in Jenkins: mxnet_incubator_master » arm64 #136

See -- Started by upstream project "mxnet_incubator_master" build number 136 originally caused by: Started by an SCM change Building in workspace

[BUILD FAILED] Branch master build 535

Build for MXNet branch master has broken. Please view the build at https://builds.apache.org/job/incubator-mxnet/job/master/535/

Re: proposal to shut down apache-mxnet.slack.com

+1. Nuke it. On Mon, Oct 16, 2017 at 8:23 AM Steffen Rochel wrote: > As we have now migrated the majority of people from apache-mxnet.slack.com > to the-asf.slack.com I would like to suggest to shut down > apache-mxnet.slack.com. > This will minimize the number of

disposing all ndarray in a given context

Quoting: https://github.com/apache/incubator-mxnet/blob/master/scala-package/core/src/main/scala/ml/dmlc/mxnet/NDArray.scala#L545-L546 * WARNING: it is your responsibility to clear this object through dispose(). * NEVER rely on the GC strategy Is there a way to say "dispose all ndarrays of this

[BUILD FAILED] Branch master build 532

Build for MXNet branch master has broken. Please view the build at https://builds.apache.org/job/incubator-mxnet/job/master/532/

Re: Improving and rationalizing unit tests

Here’s a package that may help us on flaky tests: https://pypi.python.org/pypi/flaky. It can retry tests that are marked flaky and can pass or fail based on specified threshold. In the short term we can use this to pass tests that are not 100% reliable. Best regards, -sz On 10/16/17, 10:32

RE: Improving and rationalizing unit tests

I think you’ve covered the pros/cons of having determinism in your tests. It seems like a potential maintenance effort versus forced code robustness argument to me. I’d suggest you have a separate vote on this topic. For me the main topic that should be focused on is making the CI system fast

Re: Improving and rationalizing unit tests

My argument is that I am actually categorically against having a requirement that the same input values be used for testing for every run. I don't personally view "convenience in reproducing" as outweighing "finding edge cases that I didn't think of or that haven't been tried before". On Mon,

Re: Improving and rationalizing unit tests

It's always going to be deterministic one way or another unless you use random from the entropy pool such as /dev/random. I don't think it's a good practice not to seed properly and have values depend on execution order / parallelism / time or whatever, but that's just my opinion. I would want to

Re: Improving and rationalizing unit tests

My take on the suggestion of purely deterministic inputs is (including deterministic seeding): "I want the same values to be used for all test runs because it is inconvenient when a unit test fails for some edge cases. I prefer that unforseen edge case failures occur in the field and not during

Re: Improving and rationalizing unit tests

I'd like to respectfully dispute the assumption that it's hard to debug with random values: If a test is failing with any sort of frequency, it's easy to come up with offending values by running the test in a loop for 1 times or so. I did this just yesterday to prove a test case was also

Re: Improving and rationalizing unit tests

I would be great if there is a chance of a few testcase to reflect these principles, so we have a concrete discussion basis. Having seeded random number is good, but usually it is not the cause of non deterministic error( most of which already resolved by having a relaxed tolerance level).

Re: Improving and rationalizing unit tests

For the randomness argument, I am more concerned of a unit test that exhibits different behaviors for different runs. Stochastic test, IMHO, is not a good sanity test, because the code entry Quality bar is stochastic rather than deterministic — causing a lot of churn for diagnosing Unit test

Re: Improving and rationalizing unit tests

That’s true Pedro. I assumed, in this particular context, when we say “random” numbers we mean random numbers which have not been explicitly seeded which make the intermittently failing unit tests hard to reproduce. On Oct 16, 2017, at 8:51 AM, Pedro Larroy

Re: proposal to shut down apache-mxnet.slack.com

+1 to disable old slack, but keep old messages viewable. Bhavin Thaker. On Mon, Oct 16, 2017 at 8:23 AM Steffen Rochel wrote: > As we have now migrated the majority of people from apache-mxnet.slack.com > to the-asf.slack.com I would like to suggest to shut down >

Re: Improving and rationalizing unit tests

That's not true. random() and similar functions are based on a PRNG. It can be debugged and it's completely deterministic, a good practice is to use a known seed for this. More info: https://en.wikipedia.org/wiki/Pseudorandom_number_generator On Mon, Oct 16, 2017 at 5:42 PM, pracheer gupta

Re: Improving and rationalizing unit tests

@Chris: Any particular reason for -1? Randomness just prevents in writing tests that you can rely on and/or debug later on in case of failure. On Oct 16, 2017, at 8:28 AM, Chris Olivier > wrote: -1 for "must not use random numbers for input"

Re: Improving and rationalizing unit tests

-1 for "must not use random numbers for input" On Mon, Oct 16, 2017 at 7:56 AM, Bhavin Thaker wrote: > I agree with Pedro. > > Based on various observations on unit test failures, I would like to > propose a few guidelines to follow for the unit tests. Even though I use

proposal to shut down apache-mxnet.slack.com

As we have now migrated the majority of people from apache-mxnet.slack.com to the-asf.slack.com I would like to suggest to shut down apache-mxnet.slack.com. This will minimize the number of channels anybody should watch and discussions going in parallel. Anybody who was not able to join

Re: Improving and rationalizing unit tests

I agree with Pedro. Based on various observations on unit test failures, I would like to propose a few guidelines to follow for the unit tests. Even though I use the word, “must” for my humble opinions below, please feel free to suggest alternatives or modifications to these guidelines: 1) 1a)

Improving and rationalizing unit tests

Hi Some of the unit tests are extremely costly in terms of memory and compute. As an example in the gluon tests we are loading all the datasets. test_gluon_data.test_datasets Also running huge networks like resnets in test_gluon_model_zoo. This is ridiculously slow, and straight impossible on