Mapping SAPERE on TuCSoN: An Architectural Approach

research project

Author

Marco Piraccini

Incontro con Stefano Mariani 22/11/2012

Argomenti trattati
- considerazioni sui mapping
- utilizzo Git
- analisi codice TuCSoN e funzionamento TuCSoN
- piano di lavoro

Architettura SAPERE
- Ipotesi iniziali
  - Mapping nodo SAPERE <-> nodo TuCSoN, gestiremo noi il fatto che in ogni nodo TuCSoN ci sia un solo centro di tuple.
  - Ignoriamo per ora il fatto che ogni LSA debba avere un id univoco. Probabilmente questa proprietà sarà una diretta conseguenza dell'implementazione di TuCSoN biochimica, in cui ogni tupla è presente nello spazio una sola volta con una certa concentrazione, e quindi il nome di una tupla può rappresentare il suo id univoco.
  - Per ora consideriamo i filtri SAPERE come semplici template, eventuali estensioni saranno definite successivamente agendo a livello di codice prolog in java (invece di fare la classica unify sarà definito un predicato che esegue specifiche funzioni e controlli).
    Aspetti importanti da affrontare fin da subito
  - Pensare ad una implementazione per le funzioni location e clone, inserendole come primitive base.
  - Valutare se implementare la legge di decadimento attraverso il concetto di timeout (non presente attualmente in TuCSoN, LSA presenti per un certo periodo di tempo, "tuple in leasing") nel caso in cui gli LSA non abbiano associato alcun valore di concentrazione (come previsto da SAPERE) oppure attraverso una graduale diminuzione della concentrazione delle tuple ad un certo rate.
  - Considerare una soluzione per ottenere bond tra LSA: implica concetti non presenti nativamente i TuCSoN come l'aggiornamento degli LSA e la notifica di questi cambiamenti all'agente sorgente.

TuCSoN biochimico
- Considerazioni per realizzare una estensione di TuCSoN biochimica:
  - Calcolare il valore di concentrazione di una tupla X come rapporto tra il num di tuple X e il num tot di tuple nello spazio. Per evitare troppi calcoli una soluzione ragionevole può essere che ogni tupla mantenga il valore della propria molteplicità e il calcolo corretto del valore di concentrazione è eseguito solo quando realmente serve (ad esempio nel calcolo del rate effettivo). Per fare questo sarà necessario agire nel package alice.logictuple estendendo/wrappando la classe LogicTuple.
  - Il concetto di vicinato per ora si considera possa essere reificato attraverso tuple neighbour (eventualmente inserite in uno centro di tuple particolare)
  - Valutare come implementare il calcolo del rate effettivo seguendo l'algoritmo di Gillespie. Il problema principale consiste nel dover considerare tutte le combinazioni di matching tra tuple e template in ogni ordine possibile. Una possibilità è prendere una legge generale e istanziarne tante quante sono le possibilità di match per poi calcolare il rate di ciascuna.
  - Definire primitive per estrarre un certo quantitativo di una tupla
  - Definire a livello infrastrutturale come fare ad unire due tuple con lo stesso nome, sommando la loro concentrazione (se non specificato si assume una unità)

Piano di lavoro
- Leggere articolo "Quantitative information in the tuple space coordination model" del prof Bravetti, per valutare se il concetto di peso associato alle tuple può essere usato come valore di concentrazione.
- Analizzare codice TuCSoN per valutare le sezioni critiche su cui agire.
- Definire in pseudo-codice una estensione per LogicTuple, che abbia in più il concetto di concentrazione.
- Definire in pseudo-codice una implementazione delle operazioni per prelevare una certa quantità di una tupla.
- Definire in pseudo-codice come unire due tuple con stesso nome.
- Definire in pseudo-codice una implementazione per il calcolo del rate effettico considerando tutte le combinazioni, facendo riferimento agli articoli già letti e se necessario eseguire ulteriori ricerche in internet.