Danilo Pianini / APICe

1

= Danilo Pianini’s read papers page =

2

3

== Papers I have already read ==

4

5

* {{pub}}AlvesCB2006{{/pub}}

6

** Riassume bene e chiaramente le caratteristiche dei vari simulatori stocastici.

7

* {{pub}}CrowdmodelingCybsys38{{/pub}}

8

** Viene presentato il modello SCA per la modellazione di sistemi complessi, dicendo che per ora i tool esistenti (e.g. Repast) mancano di un modello ben definito (anche Alchemist sfrutta la cosa). È interessante il supporto che offrono direttamente ai campi computazionali, mentre hanno limiti dovuti alla discretizzazione forzata sia spaziale che temporale. L'ambiente è sostanzialmente una rete di nodi. Non viene detto quale tipo di esecuzione venga effettuata dal motore di simulazione. Bellissimo l'aggancio sul motore 3D via MAX. Decisamente da non sottovalutare.

9

* {{pub}}CollectivesortSaso08{{/pub}}

10

** Cataloga le proprietà che deve possedere un mezzo di coordinazione per essere definito self-organizing. Sistema le tuple nei vari spazi utilizzando il brood sorting.

11

* {{pub}}CiocchettaFBTC2008{{/pub}}

12

** Sostanzialmente, mi pare che si possa riassumere il tutto in una divisione per "h" delle concentrazioni dei reagenti. Più "h" è piccolo più ci si avvicina al modello ODE, dato che approssima le concentrazioni a numeri continui.

13

14

* {{pub}}CohenCACM2011{{/pub}}

15

** Si parla dell'importanza crescente degli strumenti software nel processo di produzione dell'informazione. In particolare, vengono evidenziate tre aree in cui allo stato attuale si può ancora molto migliorare: content aggregation, entity extraction e clustering di documenti.

16

* {{pub}}CardoneTCJ2011{{/pub}}

17

** Paper molto completo dove si propone una struttura di rete mista fra le WSN, a basse prestazioni, e le MANET, reti spontanee di dispositivi (e.g. smartphones) con prestazioni molto più alte. Il focus dell'articolo è sulla costruzione di una sorta di backbone, una rete spontanea MANET che deve avere la responsabilità di trasportare le informazioni ad alta priorità in maniera tale da riportarle prima possibile nel punto di aggregazione. Si analizzano le prestazioni, impatto sui consumi e overhead. Rispetto al nostro lavoro è più in basso come astrazione, focalizzandosi molto sul routing.

18

* {{pub}}DavisCACM201111{{/pub}}

19

** Discute dell'appropriatezza di definire l'ingegnere del software come un ingegnere vero e proprio. Fa diversi esempi di definizione di ingegnere e mostra che l'ingegnere del software non si colloca in alcuna di esse. Chissà cosa ne pensa Antonio Natali?

20

* {{pub}}GellerCACM2011{{/pub}}

21

** Discute dell'esistenza di un progetto, finanziato dal DARPA, in cui si cerca di riconoscere l'attività che gli attori stanno compiendo di fronte ad una telecamera. Non si tratta di un esercizietto di computer vision, dato che il contesto è estremamente vasto. Il sistema dovrà essere capace di riconoscere azioni e situazioni diverse, e capire quali comportano rischi e quali invece no. C'è molto interesse anche per applicazioni non orientate al mondo militare, anche se attualmente DARPA finanzia in ottica bellica.

22

* {{pub}}StochasticsimulationJphyschema104{{/pub}}

23

** Contiene la descrizione rapida del metodo diretto e del First Reaction, introduce il Next Reaction. Nell'appendice parla anche un po' del metodo diretto ottimizzato. Contiene la descrizione delle strutture dati, e una buona parte matematica.

24

* {{pub}}GongQueue2011{{/pub}}

25

** Ricorda tutta l'evoluzione storica della sicurezza in Java, mostrandone obiettivi e soluzioni.

26

* {{pub}}GreengardCACM201110{{/pub}}

27

** Spiega i downside della vita in un mondo popolato dalle tecnologie. In particolare, spiega perché non mi ricordo mai nulla e ho bruciato la mia memoria a breve termine.

28

* {{pub}}HymanCACM201112{{/pub}}

29

** Articolo in ricordo di una persona che ha dato davvero tanto all'informatica.

30

* {{pub}}IndurkhyaPLoSONE2010{{/pub}}

31

** Descrive un metodo di fattorizzazione delle reazioni molto valido, ma per i nostri scopi problematico: forza il calcolo della propensity delle reazioni nel modo classico (impossibile l'uso di rate equations), forza le reazioni a non avere più di due reagenti (imposizione ereditata da Gillespie, ma che noi rilassiamo), ottimizza molto quando le stesse specie appaiono in molte reazioni come reagenti ma non come prodotti (evento piuttosto raro per noi, dato che modifichiamo i reagenti internamente senza rimuoverli, solitamente). Ottimo lavoro, ma scarsamente utilizzabile per i nostri scopi.

32

* {{pub}}KampCACM1111{{/pub}}

33

** Tratta il problema di dover fidarsi di codice che non è stato scritto interamente da sé stessi. Lettura molto piacevole, termina con la proposta di una legge di tre articoli per assegnare responsabilità a chi dovesse sfruttare il sistema di fiducia per diffondere malware.

34

* {{pub}}KroekerCacm54-10{{/pub}}

35

** Parla dello stato dell'arte nell'integrazione tra cervello umano e computer.

36

* {{pub}}KroekerCacm54-12{{/pub}}

37

** Parla dello stato dell'arte nella costruzione di macchine molecolari, ossia dell'utilizzo di componenti cellulari (DNA, proteine, etc.) per ottenere computazione. Allo stato attuale si riesce a computare la radice quadrata di qualunque numero (fino a 15) e ad arrotondare il risultato all'intero più vicino. Il tutto in 10 ore. Resta un po' in sospeso il fatto di capire quali applicazioni possano esserci per questi sistemi: probabilmente la risoluzione di problemi matematici non sarà particolarmente importante.

38

* {{pub}}KukkaniemiComputer2011{{/pub}}

39

** Indicazioni generali sull'uso di display pubblici. Presenta i concetti di stage e di ruolo. Mostra applicazioni pervasive ed enfatizza l'uso sociale dei display. Analizza probabili evoluzioni hardware, si sofferma sulle possibili problematiche d'uso e design di luoghi pervasivi. Mostra esperimenti funzionanti (Napoli, Helsinki). Qualche idea su come ottenere dati per costruire il software che pilota i display (computer vision, cellulari). Scarso rilievo all'analisi di quello che il software deve fare per supportare un ambiente simile. Utile.

40

* {{pub}}LanierCACM201112{{/pub}}

41

** Bell'articolo sulle analogie fra le strategie di marketing di Apple e le tecniche utilizzate dai santoni indiani per far proseliti.

42

* {{pub}}LeccaJoIB2010{{/pub}}

43

** Spiega come calcolare i rates per fare la diffusione in maniera più realistica. Tiene in considerazione forma e massa delle molecole, è piuttosto complicato ma dovrebbe essere portabile su Alchemist. Alcuni calcoli di derivata ed integrale non sono completamente sviluppati, quindi c'è da fare un po' di lavoro aggiuntivo per riuscire a tirarne fuori una versione implementabile.

44

* {{pub}}Martin2006{{/pub}}

45

** Simulatore per ambienti urbani. Poco rilevante per noi, ma fa bello sapere che l'hanno scritto in Java come noi abbiamo fatto con Alchemist. Evidentemente l'uso di quel linguaggio su software performance-oriented è tutt'altro che raro.

46

* {{pub}}BioframeworkCec09{{/pub}}

47

** Usano il vecchio simulatore multicompartimento per fare le righe col Drosophila.

48

* {{pub}}NikhilCACM201110{{/pub}}

49

** Spiega come sia possibile (e presenta anche un linguaggio) ridurre un po' il gap fra i linguaggi per lo sviluppo di software e quelli per lo sviluppo di hardware. VHDL e compagnia risalgono agli anni 80, e nel mondo dell'hardware moderno c'è necessità di maggiore parallelizzazione. Viene presentato il linguaggio Bluespec SystemVerilog (BSV).

50

* {{pub}}OSullivanQueue2009{{/pub}}

51

** Confronta i sistemi di controllo della versione centralizzati (CVS, SVN) e distribuiti (Git, Mercurial). Evidenzia i casi in cui sono da preferirsi i primi ed i casi in cui sia invece meglio puntare sui secondi. Evidenzia punti di forza e di debolezza di ognuno. Per il tipo di sviluppo che si fa all'interno di una facoltà, un DCVS appare la scelta più ovvia e logica. Git e Mercurial sono molto simili, il primo ha una curva di apprendimento un po' più ripida ed è molto più Unix oriented.

52

* {{pub}}ShmatikovCACM201112{{/pub}}

53

** Introduce un lavoro fatto sulla sicurezza, riassumendo il fatto che l'anonimizzazione dei dati (tramite, ad esempio, la cancellazione di nome e cognome) è un meccanismo largamente insufficiente alla difesa della privacy.

54

* {{pub}}SlepoyJPC2008{{/pub}}

55

** Introduzione del metodo composition-rejection per slegare la complessità computazionale dell'algoritmo diretto di Gillespie dal numero di reazioni in gioco. Bellissima idea, peccato che tutto funzioni bene perché vale nei sistemi biologici l'assunzione che le propensity variano fra loro in modo limitato. La dipendenza dal numero delle reazioni viene rilassata forzando però la dipendenza dal divario fra le varie propensity: in un sistema dove ci sono reazioni molto veloci e reazioni molto lente, il numero di gruppi da formare aumenta (logaritmicamente) e conseguentemente peggiorano le prestazioni dell'algoritmo. Nel caso SAPERE, visto che esistono reazioni con semantica ASAP, e quindi con rate markoviano tendente a infinito, l'algoritmo è molto probabilmente peggiore del classico Next Reaction. Inoltre, essendo basato sul metodo diretto di Gillespie non sul First Reaction, impedisce il trattamento semplice di eventi e reazioni con distribuzione di probabilità non esponenziale.

56

* {{pub}}SapereWoa2011{{/pub}}

57

** Me l'hanno fatta presentare a WOA 2011. Solfa SAPERE.

58

59

== Papers I want to read ==

60

61

* {{pub}}DiNoiaJAIR2007{{/pub}}

62

* {{pub}}AgentmiddlewareWetice2004{{/pub}}