Hi Eric and Scott, >>Eric wrote: >>Python bindings significantly lower the barrier to entry and >>adoption, in my opinion. People who don't know python very well, can still do >>something with nupic and get some value out of the predictions relatively >>quickly, as I believe was evidenced by the hackathon. Yes, you are right. Python is well know as an excelent language to prototyping which allow scientists (with non computational background) make experiments. So, I think we could use Python as a prototype tool, but C++ as functional code (but not integrated one-to-one). >From I understood, Scott says that the plans are keeping sincronized versions >for python and c++ but with automated tools for check inconsistences. My >suggestion is keep sincronized versions but with Python as just a design tool >and C++ as the functional code, i.e. discarding dependency between them and >thus discarding several tools to support the integration. The development process could be: - Any new features should be FIRST writen and tested in Python code. This way, people interested on research wouldn´t need know C++ and other tools to get used to CLA.- Once these new features are accepted and well integrated in Python code, C++ code assimilate the changes. This way people interested in take advantage of the code wouldn´t need know Python and integration tools.- C++ project WOULD NOT receive directly changes for business logic. The allowed changes would bug fixes, optimizations, etc. In other words, Python would play role in analysis/design phases such as UML and other tools do, while C++ would play role in implementation phases, i.e. the real code. My suggestion, of course. My best wishes, David
On 16 July 2013 05:03, Erik Blas <[email protected]> wrote: Python bindings significantly lower the barrier to entry and adoption, in my opinion. People who don't know python very well, can still do something with nupic and get some value out of the predictions relatively quickly, as I believe was evidenced by the hackathon. On Mon, Jul 15, 2013 at 10:58 PM, Scott Purdy <[email protected]> wrote: We intend to keep both the Python and C++ versions. The Python version will probably always use some swigged C++ code such as the sparse matrix in the spatial pooler but the C++ version will be pure, portable C++. And we will also swig the C++ implementation for different languages and run it against the same Python test site to ensure they stay in sync functionally.That is the plan now at least. It may change so don't hold me to it. And do let me know if you have a strong opinion for or against it.On Jul 15, 2013 9:43 PM, "Erik Blas" <[email protected]> wrote:I always get a kick out of that tool's name. I am sad to see the python support go, as it made for quick prototyping of projects, and understand why it would also make the platform more portable as a whole. Perhaps I'll get to the point of keeping a python port.
_______________________________________________ nupic mailing list [email protected] http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org
