maumau

Io preferisco 11pt, ma la mia tesi l’ho fatta in corpo 12. Il punto è che con un corpo 10 la pagina mi sembra troppo fitta, ed è un corpo che ho utilizzato solamente con testo in due colonne. Poi ho l’impressione che alcuni font stonino un po con un corpo piccolo, anche se forse è solo una mia impressione.

Liverpool” post=74334

A mio avviso però (premetto che non ho seguito i post precedenti), girerei il tutto di -90° attorno all’asse z. In tutti i libri di meccanica che ho visto finora (non sono tantissimi, ma qualcuno si), le coordinate cilindriche e sferiche sono presentate con l’asse x che viene “verso di noi”, con l’asse y che punta a sinistra e ovviamente z che punta verso l’alto.

Grazie per l’opinione. Se facciamo così, il lato fisso dell’angolo di azimut viene a trovarsi “dietro” al disegno, mentre noi vogliamo mettere in evidenza che un lato è sempre il semiasse negativo delle y.

maumau” post=74331Io sono indeciso tra l’ortodosso e l’isometrico, tuttavia sono dell’idea che gli archi colorati vadano rimpiccioliti, c’è troppo rosso.

Si può fare, ma poiché l’angolo è indefinitamente esteso, ho pensato che la colorazione dovesse arrivare al bordo del segmento che rappresenta l’asse orientato, per indicare che virtualmente la colorazione arriva all’infinito. Ma tu pensi che con un colore meno acceso questo problema si risolverebbe/ridurrebbe, oppure hai sollevato due questioni differenti (una sulla lunghezza e l’altra sulla colorazione)?

Grazie

Concordo sulla posizione dell’asse y, per quanto riguarda il colore si potrebbe pensare di colorare la parte di angolo compreso tra l’origine e l’arco con freccia. Il punto è che non è il colore il problema (anzi quel rosso mi garba parecchio) ma sulla quantità. Secondo me ce n’è troppo, e la figura ne risulta appesantita, ma è una quisquilia.

Liverpool” post=74213

Due cose si pensavano con Lorenzo: cambiare il color salmone in favore di un rosso o di un porpora; rimpicciolire tutta la figura. In particolare, l’asse z è altissimo. Ora il disegno occupa circa un terzo della gabbia. Siccome sta bene galleggiante e con didascalia sotto, si potrebbe avere della stessa grandezza di uno dei sistemi di riferimento presenti nel documento?

Per i colori provate un po’ voi. Io ho fatto qualche tentativo e quello era il colore che mi sembrava più adatto tra le possibilità di svgnames.
Bisogna sostituire la parola [tt]Coral[/tt] alla riga 43 con un altro colore, mentre il colore dell’arco orientato è [tt]DarkRed[/tt] alla riga 45.
Per l’asse z la lunghezza è la stessa dell’asse x, cioè 1 cm x 5 = 5 cm. Se lo volete ridurre, sostituite con un numero più piccolo l'[tt]1[/tt] nella riga 69. Ad esempio, con 0.8 la lunghezza diventa 0.8 cm x 5 = 4 cm. Perché x 5? Perché il valore di [tt]scale[/tt] impostato alla riga 39 è 5.
Purtroppo TikZ, al contrario di pgfplots, non ha un comando come [tt]width[/tt], perciò le dimensioni vanno impostate giocando con la chiave [tt]scale[/tt], tenendo presente che la lunghezza degli assi x e z non scalata è di 1 cm. Bisognerebbe fare qualche tentativo con un valore intorno a 3.
Se avete problemi, fatemi sapere.

Ciao

Per quanto riguarda il ridimensionamento di una figura Tikz, mi è risultato spesso utile il suggerimento dato in questa discussione, mi ha aiutato parecchie volte nello scalare figure ottenute da programmi esterni.

Ciao,
Roberto

illinguista1972″ post=73780

Un piccolo appunto, non mi risulta che pgfplots accetti una serie disordinata di coordinate (come detto a pagina 20); da quello che so io l’ordine di inserimento è importante, ad esempio nel caso in cui si voglia disegnare una curva pgfplots “collegherà” le terne di punti nell’ordine in cui sono state date.
Concordo inoltre con Claudio sulla necessità di inserire delle etichette agli assi.

Colpa mia! 😳 Ho tradotto frettolosamente questo

A long list of coordinates (x,y,z) is expected, separated by white spaces. The input list can be either an unordered series of coordinates. It can also have matrix structure, in which case an empty input line (which is equivalent to \\par”) marks the end of one matrix row.

che Lorenzo mi ha mandato dalla documentazione di [tt]pgfplots[/tt]. Proposte?

Ciao
Tommaso

E’ che hai saltato un pezzo

The input list can be either an unordered series of coordinates, for example for scatter or line plots

😉
Nel caso in cui ci sia un grafico in cui i punti non debbano essere “ordinati”, come ad esempio l’ultimo grafico a pagina 91 del manuale, allora i punti si possono dare come si vuole, nel caso in cui i punti debbano essere collegati tramite linee o superfici allora l’ordinamento diviene necessario.
Quindi nel caso in questione, userei:

1. una serie di coordinate (x, y, z) separate con spazi bianchi;
2. una serie di coordinate strutturate come una matrice, caso in cui una
   riga bianca nel codice sorgente marca la fine di una riga della matrice;
3. una serie disordinata di coordinate.

I primi due casi sono necessari nel caso in cui i punti debbano essere collegati da linee o superfici, l’ultimo caso può essere utilizzato nel caso di grafici “scattered” (che non so assolutamente come rendere decentemente in italiano).

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ì.