Environment updates

[Matthew Lohbihler]

If i have an environment that changes (in my case i need to apply gravity to objects), where should this be done? The decayModule method appears to be a candidate, but feels wrong. Do i need to create something similar to EnvironmentBackgroundTask in ALifeEnvironment? This is fine, but it seems odd that the environment wouldn't already be a task.

[Ryan J. McCall]

Matthew,

Then short answer is 'yes.' In general for module specific "background" tasks I suggest to

1) Have a private inner task class extending FrameworkTaskImpl. This task can be created in the init() method as is done in AlifeEnvironment.
2) Create a separate class, define a task type referencing this class (in the factory data xml file), and declare one of these tasks to be an initial task of the Environment module (in the agent xml file). SensoryMemoryBackgroundTask for the SensoryMemory module is an example of this.

decayModule is always called each tick and is intended for decaying the elements of the module.

The Environment is a specific type of FrameworkModule. My initial intuition was to have each module with one task-like component "built-in" to be a background tasks. However, it become apparent that some modules need many tasks while others require 0, so for generality FrameworkModules allow 0 to many tasks.

Best,

Ryan

On 10/5/12 10:52 AM, Matthew Lohbihler wrote:

If i have an environment that changes (in my case i need to apply gravity to objects), where should this be done? The decayModule method appears to be a candidate, but feels wrong. Do i need to create something similar to EnvironmentBackgroundTask in ALifeEnvironment? This is fine, but it seems odd that the environment wouldn't already be a task.

--
You received this message because you are subscribed to the Google Groups "Cognitive Computing Research Group - CCRG" group.
To view this discussion on the web visit https://groups.google.com/d/msg/ccrg-memphis/-/FqF0eeo_dQwJ.
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.

Find the Best Information on Myrtle Beach Employment Here!
http://click.lavabit.com/mz5kjhkiih3txr71gzewkwnf1j4137r3rpxuiqeewy84cdscsfwy/

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

[Matthew Lohbihler]

Thanks Ryan.

A minor point: the decayModule method has a "ticks" parameter, suggesting that the method not be called each tick, but only when somehow deemed necessary (in configuration somewhere?). Is this the case, or can the parameter be safely ignored?

[Ryan J. McCall]

Matthew,

Hmm, in my opinion the Javadoc wasn't clear enough about this method. Here's what I'm updating the Javadoc to:

     * Decays the elements of this {@link FrameworkModule} (not its submodules).
     * Framework users should not call this method. It will be called by the {@link TaskManager}.
     * However, specific {@link FrameworkModule} implementations may want to implement this method.
     * @param ticks number of ticks to decay for.
     * @see TaskManager

So the TaskManager calls this method for each module and specifies the amount of ticks (essentially how many ticks have passed since the last such call), which is variable. This parameter shouldn't be ignored.

Thanks for the question.

Best,

Ryan

Find the Best Information on Online Education Here!
http://click.lavabit.com/c5pq6xzuiu94i6u9r9ttseezq6sdxg3gprzhq9c1exuacnxnj91b/