I nomi dei Container e dei Modulator sono **univoci**. In tutta la comprensione, compreso i moduli N, AST e WTA. Questo perche' dobbiamo pensare a ciascun container come una cella univoca, espressione di possibilita', che si intrica con altre celle.
- **Comprehension**: contiene i comportamenti di BEH, DEV e TUN. Inoltre contiene **scope**, che serve a cambiare l'attivazione da BEH, DEV, TUN. Non contiene altro.
- **Container**: sono presenti in BEH, espandono altri container, e contengono **episode** e **context**. I container contengono i cosiddetti behavior “diretti”. I container sono anche Tub/blocchi.
Il **BEH** e' il comportamento dal quale si parte nella comprensione G. L'espansione della comprensione segue l'espansione dei comportamenti. I comportamenti di TUN e DEV, si "attaccano" ad un BEH. Nel caso specifico di DEV-WTA, abbiamo l'agire di un BEH su POST/PRE e SYN.
Il **TUN** lavora quando BEH e' a riposo. Agisce su Tub concettuali, creando e eliminando in actual, mantendendosi fra fullness e emptiness. La fullness puo' essere cambiata da DEV. TUN cambia la forma dell'espressione G, perche' agisce su blocchi concettuali che vanno collegati ad altri concetti, attivandoli e disattivandoli.
Mentre la scelta di mettere un comportamento in DEV rispetto a BEH e' chiara (cambiamento di fulness e RF), quella di metterlo in TUN, che si collega a BEH, dipende dal fatto che un comportamento TUN va separato in termini di "ambito temporale" (quando BEH e' a riposo).
Il **DEV** lavora durante Night a tempi lunghi rispetto a BEH e TUN. In pratica cambia la forma delle possibilita’ nell'ambito delle quali "agisce" BEH. Il DEV contiene quei behavior di modulazione che cambiano **fullness** di un Tub e **RF** di un context o episode. Ovvero c’e’ creazione di nuova “forma” di possibilita’ in BEH.
C'e' una differenza se il cambio di fullness e' su un Tub di tipo floor (esempio Ca2+) o su un Tub di tipo concettuale (esempio BEH-PRE). Nel caso del Tub concettuale, il cambio di fullness determina un cambiamento di forma piu' "marcato" perche' l'enliver deve collegare o scollegare intricazioni fra concetti.
Il context e' a RF piu' alto, che attiva la possibilita' di un episode a RF piu' basso. L'episode "dura" in un intervallo di context. Il context puo' integrare le ipotesi fatte durante l'episode.
I Tub sono caratterizzati da una fullness, un actual e un emptiness. Actual indica quanti blocchi attuali sono presenti in enliving. Tramite comportamenti si possono aumentare o diminuire i blocchi in base alla fullness e emptiness. Nulla vieta di andare oltre fullness.
I blocchi possono essere di tipo floor (Ca2+) o concettuali (BEH-PRE). Nel caso dei concettuali, l'aumento o diminuzione, implica un cambiamento di forma dell'espressione G. E questo e' il motivo per il quale, con questi tipi di blocchi, viene fatto in TUN.
La fullness di un Tub puo' essere cambiata in DEV. Dal punto di vista della comprensione, questo equivale ad un cambio di possibilita', perche' l'attualita' in BEH puo' variare in maniera diversa.
L'assegnazione dei livelli di fullness, active e emptiness viene fatta una volta completata l'espansione come per RF. Infatti l'assegnazione deve essere collegata a RF.
Nella dichiarazione di Tub, full e empty indicano i limiti fra i quali si puo' spostare l'actual. Non sono limiti invalicabili, perche' potremmo andare oltre in enliving nel caso di tanti task che agiscono sulla stessa vaschetta (decentralizzazione).
I blocchi locali che sono riferiti come intricati in altri container, vanno considerati come Tub di integrazione. RF del Tub integrazione e' piu' alto (piu' lento) di quello dei Tub che vengono integrati. Lo svuotamento (clearance) deve essere fatto con un container di pumping che ha un RF simile a quello dei container dei Tub chevengono integrati.
Nel caso del NT, locale in SYN e intricato in PRE e POST, e' diverso, perche' qui non stiamo integrando ma condividendo NT. Ed infatti gli RF dei 3 container devono essere simili/uguali.
L'assegnazione degli RF va fatta una volta completata l'espansione. E' probabile che possa essere fatta da un programma con regole precise. Ad esempio partendo dai floor dell'espressione, si assegnano gli RF che sono quelli piu' piccoli (sampling piu' veloce che si trasforma in episodi piu' rapidi), risalendo nell'espansione e tenendo presente delle integrazioni (tub piu' alti che integrano comportamenti piu' bassi).
L'espansione puo' essere vista come gerarchica, ad esempio, da ORG a Organi, a moduli (WTA), Neuroni e Astrociti. Ma queste espansioni sono intricate in varie maniere:
L'espansione G. si ferma, per nostra scelta, sui floor. Nei floor abbiamo Tub/blocchi non concettuali, tipo Ca2+ o NT. Possiamo sempre pensare di abbassare i floor, senza dover stravolgere l'espressione G, come invece saremmo costratti a fare con una riduzione tradizionale.
Si parte con tipo una fullness di 5x BEH-PRE e BEH-POST, ovviamente actual 0x perche' non assegno sinapsi all'inizio. C'e' una fase in cui l'organismo e' in vero development, perche' deve attivare le SYN. Il numero massimo di PRE e POST viene messo nel DEV-N di PRE e POST, tipo 100x fullness. Per le SYN, si parte da ?x per fullness in BEH-SYN, e il numero massimo di SYN viene messo in DEV-AST come fullness tipo ?x.
Durante la fase di development iniziale, nel quale l'organismo inizia a creare le prime SYN, non c'e' grande comportamento espresso, se non quello di stabilire le prime SYN. Fatte le prime SYN l'organismo continua con alternanza DAY/NIGHT ad aggiustare il numero di SYN, ma in maniera meno intensa che nella fase iniziale.
1. POST: Nel DEV-N si ragiona sulla possibilita' di un AXO di gestire i bottoni, da possibili ad attuali e viceversa. Lo si fa modulando la fullness di BEH-POST
2. PRE: Nel DEV-N si ragiona sulla possibilita' di un BD di gestire i bottoni, da possibili ad attuali e viceversa. Lo si fa modulando la fullness di BEH-PRE
3. SYN: Nel DEV-AST si ragiona sulla possibilita' di un AST di creare nuove SYN possibili e viceversa. Lo si fa modulando la fullness di BEH-SYN
4. WTA: Nel BEH-WTA si ragiona sulla possibilita' di mettere assieme un BEH-PRE con BEH-POST con BEH-SYN, per permettere di condividere gli NT scambiati.
Come sopra, ma il punto 4 viene gestito da una compensione che non e' piu' il WTA (organo), ma una comprensione "superiore" che gestisce l'espansione degli organi. Tipo ORG.md.
