![]() |
Informatics |
La passione per l'informatica mi ha accompagnato fin dall'epoca del VIC20, quando feci i primi esperimenti dapprima in BASIC e poi in assembly. Successivamente passai al Commodore 64 con il quale feci esperimenti più sofisticati programmandone sia la grafica che il sonoro, sempre interamente in assembly.
Il passaggio al primo sistema 386 DX-33 mi spiazzò completamente, tanto che mi si servì molto tempo per capire come funzionasse. Il concetto di sistema operativo mi era ancora sconosciuto, soprattutto a linea di comando come lo era l'ms-dos. Poi, dopo innumerevoli letture ed esperimenti, d'un tratto, l'illuminazione giunse come una saetta di ispirazione divina. Un istante prima ero ancora confuso, un istante dopo avevo una visione chiarissima, cristallina, di quali fossero i principi di funzionamento di questa nuova macchina.
Dapprima imparai il Turbo Pascal che vidi crescere dalla versione 3.0 alla versione 7.0. In seguito rispolverai la mia passione per l'assembly che utilizzai negli anni successivi per creare demo grafiche in real time, programmi di sistema ed altro. Ormai conoscevo talmente bene l'ms-dos a livello di sistema (int 21h, mcb, aree dati in memoria ecc...) che mi fu difficile passare ai sistemi Windows. Riuscii a resistere a Windows 3.11, però fui letteralmente trascinato dalla corrente di Windows 95. Questo mi dispiacque perchè avevo appena cominciato a programmare un mini sistema operativo a 32 bit in modalità protetta per demo grafiche e videogiochi. Non aveva più senso continuare il progetto e così mi arresi alla coloratissima interfaccia grafica del nuovo sistema di Microsoft. Imparai il C ed in seguito il C++ con i quali continuai a sviluppare qualche programma per console (ms-dos). Solo molti anni dopo affrontai il "mostro" della programmazione in ambiente Windows grazie al Microsoft Visual C++ 6.0 ed alla libreria MFC. Durante gli anni passati all'università ebbi modo di imparare il Java con il quale feci qualche semplice applicazione client-server ed il terribile Fortran77, un abominio di sintassi ma una ferrari nel calcolo.
Ormai la passione per la grafica real time era tramontata da un pezzo e fu solo grazie all'esame di informatica grafica che mi feci di nuovo coinvolgere da questo mondo affascinante. Così imparai ad utilizzare la libreria OpenGL che usai sia in ambiente MFC che Win32. Ricominciai a sperimentare con lo scopo di approfondire questo nuovo modo di fare grafica. Questo cammino mi ha portato nel giro di un anno a tentare di realizzare un piccolo game engine e, in seguito, ad accettare una tesi sulla simulazione e modellazione di robot.
Questo, in estrema sintesi, è il mio cammino informatico, almeno come programmatore. Infatti mi sono occupato anche di manutenzione PC, gestione di piccole reti LAN e di problemi di sicurezza. Per quanto riguarda quest'ultimo argomento consiglio di visitare l'ottimo sito Sicurezza in Rete che fornisce sia le conoscenze che i programmi (spesso gratuiti) necessari per proteggere il proprio PC.
Questa sezione contiene alcuni dei lavori che feci tantissimi anni fa in ms-dos. Purtroppo quasi nessuno di essi funziona sulle macchine attuali, li propongo qui giusto per quel senso di nostalgia che credo sia comune a tutti i programmatori di vecchia data come me. Quasi tutti i programmi sono scritti interamente in assembly ed alcuni sono ottimizzati per la doppia pipeline asimmetrica dei primi processori Pentium.
![]() |
![]() |
|
Ho imparato questo linguaggio nel corso di uno dei tanti esami universitari. Sebbene il linguaggio sia estremamente chiaro, corredato da un'infinità di librerie che rendono lo sviluppo molto veloce, soprattutto quello delle applicazioni di rete, è anche un linguaggio estremamente lento in esecuzione. Dopo aver passato anni a programmare in assembly nel tentativo di spremere anche mezzo ciclo macchina dalla cpu ho provato da subito molta avversione verso Java. Solo ultimamente, in un'ottica produttiva, ho rivalutato parzialmente le mie opinioni.
![]() |
Finestra di login |
![]() |
![]() |
Conference Client |
A parte numerosi esperimenti sia di rete che non, l'unica applicazione sviluppata, insieme ad un mio collega d'università, è un client di chat che permette di creare dei gruppi di discussione in cui i membri possono accettare o negare le richieste di ingresso di nuovi interlocutori tramite un sistema di votazioni. Inoltre è presente una lavagna di disegno condivisa da tutti i membri di un gruppo. Il tutto viene gestito da un server capace anche di far fronte ad eventi inattesi quali la caduta di un client o la mancata risposta di un utente ad una votazione.
L'unica applicazione che ho mai fatto per Linux è una shell a linea di comando. Nonostante la sua compattezza (46k) offre:
L'unica caratteristica non implementata è un linguaggio di scripting. Seguono il manuale ed il sorgente:
Un XCD è un normale CD che sfrutta non solo lo spazio normalmente destinato ai dati ma anche quello occupato dai codici di correzione d'errore. Questo comporta che un CD da 700Mb si trasformi in uno da 800Mb. E' possibile realizzare questo tipo di CD masterizzandolo in
Mode 2 Form 2 anche se, purtroppo, quasi nessuno programma di masterizzazione offre tale possibilità.
E' necessario comunque conoscere i rischi di tale scelta. Infatti senza tali codici è molto facile che un file possa diventare illeggibile in seguito ad un graffio della superficie, alla scarsa qualità del supporto o ad un processo di masterizzazione non ottimale. Per questo un XCD può essere utilizzato ad un unico scopo: archiviare file multimediali che rimangono fruibili anche in presenza di sporadici errori.
L'uso tipico degli XCD consiste nell'archiviazione di filmati compressi, tipicamente in DivX o XviD. Avere 100Mb in più può seriamente incrementare la qualità del video, soprattutto se si utilizzano formati più adatti a questo scopo dell'avi quali l'ogm o l'mkv. Io ho adottato per lungo tempo l'ogm che permette di avere la traccia audio in ogg, formato non troppo differente dall'mp3 ma che offre quel pizzico di qualità in più che fa sempre comodo.
Cosa c'entra con tutto questo l'XCD Extractor? Ebbene, una volta masterizzato il file multimediale sul CD, benchè sia possibile riprodurlo con un apposito codec, non è invece più possibile copiare il file. L'operazione non viene impedita da Windows ma il file copiato risulta illeggibile. Questo perchè Windows non gestisce correttamente il Mode 2 Form 2 e copia anche gli header dei settori del disco effettuando ne più ne meno una copia RAW del CD. Inoltre viene persa anche la dimensione effettiva del file che in lettura viene approssimata al settore. Ed ecco quindi che ho avuto la necessità di programmare questa utility che permette, come dice il nome, di estrarre le tracce multimediali masterizzate su un XCD.
![]() |
Il programma permette anche di ripristinare la dimensione effettiva del file ed integra un semplice sistema di correzione degli errori in fase di lettura. Inoltre offre la possibilità di calcolare il CRC32 di un qualunque file con un semplice drag and drop.
Il tutto è multithreaded in modo da poter eseguire più compiti contemporaneamente ed avere un'interfaccia sempre rispondente all'input dell'utente.
Non esiste nessun'altro programma al mondo che permetta di estrarre le tracce masterizzate su XCD, a parte una spartanissima utility in ms-dos.
Le reti neurali (RN) sono affascinanti, bisogna dirlo, offrono un paradigma di calcolo completamente differente dal classico approccio algoritmico. Nate dal tentativo di simulare l'attività delle strutture nervose del cervello, si sono evolute per conto proprio sfociando in modelli matematici che hanno poco a che vedere con la controparte biologica. Tuttavia hanno mantenuto caratteristiche sorprendentemente simili a quelle del cervello umano quali la capacità di apprendere, una scarsa precisione associata ad alta elasticità nell'interpretazione dell'input e quindi di estrapolazione. Quest'ultima affermazione può essere anche riscritta come "alta resistenza al rumore", ossia capacità di fornire un output corretto anche in presenza di input poco preciso, cosa impossibile ad un sistema programmato nel modo classico.
L'uso di RN è particolarmente indicato in ambiti quali il riconoscimento di forme, del parlato o di altri pattern che nonostante siano estremamente variabili mantengano delle proprietà comuni. Infatti le RN riescono ad identificare ed estrarre l'informazione rilevante anche se questa è affetta da molto rumore (il resto del segnale che non porta informazione).
Dal punto di vista del loro utilizzo si possono distinguere grosso modo tre categorie basilari:
Per chi fosse interessato all'argomento fornisco in fondo a questa sezione un'ottima introduzione in italiano ed un intero libro in inglese scritto da Ben Kröse e Patrick van der Smagt dell'università di Amsterdam. Sebbene il libro sia del 1996, e quindi non contenga le ultime novità, è molto solido e, soprattutto, è completamente gratuito.
Per capire qualcosa sulle RN ho realizzato due piccoli programmi, entrambi facenti parte della categoria "simulatori di funzioni matematiche".
![]() |
![]() |
![]() |
Simulatore di reti logiche |
Interpolatore di punti |
Il primo programma, come dice il nome, è un simulatore di porte logiche realizzato con il neurone "perceptron", un modello risalente agli anni '50, capostipite del modello a back propagation. Il programma permette di sperimentare con varie porte, incluso lo XOR per cui non vi è convergenza data l'impossibilità di separare linearmente lo spazio dell'input.
Il secondo programma non è mai stato completato, per mancanza di tempo, ma è comunque funzionante ed usa il modello a back propagation. Cliccando con il tasto sinistro del mouse sull'area bianca si segnano i punti da interpolare. Successivamente si avvia l'interpolazione automatica (pulsante con il disegno di una funzione) o quella assistita (ultimo pulsante sulla barra degli strumenti). I comandi in modalità assistita sono autoesplicativi. La zona bianca in tale finestra è la parte che doveva essere completata con un grafico di apprendimento. Il programma doveva prevedere anche la possibilità di creare reti personalizzate disegnandole su schermo, tanto che tutto il codice è stato concepito in modo da permettere un'estrema flessibilità. Purtroppo il progetto è rimasto congelato e questo programmino è tutto quel che ne rimane. La rete integrata è decisamente overfitted (molti strati e molti neuroni) per cui è naturale che le interpolazioni possano risultare estremamente... fantasiose :)
Il 3DVision è stato il mio primo tentativo di realizzare un semplice engine 3D in OpenGL e Win32. Innanzi tutto parlo di tentativo perchè riuscire a fare un engine è assolutamente fuori dalla portata di una singola persona, e poi perchè l'idea originale era diversa, molto più semplice. Infatti il mio scopo era quello di non dover riscrivere ogni volta le solite righe di codice per gestire le funzioni ripetitive come l'inizializzazione, la gestione dell'input, il sonoro, il caricamento di texture e modelli ecc... Però il codice si è andato via via arricchendo fino ad includere un buon sistema di caching e l'animazione scheletale, sia pur con tantissimi limiti.
Alla fine ne è uscita una "massa" che incominciava ad assomigliare ad un engine ed è stato proprio allora che mi sono reso conto di essere in stallo. Il tutto formava qualcosa di più di una raccolta di routines ma, allo stesso tempo, non mostrava un'architettura sufficientemente ragionata da permettere espansioni, cambiamenti o migliorie. Per renderlo definitivamente un engine avrei dovuto inserire quella che è la spina dorsale di ogni applicazione grafica 3D di una certa complessità: uno scenegraph. Inoltre manca anche il collision detection e qualche accenno alla fisica, cui si sarebbe potuto rimediare facendo uso del motore fisico gratuito ODE. Purtroppo, come ho detto, il codice non è sufficientemente flessibile da permettere queste aggiunte e così l'ho dovuto abbandonare con l'unica consolazione di aver imparato molto, soprattutto a non riprovarci di nuovo :)
Poichè ci sono sicuramente parti interessanti nel codice lo pubblico qui di seguito. E' supportato il solo formato 3D ms3d del Milkshape che può anche contenere animazioni. Per quanto riguarda l'audio sono supportati praticamente tutti i formati, le texture invece possono essere PNG, JPEG, PCX, BMP, TGA, o GIF.
![]() |
![]() |
|
Questo giochino è nato dalla difficoltà che ho avuto nel risolvere alcuni problemi di master mind pubblicati su una rivista enigmistica. Così ho deciso di creare un risolutore. Durante l'analisi del problema da risolvere ho deciso di creare il giochino per intero.La scelta di scrivere una "semplice" applicazione console è stata dettata dalla volontà di concentrarsi sull'algoritmo risolutore piuttosto che sull'implementazione dell'interfaccia.
L'applicazione è basata su 3 classi principali: una Table che fornisce l'interfaccia con l'utente, un Solver che incorpora tutta l'intelligenza del gioco, un GameController che definisce il gameplay ed usa la Table ed il Solver per realizzare il gioco.
Sono stati studiati vari algoritmi noti quali la Simple strategy di Shapiro, la Worst-Case strategy di Knuth, l'Expected Size strategy di Irving e la Most Parts strategy di Kooi. Tranne che per la Simple strategy, tutte le altre hanno un consumo di CPU e RAM esponenziali con la dimensione del problema. Quando il problema arriva ad avere 8 colori ed 8 posizioni (8 buchi), il calcolo della prima mossa richiede 1.4*10^14 valutazioni di compatibilità fra pattern (sequenze di colore). E' ovvio quindi che è necessario attuare dei compromessi. Il gioco che ho realizzato riesce a gestire una partita con 8 colori ed 8 posizioni in tempi ragionevoli (minuti su un PC normale) ed un consumo di RAM di 130Mb circa. Il risparmio di RAM è stato ottenuto allungando i tempi di calcolo e generando i dati da elaborare su richiesta piuttosto che tenerli memorizzati. Con meno colori e/o meno posizioni i tempi ed il consumo di RAM diventano irrisori.
![]() |
![]() |
|
Gioco con livello AI = 1 | Gioco con livello AI = 8 |
I livelli di difficoltà da 0 a 8 impiegano la tecnica di Shapiro, opportunamente "instupidita". Il livello di difficoltà 9 invece usa la tecnica di Kooi e, quando la dimensione del problema cresce, può richiedere qualche istante di tempo per "pensarci".
Il gioco permette di fare una partita contro il computer. In questo caso si sceglie la sequenza segreta ed il computer tenta di indovinarla. Si può anche giocare a parti inverse, dove è il computer che sceglie una sequenza segreta e noi dobbiamo indovinarla. C'è inoltre un'opzione che ho chiamato Reverse Mind perchè è quella che permette di risolvere i problemi di Master Mind delle riviste enigmistiche. In Reverse Mind si inseriscono sia le sequenze che i punteggi ed il computer prevede a ridurre le combinazioni possibili. Si procede così, inserendo tutte le coppie sequenza - punteggio che appaiono nella rivista fino a quando il computer non è arrivato ad individuare l'unica soluzione possibile.
I punteggi si danno con delle o e delle x, dove le o indicano un colore giusto al posto giusto, le x indicano un colore giusto al posto sbagliato.
Il resto lo lascio sperimentare a voi :-)