search

numenta / nupic-legacy

Numenta Platform for Intelligent Computing is an implementation of Hierarchical Temporal Memory (HTM), a theory of intelligence based strictly on the neuroscience of the neocortex.
http://numenta.org/
GNU Affero General Public License v3.0
6.34k stars 1.56k forks source link

Python-only platform-independent build of NuPIC? #1302

Open breznak opened 10 years ago

breznak commented 10 years ago

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 https://github.com/numenta/nupic.core/issues/103

subutai commented 10 years ago

@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 commented 10 years ago

:100:

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 commented 10 years ago

@subutai @rhyolight This pure python version also could solve this : https://github.com/numenta/nupic/issues/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 commented 10 years ago

@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 commented 10 years ago

@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 commented 10 years ago

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 :+1: 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 commented 10 years ago

@david-ragazzi :+1: 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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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.

:+1: 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 commented 9 years ago

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:

Remember that iorange is dead code and is being removed here: https://github.com/numenta/nupic/pull/1579

david-ragazzi commented 9 years ago

Please see this: https://github.com/numenta/nupic/issues/1728 Probably PyPy will help us with removal of C++ bindings without a traumatic loss of performance!

dstromberg commented 5 years ago

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.