+1 I try to stay out of language/religious discussions (my own preferences are eclectic) but I'm very much in favor of keeping the high-level Python code current, mostly because that forces some architectural flexibility that is likely to be the first casualty of a full conversion to C++. I suspect that concurrent and probably even distributed processing will become important as people start building multi-region models and expecting them to respond in finite time. One *can* do parallel programming in C++, but you probably don't want to start there.
- Kevin p.s. but gosh, it would be nice to have the Python part of the build cleaned up. p.p.s. I've been contemplating an update to Greenspun's tenth rule: Any sufficiently complicated distributed C/C++ program contains an ad hoc, informally-specified, brittle, unreliable implementation of half of Erlang. On Jul 16, 2013, at 7:23 AM, David Ragazzi wrote: 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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[email protected]> http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org ________________________________ The material in this message is private and may contain Protected Healthcare Information (PHI). If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail.
_______________________________________________ nupic mailing list [email protected] http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org
