From version 12.1
edited by Andrea Omicini
on 25/12/2021 12:14
Change comment: There is no comment for this version
To version 14.1
edited by Andrea Omicini
on 25/12/2021 12:22
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -31,11 +31,11 @@
31 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 32  * {{pub}}KampCACM1111{{/pub}}
33 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}}KroekerCACM201110{{/pub}}
34 +* {{pub}}KroekerCacm54-10{{/pub}}
35 35  ** Parla dello stato dell'arte nell'integrazione tra cervello umano e computer.
36 -* {{pub}}KroekerCACM201112{{/pub}}
36 +* {{pub}}KroekerCacm54-12{{/pub}}
37 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}}KuikkaniemiComputer2011{{/pub}}
38 +* {{pub}}KukkaniemiComputer2011{{/pub}}
39 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 40  * {{pub}}LanierCACM201112{{/pub}}
41 41  ** Bell'articolo sulle analogie fra le strategie di marketing di Apple e le tecniche utilizzate dai santoni indiani per far proseliti.
... ... @@ -43,7 +43,7 @@
43 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 44  * {{pub}}Martin2006{{/pub}}
45 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}}bioframework-cec09{{/pub}}
46 +* {{pub}}BioframeworkCec09{{/pub}}
47 47  ** Usano il vecchio simulatore multicompartimento per fare le righe col Drosophila.
48 48  * {{pub}}NikhilCACM201110{{/pub}}
49 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).