Python-only platform-independent build of NuPIC?

[breznak]

I got to know, but never actually tried, that nupic has dual implementation of the classes - in python and c++ (where c++ is not complete yet).

So, would it be possible to build nupic with python-only version? (without swig, w/o dependency on nupic.core)
This would make it truly OS-independent (at the speed cost) and could help eg. people waiting on numenta/nupic.core-legacy#103

[subutai]

@breznak Very interesting proposal! I think this should be very possible with some work. There are some classes that call some C++ routines such as random number generation, and faster sparse matrix operations. We would need to create a pure python version of those. Not sure how the build system would work, as we would presumably want to support both options?

[david-ragazzi]

💯

I was planning just suggest that, @breznak !! As we would have some work, we already could write it using OO approach.. This would improve performance on NuStudio, because it could use inherited classes from NuPIC in addition to NuPIC become Windows-friendly, because it wouldn't have C++ stuff.

[david-ragazzi]

@subutai @rhyolight This pure python version also could solve this : #1246 among other issues.

I think that NuPIC Python and NuPIC C++ should be independent in code but dependent in concept. I mean that both should follow the same model/specification but NuPIC Python focusing on simplicity and NuPIC C++ on performance.

[subutai]

@david-ragazzi Even if we have a pure Python version of NuPIC, we still need to have a python + C++ version - the latter will be much faster than a pure python version. As such, I don't think we can avoid the pip/build issues.

[david-ragazzi]

@david-ragazzi Even if we have a pure Python version of NuPIC, we still need to have a python + C++ version - the latter will be much faster than a pure python version. As such, I don't think we can avoid the pip/build issues.

Yeah, but do you mean that this python + C++ would be only a binding to NuPIC C++, not a hybrid implementation, don't?

[breznak]

regarding the build process, yes, I think we should support both options, and agree that this pure python is more of a last resort for unsupported environments (due to speed). We already have a switch for building with or w/o swig, so I imagine changing the Cmake that if it's called with something like -DUSE_SWIG=OFF it would skip the nupic.core pull/build.

@david-ragazzi 👍 while I'm usually in favor for OOP changes, I hope this one could be a quickie with minimal work needed to be rewritten.

[david-ragazzi]

@david-ragazzi 👍 while I'm usually in favor for OOP changes, I hope this one could be a quickie with minimal work needed to be rewritten.

I understand your concern.. We could first have a version working well without swig, and then convert it to OO later..

[cogmission]

This is the gap I feel the Java version fills. It will be just as performant as the c++ version (for longer running processes due to cutting edge run time tech); be more mobile than any platform; easily installed in a blink of an eye; and reach more developers and have a greater accessibility in terms of ease-of-comprehension than any other platform.

Respectfully, NuPIC really should have had a Java offering in the first place I feel.

David
Sent from my iPhone

On Sep 13, 2014, at 1:46 PM, David Ragazzi notifications@github.com wrote:

@Davidragazzi while I'm usually in favor for OOP changes, I hope this one could be a quickie with minimal work needed to be rewritten.

I agree.. We could first have a version working well without swig, and then convert it to OO when it get stable..

—
Reply to this email directly or view it on GitHub.

[subutai]

Yeah, but you mean only the Python binding to NuPIC C++, ok? Not a hybrid implementation..

Yeah, basically what @breznak said. We would have two build options: one that would keep the current way plus another one for a pure python implementation.

[david-ragazzi]

Yeah, basically what @breznak said. We would have two build options: one that would keep the current way plus another one for a pure python implementation.

👍 It's ok for me (supposing that we should remove any implementation of SP and TP from it and put into to pure python implementation.. The current implementation should be only a binding of NuPIC C++..

[david-ragazzi]

Have someone working to remove sparse matrix from Python? If so we could remove nupic.bindings.math in future.. @cogmission Once that you ported this part to Java, could help us on this?

If this happen, we will have only 2 bindings:

• engine_internal: which is the binding for Network API which is located on NuPIC C++ repo.
• algorithms: which is the binding for CLA Algorithms also located on NuPIC C++ repo.

Remember that iorange is dead code and is being removed here: #1579

[david-ragazzi]

Please see this: #1728 Probably PyPy will help us with removal of C++ bindings without a traumatic loss of performance!

[dstromberg]

Did this ever go anywhere? What would need to be done? Where can the code be found? With January 1, 2020 around the corner (the EOL date for CPython 2.x), it's sounding pretty nice. It seems that being pure python, it could run on pypy, which might approach C++ for performance.

There's also the possibility of writing some portions of the pure python in cython. I've had some success in the past writing a single foo.m4 that can be used to automatically generate foo.py and foo.pyx.