Qual è l'idea centrale della literate programming, proposta
da Donald Knuth nel 1984 e alla base di sistemi come knitr
e Quarto?
Knuth propone di cambiare prospettiva: invece di pensare che il compito principale sia dire al computer che cosa fare, concentrarsi sullo spiegare agli esseri umani che cosa vogliamo che il computer faccia. Testo e codice convivono nello stesso sorgente, dal quale si ottengono il programma e la sua documentazione. Quarto applica la stessa idea all'analisi dei dati: il report contiene spiegazione, codice e risultati calcolati.
La terza opzione descrive proprio la situazione che la literate programming vuole evitare. La seconda confonde l'idea con la generazione automatica di codice. La quarta riduce la proposta ai commenti nel codice, che sono utili ma restano subordinati al codice.
Quale descrizione di Quarto è corretta?
Quarto è un sistema di editoria scientifica e tecnica: unisce testo, codice e risultati in documenti curati, con equazioni, riferimenti incrociati e bibliografia, in molti formati (html, pdf, Word, presentazioni, siti, libri). È il successore di R Markdown, ma non è legato a un solo linguaggio. Si usa da RStudio, Positron o VS Code, oppure dal Terminale.
La seconda opzione confonde Quarto con un package grafico. La terza lo confonde con gli editor in cui si scrivono i documenti. La quarta è errata: Quarto è gratuito e open source; esistono servizi per pubblicare online, ma non sono Quarto.
Che cosa succede, nell'ordine, quando si esegue il rendering di un
documento .qmd che contiene codice R?
Quarto coordina più strumenti. Il motore di calcolo
(knitr per R, Jupyter per Python) esegue i blocchi di
codice e produce un file markdown in cui il codice è affiancato dai suoi
risultati (testo, tabelle, immagini dei grafici). Pandoc
converte poi il markdown nel formato richiesto: html, docx,
presentazioni o, attraverso Typst o LaTeX, pdf.
La seconda opzione inverte i due passaggi. La terza descrive il flusso di lavoro "copia e incolla" che Quarto permette di evitare. La quarta è errata: il rendering avviene sul proprio computer.
Nella console di R hai creato la tabella gap_2007. Nel
documento Quarto usi gap_2007 in un blocco di codice, ma
non la crei. Che cosa succede al rendering?
Il rendering avviene in una sessione di R nuova e "pulita": il documento vede solo gli oggetti creati dal suo stesso codice. È una garanzia di riproducibilità: chiunque, con il sorgente e i dati, deve poter ottenere lo stesso documento. Per questo tutto ciò che serve (package, dati, tabelle intermedie) va caricato o creato nel documento, di solito in un blocco di setup all'inizio.
La seconda opzione è la più insidiosa, perché eseguendo i blocchi uno alla volta in RStudio o in Positron (pulsante Run) il codice funziona davvero: in quel caso si usa la sessione dell'ambiente di lavoro. La terza e la quarta descrivono comportamenti che Quarto non ha.
Quali sono i tre ingredienti di un documento Quarto?
Un file .qmd inizia con l'intestazione YAML, delimitata
da due righe ---, che contiene le opzioni del documento
(titolo, autore, formati, ...). Seguono il testo, scritto in markdown, e
i blocchi di codice (chunk), delimitati da tre apici inversi
seguiti dal linguaggio tra parentesi graffe, ad esempio
{r}.
La seconda opzione elenca alcuni elementi del documento finale, non del sorgente. La terza confonde il documento con i file di un progetto. La quarta elenca elementi di R, non di Quarto.
Che cosa si ottiene in markdown scrivendo
Il **reddito** è *molto* asimmetrico?
In markdown il testo tra due asterischi doppi
(**testo**) è in grassetto, quello tra due asterischi
singoli (*testo*) in corsivo. Si possono usare anche i
trattini bassi: __testo__ e _testo_. Il testo
tra apici inversi (`testo`) viene invece mostrato come
codice.
La seconda opzione inverte le due regole. La terza è errata: markdown non prevede la sottolineatura. La quarta è errata, perché gli asterischi vengono interpretati come formattazione.
Nel testo di un documento Quarto si scrive:
I dati provengono da tre tabelle:
- utenti
- prestiti
- catalogo
Il risultato non è un elenco puntato. Perché?
In markdown una riga vuota separa i blocchi di testo: paragrafi, elenchi, titoli, blocchi di codice. Senza la riga vuota prima dell'elenco, il testo viene unito al paragrafo precedente. È l'errore di formattazione più frequente.
La seconda opzione è errata: per gli elenchi puntati si possono usare sia il trattino che l'asterisco (o il segno +). La terza confonde l'elenco con l'intestazione YAML. La quarta è errata: dopo il trattino si possono mettere uno o più spazi; l'editor visuale di RStudio ne usa tre.
In un documento Quarto, come si scrive un titolo di sezione di secondo livello "I dati"?
In markdown i titoli si scrivono con il carattere #
all'inizio della riga, seguito da uno spazio: # per il
primo livello, ## per il secondo, ### per il
terzo, e così via. I titoli definiscono le sezioni del documento e
l'indice. Attenzione: nei blocchi di codice R il carattere
# introduce un commento, nel testo un titolo.
La seconda opzione produce un titolo di primo livello. La terza e la
quarta non sono sintassi markdown per i titoli; :::
delimita i blocchi speciali (fenced div).
Che cosa produce il testo seguente in un documento Quarto?
::: {.callout-warning}
## Attenzione
I dati del 2025 sono provvisori.
:::
Tre "due punti" (:::) aprono e chiudono un fenced
div, cioè un blocco di contenuto a cui si applica uno stile o un
comportamento particolare, indicato tra parentesi graffe. I callout
(.callout-note, .callout-tip,
.callout-warning, .callout-important,
.callout-caution) sono riquadri evidenziati; un titolo
all'interno del blocco diventa il titolo del riquadro. Con i fenced div
si costruiscono anche colonne (.columns) e contenuti
visibili in un solo formato (.content-visible).
La seconda opzione ignora il blocco. La terza confonde il fenced div con un blocco di codice, che si apre con tre apici inversi. La quarta è errata: il titolo all'interno di un callout è previsto.
In un blocco di codice che produce un grafico si scrive
#| label: grafico-bolle e
#| fig-cap: "PIL e aspettativa di vita". Nel testo si
scrive Come mostra la @grafico-bolle. Che cosa succede?
In Quarto il tipo di oggetto citabile si deduce dal prefisso
dell'etichetta: fig- per le figure, tbl- per
le tabelle, sec- per le sezioni, eq- per le
equazioni. Con #| label: fig-bolle la figura viene numerata
e @fig-bolle diventa "Figura 1" (con
lang: it); la numerazione si aggiorna automaticamente se si
aggiungono o spostano figure. Con un'etichetta senza prefisso, Quarto
non riconosce l'oggetto e segnala un riferimento non risolto.
La seconda opzione è la più insidiosa, perché descrive il risultato che si ottiene con il prefisso corretto. La terza confonde il riferimento con la didascalia. La quarta è errata: un riferimento produce solo il testo del rimando.
Come si cita il libro con chiave wickham2023r4ds,
contenuto nel file riferimenti.bib, in un documento
Quarto?
Le voci bibliografiche si raccolgono in un file in formato BibTeX
(.bib), che si può ottenere ad esempio da Google Scholar o
da Zotero, e si collegano al documento nello YAML. Nel testo
[@chiave] produce una citazione tra parentesi,
@chiave una citazione nel testo; Quarto formatta le
citazioni e costruisce la bibliografia con le sole voci citate. Lo stile
si può cambiare con l'opzione csl.
La seconda opzione usa la sintassi di LaTeX, che in Quarto non serve. La terza confonde il file bibliografico con un file di dati. La quarta non produce alcuna citazione.
Che effetto ha l'opzione #| echo: false in un blocco di
codice che produce un grafico?
L'opzione echo stabilisce se il codice viene mostrato
nel documento; l'esecuzione e la visualizzazione dei risultati non
cambiano. È l'opzione tipica dei report destinati a chi è interessato ai
risultati e non al codice. Per nasconderlo in tutti i blocchi si usa
echo: false sotto execute: nello YAML.
La terza opzione descrive eval: false, la quarta
include: false. La seconda non corrisponde ad alcuna
opzione.
A che cosa serve, tipicamente, un blocco di codice con l'opzione
#| include: false all'inizio di un documento Quarto?
Con include: false il codice viene eseguito, ma nel
documento non compaiono né il codice né i risultati (messaggi,
avvertimenti, output). È la scelta naturale per il blocco di
setup, che carica i package e legge i dati: le operazioni sono
necessarie, ma non interessano il lettore del report.
La seconda e la terza opzione descrivono eval: false,
che mostra il codice senza eseguirlo; in quel caso gli oggetti non
verrebbero creati e i blocchi successivi darebbero errore. La quarta
confonde l'opzione con i contenuti condizionati al formato.
In un documento Quarto il primo blocco di codice, con l'opzione
#| eval: false, contiene l'istruzione
gap_2007 <- filter(gapminder, year == 2007). Il secondo
blocco, senza opzioni, contiene nrow(gap_2007). Che cosa
succede al rendering?
Con eval: false il codice viene mostrato nel documento
ma non eseguito: è utile per illustrare codice (ad esempio un comando di
installazione) senza eseguirlo. Gli oggetti che il blocco creerebbe non
esistono, e i blocchi che li usano danno errore.
La terza opzione descrive echo: false. La quarta è
errata: le opzioni di un blocco valgono solo per quel blocco; per tutti
i blocchi si usa execute: nello YAML. La seconda ignora
l'effetto di eval: false.
Nel testo di un documento Quarto si scrive:
La tabella contiene `r nrow(gapminder)` righe.
Che cosa compare nel documento finale?
Il codice inline, scritto tra apici inversi iniziando con
r, viene eseguito durante il rendering e sostituito dal suo
risultato, all'interno del testo. Così i numeri citati nel testo sono
calcolati e non copiati a mano: se i dati cambiano, il testo si
aggiorna. Il codice inline funziona anche nello YAML (ad esempio nel
titolo) e nelle equazioni.
La seconda opzione descrive il risultato senza la r
iniziale (semplice codice formattato). La terza confonde il codice
inline con i blocchi di codice (modalità display). La quarta è
errata.
Quale delle seguenti intestazioni YAML produce un documento html con l'indice?
Versione A:
format:
html:
toc: true
Versione B:
format:
html:
toc: true
Versione C:
format: html
toc: true
Versione D:
format:
html:
toc:true
Nello YAML i rientri stabiliscono chi contiene chi: le opzioni di un
formato vanno rientrate sotto il nome del formato, che a sua volta è
rientrato sotto format:. I rientri si fanno con gli spazi
(di solito due), mai con la tabulazione, e dopo i due punti serve uno
spazio.
Nella versione B mancano i rientri: html e
toc vengono letti come opzioni di primo livello. Nella
versione C format: html assegna già un valore a
format, e la riga rientrata successiva produce un errore.
La versione D è la più insidiosa: senza lo spazio dopo i due punti,
toc:true viene letto come un testo e non come un'opzione
con il suo valore.
Nello YAML di un documento si indica
execute: echo: false (con i rientri corretti). Un blocco di
codice ha l'opzione #| echo: true. Che cosa succede?
In Quarto le opzioni si possono indicare a più livelli: progetto
(_quarto.yml), cartella (_metadata.yml),
documento (YAML), formato e singolo blocco (#|). Le opzioni
più specifiche prevalgono: si fissa nello YAML il comportamento generale
e lo si modifica solo nei blocchi che fanno eccezione.
La seconda opzione inverte la regola di precedenza. La terza è errata: non c'è alcun conflitto da segnalare. La quarta estende l'eccezione a tutti i blocchi.
Lo YAML di un documento indica due formati, prima html e
poi typst. Che cosa produce il comando
quarto render report.qmd eseguito nel Terminale?
Senza indicazioni, quarto render produce tutti i formati
elencati nello YAML; con l'opzione --to se ne sceglie uno,
ad esempio quarto render report.qmd --to typst. Il pulsante
Render di RStudio produce invece il primo formato, e il
menu accanto al pulsante permette di sceglierne un altro.
La seconda opzione è la più insidiosa, perché descrive il comportamento del pulsante Render. La terza e la quarta non corrispondono al comportamento di Quarto.
Quale affermazione su Typst, usato con format: typst per
produrre un pdf, è corretta?
Per il pdf Quarto offre due strade: LaTeX (format: pdf),
lo standard dell'editoria scientifica, che richiede un'installazione a
parte ed è più lento; e Typst (format: typst), un sistema
tipografico recente, incluso in Quarto e molto veloce. Le equazioni si
scrivono comunque con la sintassi di LaTeX, e Quarto le converte. Le
opzioni principali sono papersize, margin,
fontsize, columns, toc e
number-sections.
La seconda opzione riguarda LaTeX. La terza confonde Typst con il
formato docx. La quarta è errata: il codice viene eseguito
da knitr prima della conversione, qualunque sia il
formato.
Lo YAML di un documento indica code-fold: true sotto il
formato html e il formato typst senza opzioni;
i blocchi di codice mostrano il codice. Che cosa succede al codice nel
pdf?
Le opzioni indicate sotto un formato valgono solo per quel formato:
code-fold è un'opzione del formato html, dove il codice
compare chiuso e si apre con un clic. Il pdf è un formato statico, in
cui non esistono elementi interattivi: il codice viene mostrato secondo
le opzioni comuni (echo). Allo stesso modo, nel pdf non
funzionano i grafici interattivi e le animazioni.
La seconda opzione attribuisce al pdf un'opzione del formato html. La terza è errata, perché l'opzione non viene applicata al pdf e non produce errori. La quarta descrive un comportamento che Quarto non ha.
Un documento viene prodotto in html e in pdf. A che cosa serve il blocco seguente?
::: {.content-visible when-format="html"}
Il grafico seguente è interattivo: scegli la biblioteca dal menu.
...
:::
Il fenced div .content-visible con l'attributo
when-format mostra il suo contenuto solo nel formato
indicato; .content-hidden fa il contrario. È utile quando
un documento è prodotto in più formati e alcuni contenuti, come i
controlli interattivi con OJS, hanno senso solo in html. Il codice R
all'interno del blocco viene comunque eseguito in tutti i formati.
La seconda opzione descrive un callout chiuso
(collapse="true"). La terza e la quarta attribuiscono al
blocco comportamenti che non ha.
In un documento Quarto prodotto in html, un blocco di codice R crea
la tabella prestiti_mese e un blocco {ojs}
costruisce un grafico con un menu a tendina. Quale affermazione è
corretta?
Observable JS è un dialetto di JavaScript pensato per l'analisi e la
visualizzazione dei dati. In un documento Quarto i blocchi
{ojs} vengono eseguiti nel browser, non durante il
rendering: per questo i controlli (menu, caselle di controllo, cursori)
e i grafici sono interattivi anche in un semplice file html, senza un
server. I dati preparati con R si passano a OJS con
ojs_define(), una funzione disponibile durante il
rendering.
La seconda opzione descrive i blocchi di codice R. La terza è la più insidiosa: R e OJS sono eseguiti in momenti e luoghi diversi, e i dati vanno passati esplicitamente. La quarta confonde OJS con Shiny, che richiede invece un server R attivo.
Quale dei seguenti prompt ha più probabilità di ottenere da un LLM codice OJS corretto per un documento Quarto?
Un prompt efficace riduce le ambiguità: indica il contesto (documento
Quarto in html), i dati (nome della tabella e delle colonne), il
comportamento atteso (tipo di grafico, controllo, valore di default), i
vincoli (ojs_define(), Observable Plot, niente Shiny) e il
formato della risposta (blocchi di codice completi). Le altre richieste
lasciano all'LLM troppe scelte: potrebbe proporre JavaScript generico,
Shiny o plotly, o inventare i nomi delle colonne. In ogni caso il codice
ricevuto va eseguito e verificato, provando tutte le combinazioni dei
controlli.
Lo YAML di un report contiene:
params:
biblioteca: "B01"
Come si usa il parametro nel codice R del documento?
I parametri di un report si dichiarano nello YAML con i loro valori
di default e sono disponibili nel codice nella lista
params. Al rendering si possono cambiare senza modificare
il documento: dalla console con
quarto_render(..., execute_params = list(biblioteca = "B02")),
dal Terminale con
quarto render report.qmd -P biblioteca:B02. Un solo
documento produce così un report per ogni biblioteca, regione, anno,
...
La seconda opzione è la più insidiosa: scrivendo
biblioteca nel filter, R userebbe la colonna
biblioteca della tabella, confrontandola con sé stessa. La
terza usa un nome di oggetto inesistente. La quarta ignora lo scopo dei
parametri.
Che cosa fa l'istruzione seguente, eseguita nella console di R?
quarto::quarto_render("report_biblioteca.qmd",
execute_params = list(biblioteca = "B03"),
output_file = "report_B03.html",
output_format = "html")
La funzione quarto_render() del package
quarto esegue il rendering di un documento dalla console di
R, come il pulsante Render o il comando quarto render del
Terminale. L'argomento execute_params sostituisce, solo per
quel rendering, i valori di default dei parametri;
output_file stabilisce il nome del file prodotto,
output_format il formato. Poiché è una funzione di R, si
può inserire in un ciclo per produrre molti report.
La seconda opzione è la più insidiosa: il documento non viene
modificato. La terza descrive un comportamento che la funzione non ha.
La quarta ignora l'argomento output_format.
Per produrre un report per ciascuna biblioteca si usa l'istruzione
seguente. Perché si usa walk e non map?
walk(c("B01", "B02", "B03", "B04"), \(x) quarto_render(
"report_biblioteca.qmd",
execute_params = list(biblioteca = x),
output_file = paste0("report_", x, ".html")
))
Le funzioni map e walk del package
purrr applicano una funzione a ciascun elemento di un
vettore o di una lista, al posto di un ciclo. map
restituisce i risultati in una lista (map_chr,
map_dbl, map_lgl in un vettore del tipo
indicato), ed è adatta quando interessa il valore calcolato.
walk si usa per gli effetti collaterali, come
scrivere un file o stampare un grafico: la funzione viene applicata, ma
i risultati non vengono raccolti. La funzione da applicare si scrive
spesso come funzione anonima, \(x) ....
La seconda e la quarta opzione attribuiscono a map
limiti che non ha. La terza è errata: entrambe le funzioni lavorano un
elemento alla volta.
Che cosa restituisce l'istruzione seguente?
map_chr(c("B01", "B02"), \(x) paste0("report_", x, ".pdf"))
map_chr applica la funzione a ciascun elemento del
vettore e raccoglie i risultati in un vettore di tipo carattere;
map li raccoglierebbe in una lista. Qui la funzione anonima
costruisce il nome del file per ciascuna biblioteca: il risultato può
essere usato, ad esempio, con map_lgl(nomi, file.exists)
per verificare che i file siano stati creati.
La seconda opzione è la più insidiosa, perché descrive il risultato
di map. La terza confonde la costruzione dei nomi dei file
con la loro creazione. La quarta è errata.
In un documento Quarto si vuole inserire una tabella numerata, con
didascalia, a partire dal risultato di
count(utenti, categoria). Quale blocco di codice è
corretto?
La funzione kable() del package knitr
trasforma un data frame in una tabella formattata, adatta sia all'html
sia al pdf; con col.names, digits e
align si scelgono nomi delle colonne, cifre decimali e
allineamento. La numerazione e la didascalia si indicano invece nelle
opzioni del blocco: un'etichetta con il prefisso tbl- e
l'opzione tbl-cap. Nel testo, @tbl-categorie
diventa "Tabella 1".
La seconda opzione sposta l'etichetta in un argomento che non produce un riferimento di Quarto. La terza usa le opzioni delle figure e mostra la tabella come semplice output di R. La quarta mostra l'output testuale della console, senza numerazione né didascalia.