LIDA Roadmap?

[delbert]

hello all,

is there a roadmap for LIDA, please?

from reading the documentation, it sounds like Procedural Memory and
Action Selection modules are in development, along with new learning
models.

i am also curious about the roadmap from an architectural
perspective. i think the current implementation makes complete sense,
based on a Java framework, common design patterns, and Java idioms
(XML config, Java properties, etc). but this all runs in one JVM,
right now. are there plans to break the system into OSGi bundles that
can be deployed separately? or perhaps plans to move to a model that
can take advantage of multiple cores or a cloud platform (ala AKKA)?

thanks,
delbert

[Ryan J. McCall]

Hi Delbert,

Thank you for your interest and for the questions.

On Sat, Oct 8, 2011 at 6:31 PM, delbert <del...@haiku-fu.com> wrote:

hello all,

is there a roadmap for LIDA, please?

Yes internally we have discussed some goals for the next version of the framework (Perhaps we should display these publicly somehow...):

1. At AGI-11 we got lots of feedback asking for learning, additionally it's an important part of the model.  So I'd like to implement learning in 4 places for the next framework version: we're well on our way for PAM, Episodic Memory, and Attentional Learning.  Procedural learning hasn't been worked on...

2. A second main goal is adding a better action selection based on Maes' behavior network.  This is going to lead to some changes to Procedural Memory as well. Javier and I began working on this last week. We hope to finish it by the end of the year and to have a new version of the framework at that time too.

Other goals that may or may not make the next release include:

3. XML support for GUI panel customization.

4. Agent persistence i.e. the ability to load and save agent states.

We've already made several smaller changes and will surely make a few more for the next version but these are the main things that come to mind at the moment.
 

from reading the documentation, it sounds like Procedural Memory and
Action Selection modules are in development, along with new learning
models.

i am also curious about the roadmap from an architectural
perspective.

Sure I can describe that:

Sensory Memory - I'm actively working on a detailed Sensory Memory including some vision algorithms and a few other fun things as part of my dissertation project. 

PAM - Short term we won't make too many changes here, longer term we have some ideas...

Workspace - I think we'll drop the Episodic and Perceptual Buffers and just have the Current Situational Model and Conscious Content Queue. Not a huge change.

Episodic Memory - Javier and Rodrigo have been working here and they can tell you more about it.

Attention Codelets - Changes have been made (new attention codelets, learning) and will appear in the next version.  I don't see a whole lot more changes happening here without some conceptual changes in the LIDA model first.

Global Workspace - No major plans

Procedural Memory - Our implementation is somewhat basic now but it works.  We have to implementing learning which may not be trivial. We have to implement scheme reliability. We should probably also experiment with different ways to excite schemes from the broadcast.

Action Selection - As I mentioned we're working on a new version.

Sensory-Motor Memory - My dissertation work may add some things to this module in the future.  I know Daqi and some others are working on some conceptual ideas for SMM.

 i think the current implementation makes complete sense,
based on a Java framework, common design patterns, and Java idioms
(XML config, Java properties, etc).  but this all runs in one JVM,
right now.  are there plans to break the system into OSGi bundles that
can be deployed separately?  or perhaps plans to move to a model that
can take advantage of multiple cores or a cloud platform (ala AKKA)?

Yes we had a similar question at AGI-11. Right now we don't have strong motivation to go multi-core -- of course this may not always be the case. The reason being is that we're still working out the implementation of LIDA, we're using simple input and domains.  Eventually when the nuts and bolts are ironed out I'm sure we'll be tackling problems with higher resources requirements.  I am not too familiar with the technologies you mention -- however if you want to propose something or start a discussion I'd be happy to hear about it.

Best,

Ryan
 

thanks,
delbert

--
You received this message because you are subscribed to the Google Groups "Cognitive Computing Research Group - CCRG" group.
To post to this group, send email to ccrg-m...@googlegroups.com.
To unsubscribe from this group, send email to ccrg-memphis...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/ccrg-memphis?hl=en.

--
Ryan J. McCall
Ph.D. Candidate, Dept. of Computer Science
Cognitive Computing Research Group
Institute for Intelligent Systems
The University of Memphis

[delbert]

thanks Ryan.

this is extemely helpful.

i will digest what you have provided and will get more familiar with
the existing framework.

given what you have in the works for LIDA, it probably makes sense to
keep the implementation as multiple threads, all in the same JVM, just
because it is easier to develop and to debug. then, when the Modules
have fairly distinct and stable interfaces--and there is a need to go
to a cloud deployment or multi-server deployment, then other
frameworks for distributed computing can be investigated.

thanks again,
delbert

On Oct 9, 8:00 pm, "Ryan J. McCall" <mccall.r...@gmail.com> wrote:
> Hi Delbert,
>
> Thank you for your interest and for the questions.
>