AERA

This project implements AERA (Auto-catalytic Endogenous Reflective Architecture) using the Replicode programming language.

For an overview, please visit https://openaera.org . See our FAQ which answers many questions about AERA https://openaera.org/faq .

This README file documents general information about the AERA code.

See the file INSTALL.md for build and install instructions.

See the file CHANGELOG.md for version numbers and changes.

For code documentation, see https://iiim-is.github.io/AERA .

Code structure

The main program execution for the example happens in AERA/main.cpp

main() // loads the settings.xml and the seed image, starts up r_exec/mem.cpp and then waits for run_time and ends by saving the results to disk to decompiled.txt
r_exec/mem.cpp starts up the runReductionCore and the runTimeCore threads which do the magic
The r_exec/pattern_extractor.cpp and r_exec/g_monitor.cpp push new reduction and time jobs to the job queues
The r_exec/*_controller.cpp are the controllers for mdl, pgm and more
The commands (cmd) activated in the replicode scripts would be activated through r_exec/mem.cpp::eject(Code *command), see https://github.com/IIIM-IS/Integration_OpenAI for actual device commands

Gotchas

This is a list of unintuitive issues with using AERA, to help new users.

Only the AERA/replicode_v1.2 examples really function due to syntax changes.
The term "set" is used even when it means an ordered array with repeated elements.
The term "hlp" just means "mdl" or "cst", which use similar structures for "high-level pattern".
Every object definition ends with a propagation of saliency threshold (psln_thr), usually 1. For brevity, the documentation often omits it. And there is a macro in std.replicode which allows it to be omitted from the definitions in there. But it must be included when you write code.
"icmd" means "internal command", not "instantiated command" (like "imdl" for "instantiated model").
imdl set of exposed values doesn't have LHS fact timestamps. See: HLPBindingMap::build_f_ihlp:1037
If a model's guard assigns a variable, the value passed in with the same template variable is ignored.
The timestamps of facts defined at the top level of a file automatically have the start time added for run time (and subtracted after run time for decompiled_objects.txt).
min_sim_time_horizon is really "time allowance for the simulated predictions".
OIDs are not in order of creation. (Only order of binding to a view.)
Program "guards" which check boolean constraints are different than model "guards" which assign values to variables.
Even though a drive goal is to be accomplished in the next frame, make its time interval start in the current frame so that its potential sub-goals will match current facts (and not be injected as new goals).
A program accumulates matched patterns and will run even if one of the facts is "old". You must use boolean guards to control this.
pong.2.simplified.replicode: Prediction is made after the actual fact is injected. (But the prediction doesn't look at it, and the prediction check uses the output of auto focus which correctly doesn't appear until the next frame.)
For external cmd, need a program to intercept (fact (goal (fact (cmd ...)))) and eject the cmd. Such a goal abduced from a mdl is put in primary, so the program must be instantiated in primary.
Objects with a short resilience aren't in decompiled_objects.txt. In settings.xml, try keep_invalidated_objects=yes .
If not debugging the code, then in Visual Studio run in the "Release" configuration so that it runs faster.
Math operations on two floating point numbers produce a floating point number, as expected. And addition and subtraction of two time values produces a time value, as expected. But the result of operations with mixed types is not obvious. Below 'nb' is a floating-point number and 'ts' is a 64-bit timestamp in microseconds and 'us' is a 64-bit duration in microseconds.
- (+ us ts) or (+ ts us) or (+ nb ts) or (+ ts nb) -> ts (interpret nb as microseconds duration)
- (+ nb us) or (+ us nb) or (+ us us) -> us (interpret nb as microseconds duration)
- (+ ts ts) not allowed
- (- ts ts) -> us
- (- ts nb) or (- ts us) -> ts (interpret nb as microseconds duration)
- (- us nb) -> us
- (- nb ts) or (- us ts) or (- nb us) not allowed
- (* nb us) -> nb
- ( us nb) -> us ... different than ( nb us)!
- (* us us) -> nb ... counter-intuitive
- ( nb ts) or ( ts nb) or ( us ts) or ( ts us) or (* ts ts) not allowed
- (/ nb us) -> nb
- (/ us nb) -> us
- (/ us us) -> nb
- (/ nb ts) or (/ ts nb) or (/ us ts) or (/ ts us) or (/ ts ts) not allowed

Implementation status

Demo = demonstrated functionality. Vis = explanation in Visualizer. Comm = code commented. Doc = details in software design document

Demo	Vis	Functionality
		*Facts / Success*
✓		Learn models in change targeted pattern extractor (CTPX)
		Learn models in goal targeted pattern extractor (GTPX) due to unexpected achievement of goal fact
✓	✓	Non-simulated icst from facts/icsts
✓	✓	Non-simulated prediction of imdl from weak requirement model
✓		Rating of weak requirement models
✓	✓	Testing and re-activation of models and weak requirement models in the secondary group
✓		Use of deleted models to prevent re-creating them
✓	✓	Non-simulated prediction of fact from model
✓		Non-simulated cmd from non-simulated goal RHS
		Auto-focus based on active predictions and goals (not pass-through)
✓		Views/groups and saliency propagation
✓		Simulated prediction of icst from facts/icsts
✓		Simulated prediction of imdl from weak requirement model
✓		Simulated prediction of fact from model
✓		Simulated goal from drive
✓		Simulated goal cmd from model
✓		Simulated goal requirement imdl from model
✓		Simulated goal icst from requirement model
✓		Simulated goal facts/icsts from icst
✓		Commiting to optional solutions
		*Anti-facts / Failure*
✓		Learn strong requirement models (predicted anti-imdl) in prediction targeted pattern extractor (PTPX) due to failed prediction of a fact
		Learn strong requirement models (predicted anti-imdl) in prediction targeted pattern extractor (PTPX) due to failed prediction of an anti-fact
✓		Learn models in goal targeted pattern extractor (GTPX) due to unexpected achievement of goal anti-fact
✓		Non-simulated prediction of anti-fact from model
✓		Non-simulated prediction of anti-imdl from strong requirement model (to prevent model prediction)
✓		Rating of strong requirement models
		Testing and re-activation of strong requirement models in the secondary group
		Goal actions to test conflicting weak and strong requirements
		Simulated anti-goal from opposite match of drive (and starting of new simulation from anti-goal)
✓		Simulated prediction of anti-imdl from strong requirement model (to prevent model prediction)
✓		Simulated prediction of anti-fact from model
		Conflict resolution of conflicting predictions (fact and anti-fact)
		Simulated anti-goal of cmd from model with anti-matched RHS
		Simulated anti-goal requirement imdl from model with anti-matched RHS
		Simulated anti-goal icst from requirement model with anti-matched RHS
		Simulated anti-goal facts/icsts from anti-fact icst
✓		Commiting to mandatory solutions

IIIM-IS / AERA

readme

AERA

Code structure

Gotchas

Implementation status