Liverpool

@OldClaudio ti ringrazio per le informazioni. Penso di aver capito quello che dici, ma voglio documentarmi meglio sugli algoritmi. A questo punto credo che un’occhiata al codice di TikZ sia doverosa. Nel frattempo, a parziale conferma di quanto affermi sulla povertà dell’algoritmo, ti mostro un confronto tra la spline di Bézier generata da pgfplots e la spline naturale di Matlab sugli stessi nodi. La seconda mi sembra produrre un risultato migliore. Nota anche che nel primo e nell’ultimo tratto la mutua posizione delle curve interpolanti rispetto alla sinusoide è differente (probabilmente a causa di una condizione sulla derivata prima).

[attachment=270]spline.png[/attachment]

@Lorenzo, credo di sì ma al momento non ne sono sicuro. Ho bisogno di guardare i codici. E comunque mi è sembrato di capire che in questo periodo l’autore di pgfplots è già molto impegnato.

P.S.: allora facevo bene io a dire di non fidarsi alla cieca dell’interpolazione 😉

Ciao

@Lorenzo, come ti hanno già detto l’autore non lo considererebbe un bug. Puoi usare [tt]enlarge y limits[/tt] oppure [tt]clip=false[/tt]. Nel primo caso gli assi vengono allungati oltre ymin e ymax, nel secondo quello che sporge dagli assi viene disegnato comunque (buono se vuoi aggiungere delle annotazioni che sporgano al di fuori degli assi).

maumau” post=72470La chiave mark non ha un valore predefinito (secondo il manuale di pgf), se non imposti niente dovrebbe plottare un cerchietto blu.

Perché se tracci più grafici nella stessa figura il marcatore cambia automaticamente, così come il colore del tratto, secondo quanto definito dalla chiave [tt]cycle list[/tt] (def. [tt]=color[/tt]).

Ciao

Nel mio intervento n. 72092 ho modificato la risposta n.9 (su view), perché era errata. Per gli amministratori: perché non riesco più ad inserire direttamente un link ad un intervento? Mi sembra che prima si potesse fare 😕

L’autore del pacchetto mi ha concesso il permesso di riportare la sua risposta su questo forum. Vi riassumo in breve l’inizio della conversazione. Lui sostiene che il problema del cubo riguarda la chiave [tt]axis equal[/tt] ed è collegato al problema della sfera di Lorenzo. Io gli ho fatto notare che se proiettiamo la sfera sui piani coordinati con [tt]axis equal=true[/tt] si ottiene un cerchio in tutti e tre i casi, quindi a me sembra un problema del metodo di proiezione piuttosto che della lunghezza dei versori degli assi. Tra l’altro, misurando gli spigoli del cubo nel caso dell’assonometria isometrica che ho postato in precedenza, si ottiene lo stesso valore, mentre gli angoli tra le coppie di assi appaiono di circa 135° e 113°, quindi ancora una volta a me sembra una deformazione operata dall’algoritmo di proiezione. Ora vi riporto la risposta a queste osservazioni. Faccio presente che la soluzione di cambiare lo [tt]scale mode[/tt] che suggerisce come soluzione, funziona (per il cubo) con la versione in via di sviluppo, ma non con quella stabile in mio possesso, perciò non vi posto il codice che mi ha inviato.

Christian FeuersaengerI guess your examples actually reveal the same as in the bug report of the sphere problem (which I summarized as “axis equal” problem). Here is a detailled (yet related) list of problems. All of them need to be fixed before the problem can be considered to be “solved”:

1. pgfplots still applies ‘scale mode=stretch to fill’ although ‘axis equal’ is active. It should apply ‘scale mode=scale uniformly’. Unfortunately, the implementation of ‘scale mode=scale uniformly’ had some unfortunate pgf math issues (intermediate results became too large). I have already fixed that. I attached your example in which I replaced “axis equal” by “scale mode=scale uniformly”. I believe it looks much closer to the original expectation.

2. Even if we would apply ‘scale mode=scale uniformly’ whenever the ‘axis equal’ option is in effect, the implementation of ‘axis equal’ is wrong: it measures the size of the *projected* unit vectors (i.e. 2d vectors) and rescales them such that they have the same size. This cannot be correct. It would probably be correct to modify the plot box
ratio before it is projected to 2d. However, I have not fully understand how this has to be done (I haven’t thought about it thoroughly since I received the bug reports).

3. the enlarge limits issue arises due to the default settings of pgfplots: for 3d axes, it ONLY enlarges the z limits unless the user explicitly requests ‘enlargelimits’. This is a minor issue I guess.

Currently, I believe that
– I need to disable ‘scale mode=stretch to fill’ whenever someone requested specific axis ratios. I am unsure if this causes unexpected changes to the shape of the displayed axis. I believe this is what you mentioned as “projection issue” — it certainly *is* a projection issue if stretch-to-fill is active (since it skews the axes after the 3d projection). However, ‘scale mode=scale uniformly’ should fix it.

– I need to fix axis equal; it must be wrong. But I currently do not know how.

– interestingly, my current developer version must have introduced a regression concerning the view normal: the XY plane projection is wrong (and different from your image where it is still correct). That is good to know 🙂

L’ultimo punto è stato risolto.

Ciao