Okay, great that the links are bounded buffers. 1st UBF; So those links need to be built into the component (encoder, region classifier) and at runtime the components figure out what type of links they are depending on the contract as given by UBF.
UBF is split up into 3 bits a transport format, type system and contracts. The contracts make sure the components don't miscommunicate. Here is a recent implementation of ubf: https://github.com/ubf/ubf 2nd Networking; I'm wrestling with this, it's quite mental, framing, asynchronous io, etc its a lot of work. But it makes for a very simple and easy way to snap components together. There should be one way of doing things. This way is optimal and fast and super simple way to stack things together in a distributed environment. I'm warming to nanomsg. 3rd Snapshotting; what is most valuable in life? Lessons learnt. Its what keeps us alive. Therefore the component should be responsible for snapshotting its own learning and storing it. This should be the default behaviour. Also sharing lessons/learning is important, so we should be able to tell a component 'send your patterns to X address' and it does. This way, I can run my application and it doesn't have to relearn everything from scratch everytime I shut down my computer. Just a side note on sending raw data from the solar panels. I understand and appreciate your suggestion it will indeed be more efficient but if I prick my toe, that sensation is converted to SDRs immediately on site and transmitted from the toe to the brain. I don't have to prick the brain in a certain part. Therefore the link from panel over GSM to main house to datacentre could be seen as the nervous system. As we'll have many moving pieces we will want to make sure the communication between different systems is solid, this has already been shown by use of contracts. which UBF has, (notice how the github.com/ubf/ubf has many different formats thrift etc. We need to expand our nervous system and be able to translate data into SDRs asap then over whatever medium transfer those SDRs and get them processed in a region. Contracts keep things sane, especially when humans can't understand the SDRs in transit! Subutai Ahmad <[email protected]> wrote: >Yes, this is a pretty straightforward case that is supported (as long >as >the microcontroller supports C++). In this case it might be better to >not >use an encoder on the panels since encoder output is generally are more >inefficient than the original numbers. It might be best to transmit the >raw >data and instantiate the encoders in the Philippines. > >All the Link classes use bounded buffers already (fixed length >contiguous >buffers). The dimensions are fixed at network construction time and the >Regions have access to the pointers. Or, the application can just >ignore >that and instantiate encoders, algorithms directly. > >We don't have UBF or networking right now. I'm interested to learn more >about UBF. I don't know much about it other than it's used in Erlang. >Networking could be added in - not sure yet if that belongs in >nupic.core >or in supporting libraries. That would be something we'd want to decide >together. > >--Subutai > Kind regards Stewart -- Please excuse my typos and brevity _______________________________________________ nupic mailing list [email protected] http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org
