multi_cue_tmaze_sim (faber_tweann v2.4.0)
View SourceMulti-cue T-maze: a memory-CAPACITY benchmark (two held bits).
Where tmaze_sim tests memory DURATION (hold one cue across a corridor), this tests memory CAPACITY (hold TWO independent cues at once). Each trial shows cue A on its own channel, then cue B on its own channel, then a corridor of delay empty steps, then TWO junctions: junction 1 asks for cue A, junction 2 asks for cue B. Both cues are shown early and recalled late, so both must be carried; getting both right needs room for two bits, not just a longer memory.
Sensor (vl 4): [CueA, CueB, Junction1, Junction2]. step 0 -> [a, 0, 0, 0] cue A shown (+1 / -1), its OWN channel step 1 -> [0, b, 0, 0] cue B shown (+1 / -1), its OWN channel corridor -> [0, 0, 0, 0] nothing step delay+2 (J1) -> [0, 0, 1, 0] recall A step delay+3 (J2) -> [0, 0, 0, 1] recall B Cue A is on channel 0 ONLY at step 0, so a consumer can detect trial-start (and reset a plastic net) without mistaking cue B for a new trial. Actuator (vl 1): Output of zero or more decides +, below zero decides -, at each junction.
Baselines: trials use all four (A,B) combinations in equal number, so at each junction a MEMORYLESS "always one way" policy scores exactly half -- fitness 50 with zero variance. A one-bit memory (hold A only, or B only) caps at 75. Only a genuine two-bit memory reaches the 90 solve line. Fitness is scaled to 0-100 (each of the 2*trials decisions worth 50/trials), so it reuses the same solve goal and ES options as tmaze_sim.
Actuator/sensor parameters [Delay | Trials] override the corridor length and trial count (defaults 4 and 100).