Thank you for your points, will def. add them to the poll.
This is not a product or production application. This is a framework for experimentation.
I agree, in a way. I’m open for more rapid and extreme changes, but on the other hand, I’d like to have a fork that is “an actively developed continuation of the Numenta’s repositories”. So that Numenta can try to sync once in a while, if they wish, and people who build their apps on top of it can continue to use a fixed and developed descendant. So I’ll also add
- compatibility (more or less) with the current Numenta API
- rapid (vs conservative) development (API breakage)
- unit-test coverage (each new feature is tested)
- keep c++ / Py feature+API parity (vs the repos can separately diverge and live on their own)
Note, I’m collecting ideas to ask here, not that I’d agree with all the points I’m listing here.
library should be focused on how easy it is to understand even by someone that is not a professional programmer
I’m not sure about this one. Either they are scientists and focus mainly on the papers/NeuroSci, or programmers who focus (and know) the internal workings, or application users, who use products based on HTM (Grok, HTM schools, …)…imho
I would not really care about whitespaces and coding-style so much (always Matt had to punch me to do that )
…if someone discovers a new way to do SP and has a working implementation in Python we should help them port that to C++ and add it to the library if they are unable to do that themselves
Careful with this, of course we’ll do it if we like that or it’s uber cool feature; but you might soon end up porting code you are not interested at.
More ponts, ideas for the poll, what you want from future nupic?