Elrond

`$a^{b^{c}}$`

skevin93″ post=87775Ora lo script è perfetto, grazie mille :D. Posso solo chiederti perché make compila anche l’obbiettivo $(IMG_DIR)/%.pdf =….? Perché se io non specifico niente dando solo make (o make pdf) il programma prende il primo obbiettivo di default. Grazie per l’eventuale risposta.

Non sono sicuro di aver compreso la domanda: vuoi sapere perché venga eseguita la seconda regola ([tt]$(IMG_DIR)/%.pdf[/tt]) anche quando esegui solo [tt]make[/tt] senza specificare l’obiettivo? In questo caso la risposta è: «è così che funziona make ed è per questo che è utile». [tt]$(MAIN_PDF)[/tt] dipende dai file [tt]$(IMG_DIR)/%.pdf[/tt], se questi non sono aggiornati (cioè sono più vecchi dei loro prerequisiti) allora make prima di eseguire la regola associata a [tt]$(MAIN_PDF)[/tt] aggiornerà i file [tt]$(IMG_DIR)/%.pdf[/tt]. L’utilità è che queste regole ([tt]$(IMG_DIR)/%.pdf[/tt]) saranno eseguite, senza bisogno di invocarle manualmente, solo quando necessario, con un bel risparmio di tempo. Se hai un Makefile ben organizzato ti basta sempre eseguire solo [tt]make[/tt] senza preoccuparti di specificare tutte le regole, per aggiornare il tuo progetto.

Noto che per gestire le immagini TikZ hai adottato lo stesso approccio che ultimamente sto usando io, cioè quello di realizzarle in un file separati dal sorgente del documento principale. Per velocizzare leggermente la compilazione delle immagini, però, invece di includere il preambolo, come immagino stia facendo tu usando il file [tt]$(IMG_DIR)/Pacchetti.tex[/tt], creo un file di formato a partire dal preambolo comune delle figure. Così risparmio circa 2-3 secondi per immagine 🙂

Visto che sei interessato ai Makefile, se non l’avessi vista qui c’è una semplice guida introduttiva proprio orientata ai documenti LaTeX: /wp-content/uploads/joomla-images/doc/GuideGuIT/guidamake.pdf Se c’è qualcosa di poco chiaro chiedi pure 😉

Sicuramente c’è il problema che i PDF prodotti dai file TikZ non sono dipendenze dell’obiettivo [tt]MAIN_PDF[/tt], quindi la regola
`$(MAIN_PDF): $(MAIN_TEX) $(CAP_TEX) $(IMG_PDF)`
al posto di
`$(MAIN_PDF): $(MAIN_TEX) $(CAP_TEX)`
dovrebbe risolvere il problema (nota: non l’ho provato). Inoltre credo che gli obiettivi della seconda regola dovrebbero essere [tt]$(IMG_DIR)/%.pdf[/tt], non [tt]%.pdf[/tt], perché i file si troveranno nella cartella [tt]$(IMG_DIR)[/tt], è corretto?

Un consiglio: i file di partenza nella cartella IMG_DIR sono i file [tt]*.tikz[/tt], non i PDF, quindi nell’elenco delle variabili scriverei
`IMG_TIKZ = $(wildcard $(IMG_DIR)/*.tikz)
IMG_PDF = $(patsubst tikz/%.tikz, %.pdf , $(IMG_DIR)/*.tikz)`

Cerca [tt]\phantomsection[/tt] ne L’arte di scrivere con LaTeX o una qualsiasi altra buona guida che conosci

Dork” post=87706ps: ma la funzione cerca funziona? (ho inserito “goto error” nessun risultato, “errore console” nessun risultato, “errore” UN risultato…alla fine mi sono rassegnato e ho aperto una nuova discussione :-), se l’argomento è già stato trattato scusatemi)

Per le ricerche nel forum devi andare qui: http://www.guitex.org/home/it/forum/search Trovi il link nella pagina principale del forum. Il modulo di ricerca presente in alto a destra è per le ricerca all’interno del resto del sito

Bottoli” post=87565Ho dato un occhiata all’articolo che m’hai segnalato, ma li si consiglia di utilizzare programmi esterni per svolgere calcoli sui dati…. 🙁

Per fare solo il grafico dei punti forniti dall’esterno non c’è bisogno di altri programmi, per la regressione lineare non so se sia proprio indispensabile usarli, non l’ho mai fatta con pgfplots. Comunque nella breve guida in italiano che ti ho segnalato mi sembra non si parli della regressione lineare, che però è trattata nel manuale ufficiale in inglese

robitex” post=87489Poi c’è il punto di vista model-view: pgfplots dovrebbe solo disegnare il grafico per punti la cui densità e posizione è giá stata stabilita da software esterni.
Ovvero: lavoro in un ambiente appropriato di modellazione e poi creo i grafici giá risolti.

Il punto è che con gnuplot ho risultati estetici analoghi, tanto vale fare i grafici direttamente con gnuplot, continua a sfuggirmi perché dovrei far fare i calcoli a gnuplot e la grafica a pgfplots (con le sue limitazioni di potenza e rapidità) se gnuplot si può occupare di entrambi. E riconosco che in quanto a potenzia di calcolo gnuplot non è ai livelli di tanti altri programmi, come Matlab o Mathematica, ma a differenza di questi i suoi grafici possono essere perfettamente integrati nei documenti LaTeX, basta solo usare l’opportuno terminale.

Devo fare un grafico simile a una mappa del calore, con una matrici di 5000×5000. A proposito di questo problema su TeX.StackExchange Jake ha detto (http://tex.stackexchange.com/a/50020/31416)

JakeThis can then be plotted with PGFplots. Note, however, that this is a very memory intensive task, even the 87 by 61 volcano dataset could only be plotted using lualatex because pdflatex would exceed its memory limits. Plotting a 400 by 1000 matrix would take a very long time.

Usare gnuplot per me in questo caso non è un capriccio ma una necessità dato che devo rappresentare una matrice che è 50 volte più grande di quella che “would take a very long time”.

Quello di cui mi sto rendendo conto è che TikZ non è la panacea, le capacità in 3D non mi sembrano eccezionali (a parte tikz3dplot, mi sembra che il trucco più usato sia quello di disegnare in due dimensioni la proiezione di quello di quello che si vorrebbe realizzare in tre dimensioni, ma non tutti hanno voglia di calcolarsi manualmente la proiezione e comunque non mi sembra la cosa più naturale da fare, però sarei felice di saperne di più da chi ha maggiore esperienza in questo ambito) e per evitare tempi di compilazione biblici sto iniziando a creare i disegni in file PDF esterni realizzati usando la classe [tt]standalone[/tt] demolendo l’unico forte aspetto positivo di TikZ, cioè la diretta integrazione nel codice sorgente. Poi, ditemi quello che volete ma [tt]pgfplots[/tt] non mi piace, ma non per il risultato finale che è ottimo, ma a mio parere le sue limitazioni (grafici con non molti punti pena tempi di compilazione geologici, sempre che non si esaurisca la memoria di TeX se non si usa lua*tex) sono gravi