L’arte di scrivere dati numerici con LaTeX

Ovvero: “Le gioie di siunitx”
————————————–

Ciao a tutti. Sono alle prese con il pacchetto siunitx: mi piace moltissimo, perché concentra funzioni di altri pacchetti (come numprint, icomma e dcolumn) e si propone come la soluzione definitiva per la scrittura di dati numerici.

Delle colonne S di siunitx c’è però qualcosa che mi sfugge. Da quanto ho capito, quando maneggia una colonna S, siunitx di default mettre il separatore decimale al centro della colonna. Questo, secondo me, produce risultati non sempre adeguati. Per esempio:
`\documentclass{article}
\usepackage[italian]{babel}
\usepackage[osf]{mathpazo}
\usepackage[mode=math]{siunitx}
\usepackage{booktabs}
\sisetup{decimalsymbol=comma}

\begin{document}

\begin{tabular}{SSSSS}
\toprule
$B$ & $P_u$ & $u_u$ & $\beta$ & $G_f$ \\
{(m)} & {(kg)} & {(m)} & & {(Pa)} \\
\midrule
5 & 269,8 & 0,000674 & 1,79 & 0,04089 \\
10 & 421,0 & 0,001035 & 3,59 & 0,04089 \\
20 & 640,2 & 0,001565 & 7,18 & 0,04089 \\
\bottomrule
\end{tabular}

\end{document}
`
Se si prova a compilare, si vede una voragine tra le seconda e la terza colonna.

Per rimediare si può dare l’opzione abnumalign=center che, da quanto ho capito, centra tutto il numero, ma a condizione che se ne specifichi manualmente il “formato” come ..

`\begin{tabular}{S[tabnumalign=center]%
S[tabnumalign=center,tabformat=3.1]%
S[tabnumalign=center,tabformat=1.6]%
S[tabnumalign=center,tabformat=1.2]%
S[tabnumalign=center,tabformat=1.5]}
\toprule
$B$ & $P_u$ & $u_u$ & $\beta$ & $G_f$ \\
{(m)} & {(kg)} & {(m)} & & {(Pa)} \\
\midrule
5 & 269,8 & 0,000674 & 1,79 & 0,04089 \\
10 & 421,0 & 0,001035 & 3,59 & 0,04089 \\
20 & 640,2 & 0,001565 & 7,18 & 0,04089 \\
\bottomrule
\end{tabular}
`
Ora il risultato è ottimo, ma specificare manualmente il formato di ciascuna colonna è scomodo: non dovrebbe pensarci il pacchetto automaticamente?

Attribuisci a TeX doti di chiaroveggenza che non può avere. Non conosco il funzionamento dettagliato di siunitx, ma a quanto pare lo spazio riservato alla parte intera coincide con quello riservato alla parte decimale e questo spiega le “voragini”.

Soluzione: come in tutti gli aspetti della composizione tipografica, non si può avere un automatismo sempre, soprattutto nelle tabelle che vanno esaminate a una a una per trovarne i difetti e risolverli. Ma qui non è difficile: chi scrive la tabella sa qual è il formato dei dati.

Il fatto è che se non specifico il formato e mi limito semplicemente a dare tabnumalign=center come opzione globale
`\sisetup{tabnumalign=center}

\begin{tabular}{SSSSS}
\toprule
$B$ & $P_u$ & $u_u$ & $\beta$ & $G_f$ \\
{(m)} & {(kg)} & {(m)} & & {(Pa)} \\
\midrule
5 & 269,8 & 0,000674 & 1,79 & 0,04089 \\
10 & 421,0 & 0,001035 & 3,59 & 0,04089 \\
20 & 640,2 & 0,001565 & 7,18 & 0,04089 \\
\bottomrule
\end{tabular}`
il risultato è inaccettabile (alcune colonne sbordano e si sovrappongono).

Un altro mistero: provate a sostituire nella tabella precedente $D$ al posto di $B$: siunitx dà un errore:
`! Package siunitx Error: Invalid number format `D'.

See the siunitx package documentation for explanation.
Type H for immediate help.
…

l.12 $D$ &
$P_u$ & $u_u$ & $\beta$ & $G_f$ \\
?
`
Neppure mettere $D$ tra graffe risolve. Un bug?

Non è un bug; nelle colonne di tipo S vanno numeri. Ciò che non lo è può funzionare oppure no, dipende se entra in conflitto con il funzionamento interno della specifica dei numeri (d oppure D sono riservati per varie notazioni, mi pare). Ovviamente la soluzione è \multicolumn{1}{c}{…}

Purtroppo la revisione dell’Arte cade in un brutto periodo: siunitx ha fatto la transizione alla versione 2 che non è pienamente compatibile con la 1; occorre specificare
`\usepackage[load-configurations=version-1]{siunitx}`
se si ha un documento preparato per la versione 1. Noioso, forse, ma la versione 2 è davvero molto più potente e configurabile della precedente e vale la pena passare alla nuova.

Nella documentazione della versione 2 c’è la tabella riassuntiva con le corrispondenze fra vecchie opzioni e nuove. Secondo me è meglio usare la 2.

Ciao
Enrico

Attribuisci a TeX doti di chiaroveggenza che non può avere. Non conosco il funzionamento dettagliato di siunitx, ma a quanto pare lo spazio riservato alla parte intera coincide con quello riservato alla parte decimale e questo spiega le “voragini”.

Per una volta, non sono d’accordo. Infatti le colonne standard di tipo c centrano il loro contenuto automaticamente.
`\begin{tabular}{ccccc}
\toprule
{$B$} & {$P_u$} & {$u_u$} & {$\beta$} & $G_f$ \\
{(m)} & {(kg)} & {(m)} & & {(Pa)} \\
\midrule
5 & 269,8 & 0,000674 & 1,79 & 0,04089 \\
10 & 421,0 & 0,001035 & 3,59 & 0,04089 \\
20 & 640,2 & 0,001565 & 7,18 & 0,04089 \\
\bottomrule
\end{tabular}`
Penso che sarebbe logico che siunitx, una volta data l’opzione tabnumalign=center, facesse lo stesso (mettendo però sempre in maiuscolo i numeri, spaziando le cifre e tenendo la virgola decimale intelligente). Così non è:
`\sisetup{tabnumalign=center}

\begin{tabular}{SSSSS}
\toprule
$B$ & $P_u$ & $u_u$ & $\beta$ & $G_f$ \\
{(m)} & {(kg)} & {(m)} & & {(Pa)} \\
\midrule
5 & 269,8 & 0,000674 & 1,79 & 0,04089 \\
10 & 421,0 & 0,001035 & 3,59 & 0,04089 \\
20 & 640,2 & 0,001565 & 7,18 & 0,04089 \\
\bottomrule
\end{tabular}`

La documentazione dice chiaramente che tabnumalign=center va accompagnata da tabformat. Se questo non ti va, scrivi una tua estensione di siunitx. 🙂 Il fatto è che lo spazio riservato ai numeri è fisso, se non specificato diversamente con tabformat; suppongo che Joseph Wright ci abbia pensato e non sia riuscito a risolverlo diversamente e temo che ci sia poco da fare al riguardo. Problemi analoghi li ha anche numprint, che richiede per la stessa cosa una sintassi molto più complessa.

Ti potrei anche spiegare dov’è il problema: risiede principalmente che il dato contenuto nella tabella va massaggiato in vari modi e questo richiede parecchi trucchi non semplici. Se vuoi la virgola intelligente e la separazione dei gruppi di cifre, questo è il prezzo.

Considero il fatto che non si possa scrivere $D$ nell’intestazione di una colonna un bug bello e buono. Nella doc. c’è scritto di mettere le intestazioni tra graffe: devo poter scrivere una $D$, se lo desidero.

Scrivendo {$D$} non ottengo alcun errore. Lo ottengo solo se invece scrivo ${D}$.

Ciao
Enrico

Ciao a tutti.
Ho fatto numerosissime prove per capire il funzionamento del comando \num di siunitx, e ho notato che caricando gli euler per la matematica ma cambiando font corrente, diciamo i kpfonts con l’opzione oldstyle, \num fa quello che ci si aspetta: stampa numeri maiuscoli e spaziati ogni tre cifre a partire da destra, ma NON in Euler, ma in kpfonts maiuscolo. Euler fa il proprio dovere se i numeri sono scritti tra dollari.

Con mathpazo ed euler, invece, \num stampa sempre in minuscolo.

La stessa cosa accade se invece di Euler metto i font sansmath:

`\usepackage{sansmath}
\sansmath`

I numeri in sansmath vengono senza grazie soltanto se tra dollari. Dentro \num vengono in kpfonts maiuscolo. E questo accade sia con mathpazo che con kpfonts…

A questo punto, due domande:

1. non è che centri anche matphazo oltre che Euler, dal momento che cambiando font corrente \num fa il proprio lavoro?

2. non potrebbe essere che quel “math” dell’opzione mode=math di siunitx voglia dire semplicemente “maiuscolo” e non “matematico”?

Ciao
Tommaso

Non so rispondere. Però osservo che \numprint di numprint si comporta in modo (forse) più “logico”:
`\documentclass{scrreprt}
\usepackage[italian]{babel}
\usepackage[eulermath]{classicthesis}
\usepackage[mode=math]{siunitx}
\usepackage{numprint}
\begin{document}
1500000 \\
$1500000$ \\
\numprint{1500000} \\
$\numprint{1500000}$
\end{document}`
Come si vede compilando, \numprint fa esattamente quello che ci si aspetta:
1. numeri minuscoli nella prima riga;
2. numeri maiuscoli (Euler) nella seconda;
3. numeri minuscoli (ma spaziati) nella terza;
2. numeri maiuscoli (Euler) nella quarta.

No, non è quello che ci si aspetta. Con i font Euler si ottiene il comportamento voluto dando anche l’opzione “math-rm=\mathnormal” (che però ha qualche limite che lascio trovare all’attento lettore). Nella terza riga i numeri devono venir fuori in modo matematico; non succede, senza l’opzione menzionata, per questioni TeXniche.

Colgo l’occasione per annunciare severe rappresaglie contro Tommaso, colpevole di un “centri” che mi ha lasciato boccheggiante. E non era il caldo. 👿

Ciao
Enrico

@ Enrico:
Certo, domani lascio pagare a te, OK? 😉
Purtroppo si sta andando verso questa direzione: c’entra o centra? c’entrare, centrare o entrarci? Nessuno ha la risposta, e una lingua è una brutta bestia…
Però le mie due domande non hanno avuto risposta 8)

@ Lorenzo:
Grazie, tu sì che sei un vero amico. Mica come quell’altro 😀

Ciao
Tommaso

@ Enrico:
Certo, domani lascio pagare a te, OK? 😉
Purtroppo si sta andando verso questa direzione: c’entra o centra? c’entrare, centrare o entrarci? Nessuno ha la risposta, e una lingua è una brutta bestia…

La risposta c’è eccome. Che ci sia chi scrive “centra” senza apostrofo è un dato di fatto; se però perfino chi dovrebbe insegnare la forma corretta cala le braghe… 🙁

🙂

Però le mie due domande non hanno avuto risposta 8)

Il pacchetto “sansmath” è un accrocchio che serve per scopi molto limitati. Che non funzioni con siunitx non mi sorprende.

Ciao
Enrico

No, non è quello che ci si aspetta. Con i font Euler si ottiene il comportamento voluto dando anche l’opzione “math-rm=\mathnormal” (che però ha qualche limite che lascio trovare all’attento lettore). Nella terza riga i numeri devono venir fuori in modo matematico; non succede, senza l’opzione menzionata, per questioni TeXniche.

Perché nella terza riga DEVONO venire in modo matematico? Riporto dalla doc di numprint:

The number is printed in the current mode (math or text mode) so that an eventual chosen difference between mathematical and text numbers stays visible (e.g., by using the eco package).

[…]

The number is printed in the active mode (text mode resp. math mode). This may be important if the digits are different in text and math mode as in this documentthatusesold-stylefiguresintextandliningfiguresinmathmode. See the difference between […] produced by

‘‘\numprint{123456.134e123}’’ and ‘‘$\numprint{123456.134e123}$’’

Sarò anche stupido, ma io capisco che \numprint stampa numeri nel font corrente, e $\numprint$ in modo matematico. Ho fatto una prova, e caricando gli Euler $\numprint$ stampa in Euler, mentre senza dollari stampa in minuscolo ma spaziato, avendo caricato mathpazo con opzione osf.

Chi mi chiarisce le idee? 😀

Ciao
Tommaso

Ciao Lorenzo,

grazie per il tuo lavoro, non vedo l’ora di leggerlo!

Con l’occasione ti volevo chiedere se scriverai anche del pacchetto pgfplotstable.

Ti dico questo perché nella relazione che ho scritto per un esame penso che non ne sarei uscito vivo senza quel pacchetto.

Il risultato di una tebella che ho scritto è questo:

P.S. Lo so che la testa della tabella contiene qualche errore!! 🙂

Saluti

Michele

No, non è quello che ci si aspetta. Con i font Euler si ottiene il comportamento voluto dando anche l’opzione “math-rm=\mathnormal” (che però ha qualche limite che lascio trovare all’attento lettore). Nella terza riga i numeri devono venir fuori in modo matematico; non succede, senza l’opzione menzionata, per questioni TeXniche.

Perché nella terza riga DEVONO venire in modo matematico? Riporto dalla doc di numprint:

The number is printed in the current mode (math or text mode) so that an eventual chosen difference between mathematical and text numbers stays visible (e.g., by using the eco package).

[…]

The number is printed in the active mode (text mode resp. math mode). This may be important if the digits are different in text and math mode as in this documentthatusesold-stylefiguresintextandliningfiguresinmathmode. See the difference between […] produced by

‘‘\numprint{123456.134e123}’’ and ‘‘$\numprint{123456.134e123}$’’

Sarò anche stupido, ma io capisco che \numprint stampa numeri nel font corrente, e $\numprint$ in modo matematico. Ho fatto una prova, e caricando gli Euler $\numprint$ stampa in Euler, mentre senza dollari stampa in minuscolo ma spaziato, avendo caricato mathpazo con opzione osf.

Chi mi chiarisce le idee? 😀

Ciao
Tommaso

Il “mode” si riferisce all’opzione valida in quel momento per siunitx (mode=math oppure mode=text).

Ciao
Enrico

Credo che ci siamo.
RIporto la risposta di Joseph Wright, cordialissimo e solerte autore di siunitx:

Hello Tommaso,

The standard settings for siunitx use \mathrm when printing in math
mode. The euler package sets up different digit styles in \mathrm and
\mathnormal. You probably want to use the later:

`\documentclass{article}
\usepackage[osf]{mathpazo}
\usepackage{euler}
\usepackage{siunitx}
\sisetup{math-rm = \mathnormal,mode = math}

\begin{document}
\num{123}
\end{document}`

La compilazione si interrompe con un errore, ovviamente, perché l’opzione data da Wright è per la versione 2 del pacchetto, che sarà disponibile soltanto con la TeX Live 2010. Preciso, per scansare le severe rappresaglie, che la stessa opzione era stata data anche da Enrico. 😀

Ora, compilate questo codice:

`% !TEX encoding = UTF-8 Unicode

\documentclass{scrreprt}
\usepackage[italian]{babel}
\usepackage[eulermath]{classicthesis}
\usepackage[decimalsymbol=comma]{siunitx}
\usepackage{numprint}
\sisetup{mathrm=mathnormal}

\begin{document}
123456

$123456$

123,456

$123,456$

\numprint{123456}

\numprint{123,456}

$\numprint{123456}$

$\numprint{123,456}$

\num{123456}

\num{123,456}

\sisetup{mode=text}
\num{123456}

\num{123,456}

\sisetup{mode=math}
\numprint{123}
\end{document}`

Io dico che i comandi di numprint e di siunitx funzionano bene, tranne che per una cosa: la virgola nell’argomento di \num non è quella di Euler, ma quella di Palatino. Da una serie di prove ho visto che caricando altri font che prevedono numeri minuscoli, come i kpfonts con l’opzione oldstyle, la virgola stampata è quella degli Euler. Forse c’entra anche Palatino.
Mettendo l’opzione per la versione 1 del pacchetto, tutto torna. E \numprint continua a stampare in minuscolo, se non è tra dollari. Forse che è proprio questa la sua funzione! 😀

Wright mi ha appena scritto:

You have version 1 of siunitx 🙂 Option should therefore read

`sisetup{mathrm = mathnormal,mode = math}`

(Version 2 was released about 6 weeks ago.)

Attendo critiche 😉

Ciao
Tommaso

Credo che ci siamo.
RIporto la risposta di Joseph Wright, cordialissimo e solerte autore di siunitx:

Hello Tommaso,

The standard settings for siunitx use \mathrm when printing in math
mode. The euler package sets up different digit styles in \mathrm and
\mathnormal. You probably want to use the later:

`\documentclass{article}
\usepackage[osf]{mathpazo}
\usepackage{euler}
\usepackage{siunitx}
\sisetup{math-rm = \mathnormal,mode = math}

\begin{document}
\num{123}
\end{document}`

La compilazione si interrompe con un errore, ovviamente, perché l’opzione data da Wright è per la versione 2 del pacchetto, che sarà disponibile soltanto con la TeX Live 2010. Preciso, per scansare le severe rappresaglie, che la stessa opzione era stata data anche da Enrico. 😀

Ora, compilate questo codice:

`% !TEX encoding = UTF-8 Unicode

\documentclass{scrreprt}
\usepackage[italian]{babel}
\usepackage[eulermath]{classicthesis}
\usepackage[decimalsymbol=comma]{siunitx}
\usepackage{numprint}
\sisetup{mathrm=mathnormal}

\begin{document}
123456

$123456$

123,456

$123,456$

\numprint{123456}

\numprint{123,456}

$\numprint{123456}$

$\numprint{123,456}$

\num{123456}

\num{123,456}

\sisetup{mode=text}
\num{123456}

\num{123,456}

\sisetup{mode=math}
\numprint{123}
\end{document}`

Io dico che i comandi di numprint e di siunitx funzionano bene, tranne che per una cosa: la virgola nell’argomento di \num non è quella di Euler, ma quella di Palatino. Da una serie di prove ho visto che caricando altri font che prevedono numeri minuscoli, come i kpfonts con l’opzione oldstyle, la virgola stampata è quella degli Euler. Forse c’entra anche Palatino.
Mettendo l’opzione per la versione 1 del pacchetto, tutto torna. E \numprint continua a stampare in minuscolo, se non è tra dollari. Forse che è proprio questa la sua funzione! 😀

Wright mi ha appena scritto:

You have version 1 of siunitx 🙂 Option should therefore read

`sisetup{mathrm = mathnormal,mode = math}`

(Version 2 was released about 6 weeks ago.)

Attendo critiche 😉

Ciao
Tommaso

Il problema è: che c’entra \numprint con siunitx?

Ciao
Enrico

Eureka! Con l’opzione mathrm=mathnormal siunitx funziona anche con Euler! 🙂
`\documentclass{scrreprt}
\usepackage[eulermath]{classicthesis}
\usepackage[mode=math,decimalsymbol=comma,mathrm=mathnormal]{siunitx}
\usepackage{booktabs}

\usepackage{numprint}
\begin{document}
1500000 \\
$1500000$ \\

\num{1500000} \\
$\num{1500000}$

\num[mode=text]{1500000} \\
$\num[mode=text]{1500000}$

\begin{tabular}{cS}
\toprule
Espressione & {Valore} \\
\midrule
$\pi$ & 3,1416 \\
$\pi^{\pi}$ & 36,46 \\
$\pi^{\pi^{\pi}}$ & 80662,7 \\
\bottomrule
\end{tabular}
\end{document}`
Tutto va come “ci si aspetta”.

Nella prima coppia di righe abbiamo il numero in minuscolo (Palatino) e maiuscolo (Euler).

Nella seconda coppia abbiamo sempre gli Euler: è giusto, perché l’impostazione generale è “mode=math” (che ritengo sia predefinita).

Nella terza coppia abbiamo i numeri minuscoli: giusto, perché lo si è richiesto espressamente in entrambi i casi.

La tabella, poi, è perfetta: Euler, incolonnamento alla virgola e cifre raggruppate a gruppi di tre.

Ottimo…

Non proprio. Prova ad aggiungere \SI{123456}{m^{23}} e sappimi dire. Se specifichi “unitmode=text”, l’unità di misura sarà nel carattere corretto, ma l’esponente diventa sbagliato. Soluzione: \SI{123456}{m^{$23$}}

Commenti finali: si possono usare i font Euler per il modo matematico, ma è meglio evitarli.

A che serviva numprint?

Ciao
Enrico

Serviva soltanto per far vedere la differenza di comportamento dei due pacchetti con Euler. Tu stesso, quando ti ho riportato la citazione dalla documentazione di numprint, hai chiamato in causa siunitx, che con numprint non C’ENTRA molto, o no? 😉

A dopo
Tommaso

OK,
scusa a Enrico, potevo leggere con più attenzione. Ma qui ci sono troppe cose sulla griglia…

Ciao
Tommaso