Ne segue la ben nota tendenza ad accogliere ciarpame di ogni genere, che fa bella mostra di sé ad ogni successiva esecuzione di ls. Ma come dovrebbe essere una home “ben tenuta”? Secondo me, le regole di base sono due:

• niente file (o il minimo indispensabile), solo directory, e
• un massimo di 10/12 elementi, in modo da non superare le due/tre righe di output di ls (in un terminale di dimensioni sensate).

Purtroppo, la recente evoluzione delle distribuzioni Linux sta andando decisamente contro a questo mio ideale di ordine. Ecco infatti come appare la home directory di un sistema appena installato:

Non abbiamo nemmeno iniziato a caricare i nostri dati che già l’installer ha “opportunamente” pensato di creare una manciata di cartelle di dubbia utilità. Il problema è che queste cartelle non si possono semplicemente cancellare, perché sono memorizzate come percorsi di default per certe applicazioni che quindi, non trovandole, potrebbero giustamente lamentarsi o, peggio ancora, ricrearle autonomamente ogni volta.

Che fare, dunque? La mia personalissima analisi di queste cartelle di default è la seguente:

• Desktop: questa me la devo tenere, anche se personalmente la uso pochissimo (che senso ha mettere delle icone in un posto che è quasi sempre coperto al 90% dalle finestre?), ma il window manager la tratta in maniera speciale e non sarebbe opportuno unirla a un’altra
• Documents: magari a qualcuno serve, per me è totalmente inutile (i miei documenti li organizzo come credo io, non certo mettendo tutto in un’unica directory); una pessima scoppiazzatura dal mondo Windows
• Downloads: questa è effettivamente una buona idea, mettere di default i file scaricati qui contribuisce ad evitare l’effetto “ciarpame nella home” menzionato sopra
• Music, Pictures, Videos: anche queste sono utili per fare ordine, volendo si potrebbero unire in un’unica cartella “Media” ma a volte è meglio averle separate (ad es. per le ricerche su un solo tipo di media)
• Public: totalmente inutile se non avete condivisioni di rete
• Templates: non uso programmi che sfruttino questa directory, quindi inutile anch’essa

Riassumendo, almeno 3 cartelle su 8 sono del tutto inutili, e sarebbe bello liberarsene. Come fare? La chiave sta nel file .config/user-dirs.dirs, che contiene l’associazione tra i “ruoli” che queste directory svolgono nel sistema e il loro percorso su disco. Fortunatamente non è necessario che questa associazione sia biunivoca, quindi è possibile far svolgere a un’unica directory più ruoli. Ad esempio per unificare Documents e Downloads basta modificare il file summenzionato come segue:

XDG_DOWNLOAD_DIR="$HOME/Downloads"
XDG_DOCUMENTS_DIR="$HOME/Downloads"

oppure, per unificare Music, Pictures e Video nell’unica cartella Media:

XDG_MUSIC_DIR="$HOME/Media"
XDG_PICTURES_DIR="$HOME/Media"
XDG_VIDEOS_DIR="$HOME/Media"

Se infine vogliamo solo nascondere una cartella che non ci serve (ad es. Public) in modo tale che non appaia più nell’elenco dei file, ma senza identificarla con altre, la soluzione migliore è rinominarla in modo tale da farla diventare nascosta (ad es. da Public a .Public), e modificare di conseguenza la linea corrispondente:

XDG_PUBLICSHARE_DIR="$HOME/.Public"

Niente male, no? In questo modo abbiamo subito una home molto più ordinata, e possiamo procedere a riempirla senza remore con le nostre schifezze.

Ma parlando di schifezze… cos’altro c’è nella home di un sistema appena installato? Nient’altro di visibile, d’accordo, ma che dire dei file nascosti? Sarà l’argomento della prossima (e ultima…) puntata!

Rimango sempre affascinato da come i giganti informatici del XXI secolo come Google Alphabet siano in grado di sviluppare software enormemente complessi (e che funzionano generalmente bene) in cui però anche l’effettuare correttamente una innocua sottrazione si può rivelare, talvolta, un problema insolubile.

Per questo motivo iniziative come quella lanciata dal cofondatore di Microsoft Paul Allen sono particolarmente importanti. Nel 2006, infatti, Allen ebbe l’idea di mettere a disposizione del pubblico la sua collezione di computer storici (e ancora funzionanti), dapprima tramite accesso remoto (via telnet) e poi, a partire dal 2012, anche di persona, con l’apertura del Living Computer Museum (“Museo dei computer viventi”; già il nome è tutto un programma) a Seattle, la sua città e — non per caso — una delle capitali mondiali dell’informatica.

Il museo, che si è poi ingrandito nel tempo grazie a varie donazioni successive, era l’unico posto al mondo in cui si potevano osservare e (ancora più importante) operare esemplari originali e perfettamente funzionanti di alcuni tra gli elaboratori che hanno fatto la storia dell’informatica, tra cui il PDP-10 della DEC (primo computer usato da Allen e Gates), vari mainframe della linea System/360 della IBM, il mitico Xerox Alto, i primi microcomputer della Apple (l’Apple II su tutti) e della IBM (tra cui il primo e unico Personal Computer), e molti altri ancora.

Purtroppo i verbi coniugati al passato sono d’obbligo: nel frattempo infatti Allen è morto (nell’ottobre del 2018) e il museo (le cui spese di gestione non erano probabilmente coperte nemmeno lontanamente dagli incassi) ha chiuso i battenti nel febbraio del 2020, con la “scusa” della pandemia da COVID-19, e non ha mai più riaperto. È notizia di questi giorni che la chiusura è a tutti gli effetti permanente, e che parte del materiale esposto (almeno 150 pezzi) sarà messo all’asta alla celebre casa d’aste Christie’s.

Al di là del fatto che, come qualcuno ha giustamente osservato, non è esattamente elegantissimo vendere all’asta del materiale che è stato donato a un museo con l’idea che rimanesse in quel museo (anche se è stato annunciato che i proventi andranno in beneficenza), la cosa veramente sconfortante è il fallimento dell’idea stessa. Se nemmeno uno degli uomini più ricchi del mondo è in grado di costruire un’istituzione che permetta di continuare a operare questi oggetti che hanno avuto un ruolo così importante nell’evoluzione della tecnica umana, che speranze possiamo avere sul fatto che qualcun altro ci riesca?

Aggiornamento (27/06): discussione dell’annuncio su Hacker News. Secondo Kragen Sitaker, il PDP-10 che era ospitato nel LCM era l’ultimo esemplare ancora funzionante al mondo. In quanto Emacsiano di lunga data, mi scende la lacrimuccia.

Aggiornamento (19/08): Jason Scott fornisce altre informazioni interessanti su tutta la vicenda.

Nello specifico ci sono ricascato una decina di giorni fa, quando, dovendo riprendere un po’  di dimestichezza con il proof assistant (“assistente dimostrativo”?) Coq, ho deciso di leggermi il primo volume di Software Foundations. Per chi non lo sapesse (ovvero — a naso — il 99,9999% della popolazione mondiale), si tratta di un corso sui fondamenti logici della programmazione con la peculiare caratteristica di essere completamente formalizzato (nel calcolo delle costruzioni induttive, che è appunto la teoria implementata da Coq). Ah, e per la cronaca è anche (gratuito e) liberamente disponibile dal sito sopra linkato.

La cosa era partita, giovedì 18 Aprile, in maniera del tutto innocente, ovvero scaricando l’archivio con i sorgenti del libro, spacchettandolo e iniziando a leggere (e a fare gli esercizi incorporati nel testo). La domenica mi accorgo che, bene o male, stavo riuscendo a tenere il ritmo di un capitolo al giorno, compatibilmente con gli altri impegni che avevo. Per cui mi sono detto: perché non provare a continuare così fino alla fine? La settimana dopo ci sarebbe oltretutto stato il ponte del 25 aprile, quindi la cosa non sembrava completamente impossibile.

Per farla breve, i risultati li vedete nello screenshot qui sopra: tutto sommato direi che lo speedrun è effettivamente riuscito, con l’eccezione del capitolo IndProp che ha richiesto due giorni e peraltro, come potrà testimoniare chiunque abbia fatto il corso, contiene sostanzialmente il doppio del materiale del capitolo medio. (I capitoli in fondo, quelli che non ho modificato, sono opzionali, anche se conto di fare pure quelli.)

Ma gli esercizi, direte voi?

Quasi tutti ok, come si può notare dal resoconto qui sopra. (Il comando Admitted. è quello che si usa all’interno di una dimostrazione per dire a Coq «basta, non ne posso più, va’ a quel paese e fammi andare avanti». Più o meno.) Con l’eccezione di alcuni esercizi inutilmente noiosi su cui non sono stato a perdere tempo (in Induction e in Logic; i match in Basics sono spurii), gli unici che mancano sono in IndProp e in Imp, e riguardano comunque parti opzionali e/o addizionali (su cui comunque conto di ritornare con più calma).

Mica male, no? E adesso sotto con il volume 2, dove inizia la parte più interessante; ma stavolta senza vincoli di tempo, perché un bel gioco dura poco!

Ebbene, vi annuncio con grande gioia che sì, è ancora possibile mettere su un sistema dual boot nel 2024, ma ci sono (ovviamente) alcune trappole disposte sul cammino che è necessario evitare per non complicarsi la vita oltremodo. Siccome online ho trovato un sacco di informazioni obsolete e/o fuorvianti, ho pensato di riassumere i passaggi principali in un post, che mi auguro possa servire da riferimento ad altri sventurati che decidessero di intraprendere questa strada (compreso, eventualmente, me stesso nel futuro).

Naturalmente è necessario che l’hardware di cui disponete sia supportato dalla versione più recente del kernel Linux; questo purtroppo non è un dato scontato (oggi come nel 1998…), ma è facilmente verificabile prima di procedere su appositi siti come il glorioso linux on laptops o sui siti delle varie distribuzioni (ad esempio qui per Debian, la mia distro di riferimento). Io non ho avuto problemi da questo punto di vista: il PC che ho usato infatti è uno Thinkpad della Lenovo, linea di portatili nota per l’ottima compatibilità del loro hardware con Linux.

Anzitutto sgombriamo il campo da un primo equivoco: non è più necessario disabilitare lo UEFI Secure Boot per installare Linux nel 2024. Molte guide online affermano il contrario, ma è da almeno cinque anni che tutte le maggiori distribuzioni sono in grado di gestire il SB senza problemi, grazie a uno shim sviluppato originariamente da Ubuntu. La cosa è importante perché il Secure Boot funge da root of trust per il sistema, e alcune applicazioni possono rifiutarsi di funzionare su sistemi in cui esso è disabilitato.

Nessun problema da questo punto di vista, quindi? Non proprio: alcune marche (tra cui, neanche a dirlo, Lenovo…) hanno pensato bene di vietare di default l’uso del Secure Boot da parte di software che non sia firmato dalla chiave privata della Microsoft (!!). Per questo motivo potrebbe dover essere necessario entrare nel menu di boot e abilitare esplicitamente questa possibilità, come descritto ad esempio da Lenovo in questo documento.

Superato questo primo ostacolo diventa tecnicamente possibile scaricare una immagine ISO della vostra distribuzione preferita, copiarla su una pennetta USB (usando i soliti metodi ben documentati) e procedere all’installazione (se necessario, abilitando l’avvio da USB nel solito menu di boot). Ma prima di farlo è opportuno disinnescare altre due mine proditoriamente piazzate dalla Microsoft.

1. La prima mina si chiama Bitlocker, nel caso fosse attivo (lo è di default nell’edizione Pro di Windows, cosa che ovviamente ignoravo). Trattandosi di un sistema di crittazione del disco rigido, non gli vanno molto a genio le modifiche fatte alle sue spalle, ragion per cui, se non lo disabilitate, ad ogni riavvio Windows si bloccherà chiedendovi di immettere una recovery key per sbloccare il vostro prezioso volume. Questa recovery key si può recuperare (ehm…) utilizzando l’account Microsoft che è stato associato al PC in fase di installazione; eggià, perché nel 2024 è diventato impossibile usare un computer senza avere (accesso a internet e) un account Microsoft.
   (Sì, lo so che volendo è possibile installare Windows eludendo la richiesta di creare un account, ma realisticamente, quante persone si prenderanno il disturbo di farlo?)
   ((Peraltro, per una volta mi sento di dover ringraziare la MS: grazie a questa esperienza ho potuto provare, seppur in maniera surrogata, l’emozione indubbiamente notevole di essere oggetto di un attacco ransomware.))
2. La seconda mina si chiama Fast Startup, anch’esso attivo di default; si tratta di un sistema per ridurre i tempi di avvio di Windows che, essenzialmente, invece di spegnere il PC quando gli dite di farlo lo manda in ibernazione. In questo caso il sintomo non è così traumatico (Windows si limita a notare all’avvio che il PIN che avevate inserito non è più valido, e vi chiede di immetterne un altro), ma è comunque fastidioso, motivo per cui è opportuno disabilitare la “feature” una volta per tutte, specialmente se avviate Windows una volta ogni morte di papa.

A questo punto ogni ostacolo è rimosso, e si può procedere con l’installazione. Se l’installer è fatto bene, dovrebbe permettervi di ridimensionare la partizione di Windows per fare spazio a Linux; quando sarà il momento di decidere le dimensioni, tenete presente che la partizione Windows sarà accessibile da Linux ma non viceversa, per cui può essere opportuno lasciare un po’ più di margine alla partizione Windows (ma ovviamente tutto dipende dall’uso che verrà fatto dei due sistemi).

Infine, alcuni consigli specifici per Debian:

• Usate l’immagine netinst se avete un accesso di rete “facile”, cioè tramite cavo ethernet oppure via wi-fi (controllate che la vostra scheda sia supportata dal kernel!), ma solo in caso di autenticazione tramite chiave condivisa (PSK); metodi di autenticazione più sofisticati non sono al momento supportati da debian-installer.
• In caso contrario conviene scaricare una immagine più corposa, che vi permetterà di mettere in piedi un sistema ragionevolmente completo senza accesso a internet; quest’ultimo potrà poi essere configurato successivamente con calma.

Se tutto va bene, nell’arco di una mezz’oretta avrete il vostro sistema dual-boot bello e pronto. Per sicurezza si può far girare chkdsk.exe sulla partizione Windows, giusto per verificare che l’aver rimpicciolito la partizione di Windows non abbia prodotto danni (ma non dovrebbe).

Yes, Virginia, there is a Santa Claus!

Gli esperti di programmazione esoterica riconosceranno nel sottoinsieme di istruzioni x86 utilizzate dal tizio qualcosa di simile a una macchina a una istruzione del tipo subtract and branch if negative, vista la disponibilità di SUB, CMP e Jxx, ma le pesanti limitazioni sui metodi di addressing rendono tutto notevolmente più complicato, per non parlare del vincolo sull’assenza di codice auto-modificantesi. Davvero ben fatto!

Ma come è nato questo deposito di articoli (o e-prints) che, soprattutto in alcuni campi della fisica e della matematica, è ormai diventato un punto di riferimento imprescindibile? La storia ce la racconta nientemeno che il suo ideatore, il fisico teorico americano Paul Ginsparg, in questo articolo (reperibile indovinate un po’ dove?) di due anni fa.

Tutto comincia nella primavera del 1991, quando Ginsparg si trasferisce da Harvard ai laboratori di Los Alamos, nel New Mexico, celebri per essere stati il luogo dove Fermi, Oppenheimer e gli altri membri del progetto Manhattan costruirono nel 1945 le prime bombe nucleari. Arrivato nel suo nuovo ufficio, Ginsparg scopre con piacere di avere a disposizione, per la prima volta in carriera, un computer tutto per lui (una NeXTstation a 25 MHz con hard disk da 105 Mb e 16 Mb di RAM) e ne approfitta per mettere in pratica un’idea che gli girava in testa da un po’ di tempo.

Dobbiamo anzitutto precisare che all’epoca Internet non c’era ancora, o meglio stava nascendo proprio in quegli anni. La principale infrastruttura di rete, il cosiddetto backbone, era fornita dalla NSFNet, una rete creata nel 1985 per iniziativa della National Science Foundation che aveva raccolto il testimone dalla precedente ARPANET. Nel 1991 la NSFNet collegava tra loro 13 nodi sparsi per gli Stati Uniti alla straordinaria (per i tempi) velocità di 1.5 Mbit/s:

Le più piccole reti regionali potevano poi mettersi in comunicazione tra di loro collegandosi al nodo NSFNet più vicino.

Questo primo abbozzo di rete globale fu fondamentale per facilitare i contatti tra gli accademici statunitensi e l’uso delle e-mail, prima limitato alle reti locali nelle singole università, divenne presto un’abitudine anche per le comunicazioni a lunga distanza. Tra l’altro, se diamo retta a Ginsparg, pare che sia stato proprio lui il primo ad avere l’idea di inserire tra i dati presenti nella testata dei propri articoli anche l’indirizzo e-mail, per la prima volta in questo lavoro del dicembre 1987:

Un’altra cruciale innovazione di quegli anni fu la diffusione capillare del programma di typesetting TeX, la cui versione “definitiva” era uscita due anni prima (1989). Molti ricercatori, soprattutto tra i più giovani, si erano convertiti rapidamente all’uso del nuovo sistema, soprattutto per via della notevole semplificazione che garantiva nella composizione delle formule matematiche.

Con la diffusione dei documenti elettronici i tempi erano maturi per pensare a una infrastruttura che facilitasse la diffusione rapida e su larga scala dei nuovi articoli non ancora arrivati alla pubblicazione su rivista (tipicamente perché in attesa di peer review), i cosiddetti preprint. I primi tentativi in tal senso furono compiuti affidandosi a delle mailing list gestite manualmente, ma iscriversi a una mailing list di questo tipo significava correre costantemente il rischio di vedere la propria casella e-mail intasata dagli articoli in arrivo. Fu così che Ginsparg ebbe l’idea di creare un sistema completamente automatizzato che fosse in grado di ricevere ed archiviare i preprint, divulgare periodicamente una lista contenente i titoli e gli abstract dei preprint ricevuti, e infine distribuire gli articoli veri e propri su richiesta.

Nasce così la prima incarnazione del’arXiv, un rudimentale server e-mail (e, qualche mese dopo, anche FTP) gestito da un insieme di script csh, reperibile allo storico indirizzo xxx.lanl.gov (il curioso nome “xxx”, che ovviamente non ha nulla a che fare con la pornografia, deriva dalla sigla che Ginsparg era solito inserire nei suoi sorgenti TeX dove c’era qualcosa da correggere.) Il successo fu immediato: Ginsparg si aspettava un centinaio di preprint all’anno, ne arrivarono 400 nei primi sei mesi. L’onore della prima submission, ricevuta il 14 Agosto 1991, spettò al noto stringhista Gary Horowicz assieme a J. H. Horne, mentre in quarta posizione (16 Agosto) troviamo nientemeno che Ed Witten, peraltro non con uno dei suoi lavori più famosi, e appena fuori dalla top ten (21 Agosto) c’è il primo contributo di un altro grosso calibro, Ashoke Sen.

Curiosamente, l’idea iniziale era di cancellare i preprint archiviati dopo tre mesi dalla loro ricezione, quando in teoria essi sarebbero stati resi obsoleti dalla pubblicazione su rivista dell’articolo corrispondente; ma Andrew Strominger fece giustamente notare a Ginsparg che poter ottenere istantaneamente la copia di un articolo via e-mail è molto più comodo rispetto al perdere delle ore a cercare la relativa stampa nel proprio ufficio, e così nulla venne mai cancellato.

Ben presto cominciarono a spuntare “cloni” dell’archivio originale (ufficialmente denominato hep-th, che sta per high energy physics – theory) relativi ad altre aree della fisica e della matematica: così il 5 Febbraio 1992 nasce l’archivio alg-geom (geometria algebrica) all’indirizzo eprints.math.duke.edu (oggi non più in uso), mentre l’8 Marzo arriva, a grande richiesta, l’archivio hep-ph (fenomenologia). Un poco più tardi, il 7 Aprile, nasce hep-lat (teorie su reticolo) e tre giorni più tardi arrivano astro-ph (astrofisica), cond-mat (fisica dello stato solido) e funct-an (analisi funzionale), questi ultimi ospitati in Italia, su un server della SISSA (oggi, purtroppo, anch’esso defunto).

Nell’autunno del 1992 Ginsparg viene a conoscenza di una nuova e interessante tecnologia da poco sviluppata al CERN, e decide di dare una mano alla libreria dello SLAC per mettere online un server web (il primo su suolo americano!) che consentisse, tra le altre cose, di accedere a un’altra storica risorsa che ogni fisico conosce ed ama, il database SPIRES (recentemente ribattezzato inspire). Un sito web per il “physics e-print archive”, com’era chiamato all’epoca, arriverà solo nell’Aprile del 1993.

Molti anni più tardi, e precisamente il 28 Dicembre del 1998, il sito acquisterà finalmente il nome arXiv, trasferendosi nel contempo al suo attuale indirizzo. L’idea che sta dietro a tale criptica sigla è che la X maiuscola va pensata come la lettera greca χ, da cui la pronuncia simile a quella della parola inglese «archive». Per la cronaca, il nome più ovvio di “archive” dovette essere scartato perché nel frattempo all’indirizzo archive.org si era già stabilmente insediato l’Internet Archive: ecco un caso in cui persino l’essere nati prima ancora del web non è stato sufficiente ad assicurarsi il nome di dominio che si desidera!

«The arXiv could well end up as string theorists’ greatest contribution to science.» (David Mermin)

Queste riflessioni sono ispirate da un vecchio articolo in cui mi sono imbattuto recentemente che riguarda il linguaggio di programmazione J, ideato negli anni ’90 da Ken Iverson come successore della sua precedente creazione APL. Si tratta di un linguaggio molto diverso da quelli mainstream, sotto molti punti di vista. In particolare, la sua peculiare sintassi permette di scrivere programmi molto più concisi rispetto al loro equivalente in un linguaggio convenzionale. Ma la domanda è: ne vale la pena? Prendiamo ad esempio il codice illustrato nell’articolo di cui sopra:

+/1e6<,!/~>:i.100

Anche se a prima vista è difficile crederlo, questa stringa di 17 caratteri è un programma completo in J; esso calcola il numero di coefficienti binomiali \(n\choose k\) maggiori di un milione, per \(n\) e \(k\) che variano da 1 a 100. Rimando all’articolo sopra citato per una spiegazione dell’algoritmo utilizzato.

La cosa interessante è che la stessa identica strategia risolutiva (sostituendo gli array con le liste) può essere implementata in Scheme, perdendo un po’ in concisione ma guadagnando enormemente in trasparenza del codice. Proviamo a fare questo esercizio di traduzione, seguendo l’algoritmo così come spiegato dal buon Tardieu.

Anzitutto dobbiamo generare una lista dei primi 100 numeri naturali. Non casualmente, nella libreria srfi-1 c’è una funzione iota che è l’esatta traduzione dell’operatore i di J (e di APL). Quindi la nostra prima mossa sarà

(iota 100)

Proprio come in J, questo genera in realtà la lista dei numeri da 0 a 99, quindi occorre incrementare ciascun numero di una unità:

(map 1+ (iota 100))

Qui ho usato la procedura 1+ predefinita del mit-scheme, ma in qualunque altro interprete Scheme basterebbe usare la procedura anonima (lambda (x) (+ x 1)).

Supponiamo di avere già a disposizione una procedura (binom n k) che calcola il coefficiente binomiale di \(n\) e \(k\); dobbiamo costruire una tabella formata dai risultati di questa procedura per \(n\) e \(k\) che assumono ciascuno dei valori contenuti nella lista creata precedentemente. La soluzione di questo problema si ottiene, come ben sa chiunque abbia letto il secondo capitolo di SICP, annidando due applicazioni di map. Il fatto che dobbiamo utilizzare lo stesso argomento per due volte significa che il problema ci sta supplicando di introdurre una procedura apposita, e noi lo accontentiamo:

(define (table f x)
  (map (lambda (n)
         (map (lambda (k)
                (f n k))
              x))
       x))

Questa procedura ritorna una lista di liste (la versione Lispiana di una matrice), ma noi vogliamo dimenticarci della suddivisione in righe e ottenere semplicemente una lista con tutti i coefficienti binomiali che abbiamo calcolato; vogliamo cioè “schiacciare” la nostra lista di liste, il che si fa usando reduce con append:

(reduce append
        '()
        (table binom (map 1+ (iota 100))))))

Dunque questo codice genera una lista con tutti i coefficienti binomiali desiderati. Per concludere occorre sostituire ciascuno di questi numeri con 1 o con 0 a seconda che esso sia maggiore di un milione o meno:

(map (lambda (n) (if (> n 1000000) 1 0))
     (reduce append
             '()
             (table binom (map 1+ (iota 100))))))

e infine sommare tutti i risultati, ancora con reduce:

(reduce +
        0
        (map (lambda (n) (if (> n 1000000) 1 0))
             (reduce append
                     '()
                     (table binom (map 1+ (iota 100))))))

(In realtà, da un punto di vista Lispiano sarebbe probabilmente più naturale usare filter per eliminare dalla lista tutti i numeri minori di un milione e ritornare come risultato la lunghezza della lista risultante; ma qui stiamo semplicemente facendo un esercizio di traduzione letterale, e quindi ci dobbiamo attenere all’algoritmo originario che è pensato per operare su array di lunghezza fissa piuttosto che su liste di lunghezza variabile.)

La prova del fuoco:

che è il risultato corretto.

Il bello è che i due programmi, l’originale in J e la sua traduzione in Scheme, si possono praticamente mettere in corrispondenza biunivoca:

Mi sembra inutile evidenziare quale delle due versioni sia maggiormente leggibile. Forse non è un caso se J e APL sono stati definiti, ironicamente ma fino a un certo punto, linguaggi di sola scrittura.

Non ricordo di preciso a quando risale il mio primo incontro col K&R. Mio fratello era probabilmente al secondo anno di università (al primo si studiava il Modula-2), quindi io avrò avuto tra i 12 e i 13 anni. Ho ancora bene in mente però l’impressione di curiosità che quel libro, con la sua buffa copertina bianca sulla quale campeggiava una grande C azzurra, aveva destato rapidamente in me una volta entrato in casa.

Un’altra cosa che ricordo bene è che quando iniziai a leggerlo, partendo diligentemente dalla prefazione (abitudine questa che mi è rimasta ancora oggi, per ogni tipo di libro), ci fu un passaggio che mi colpì in modo particolare. Siccome in questo momento non ho sottomano (e non posso reperire in alcun modo) una copia dell’edizione italiana, non posso fare altro che citarvi il paragrafo corrispondente dell’edizione originale:

In our experience, C has proven to be a pleasant, expressive, and versatile language for a wide variety of programs. It is easy to learn, and it wears well as one’s experience with it grows. We hope that this book will help you to use it well.

Ricordo che commentai la cosa con mio fratello, facendogli notare che a giudicare da questa descrizione il C sembrava una figata incredibile. Mio fratello (che non aveva letto la prefazione: per lui quello era un libro da studiare, non da leggere per diletto!) diede un’occhiata a quel passaggio e commentò: «Secondo me ci stanno prendendo per il culo».

In effetti non so se imparare il C da quel libro sia davvero un’esperienza “facile” o “piacevole” come la descrivono K&R, però so che a quel libro, e di conseguenza ai suoi due autori, sono rimasto un po’ affezionato, anche adesso che il C non lo uso quasi più. E così, quando oggi ho appreso della morte di Dennis Ritchie, il rubinetto della mia memoria ha perso un po’; e invece di lasciarli scorrere via, ho pensato bene di raccogliere i pochi ricordi che ne sono usciti in questo post. Dopotutto i blog dovrebbero servire anche a questo… almeno credo.

Si tratta di un classico esempio di immagine raster, curioso termine che ha origine nella lingua inglese (in cui deriva dal latino rastrum, “rastrello”) ed è stato successivamente reimportato in italiano con il suo nuovo significato tecnico, in una sorta di girotondo linguistico. Un’immagine raster non è altro che una griglia rettangolare di pixel a ciascuno dei quali è associato un colore; nel nostro caso i colori in gioco sono solo due, bianco e nero, e si parla perciò più propriamente di una bitmap, o griglia di bit, l’idea essendo ovviamente che un bit acceso corrisponda a un pixel nero e un bit spento a uno bianco (o viceversa, non è importante).

Un’immagine di questo tipo si presta molto facilmente a rappresentare una relazione binaria tra numeri naturali: quest’ultima infatti non è altro che un insieme di coppie ordinate di elementi di \(\mathbb{N}\), o se si preferisce un sottoinsieme del prodotto cartesiano \(\mathbb{N}\times \mathbb{N}\) (che per definizione è l’insieme di tutte le coppie ordinate di numeri naturali). Ora, si dà il caso che \(\mathbb{N}\times \mathbb{N}\) sia proprio una griglia bidimensionale (infinita, ma non sottilizziamo…), e quindi che un suo sottoinsieme \(R\) sia completamente determinato “accendendo” tutti e soli i pixel di questa griglia che corrispondono a coppie \((a,b)\) di numeri naturali che appartengono a \(R\). Si ottiene così quello che si suole chiamare il grafico della relazione binaria \(R\).

Nell’immagine precedente la relazione raffigurata è quella di divisibilità, usualmente denotata \(a\mid b\), definita come segue:

\(a\mid b\) se e solo se esiste \(n\in \mathbb{N}\) tale che \(b = na\)

In altri termini, il pixel di coordinate \((a,b)\) (partendo dall’angolo in alto a sinistra) è acceso se e solo se \(a\mid b\), cioè \(a\) divide \(b\).

Naturalmente il discorso può essere ripetuto pari pari per qualunque altra relazione tra numeri naturali. Ad esempio, due numeri \(a\) e \(b\) si dicono coprimi se non hanno fattori primi in comune, o equivalentemente se il loro m.c.d. è 1. Il seguente è il grafico della relazione “\(a\) è coprimo a \(b\)” sull’insieme dei numeri naturali minori di 80, ingrandito quattro volte (o se preferite, con pixel di lato 4):

Niente male, nevvero? La vedrei bene come stampa da appendere al muro, o magari come tappeto, al posto di un più classico persiano.

Tra l’altro, certe proprietà di una relazione binaria emergono chiaramente dal suo grafico: ad esempio l’immagine precedente è simmetrica per riflessione attorno alla diagonale principale, il che corrisponde al fatto che la relazione di coprimalità è simmetrica (se \(a\) è coprimo con \(b\) allora è anche vero che \(b\) è coprimo con \(a\)). O ancora, la diagonale principale è formata da soli pixel bianchi: questo significa che la relazione in esame è irriflessiva (nessun numero è coprimo con sé stesso). Viceversa nell’immagine a inizio post la diagonale principale è formata da soli pixel neri: questo perché ogni numero è divisibile per sé stesso, ovvero la relazione di divisibilità è riflessiva. Per la cronaca, essa è anche antisimmetrica e transitiva (e quindi è una relazione d’ordine parziale), e con un po’ di impegno anche queste altre proprietà potrebbero essere messe in evidenza per via grafica.

Ma parlare di queste cose ci porterebbe su un’altra strada; quello che voglio fare adesso è invece spiegare in che maniera ho generato queste immagini. Si tratta in realtà di un esercizio di programmazione abbastanza semplice. Come i lettori di vecchia data di questo blog forse ricorderanno, da circa un anno a questa parte il mio linguaggio di programmazione preferito è il Lisp, nella sua variante nota come Scheme, ed è pertanto in tale linguaggio che ho implementato il programma in questione.

Ora, poiché il Lisp è sfortunatamente molto poco conosciuto rispetto a linguaggi più tradizionali come C e derivati, immagino che questo post perderà gran parte del suo interesse per molti di voi. D’altro canto non posso neanche somministrarvi un crash-course del tipo “il Lisp in mezz’ora” (ammesso che una cosa del genere sia possibile), quindi non mi resta che confidare nella leggibilità del mio codice. Almeno una cosa però la devo assolutamente spiegare: laddove nella stragrande maggioranza dei linguaggi di programmazione si scrive f(x) per indicare l’applicazione della funzione f all’argomento x, in Scheme si scrive invece (f x); similmente si scrive (f a b) se f è una funzione di due argomenti, e così via. La stessa notazione si applica anche ai predicati: così ad esempio un test quale a>0 si scrive (in maniera un po’ perversa) come (> a 0). Senza questa dritta, un sorgente Lisp rischia di sembrare solo un’accozzaglia di parentesi messe giù a caso.

Il modo più naturale di implementare in Scheme una relazione binaria tra numeri naturali è quello di definire il corrispondente predicato, cioè una procedura che mangia due numeri naturali e ritorna #t (“vero”) se i due numeri sono in relazione tra loro e #f (“falso”) altrimenti. Ad esempio per la relazione di divisibilità questo si fa come segue:

(define (divides? a b)
  (if (= a 0)
      (= b 0)
      (= (remainder b a) 0)))

(È convenzione comune in Scheme dare ai predicati un nome che termina con un punto di domanda, per evidenziare che il risultato è un valore di verità. La sintassi dell’espressione condizionale if è quella che ci si aspetta: (if x y z) significa “se x è vero allora il risultato è y, altrimenti è z“.)

In generale, supponiamo di avere un predicato pred cui si possa dare in pasto una qualunque coppia di numeri naturali e di voler produrre il suo grafico. Siccome i numeri naturali sono infiniti (ma va?), dovremo accontentarci di graficare la relazione su un sottoinsieme di \(\mathbb{N}\times \mathbb{N}\), per esempio sul quadrato \([0,n]\times [0,n]\). La prima cosa da fare è quella di calcolare (pred a b) per tutti i valori di a e b compresi tra 0 e \(n\) e memorizzare i risultati in una struttura dati opportuna. Siccome in Lisp (che, ricordiamo, è l’acronimo di list processing) la struttura dati per eccellenza è la lista, raccoglieremo tutti questi simpatici bit in una lista. Questo si può fare con una ricorsione che, se stessi scrivendo in inglese, definirei almost straightforward (è un classico esercizio da primi capitoli di un libro di programmazione in Lisp), e otteniamo così una procedura di questo tipo (in cui supponiamo che i simboli pred e n siano già definiti):

(define (gen-bit-list i j)
  (cond ((> i n) '())
        ((= j n) (cons (pred i j)
                       (gen-bit-list (+ i 1) 0)))
        (else (cons (pred i j)
                    (gen-bit-list i (+ j 1))))))

(cond è un costrutto analogo allo switch del C: si tratta di un condizionale multiplo, o sequenza di if effettuati uno dopo l’altro.) L’indice i corre sulle righe e l’indice j sulle colonne, e la ricorsione è sul quadrato \([0,n]\times [0,n]\) con l’ordinamento lessicografico. Questo significa che l’indice j viene incrementato fino a raggiungere la fine di una riga (j=n); quando ciò accade viene incrementato i e resettato a zero j. La condizione di terminazione è i>n, nel qual caso la procedura ritorna la lista vuota (che in Scheme si denota con '() e in altri dialetti di Lisp con nil); la ricorsione fa il resto, costruendo a partire da questo caso base la lista desiderata.

C’è ancora un piccolo caveat: siccome un predicato ritorna non un numero ma un valore di verità (cioè #t o #f), la procedura così com’è costruisce in realtà una lista di valori di verità, mentre noi vogliamo una lista di bit. Per rimediare a ciò basta definire quello che in gergo si chiama un wrapper, cioè una procedura che “avvolge” il predicato pred e converte il suo valore nella forma che desideriamo:

(define (pred-wrapper a b)
  (if (pred a b) 1 0))

e sostituire poi tutte le chiamate a pred con chiamate a pred-wrapper.

Occorre ora trasformare questa lista di bit in un’immagine bitmap vera e propria. Il modo più semplice per farlo è quello di usare il formato (plain) PBM che, per citare la relativa pagina di manuale, è talmente semplice che

we hardly need to define the format here, because you can decode it by inspection.

Sostanzialmente, un file plain PBM è formato da un header (che specifica larghezza e altezza della griglia di bit) seguito dalla sequenza di bit che compongono l’immagine, ciascuno dei quali è rappresentato dal numero 0 (bianco) o 1 (nero), separati da spazi. Più semplice di così si muore! Ecco la procedura che scrive la lista di bit ottenuta in precedenza nel file associato alla porta port (che deve essere stata precedentemente aperta in scrittura):

(define (write-bit-list lst port)
  (if (null? lst)
      (display "\n" port)
      (begin (display (string (car lst) " ") port)
             (write-bit-list (cdr lst) port))))

(car e cdr sono i nomi che il Lisp dà alle procedure che ritornano la testa e la coda di una lista, quelle che di solito vengono chiamate head e tail.)

A questo punto resta solo da mettere assieme queste procedure con il codice che provvede ad aprire il file di output e a scrivere l’header PBM. Il programma completo è:

(define (graph pred n filename)
  (define (pred-wrapper a b) (if (pred a b) 1 0))

  (define (gen-bit-list i j)
    (cond ((> i n) '())
          ((= j n) (cons (pred-wrapper i j)
                         (gen-bit-list (+ i 1) 0)))
          (else (cons (pred-wrapper i j)
                      (gen-bit-list i (+ j 1))))))

  (define (write-bit-list lst port)
    (if (null? lst)
        (display "\n" port)
        (begin (display (string (car lst) " ") port)
               (write-bit-list (cdr lst) port))))

  (let ((outport (open-output-file filename)))
    (display (string "P1\n" (+ n 1) " " (+ n 1) "\n")
             outport)                             ; PBM header
    (write-bit-list (gen-bit-list 0 0) outport)   ; raster data
    (close-output-port outport)))

L’immagine del quiz è stata prodotta con un comando del tipo
(graph divides? 255 "prova.pbm") e successivamente sottoposta a un veloce passaggio con GIMP per convertirla in formato PNM compresso e ingrandirla.

In realtà, questa prima versione di graph può essere migliorata in vari modi. Tanto per cominciare, notiamo che la lunghezza della lista di bit generata da gen-bit-list cresce come il quadrato di n (lato dell’immagine), e ciò può portare a ricorsioni che esauriscono lo spazio disponibile per lo stack anche per valori di n relativamente bassi. Un modo di procrastinare questo problema è quello di memorizzare, al posto dei singoli bit, direttamente i byte che si ottengono “impacchettando” 8 bit alla volta. In questo modo diventa anche molto più facile creare in output un file in formato PBM vero e proprio (che si differenzia dal plain PBM proprio per il fatto che i bit sono rappresentati come tali, cioè come cellette all’interno di un byte, e non tramite i simboli 0 e 1).

Un’altra piccola ma significativa modifica consiste nell’introdurre la possibilità di graficare la relazione data non necessariamente sul quadrato \([0,n]\times [0,n]\) ma su un qualunque rettangolo \([r_{0},r_{1}]\times [c_{0},c_{1}]\) per opportuni numeri naturali \(r_{0}\), \(r_{1}\), \(c_{0}\) e \(c_{1}\). Implementando tutte queste idee sono arrivato alla versione corrente del programma (ribattezzato pred-plot), con cui ho prodotto le immagini di questo post:

(define (pred-plot pred r0 r1 c0 c1 filename)
  (define (pred-wrapper a b) (if (pred a b) 1 0))

  (define (pad w)
    (if (= (string-length w) 8)
        w
        (pad (string w 0))))

  (define (gen-byte-list i j w)
    (cond ((> i r1)
           '())
          ((> j c1)
           (cons (pad w) (gen-byte-list (+ i 1) c0 "")))
          ((= (string-length w) 8)
           (cons w (gen-byte-list i j "")))
          (else
           (gen-byte-list i (+ j 1) (string w (pred-wrapper i j))))))

  (define (write-byte-list lst port)
    (if (null? lst)
        (display "\n" port)
        (begin (write-char (integer->char (car lst)) port)
               (write-byte-list (cdr lst) port))))

  (let ((byte-list (map (lambda (w) (string->number w 2))
                        (gen-byte-list r0 c0 "")))
        (outport (open-output-file filename)))
    (display (string "P4\n" (+ (- c1 c0) 1)
                     " " (+ (- r1 r0) 1) "\n")
             outport)                             ; PBM header
    (write-byte-list byte-list outport)           ; raster data
    (close-output-port outport)))

(Nota: il codice precedente funziona senza problemi con l’interprete Scheme del MIT, che è quello che uso di solito; non garantisco per gli altri, anche se un qualunque interprete R5RS dovrebbe andare bene.)

L’ovvio passo successivo consiste nel passare dalle immagini in bianco e nero a quelle in toni di grigio, ovvero dal grafico di una relazione binaria a quello di una operazione binaria. Ciò rende possibile ad esempio generare immagini come questa:

che rappresenta il grafico dell’addizione nel quadrato \([0,255]^{2}\). Per questo e altri sviluppi vi rimando però a una prossima (spero) puntata.