Adapt MNIST example to use the original lecun data files

[jrp2014]

This version downloads and uses the MNIST data files, converting the data from Word8 to Double. The runMNIST.sh script does the work.

Unfortunately, it still runs out of memory on my Ubuntu VM...

Anyway, I hope that it's of some use.

[jrp2014]

The CI seems to confirm that it's not just an issue with my setup.

[erikd]

The Data.Semigroup import needs to be wrapped in some CPP goop.

Let me do that in a separate PR.

[erikd]

In general PRs should change only what absolutely must be changed.

[erikd]

More semantically NULL changes.

[erikd]

I am actually wondering why we don't just update the documentation.

[erikd]

For PR branches like this one, you really should rebase rather than merge,

[erikd]

Is that a comma in that file name or a period?

Should probably also use a #!/bin/bash -eu at the top as well.

[erikd]

Also, can stack and cabal be use interchangablly there?

[erikd]

I think this shell script can be made quite a bit nicer. I can do that but may not get a chance before the weekend.

[jrp2014]

Sounds good. The script is an extract of a retread of a retread :-)

[jrp2014]

The CI fails because gan-mnist takes too long to generate 15 examples. mnist itself still uses too much memory to run.

[erikd]

Where is this this PR going? If this is ever to be merged it should be rebased against master and commits like "ci typo" need to be squashed down.

[jrp2014]

Thanks @erikd. I want to find time over the w/e to kick the tyres some more:

• better run script (so that args can be passed)
• use that to limit travis.yaml test runs so that they pass within time and space constraints
• improve formatting / intelligibility of output
• try some different example models in mnist
• a couple of lines of documentation on how to run, easily
• optimization (eg, by profiling) for time / space improvements
• git hygiene

Are you going to be able to refactor the script?

[erikd]

Probably best if I wait until you finish what you are working on and then assuming everything is ok, I will do done final clean up run

[erikd]

Big PRs with mainy unrelate changes are far more difficult to review than a series of small PRs that only change one thing.

There is already one large, long running PR against Grenade that is likely to never be merged because it contains a huge number of unrelated changes and that PR branch has diverged from master. Changes on that branch will be need to be cherry picked, tested, evaluated indvcidiually which is significantly more work that if they had been submitted as s stream of small simple PRs.

[erikd]

A new example is a great idea, but should probably be a separate PR from the other changes you are making.

Having them a separate make reviewing both PRs easier.

[jrp2014]

Understood. In this case the changes are focused on making the examples run (which they now do, as you can see from the travis output). I think that I've got to a stage where the pieces are in place. If you want to improve the run scripts, I think that that would be good. I'd be happy to flesh out some of the documentation, if that would help.

[erikd]

Not too sure it the examples should run in CI. Will have a look.