2026-05-06 10:54:57 +02:00
2026-05-06 10:54:57 +02:00
2026-04-14 15:24:01 +02:00
2026-05-06 10:54:57 +02:00
2026-04-14 15:24:01 +02:00
2026-04-14 15:24:01 +02:00
2026-05-06 10:54:57 +02:00
2026-04-14 16:29:20 +02:00
2026-04-06 15:54:11 +02:00

README.md

Qui mettiamo le spiegazioni sulla struttura della comprensione G e alcuni punti fondamentali sulla comprensione dell'organismo.

Struttura della comprensione G

L'intera espressione G e' strutturata in varie comprensioni intricate.

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.

Elementi strutturali

  • 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.
  • Modulator sono presenti in TUN e DEV. Si "attaccano" ad un BEH, modulandolo. Contengono altri modulator e contengono episode e context.

Comportamenti

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 ce 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.

Context and Episode

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.

A Context sets the conditions, an Episode is a named outcome within those conditions.

Condition, hypothesis

...

Tub / Blocchi

Il concetto di tub / blocco e' una maniera di vedere in due modi diversi. Come contenitore di blocchi, e come blocco.

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.

full and empty

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).

Inoltre posso verificare come condizione e hypothesis se un tub e' full o empty.

emptiness, medium and fullness

Il controllo di condition in un context o hypothesis in un episode viene fatto con:

  • emptiness: se gli actual sono almeno 30% di (full - empty)
  • medium: se gli actual sono fra 30% e 70% di (full - empty)
  • fullness: se gli actual sono almeno 70% di (full - empty)

Integrazione/intricazione

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.

RF

Teorema di Shannon inverso. E' come se facessimo un campionamento su un ipotesi di continuita'.

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).

Intricazione

La comprensione G non e' un eterarchia ottenuta con riduzione tradizionale, ma un'eterarchia ottenuta con espansione G.

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:

  • espansione (gerarchica)
  • intricazione fra Tub
  • modulazione

Floor

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.

Comprensione Organism

Struttura della espansione

L'espansione parte da ORG.md:

  • Organ1, Organ2, etc
  • EXH-ORG, INH-ORG
  • WTA, WTA1,etc
    -- EXH, INH
  • AST
  • N
    -- AXO: PRE: VGCC
    -- SOMA: VGCC
    -- BD: POST: AMPA. NMDA, VGCC

Tuning e Developing

Il tuning per ora lo abbiano definito per i VGCC e AMPA.

Il DEV:

  • per RF in N
  • per PRE, POST e AST

Associazione PRE, POST e SYN

Inter moduli

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.

Si tratta di 4 ragionamenti locali:

  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.

Fra moduli e organi

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.

Presynapse

S
Description
No description provided
Readme 2.1 MiB
Languages
Python 85.9%
HTML 14.1%