It was the first thing I looked at, if you recall the earliest conversations with Luiz - and our meeting? However, I moved away from that after I had no immediate success due to the fast moving circumstances in the background where Marcus and @amalta were just getting started on their TM enhancements. I had a two-pronged obligation to keep up with the porting effort and debug the NAB issue - which I felt I could solve all at once by simply ensuring that the port re-writing and testing were held to an extremely rigorous standard (which they indeed were).
Hindsight has now shown that the preponderant probability is that the issue lies elsewhere outside of the algorithms or network - though there were a few issues that got cleaned up along the way; but we couldn't have known this at the beginning.
Actually, HTM.Java has a very thought-out Parameters system that I've been advocating that something similar and Pythonic, be used with NuPIC too. (see the wiki which describes its use, here).
It's very nice, parameters are configured and then applied via
Parameters.apply(<any object>) (It can be any object because they are applied via reflection. For now, they're only "applied" to a
Connections object. The
Connections object contains the column/cell matrix and operations to mutate it. Parameters in HTM.Java have bounds, type, and range validation too! As a whole, the
Parameters object can be manipulated also. For instance, you can get just ones that apply to a particular algorithm (such as
Parameters.getSpatialDefaultParameters()) - or you can get all the defaults - and copy them, or do a union with other Parameters; to combine them with another
In HTM.Java, the algorithms have no state - they are just "actions" applied to a column/cell structure - and so the variables were removed from the algorithms and placed inside the
Connections object. This has several advantages, which I've been preaching about but I'm not going to go into here. (Having to do with serialization, and ability to employ concurrency, among others...)
At the algorithm level, HTM.Java has every single parameter that NuPIC does - since its a direct port. However, the Network API is different, and also there is no corollary for an OPF - so it does not contain the exact NuPIC OPF parameters that act upon the network as a whole. Those would be the only difference.
My next task is to do a deep dive into the configurations transference and see if I can find any problem there... And too, I haven't yet run the NAB with the most recent changes - so I have to see what the state of things are.