Caro z,
mi dispiace che il mio ritardo a rispondere ti abbia indotto a pensare che "mi hai lasciato dei bla"... e siccome oggi vengo fresco fresco da una giornata in cui uno dei miei "periodi stressati" è terminato, mi sono preso un paio d'ore di relax... ed eccomi qua. Riguardo i tuoi commenti:
per quello che riguarda le presentazioni e LaTeX dobbiamo ammettere una cosa (detta da un estremista del LaTeX, premetto): LaTeX non è lo strumento ideale per fare delle presentazioni in quanto, quando ci si accinge a prepararne una, si deve in qualche modo contraddire la filosofia stessa del LaTeX. Mi spiego meglio: quello che rende LaTeX straordinario è la filosofia secondo la quale il redattore e l'editore del documento non devono essere la stessa persona. Chi sa di matematica, e vuole trasmettere su carta il suo sapere, non è necessariamente un esperto in tipografia. Con LaTeX si deve, in generale, sottostare a delle regole tipografiche che qualcun altro, esperto in materia, ha scritto. L'utente può effettuare dei cambiamenti relativi alle impostazioni tipografiche solo a prezzo di qualche sacrificio, che in generale costa tanto quanto impratichirsi nell'arte tipografica (su questo ci sarebbe ancora da parlare, ma mi fermo qui). Ecco perché i documenti LaTeX sono molto più belli di quelli Word: oltre ai fonts, che sono oggettivamente belli, ma potrebbero in linea di principio essere importati in Word, l'utente non può decidere dove posizionare il titolo, con che grandezza etc. Questa filosofia non è rispettata nel caso delle slides, per le quali, le due persone del redattore e dell'impaginatore
devono coincidere perché l'impostazione grafica
è parte dell'informazione che si vuole trasmettere: dove posizionare una figura (esattamente lì dove la si vuole) è di primaria importanza nella presentazione, ed enfatizzare un concetto con un font piuttosto che un altro fa parte del contenuto. In questi casi, quindi, accedere alle impostazioni LaTeX "fini" può essere scomodo.
Detto questo, appunto, io uso LaTeX anche per le presentazioni (anche per la lista della spesa, direi, quindi non faccio testo): non solo sono, a mio avviso, belle, ma ritengo che anche nel caso delle slides, abbandonarsi alla filosofia LaTeX, autolimitandosi nelle libertà su fonts, colori, è un bene: alcune presentazioni che si vedono in giro sono talmente colorate e scoppiettanti da far passare il contenuto in secondo piano. Il primo pacchetto dedicato alle slides, in ordine ti tempo, credo sia stato proprio
prosper: l'ho usato; non solo ha molte scomodità e incompatibilità, ma se gli stili forniti non sono soddisfacenti, è difficile crearne uno proprio. Poi venne
beamer (almeno nell'ordine in cui io li ho usati): questo pacchetto rimane il più ricco di funzionalità ed è quello che raccomando sempre. Ci sono molte possibilità di personalizzare il documento, e ambienti dedicati. Tra gli svantaggi, quello della compilazione obbligatoria in pdfLaTeX. La cosa migliore di beamer, comunque, è il manuale. Prima di essere un guida su com usare beamer, è una guida su come fare delle presentazioni in generale, e ripristina la filosofia LaTeX anche nelle slides: se puoi leggila, è interessantissima. Recentemente, comunque, è nato un nuovo progetto, una costola del vecchio prosper. Il pacchetto si chiama
powerdot. Ha grossomodo le funzionalità di beamer (quasi tutte, devo dire, e ne anche di nuove), un manuale ridottissimo (quindici pagine) e crearsi il proprio stile è abbastanza facile. Io ormai uso stabilmente quest'ultimo, soprattutto perché le presentazioni beamer sono oramai viste e straviste: in alcune conferenze mi è capitato di vedere fino a tre presentazioni consecutive con lo stesso stile di beamer.
MPI: nel mio caso, una manna dal cielo. Cercando soluzioni di sistemi di equazioni con più di due milioni di incognite (un numero preciso, non una cifra sparata a caso per dire "grande"), ho la necessità di spargerle il più possibile nei vari processori, con tutto quello che questo comporta sia dal punto di vista algoritmico (non tutti gli algoritmi sono parallelizzabili con la stessa efficienza), sia dal punto di vista del codice stesso (una volta che uno sa cosa fare dal punto di vista concettuale, scrivere il codice relativo non è sempre facile). Tra le varie implementazioni MPI (tra cui OpenMPI, Lam MPI, Mpich), io utilizzo sia OpenMpi che Lam MPI: allo stato attuale ho un codice che è portabile (gira, anzi, sta girando anche in questo momento!) su Linux 32 e 64 bit, Sun, e, udite udite Mac OS (ci ritornerò dopo...). Ho un makefile che compila in modo differente a seconda dell'architettura, e chiama l'eseguibile con MPI di conseguenza. Il codice gira indifferentemente su 1,2,3,..., n processori. Come sicuramente saprai, non sempre ha senso aumentare il numero di processori a dismisura, perché non tutti gli algoritmi sono scalabili (leggi: girano m volte più veloce se aumenti il numero di processori di un fattore m).
Non ti avevo ancora detto che sono passato dal C al C++. E quando intendo C++, intendo vera programmazione ad oggetti: ho fatto una discreta fatica a passare a questo stile di programmazione, ma la cosa ha portato ha i suoi frutti. Nel mio caso avevo bisogno di utilizzare lo stesso codice per girare una moltidudine di modelli diversi, che ora sono tradotti un opportune classi. Utilizzo le librerie Trilinos per il calcolo computazionale (http://software.sandia.gov/trilinos/): i laboratori del SandiaLabs (che ho visitato personalmente lo scorso Ottobre) hanno riscritto i classici Blas, Lapack in chiave object oriented, complementandoli con una serie di pacchetti aggiuntivi spaventosi. Dai un'occhiata alla pagina web per vedere quanto il progetto sia esteso. Al Sandia Labs utilizzano queste librerie per scrivere codici che girano su supercalcolatori con centinaia di migliaia di nodi (ancora una volta questa è una stima adeguata, non è un numero grande a caso). Quando ero lì, mi hanno "prestato" un clusterino da 64 processori: "Tanto non lo usa nessuno" è stata la motivazione ufficiale. Usare queste librerie non significa avere degli oggetti "black box" a disposizione, ma bisogna programmare nel dettaglio. Lunghezza media di uno dei miei codici: 2000-3000 linee di comando, senza prendere in considerazione le classi "atomistiche" che uso di default che fanno 7000-8000 linee. Insomma, un po' stressante stargli dietro (e forse capirai perché ho lasciato un po' andare il blog...), ma molto remunerativo: i codici sono veramente molto, molto efficienti. Siamo alle solite: vuoi qualcosa che funzioni veramente bene? Allora devi soffrire con una curva d'apprendimento vertiginosa. Per me è stato sempre così: a cominciare da come digitare sulla tastiera (ricordo di un gioco formidabile sotto linux per imparare a digitare correttamente con tutte le dita), per continuare con Vim (ed il mouse, chi lo usa più) passando per LaTeX e così via...
Ed ora la mela: ultimo acquisto del mio supervisore (espressamente per me ed un mio collega, devo dire) è un server Mac, due Dual Core (Intel) e 8 GB di Ram. Mangio mela, quindi, anche se mi perdo la parte più succosa, cioè la possibilità di avere tutte le funzionalità desktop... ma prima o poi...
Ovviamente, su questa macchina sono "quasi" root, perché ho dovuto installare da zero tutti i pacchetti (OpenMPI, Trilinos, etc.) ed indovina un po' dove ho preso tutte le dritte? Proprio sul sito di High Performance Computing per Mac che mi hai segnalato tu... ed ora alcune considerazioni conclusive:
1) A parte questo lato smanettone, mi occupo anche di Matematica. Matematica applicata, va bene, ma pur sempre Matematica. E di questo mi piacerebbe parlarti(vi?) prossimamente, perché ci sono un mucchio di novità al riguardo.
2) Più mi scrivi e più mi rendo conto che ci interessiamo di molte cose in comune. Quando andrò a trovare Paolo e magari Davide, a Firenze, che ne diresti di unirti a noi per una birra?
3) Non so se sono stato chiaro: grazie dei tuoi "bla"!
4) Qualche dritta sulle flag da usare con g++ con Intel Mac? Tra tutte le macchine che uso, il server Mac è quella più nuova, ma ancora, ahimé la più lenta.
Un abbraccio
Daniele
