lorenzo.pantieri” post=73576
8 ) A pag. 15 si parla ancora di variabili assegnate a domini. Ma Lorenzo non lo doveva rivedere?
Prima si parlava di “dominio di un asse” che era certamente sbagliato. Ora parliamo di “variabile assegnate a un dominio”: forse è un po’ improprio, ma lo ritengo accettabile. Se una funzione $f(x,y)$ ha dominio $A\times B$ credo si possa dire che la $x$ appartiene ad $A$ e la $y$ appartiene a $B$. Ad ogni modo, la scelta dei nomi dell’autore (“domain” e “y domain”) credo autorizzi l’espressione. Ad ogni modo, se hai proposte migliori, siamo qui! 😉
…
Liverpool” post=7356910) Non c’è scritto da nessuna parte un cenno al modo in cui devono essere espresse le coordinate per le superfici 3D, nemmeno un rimando al manuale.
Non sono proprio d’accordo. All’inizio avevamo parlato di “coppie o terne di valori (corrispondenti a coordinate di punti del piano o dello spazio)”, mi pare chiaro. Dici che non basta?
Il punto è che pgfplots si aspetta delle coordinate distribuite in un certo modo, se le terne di valori vengono date in un file di input, allora c’è bisogno di formattarlo correttamente per dire a pgfplots quando cambiare riga nella costruzione della matrice delle coordinate. Se per esempio nel file di input non ci sono righe bianche, allora è necessario dire esplicitamente a pgfplots quando cambiare riga. Forse un cenno, con il rimando al manuale, lo si dovrebbe dare.
…
lorenzo.pantieri” post=73576
P.S. @Lorenzo, \addplot file ha l’opzione skip first che permette di ignorare la prima riga qualora contenga le etichette di colonna, perciò un minimo di personalizzazione ce l’ha.
Ok, però di questa cosa non ne parliamo nell’articolo. Io direi semplicemente che “table” è una variante personalizzabile di “file”: questo mi sembra corretto (e non implica che “file” non sia personalizzabile).
Attendo le risposte di Liverpool sui punti in sospeso. E anche i commenti degli altri. 😉
Grazie,
L.
file è poco (se non per nulla) personalizzabile, quindi io lascerei così.