Closed Tasignotas closed 9 years ago
This is certainly something we want to get done soon!
We still need to decide how we want to test sparse properly. Maybe we will want some general mechanism to switch out different projection types in the GCAL tests?
I suppose I could make a new ty file in topo/tests
(next to gcal_legacy.ty
) which subclasses ModelGCAL
, only switching out the normal dense projection for a sparse one. If we end up with even more projection types to test in future, it may be possible to parametrise this file to switch between a number of different projection types (as long as the test results are to match the dense version!).
For now, I suggest we call it gcal_sparse.ty
even though there won't be any significant sparsity in the weights used (we don't have a suitable model for this just yet). At least this will test that the results match the dense version as expected.
Unless anyone has any objections, I might go and implement this additional test tonight. My only worry is that Jenkins may not have Cython (and maybe it needs installation of doozy).
I asked Ignotas a few days ago to make a pull request for a test that basically just duplicates one of our existing tests, but using the sparse projection support. It won't actually be noticeably sparse, but that should test nearly all of what the code does. I agree that a new file in topo/tests is the right approach, at least for now.
Doozy has Cython for Python 2.7 already. No idea about Jenkins; you can check the VM.
Tests for sparse Topographica have been merged.
Even though the implementation of sparse projections has been merged with master, no tests were included. This has to be done in order to be confident about the correctness of the code and allow topographica users to start using sparse projections in their work.