Closed floybix closed 7 years ago
Happily, clojure.spec came along. I'm starting work on using it to describe and test the code.
Starting in cells.cljc
.
I already spec'd the layer parameters: https://github.com/floybix/comportex/commit/1c757726c26d415984702860e75dbb890ee82e63 At the moment they are all listed together and checked once. I think the checking should be at the implementation level, checking the specific keys that are needed -- e.g. specific params needed by different inhibition algorithms or homeostasis algorithms.
I'm proposing to get rid of the defrecord
s and replace them with spec'd maps. I used records in the first place mainly just as a way to list the expected keys. While it is fine to spec records, you just end up listing the keys twice (once in the spec and once in defrecord).
This is, I think, a no-brainer in the case of LayerActiveState, LayerDistalState, etc. It's less clear however in the case of LayerOfCells. That record is defined with implementations of several protocols:
So I guess I will keep it as a record.
I have a feeling that activate/learn/depolarise
would be nicer as multi-methods, but I'm not sure.
Figuring out how to spec the generic functions in the org.nfrac.comportex.protocols
namespace while leaving implementation details in their separate namespace. It can be done with multispec
. As part of this it seemed more natural to replace the layer getters -- active-columns, bursting-columns, active-cells
, etc -- with a single layer-state
that returns a map. If anyone is watching please take a look and tell me if i'm crazy... https://github.com/floybix/comportex/commit/6b5008d7c9ec8bd5ae93edc332d77d1c228a4a2b
We should have some better automated tests. But avoiding the unproductive mess of lots of naive example-based tests.
Thinking specifically of
Even Simulation-based testing would arguably be appropriate for HTMs, but not sure I want to invest too much time on that at the moment.
Any thoughts?