Comparative Analysis of BEAST GO and JS Implementations

Introduction

Despite a common theoretical foundation, the implementations demonstrate fundamentally different architectural approaches. This reflects how the understanding of the task evolved and how each language was used.

1. General Principles

1.1 Discrete time (pulse)

Aspect GO JS
Mechanism time.AfterFunc with a recursive call setTimeout using the recursive pulse separator (sep_of_puls)
Counter PulsCount Cur_puls_val + cpuls
Accuracy 1 second (with correction) 1 second (with correction)

1.2 Hierarchical model

Both systems are organized in layers: vitals contexts stimuli reflexes memory awareness.

1.3 Separation by memory type

1.4 The Orientation Reflex (OR) as the central trigger

In both implementations, OR acts as a trigger for awareness and for fixing episodes in episodic memory.

2. Main Architectural Differences

2.1 Memory model

Characteristic GO version JS version
Structure of episodic memory Episodic tree (EpisodicTree) with fixed levels Linear array (Episodes) with an index
Rule search Recursive traversal of the tree Linear search with filtering
Teacher rules PARAMS[0] == 100 Field responseStimulusImageId in the response frame
Abstractions Absent AbstractPerceptionImages, AbstractActionImages, semanticStructure
Mental rules Separate tree (EpisodicMentalTree) Integrated through MentalRules_* and MentalAutomatizms
Analysis: JS introduced a fundamentally new layer - abstractions (clones of hard images). This lets the system generalize experience as "what if", not only record what happened. The GO version does not provide this capability.

2.2 Consciousness process

Characteristic GO version JS version
Cyclic structure cycleInfo with step, count, dreaming CycleInfo with step, count, thinkingMode, awaitingAutomatismEpisodeFeedback
Dispatching dispetchConsciousnessThinking() with pulse-based thinking Similar logic, but with clear main/background separation
Awareness levels 1-2 in consciousnessElementary, 3-4 in consciousnessThinking 1-2 in runElementary, 3-4 in runOneStep via separate modules
Waiting gates LastRunAutomatizmPulsCount awaitingAutomatismEpisodeFeedback + automatismOperatorAnswerReceived
Passive mode dreaming flag + GotoDreaming() thinkingMode = 'passive' + info_fantasizming()
Analysis: JS introduced explicit waiting gates that prevent re-searching for rules while the system waits for an operator response. GO uses a simpler mechanism, which may cause "bouncing" on repeated calls.

2.3 Conditional reflexes

Characteristic GO version JS version
Structure ConditionReflex with rank, lastActivation, birthTime SynonymReflex with tryCount, isReady
Maturity threshold 2 combinations (rank) 3 combinations (REFLEX_READY_THRESHOLD)
Decay By time (lastActivation - birthTime > 50) No decay (only clearing via button)
Formation updateNewsConditions() with accumulation into TriggerStimulsTempArr synonyms_onGeneticActionFired() with context/stimulus checking
Analysis: GO has a more complex forgetting/decay mechanism that imitates memory forgetting. JS currently does not implement forgetting, but it has a cleaner formation logic (only when there are > 1 active stimuli).

2.4 Goals and motivation

Characteristic GO version JS version
Base goals Genetic goals via TerminalActionsTargetsFromID getActiveBaseGoalVitalId() (only "Poor")
Life experience PurposeGenetic (temporary, not persisted) GoalImagesLife (persisted in IndexedDB)
Arbitrary goals Absent Planned placeholder (in comments)
Goal "meaning" Absent GOAL_KIND_MEANING_DEFAULT (default)
Goal "Cry" Absent GOAL_KIND_CRY_DEFAULT
Analysis: JS introduced persistable goal images, allowing the system to "remember" successful strategies across sessions. GO goals exist only in runtime memory.

2.5 Persistence

Characteristic GO version JS version
FormatText files (*.txt)IndexedDB + JSON files
MechanismDirect write on changeDirty flags + state signatures
LoadingAt initializationAsynchronously with a localStorage fallback
Save on closingcleanupFunc() in mainbeforeunload + saving_before_closing
Emergency terminationIsBeastDeathwas_emergency_shutdown flag
Analysis: JS uses a more reliable mechanism with dirty flags and state signatures, preventing unnecessary writes. GO writes on each change, which can be inefficient for large data volumes.

2.6 Verbal sensors

Characteristic GO version JS version
Presence Full word and phrase tree (WordTree, PhraseTree) Absent (tree levels 4-6 not used)
Recognition WordDetection(), PhraseDetection() -
Accumulation words_temp_arr.txt with repetition thresholds -
Typos Alternative recognition (first/last letters) -
Analysis: The verbal subsystem is the most substantial difference. GO implements a full verbal system, making it significantly more complex. JS intentionally excludes verbal input and focuses on non-verbal adaptivity. This matches the declared goal: the project is not a functioning creature with upbringing, but the most adequate way to implement the theory.

3. Differences in Specific Adaptive Mechanism Implementations

3.1 Effect evaluation

Aspect GO version JS version
Computation BetterOrWorseNow() ? commonDiffValue (from -10 to +10) closeLastFrame() ? effect = clamp(diffAfter - diffBefore)
Pain/Joy accounting GomeostazActionEffectPainV and JoyV (from homeostasis) No direct analogue
Teacher button handling Separate processing via IsPress3or4button Through responseStimulusImageId present in the frame
Passing to automatism automatizmCorrection() with averaging addUsefulnessSample() with averaging
Analysis: Both average, but JS has a single unified point of effect calculation (closeLastFrame), preventing discrepancies between episodic memory and automatisms.

3.2 Stimulus competition

Aspect GO version JS version
RelevanceNovelty ? significance (in OR)Similar, with hysteresis
HysteresisOR_HYSTERESIS = 0.5Similar
Episodic chain priorityAbsentEpisodicMemory_getChainPriorityStimulusSet() (?2 consecutive frames)
Interruption thresholdINTERRUPT_THRESHOLD_ATTENTION_RATIO Analogous, considering themeSituationMismatch
Analysis: JS introduced episodic chain priority to avoid breaking meaningful sequences. This is an important improvement for supervised learning.

3.3 Base contexts and emotions

Aspect GO version JS version
ActivationVia vitals outputs relative to normAnalogous
Antagonistsantagonists mapAbsent (contexts are independent)
HysteresishysteresisLimitVal for switching CurStyleImageAbsent
RetentionkeepingContextTime (20 pulses)state_retention_period (15 pulses), implemented via SetWellForHolding and related logic
EmotionsEmotion (combination of contexts)Analogous
Analysis: GO has a more complex system of antagonists and hysteresis that imitates lateral inhibition. JS simplified the model but added explicit state retention.

3.4 Cerebellar reflexes (strength correction)

Aspect GO version JS version
PresenceFull cerebellumReflex systemAbsent
MechanismaddEnergy (from -10 to +10)˜
Additional actionsadditionalAutomatizmID˜
Analysis: GO contains a complex cerebellar correction system that is not implemented in JS. This is a direction for future development.

3.5 Gestalts and insights

Aspect GO version JS version
StructureDominanta (problemTreeID, objectID, targetActionID) GestaltArr (goalImageId, status, analogyPool)
Resonance bufferAbsent GestaltResonanceBuffer (FIFO signatures)
AnalogiescheckRelevantAction() Gestalt_processResonanceBufferForCycle() with a heuristic score
InsightstoConsciousHeuristics() registerInsight() with insight types 'local', 'analogy', 'feedback'
Analysis: JS has a much more developed gestalt system with cross-cycle analogies through a resonance buffer. GO dominants are tied to objects and actions but lack an analogy mechanism.

4. Efficiency Evaluation and Resource Requirements

4.1 Computational complexity

OperationGOJS
Search in episodic memory by conditionsO(n) linear walkO(1) via indices (byPerceptionKey)
Semantic accessO(n) by arrayO(1) via SemanticMemoryIndex[well][emotionId][finalImageId]
Search automatisms by branchO(n) by arrayO(1) via byBranchId index
Conditional reflexesO(n) by arrayO(n) by array (potential bottleneck)
Perception tree traversalO(n) recursive traversalO(1) via pathIndex
Conclusion: JS is significantly more efficient due to indices and hash tables. GO relies on linear traversal and recursion, which can become a scaling issue.

4.2 Memory consumption

AspectGOJS
Data structuresMany maps with pointersSlices with indices
Verbal treesFull word and phrase treesAbsent
Episodic memoryTree (condition duplication)Linear array
AbstractionsAbsentAdditional clone arrays
Conclusion: JS uses less memory because it excludes verbal trees and uses more compact structures. However, abstractions add some overhead.

4.3 Execution speed

AspectGOJS
Overall performanceHigh (compiled language)Medium (interpreted)
IndexingAbsentPresent; compensates for interpretation
AsynchronyGoroutines (potentially complex)Event loop (simpler)
Data loadingSynchronousAsynchronous
Conclusion: Despite GO being a compiled high-performance language, JS shows that language speed is not critical for this architecture. Correct data structures (indices, hash tables) and discrete time allow JS to work efficiently in a browser.

4.4 Hardware requirements

AspectGOJS
Runtime environmentServer (Go binary)Browser (client)
CPU consumption1 pulse/sec (minimal)1 pulse/sec (minimal)
RAMModerate (depends on memory volume)Moderate (depends on volume)
Network loadNone (local server)None (local)
Conclusion: Both implementations are not demanding in terms of computer power. JS demonstrates that a complex adaptive system can run in a browser on a regular PC without server hardware, emphasizing the non-critical nature of high-speed languages for this class of tasks.