Such external folder size is necessary in case of we want have a decreased compile time, i.e. if we already have the static libs, we don't need compile them but just link them. Obviously, the price paid is an increasead download time.
Just for clarify: the 4/210 MB numbers are for nupic.core (c++), not nupic (pyhton). On 2 February 2015 at 21:14, David Ragazzi <[email protected]> wrote: > Actually most of these bytes are due to "external" folder which contains > precompiled static libraries, headers and binaries, for Windows, Linux > 32/64, and Dawin. > > While "external" folder has about 210 MB, the other folders has all > together less than 4 MB!! Is not fault of HTM algorithms! > > On 2 February 2015 at 20:58, Michael Klachko <[email protected]> > wrote: > >> Lol, please don't shoot! >> >> I'm just trying to understand the complexity of HTM algorithms. What >> would an estimated line count of all HTM algoritms implemented in Nupic - >> just the algoritms? >> >> Btw, your example of 16k servers is wrong on multiple levels. First of >> all, same code was run on 3 servers two years later with the same results. >> Second, that code was performing a task whick Grok is not suited for. >> Finally, even if the task was the same, and Grok was more efficient, why >> would that mean it needed more code? >> > > > > -- > David Ragazzi > MSc in Sofware Engineer (University of Liverpool) > OS Community Commiter at Numenta.org > -- > "I think James Connolly, the Irish revolutionary, is right when he says that > the only prophets are those who make their future. So we're not > anticipating, we're working for it." > -- David Ragazzi MSc in Sofware Engineer (University of Liverpool) OS Community Commiter at Numenta.org -- "I think James Connolly, the Irish revolutionary, is right when he says that the only prophets are those who make their future. So we're not anticipating , we're working for it."
