I’m looking to build the 3.x work-in-progress version, but I don’t know how to get started.
I’ve installed pybind11 2.0.1-4, and am on a Linux Mint 19.1 system.
If I run py.test from the top-level directory, I get lots of:
ModuleNotFoundError: No module named ‘nupic’
I assume this means I need to generate the pybind bindings, but how?
It appears 2 of the links in the message I’m replying to are dead now.
Thanks!
Dan, it might help you to see how I got the nupic.cpp working in python 3 here:
Python2 -> Python3 is a big change - more than Python1 -> Python2 was, and more than Python3 -> Python4 will be.
The biggest change is that strings are unicode by default instead of a bunch of octets. Also, parts of the extension module API changed.
The one people complain about the most is probably that print became a function instead of a statement.
Originally, the core team wanted us to run our code through 2to3, but a lot of people have been finding that writing code to work on both as a single codebase, works pretty well.
Hi @breznak
Are we done with nupic.py py2 to py3 migration? If not what are the remaining issues?
Cheers
Hi Jose,
The community fork of nupic fully supports both python2 as well as python3.
However the codebase as a whole is not yet stable so we are not advertising that its done.
I’m hoping to try a nearly-1-million-line-project that currently uses Numenta nupic with nupic.cpp before long.
In what ways are nupic.cpp anticipated to be less than fully production-ready? Does it trackback? Segfault? Give wrong results?
PS: I was pleased by the unit test situation for nupic.cpp.
Worse than a segfault, we’re changing the public API. No more argument names like “n” or “w” means ppl using those keyword arguments will need to rewrite stuff. Also im making all of the algorithms use an SDR object instead of lists of floats, which is another big change for the existing users to deal with. In the near future we hope to rename / reorganize all of the modules …
I see.
I’m sympathetic to the desire to have non-mathy-terse names in code.
When I worked on a bloom filter module, I found that the literature tended to use “n” and “p” as variable names, which I didn’t care for much. So I started using ideal_num_elements_n and error_rate_p.
I hope the changes can be incorporated into the relevant bits of documentation. 
Thanks.