Tests are too slow

[dfdx]

Currently tests run more than 2 hours on Travis, which is unreasonably long. The main cause for this is a brute force approach in which we test every supported element type with every possible visible and hidden unit type for both - dense and sparse input - plus different sets of options. The principal question is how to exclude most flows, but keep coverage high. Any suggestions are welcome.

[rofinn]

Reducing the sizes of the RBM and input data for those tests doesn't help enough?

Also, this is probably related to running the tests with coverage being particularly slow. Ideally, we should be able to run the fast tests with coverage and the benchmarking and acceptance/performance tests without. I've opened in an issue here to make this easier to do, but in the mean time we could probably just use an environment variable to specify groups of tests to run.

I'll include some test refactoring with a benchmarking PR which should at least partly address this.

[rofinn]

Tests down to around 30-40 min with coverage and benchmarking here

[dfdx]

I think we can also decompose tests into parts. Though we need to test every kind of visible and hidden units and every option, we don't need to test every combination of units and options. Essentially, kinds of units affect only sampling functions, while options in most cases control some specific functions, independent of sampling and each other. There are other independencies that we can use to drastically reduce test time.

(Ironically, exactly the same decomposition of independent parts is what distinguishes restricted Boltzmann machines from fully-connected Boltzmann machines :))