Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
tikz, troisième point d'un triangle équilatéral
79 views
Skip to first unread message
Le TeXnicien de surface
Jan 9, 2013, 6:13:50 AM1/9/13
to
bonjour à tou(te)s
question certainement assez bête mais...
J'ai deux points définis grace à \coordinate (I) ...
et même chose pour (J).
Je voudrais récupérer le point (sous forme d'un noeud de nom K) tel que
IKJ est équilatéral, les points étant énoncés dans l'ordre trigo.
tout début de piste sera hautement apprécié
remerciements anticipés
--
Le TeXnicien de surface
TikZ nioubi
question certainement assez bête mais...
J'ai deux points définis grace à \coordinate (I) ...
et même chose pour (J).
Je voudrais récupérer le point (sous forme d'un noeud de nom K) tel que
IKJ est équilatéral, les points étant énoncés dans l'ordre trigo.
tout début de piste sera hautement apprécié
remerciements anticipés
--
Le TeXnicien de surface
TikZ nioubi
GL
Jan 9, 2013, 7:00:45 AM1/9/13
to
Le 09/01/2013 12:13, Le TeXnicien de surface a écrit :
> bonjour à tou(te)s
>
> question certainement assez bête mais...
>
> J'ai deux points définis grace à \coordinate (I) ...
> et même chose pour (J).
>
> Je voudrais récupérer le point (sous forme d'un noeud de nom K) tel que
> IKJ est équilatéral, les points étant énoncés dans l'ordre trigo.
>
> tout début de piste sera hautement apprécié
>
> remerciements anticipés
>
Vous pouvez utiliser par exemple:
> bonjour à tou(te)s
>
> question certainement assez bête mais...
>
> J'ai deux points définis grace à \coordinate (I) ...
> et même chose pour (J).
>
> Je voudrais récupérer le point (sous forme d'un noeud de nom K) tel que
> IKJ est équilatéral, les points étant énoncés dans l'ordre trigo.
>
> tout début de piste sera hautement apprécié
>
> remerciements anticipés
>
\begin{tikzpicture}[framed]
\coordinate (A) at (0,0);
\coordinate (B) at (3,8);
\coordinate (C) at ($($(A)!+.5!(B)$)!2!90:(B)$);
\draw (A) node {A} -- (B) node {B} -- (C) node {C} -- cycle;
\end{tikzpicture}
Tout ceci est expliqué dans la partie "Coordinate Calculations" du
pgfmanual. Il y a certainement plusieurs méthodes possibles...
michel....@wanadoo.fr
Jan 9, 2013, 8:36:05 AM1/9/13
to
Avec le package d'Alain MATTHES, c'est facile:
\documentclass[a4paper,DIV=16]{scrartcl}
\usepackage{tkz-tab,tkz-fct,tkz-tukey}
\usepackage{tkz-euclide}
\usepackage[utf8]{inputenc}
\usepackage[upright]{fourier}
\usepackage[greek,frenchb]{babel}
\begin{document}
\begin{tikzpicture}
\tkzDefPoints{0/0/A,3/6/B}
\tkzDefPointBy[rotation=center A angle 60](B) \tkzGetPoint{C}
\tkzDrawSegments(A,B B,C C,A)
\tkzLabelPoint[below](A){$A$} \tkzLabelPoint[right](B){$B$} \tkzLabelPoint[above left](C){$C$}
\end{tikzpicture}
\end{document}
\documentclass[a4paper,DIV=16]{scrartcl}
\usepackage{tkz-tab,tkz-fct,tkz-tukey}
\usepackage{tkz-euclide}
\usepackage[utf8]{inputenc}
\usepackage[upright]{fourier}
\usepackage[greek,frenchb]{babel}
\begin{document}
\begin{tikzpicture}
\tkzDefPoints{0/0/A,3/6/B}
\tkzDefPointBy[rotation=center A angle 60](B) \tkzGetPoint{C}
\tkzDrawSegments(A,B B,C C,A)
\tkzLabelPoint[below](A){$A$} \tkzLabelPoint[right](B){$B$} \tkzLabelPoint[above left](C){$C$}
\end{tikzpicture}
\end{document}
rpapa
Jan 9, 2013, 12:23:30 PM1/9/13
to
Le 09/01/2013 13:00, GL a �crit :
> Le 09/01/2013 12:13, Le TeXnicien de surface a �crit :
>> bonjour � tou(te)s
>>
>> question certainement assez b�te mais...
>>
>> J'ai deux points d�finis grace � \coordinate (I) ...
>> et m�me chose pour (J).
>>
>> Je voudrais r�cup�rer le point (sous forme d'un noeud de nom K) tel que
>> IKJ est �quilat�ral, les points �tant �nonc�s dans l'ordre trigo.
>>
>> tout d�but de piste sera hautement appr�ci�
>>
>> remerciements anticip�s
>
> Tout ceci est expliqu� dans la partie "Coordinate Calculations" du
> pgfmanual. Il y a certainement plusieurs m�thodes possibles...
cette documentation est un puits sans fond, on a beau la lire et la
relire, on en d�couvre toujours
Bonne Ann�e
> Le 09/01/2013 12:13, Le TeXnicien de surface a �crit :
>> bonjour � tou(te)s
>>
>> question certainement assez b�te mais...
>>
>> J'ai deux points d�finis grace � \coordinate (I) ...
>> et m�me chose pour (J).
>>
>> Je voudrais r�cup�rer le point (sous forme d'un noeud de nom K) tel que
>> IKJ est �quilat�ral, les points �tant �nonc�s dans l'ordre trigo.
>>
>> tout d�but de piste sera hautement appr�ci�
>>
>> remerciements anticip�s
>>
>
> Vous pouvez utiliser par exemple:
>
> \begin{tikzpicture}[framed]
>
> \coordinate (A) at (0,0);
> \coordinate (B) at (3,8);
> \coordinate (C) at ($($(A)!+.5!(B)$)!2!90:(B)$);
>
> \draw (A) node {A} -- (B) node {B} -- (C) node {C} -- cycle;
>
> \end{tikzpicture}
tr�s beau
>
> Vous pouvez utiliser par exemple:
>
> \begin{tikzpicture}[framed]
>
> \coordinate (A) at (0,0);
> \coordinate (B) at (3,8);
> \coordinate (C) at ($($(A)!+.5!(B)$)!2!90:(B)$);
>
> \draw (A) node {A} -- (B) node {B} -- (C) node {C} -- cycle;
>
> \end{tikzpicture}
>
> Tout ceci est expliqu� dans la partie "Coordinate Calculations" du
> pgfmanual. Il y a certainement plusieurs m�thodes possibles...
cette documentation est un puits sans fond, on a beau la lire et la
relire, on en d�couvre toujours
Bonne Ann�e
GL
Jan 9, 2013, 1:19:13 PM1/9/13
to
Le 09/01/2013 18:23, rpapa a �crit :
Du coup j'ai imaginer faire un
\def\equilateral #1#2{($(#1)!+.5!(#2)$)!+2!+90:(#2)}
puis \coordinate (C) at ($\equilateral AB$);
mais il y a un probl�me de parsing...
Je ne vois donc pas comment faire pour se constituer une petite
biblioth�que de calcul de coordonn�es.
>>
>> Tout ceci est expliqu� dans la partie "Coordinate Calculations" du
>> pgfmanual. Il y a certainement plusieurs m�thodes possibles...
>
>
> cette documentation est un puits sans fond, on a beau la lire et la
> relire, on en d�couvre toujours
>
> Bonne Ann�e
>
Vous de m�me.
> Le 09/01/2013 13:00, GL a �crit :
>> Le 09/01/2013 12:13, Le TeXnicien de surface a �crit :
>>> bonjour � tou(te)s
>>
>> Le 09/01/2013 12:13, Le TeXnicien de surface a �crit :
>>> bonjour � tou(te)s
>>
>> Vous pouvez utiliser par exemple:
>>
>> \begin{tikzpicture}[framed]
>>
>> \coordinate (A) at (0,0);
>> \coordinate (B) at (3,8);
>> \coordinate (C) at ($($(A)!+.5!(B)$)!2!90:(B)$);
>>
>> \draw (A) node {A} -- (B) node {B} -- (C) node {C} -- cycle;
>>
>> \end{tikzpicture}
>
> tr�s beau
oui pas mal ;-)
>>
>> \begin{tikzpicture}[framed]
>>
>> \coordinate (A) at (0,0);
>> \coordinate (B) at (3,8);
>> \coordinate (C) at ($($(A)!+.5!(B)$)!2!90:(B)$);
>>
>> \draw (A) node {A} -- (B) node {B} -- (C) node {C} -- cycle;
>>
>> \end{tikzpicture}
>
> tr�s beau
Du coup j'ai imaginer faire un
\def\equilateral #1#2{($(#1)!+.5!(#2)$)!+2!+90:(#2)}
puis \coordinate (C) at ($\equilateral AB$);
mais il y a un probl�me de parsing...
Je ne vois donc pas comment faire pour se constituer une petite
biblioth�que de calcul de coordonn�es.
>>
>> Tout ceci est expliqu� dans la partie "Coordinate Calculations" du
>> pgfmanual. Il y a certainement plusieurs m�thodes possibles...
>
>
> cette documentation est un puits sans fond, on a beau la lire et la
> relire, on en d�couvre toujours
>
> Bonne Ann�e
>
Paul Gaborit
Jan 9, 2013, 5:06:59 PM1/9/13
to
À (at) Wed, 09 Jan 2013 13:00:45 +0100,
GL <goua...@gmail.com> écrivait (wrote):
> Le 09/01/2013 12:13, Le TeXnicien de surface a écrit :
>> bonjour à tou(te)s
>>
>> question certainement assez bête mais...
>>
>> J'ai deux points définis grace à \coordinate (I) ...
>> et même chose pour (J).
>>
>> Je voudrais récupérer le point (sous forme d'un noeud de nom K) tel que
>> IKJ est équilatéral, les points étant énoncés dans l'ordre trigo.
>>
>> tout début de piste sera hautement apprécié
>>
>> remerciements anticipés
>>
>
> Vous pouvez utiliser par exemple:
>
> \begin{tikzpicture}[framed]
>
> \coordinate (A) at (0,0);
> \coordinate (B) at (3,8);
> \coordinate (C) at ($($(A)!+.5!(B)$)!2!90:(B)$);
équilatéral n'est pas égale à la longueur de son côté. Par contre, tous
les angles sont égaux à 60°.
Donc je ferai plutôt (le -60 au lieu de 60 est pour respecter l'ordre
trigo):
\documentclass[tikz]{standalone}
\usetikzlibrary{calc}
\begin{document}
\begin{tikzpicture}
\coordinate (I) at (0,0);
\coordinate (J) at (3,0);
\coordinate (K) at ($(I)!1!-60:(J)$);
% pour vérifier
\draw (I) node[left]{I}
-- (K) node[below]{K}
-- (J) node[right]{J}
-- cycle;
\end{tikzpicture}
\end{document}
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
Paul Gaborit
Jan 9, 2013, 5:14:00 PM1/9/13
to
À (at) Wed, 09 Jan 2013 19:19:13 +0100,
GL <goua...@gmail.com> écrivait (wrote):
> Du coup j'ai imaginer faire un
>
> \def\equilateral #1#2{($(#1)!+.5!(#2)$)!+2!+90:(#2)}
>
> puis \coordinate (C) at ($\equilateral AB$);
>
>
> Je ne vois donc pas comment faire pour se constituer une petite
> bibliothèque de calcul de coordonnées.
> Je ne vois donc pas comment faire pour se constituer une petite
Le moyen le plus simple (c'est une manière de parler) est de définir un
nouveau système de coordonnées via \tikzdeclarecoordinatesystem... mais
c'est très lourd (il faut le faire en pgf et non en TikZ).
GL
Jan 9, 2013, 6:34:34 PM1/9/13
to
Le 09/01/2013 23:06, Paul Gaborit a écrit :
>
> À (at) Wed, 09 Jan 2013 13:00:45 +0100,
> GL <goua...@gmail.com> écrivait (wrote):
>
>
>
> À (at) Wed, 09 Jan 2013 13:00:45 +0100,
> GL <goua...@gmail.com> écrivait (wrote):
>
>
> Heu... Si mes souvenirs de géométrie sont bons, la hauteur d'un triangle
> équilatéral n'est pas égale à la longueur de son côté. Par contre, tous
> les angles sont égaux à 60°.
Trop fort !!!
> équilatéral n'est pas égale à la longueur de son côté. Par contre, tous
> les angles sont égaux à 60°.
Je me disais aussi qu'il avait une gueule bizarre mon triangle ;-)
A une racine de trois de deux près, je crois qu'il est équilatéral.
Merci.
>
> Donc je ferai plutôt (le -60 au lieu de 60 est pour respecter l'ordre
> trigo):
>
> \documentclass[tikz]{standalone}
> \usetikzlibrary{calc}
> \begin{document}
> \begin{tikzpicture}
> \coordinate (I) at (0,0);
> \coordinate (J) at (3,0);
> \coordinate (K) at ($(I)!1!-60:(J)$);
Paul Gaborit
Jan 9, 2013, 7:59:04 PM1/9/13
to
À (at) Wed, 09 Jan 2013 23:14:00 +0100,
Paul Gaborit <Paul.G...@invalid.invalid> écrivait (wrote):
syntaxe que vous demandiez:
\documentclass[tikz]{standalone}
\usetikzlibrary{calc}
\begin{document}
\begin{tikzpicture}
\coordinate (I) at (0,0);
\coordinate (J) at (3,0);
\path \equilat{I}{J}{K};
\begin{tikzpicture}
\coordinate (I) at (0,0);
\coordinate (J) at (3,0);
% pour vérifier
\draw (I) node[left]{I}
-- (K) node[below]{K}
-- (J) node[right]{J}
-- cycle;
\end{tikzpicture}
\end{document}
GL
Jan 9, 2013, 10:12:42 PM1/9/13
to
Le 10/01/2013 01:59, Paul Gaborit a écrit :
>
> À (at) Wed, 09 Jan 2013 23:14:00 +0100,
> Paul Gaborit <Paul.G...@invalid.invalid> écrivait (wrote):
>
>
> À (at) Wed, 09 Jan 2013 23:14:00 +0100,
> Paul Gaborit <Paul.G...@invalid.invalid> écrivait (wrote):
>
>>> puis \coordinate (C) at ($\equilateral AB$);
>>>
>>> mais il y a un problème de parsing...
>>>
>>> Je ne vois donc pas comment faire pour se constituer une petite
>>> bibliothèque de calcul de coordonnées.
>>
>> Le moyen le plus simple (c'est une manière de parler) est de définir un
>> nouveau système de coordonnées via \tikzdeclarecoordinatesystem... mais
>> c'est très lourd (il faut le faire en pgf et non en TikZ).
>
> Il y a quand un moyen plus simple mais qui ne correspond pas à la
> syntaxe que vous demandiez:
>
> \documentclass[tikz]{standalone}
> \usetikzlibrary{calc}
> \def\equilat#1#2#3{($(#1)!1!-60:(#2)$) coordinate (#3)}
> \begin{document}
> \begin{tikzpicture}
> \coordinate (I) at (0,0);
> \coordinate (J) at (3,0);
> \path \equilat{I}{J}{K};
>
> % pour vérifier
> \draw (I) node[left]{I}
> -- (K) node[below]{K}
> -- (J) node[right]{J}
> -- cycle;
> \end{tikzpicture}
> \end{document}
Si c'est pas mal du tout ça !
>>>
>>> mais il y a un problème de parsing...
>>>
>>> Je ne vois donc pas comment faire pour se constituer une petite
>>> bibliothèque de calcul de coordonnées.
>>
>> Le moyen le plus simple (c'est une manière de parler) est de définir un
>> nouveau système de coordonnées via \tikzdeclarecoordinatesystem... mais
>> c'est très lourd (il faut le faire en pgf et non en TikZ).
>
> Il y a quand un moyen plus simple mais qui ne correspond pas à la
> syntaxe que vous demandiez:
>
> \documentclass[tikz]{standalone}
> \usetikzlibrary{calc}
> \def\equilat#1#2#3{($(#1)!1!-60:(#2)$) coordinate (#3)}
> \begin{document}
> \begin{tikzpicture}
> \coordinate (I) at (0,0);
> \coordinate (J) at (3,0);
> \path \equilat{I}{J}{K};
>
> % pour vérifier
> \draw (I) node[left]{I}
> -- (K) node[below]{K}
> -- (J) node[right]{J}
> -- cycle;
> \end{tikzpicture}
> \end{document}
Et ca a l'avantage de normaliser la syntaxe:
\path \commande {#1}{#2}{#3...}
Du coup je ferais plutôt: \path \equilat (K) {I}{J};
\documentclass[tikz]{standalone}
\usetikzlibrary{calc}
\begin{document}
\begin{tikzpicture}
\coordinate (I) at (4,6);
\coordinate (J) at (3,0);
\draw [thick] \equilat (K) {I}{J} node {K}
-- (I) node {I}
-- (J) node {J} -- cycle;
\end{tikzpicture}
\end{document}
Merci !
Paul Gaborit
Jan 10, 2013, 2:36:59 AM1/10/13
to
À (at) Thu, 10 Jan 2013 04:12:42 +0100,
GL <goua...@gmail.com> écrivait (wrote):
> Le 10/01/2013 01:59, Paul Gaborit a écrit :
>>
>> À (at) Wed, 09 Jan 2013 23:14:00 +0100,
>> Paul Gaborit <Paul.G...@invalid.invalid> écrivait (wrote):
>>
>>>> puis \coordinate (C) at ($\equilateral AB$);
>>>>
>>>> mais il y a un problème de parsing...
>>>>
>>>> Je ne vois donc pas comment faire pour se constituer une petite
>>>> bibliothèque de calcul de coordonnées.
>>>
>>> Le moyen le plus simple (c'est une manière de parler) est de définir un
>>> nouveau système de coordonnées via \tikzdeclarecoordinatesystem... mais
>>> c'est très lourd (il faut le faire en pgf et non en TikZ).
>
> Si c'est pas mal du tout ça !
> Et ca a l'avantage de normaliser la syntaxe:
> \path \commande {#1}{#2}{#3...}
>
> Du coup je ferais plutôt: \path \equilat (K) {I}{J};
En fait il y a encore plus "tikziens":
> Si c'est pas mal du tout ça !
> Et ca a l'avantage de normaliser la syntaxe:
> \path \commande {#1}{#2}{#3...}
>
> Du coup je ferais plutôt: \path \equilat (K) {I}{J};
\documentclass[tikz]{standalone}
\usetikzlibrary{calc}
equilateral with/.style args={#1 and #2}{
at={($(#1)!1!-60:(#2)$)},
}
}
\begin{document}
\begin{tikzpicture}
\coordinate (I) at (0,0);
\coordinate (J) at (3,0);
\coordinate[equilateral with=I and J](K);
}
\begin{document}
\begin{tikzpicture}
\coordinate (I) at (0,0);
\coordinate (J) at (3,0);
% pour vérifier
\draw (I) node[left]{I}
-- (K) node[below]{K}
-- (J) node[right]{J}
-- cycle;
\end{tikzpicture}
\end{document}
Paul Gaborit
Jan 10, 2013, 4:26:31 AM1/10/13
to
À (at) Thu, 10 Jan 2013 08:36:59 +0100,
Paul Gaborit <Paul.G...@invalid.invalid> écrivait (wrote):
> En fait il y a encore plus "tikziens":
>
> \documentclass[tikz]{standalone}
> \usetikzlibrary{calc}
>
> \tikzset{
> equilateral with/.style args={#1 and #2}{
> at={($(#1)!1!-60:(#2)$)},
> }
> }
> \begin{document}
> \begin{tikzpicture}
> \coordinate (I) at (0,0);
> \coordinate (J) at (3,0);
> \coordinate[equilateral with=I and J](K);
>
> % pour vérifier
> \draw (I) node[left]{I}
> -- (K) node[below]{K}
> -- (J) node[right]{J}
> -- cycle;
> \end{tikzpicture}
> \end{document}
Et pour finir, il me semble qu'il vaut mieux choisir l'ordre trigo par
>
> \documentclass[tikz]{standalone}
> \usetikzlibrary{calc}
>
> \tikzset{
> equilateral with/.style args={#1 and #2}{
> at={($(#1)!1!-60:(#2)$)},
> }
> }
> \begin{document}
> \begin{tikzpicture}
> \coordinate (I) at (0,0);
> \coordinate (J) at (3,0);
> \coordinate[equilateral with=I and J](K);
>
> % pour vérifier
> \draw (I) node[left]{I}
> -- (K) node[below]{K}
> -- (J) node[right]{J}
> -- cycle;
> \end{tikzpicture}
> \end{document}
défaut puisqu'il suffit d'inverser les deux noeuds de référence pour
obtenir l'ordre inverse. Cela donne donc:
\documentclass[tikz]{standalone}
\usetikzlibrary{calc}
\tikzset{
equilateral with/.style args={#1 and #2}{
}
}
\begin{document}
\begin{tikzpicture}
\coordinate (I) at (0,0);
\coordinate (J) at (3,0);
\coordinate[equilateral with=J and I](K);
}
\begin{document}
\begin{tikzpicture}
\coordinate (I) at (0,0);
\coordinate (J) at (3,0);
GL
Jan 10, 2013, 8:33:23 AM1/10/13
to
pour utiliser pgfmath@onquick qui raccourcit assez
considérablement le processus...
Merci.
Paul Gaborit
Jan 10, 2013, 9:51:56 AM1/10/13
to
À (at) Thu, 10 Jan 2013 14:33:23 +0100,
GL <goua...@gmail.com> écrivait (wrote):
> oui avec cependant $(#1)!+1!+60:(#2)$
> pour utiliser pgfmath@onquick qui raccourcit assez
> considérablement le processus...
milli-secondes. Vu que ce n'est pas documenté, j'hésite toujours à
utiliser ce genre d'optimisations car, juste en lisant le code, j'ai du
mal à identifier dans quels cas cela pourraient poser problème (même si
là, il est assez évident que ça n'en posera pas ;-)).
GL
Jan 10, 2013, 11:52:34 AM1/10/13
to
Engine). C'est à réserver aux cas où il n'y a rien à parser (pas
d'expression):
\pgfmathsetlength \dimen@ {+1cm+2cm} ne fonctionnera pas (il s'agit
d'une expression)
mais \pgfmathsetlength \dimen@ {+1cm} ira plus vite que "1cm"
(nota: pour le négatif, il faut \pgfmathsetlength \dimen@ {+-1cm})
Pour moi, ce n'est pas vraiment la question du temps de compilation,
mais celle de la longueur du .log (divisé par 2 pour l'exemple
précédent).
Bonne journée.
michel....@wanadoo.fr
Jan 10, 2013, 11:59:13 AM1/10/13
to
Une petite question qui me taraude depuis le début de ce fil: quelle était la question de départ?
-1- faire un triangle équilatéral avec Tikz
-2- discuter sur les entrailles de Tikz.
Si la question était la -1-, pourquoi ne pas aller voir du côté de tkz-euclide? Est-ce "caca" d'utiliser ces macros? ;-) ou dit autrement, est-ce impur de ne pas utiliser le package d'origine? Cela me rappelle le débat entre ceux qui voulaient n'utiliser que TeX et ceux qui trouvaient que la surcouche de Lamport était bien pratique.
Si la question est -2- alors je trouve le débat intéressant, mais je me demande pourquoi il faut toujours que l'on réinvente la roue.
N'y voyez aucun reproche, je cherche seulement à comprendre pourquoi faire une macro "equilatera with" est mieux que d'utiliser le travail de quelqu'un que je tiens à féliciter et remercier encore une fois ici.
Michel
-1- faire un triangle équilatéral avec Tikz
-2- discuter sur les entrailles de Tikz.
Si la question était la -1-, pourquoi ne pas aller voir du côté de tkz-euclide? Est-ce "caca" d'utiliser ces macros? ;-) ou dit autrement, est-ce impur de ne pas utiliser le package d'origine? Cela me rappelle le débat entre ceux qui voulaient n'utiliser que TeX et ceux qui trouvaient que la surcouche de Lamport était bien pratique.
Si la question est -2- alors je trouve le débat intéressant, mais je me demande pourquoi il faut toujours que l'on réinvente la roue.
N'y voyez aucun reproche, je cherche seulement à comprendre pourquoi faire une macro "equilatera with" est mieux que d'utiliser le travail de quelqu'un que je tiens à féliciter et remercier encore une fois ici.
Michel
GL
Jan 10, 2013, 12:31:40 PM1/10/13
to
Le 10/01/2013 17:59, michel....@wanadoo.fr a �crit :
> Une petite question qui me taraude depuis le d�but de ce fil: quelle �tait la question de d�part?
>
> -1- faire un triangle �quilat�ral avec Tikz
>
> Si la question est -2- alors je trouve le d�bat int�ressant, mais je me demande pourquoi il faut toujours que l'on r�invente la roue.
>
> N'y voyez aucun reproche, je cherche seulement � comprendre pourquoi faire une macro "equilatera with" est mieux que d'utiliser le travail de quelqu'un que je tiens � f�liciter et remercier encore une fois ici.
Si vous comparez votre code � celui de Paul Gaborit,
en toute honn�tet�, si vous arr�tez TeX pendant 2 mois,
duquel pourriez-vous vous souvenir ?
La question -3- est: Pourquoi tkz si on peut faire
aussi bien et plus vite avec TikZ ?
Pour ma part, je consid�re tkz comme une extension: on
ne l'utilise qu'en tant que de besoin (par exemple
pour les graphes, c'est tr�s pratique...)
Cordialement.
>
> Michel
>
> Une petite question qui me taraude depuis le d�but de ce fil: quelle �tait la question de d�part?
>
> -1- faire un triangle �quilat�ral avec Tikz
> -2- discuter sur les entrailles de Tikz.
>
> Si la question �tait la -1-, pourquoi ne pas aller voir du c�t� de tkz-euclide? Est-ce "caca" d'utiliser ces macros? ;-) ou dit autrement, est-ce impur de ne pas utiliser le package d'origine? Cela me rappelle le d�bat entre ceux qui voulaient n'utiliser que TeX et ceux qui trouvaient que la surcouche de Lamport �tait bien pratique.
>
>
> Si la question est -2- alors je trouve le d�bat int�ressant, mais je me demande pourquoi il faut toujours que l'on r�invente la roue.
>
> N'y voyez aucun reproche, je cherche seulement � comprendre pourquoi faire une macro "equilatera with" est mieux que d'utiliser le travail de quelqu'un que je tiens � f�liciter et remercier encore une fois ici.
Si vous comparez votre code � celui de Paul Gaborit,
en toute honn�tet�, si vous arr�tez TeX pendant 2 mois,
duquel pourriez-vous vous souvenir ?
La question -3- est: Pourquoi tkz si on peut faire
aussi bien et plus vite avec TikZ ?
Pour ma part, je consid�re tkz comme une extension: on
ne l'utilise qu'en tant que de besoin (par exemple
pour les graphes, c'est tr�s pratique...)
Cordialement.
>
> Michel
>
michel....@wanadoo.fr
Jan 10, 2013, 12:40:15 PM1/10/13
to
> Si vous comparez votre code � celui de Paul Gaborit,
>
> en toute honn�tet�, si vous arr�tez TeX pendant 2 mois,
>
> duquel pourriez-vous vous souvenir ?
Je me souviendrai sûrement plus facilement du code de Tkz car plus intuitif et plus proche de ce que l'on fait en classe.
> duquel pourriez-vous vous souvenir ?
Il n'y a rien de très intuitif dans ce genre de code: "($($(A)!+.5!(B)$)!2!90:(B)$);"
Par contre, "\tkzDefPointBy[rotation=center A angle 60](B) \tkzGetPoint{C}" me parle beaucoup plus.
> La question -3- est: Pourquoi tkz si on peut faire aussi bien et plus vite > avec TikZ ?
Cordialement
Michel
GL
Jan 10, 2013, 12:59:30 PM1/10/13
to
Le 10/01/2013 18:40, michel....@wanadoo.fr a �crit :
>
> Il n'y a rien de tr�s intuitif dans ce genre de code: "($($(A)!+.5!(B)$)!2!90:(B)$);"
Non mais si on veut utiliser TikZ, on est bien oblig� d'apprendre
sa syntaxe, et en particulier la d�finition des coordonn�es qui est
quelque chose d'� la fois conceptuellement �l�mentaire et graphiquement
tr�s puissant. Donc pas intuitif pour le profane, mais comme disait
Descartes, � lire 10 fois une d�monstration, on consid�re son
cheminement comme une �vidence ;-)
De plus vous trichez un peu car la formule est (comme Paul Gaborit
me l'a montr� -- honte sur moi !)
($(I)!1!-60:(J)$);
ce qui n'a rien de bien sorcier.
>
> Par contre, "\tkzDefPointBy[rotation=center A angle 60](B) \tkzGetPoint{C}" me parle beaucoup plus.
C'est une question de go�t, ou d'habitude (cf Descartes).
Perso je trouve que \coordinate c'est pas mal comme nom de commande...
S�mantiquement, \coordinate (C) at ($(I)!1!-60:(J)$); signifie:
DefPoint (C) by [rotation=center I angle -60,distance ratio=1] (B)
C'est donc identique avec une syntaxe plus compacte.
>> La question -3- est: Pourquoi tkz si on peut faire aussi bien et plus vite > avec TikZ ?
>
> Gagner quelques dixi�mes de seconde n'a jamais �t� ma motivation principale pour utiliser LaTeX, par contre, si les deux codes font aussi bien, ce dont je ne doute pas, je choisis celui dont le code est le plus simple, pour moi, � retenir.
Je pensais "plus vite" dans le sens o� si conna�t la syntaxe des
coordonn�es TikZ (et aussi qu'on ne se plante pas lamentablement
sur la m�thode pour d�finir le point souhait�) une syntaxe compacte
a quand m�me des avantages...
>
> Cordialement
>
> Michel
>
>
>
>> Si vous comparez votre code � celui de Paul Gaborit,
>>
>> en toute honn�tet�, si vous arr�tez TeX pendant 2 mois,
>> Si vous comparez votre code � celui de Paul Gaborit,
>>
>>
>> duquel pourriez-vous vous souvenir ?
>
>
> Je me souviendrai s�rement plus facilement du code de Tkz car plus intuitif et plus proche de ce que l'on fait en classe.
>> duquel pourriez-vous vous souvenir ?
>
>
>
> Il n'y a rien de tr�s intuitif dans ce genre de code: "($($(A)!+.5!(B)$)!2!90:(B)$);"
Non mais si on veut utiliser TikZ, on est bien oblig� d'apprendre
sa syntaxe, et en particulier la d�finition des coordonn�es qui est
quelque chose d'� la fois conceptuellement �l�mentaire et graphiquement
tr�s puissant. Donc pas intuitif pour le profane, mais comme disait
Descartes, � lire 10 fois une d�monstration, on consid�re son
cheminement comme une �vidence ;-)
De plus vous trichez un peu car la formule est (comme Paul Gaborit
me l'a montr� -- honte sur moi !)
($(I)!1!-60:(J)$);
ce qui n'a rien de bien sorcier.
>
> Par contre, "\tkzDefPointBy[rotation=center A angle 60](B) \tkzGetPoint{C}" me parle beaucoup plus.
Perso je trouve que \coordinate c'est pas mal comme nom de commande...
S�mantiquement, \coordinate (C) at ($(I)!1!-60:(J)$); signifie:
DefPoint (C) by [rotation=center I angle -60,distance ratio=1] (B)
C'est donc identique avec une syntaxe plus compacte.
>> La question -3- est: Pourquoi tkz si on peut faire aussi bien et plus vite > avec TikZ ?
>
Je pensais "plus vite" dans le sens o� si conna�t la syntaxe des
coordonn�es TikZ (et aussi qu'on ne se plante pas lamentablement
sur la m�thode pour d�finir le point souhait�) une syntaxe compacte
a quand m�me des avantages...
>
> Cordialement
>
> Michel
>
>
Paul Gaborit
Jan 11, 2013, 2:21:35 AM1/11/13
to
À (at) Thu, 10 Jan 2013 08:59:13 -0800 (PST),
michel....@wanadoo.fr écrivait (wrote):
> Une petite question qui me taraude depuis le début de ce fil: quelle était la question de départ?
>
> -1- faire un triangle équilatéral avec Tikz
> -2- discuter sur les entrailles de Tikz.
>
> Si la question était la -1-, pourquoi ne pas aller voir du côté de
> tkz-euclide? Est-ce "caca" d'utiliser ces macros? ;-) ou dit
> autrement, est-ce impur de ne pas utiliser le package d'origine? Cela
> me rappelle le débat entre ceux qui voulaient n'utiliser que TeX et
> ceux qui trouvaient que la surcouche de Lamport était bien pratique.
> N'y voyez aucun reproche, je cherche seulement à comprendre pourquoi
> faire une macro "equilatera with" est mieux que d'utiliser le travail
> de quelqu'un que je tiens à féliciter et remercier encore une fois
> ici.
Malgré toutes ses qualités (et celles de son auteur), tkz-euclide n'est
> faire une macro "equilatera with" est mieux que d'utiliser le travail
> de quelqu'un que je tiens à féliciter et remercier encore une fois
> ici.
pas du tout écrit dans l'esprit de la syntaxe TikZ et ne s'intègre que
difficilement avec toutes les autres extensions de TikZ.
L'intérêt de passer par une clé 'equilateral with' vient à la fois de la
simplicité de la syntaxe et de la possibilité de l'utiliser en de
nombreuses circonstances en TikZ (par exemple, en plein milieu de la
définition d'un path) ce que les macros de tkz-euclide ne permettent pas
sauf à passer par un appel à \pgfextra (et souvent combiné à un appel au
couple \pgfinterruptpath, \endpgfinterruptpath).
En fait, quand je vois les macros proposées par tkz-euclide, j'ai
presque l'impression inverse de la vôtre : c'est du code qui en est
resté à la syntaxe de (La)TeX alors que TikZ offre des mécanismes
d'extension de sa syntaxe beaucoup plus souples et adaptés !
GL
Jan 11, 2013, 7:07:55 AM1/11/13
to
Le 10/01/2013 17:59, michel....@wanadoo.fr a écrit :
> Une petite question qui me taraude depuis le début de ce fil: quelle était la question de départ?
>
> -1- faire un triangle équilatéral avec Tikz
> -2- discuter sur les entrailles de Tikz.
>
> Si la question était la -1-, pourquoi ne pas aller voir du côté de tkz-euclide?
Est-ce "caca" d'utiliser ces macros? ;-) ou dit autrement, est-ce impur
de ne pas
utiliser le package d'origine? Cela me rappelle le débat entre ceux qui
voulaient
n'utiliser que TeX et ceux qui trouvaient
que la surcouche de Lamport était bien pratique.
Du coup me vient la réflexion que ceux qui trouvent la /surcouche/
> Une petite question qui me taraude depuis le début de ce fil: quelle était la question de départ?
>
> -1- faire un triangle équilatéral avec Tikz
> -2- discuter sur les entrailles de Tikz.
>
> Si la question était la -1-, pourquoi ne pas aller voir du côté de tkz-euclide?
Est-ce "caca" d'utiliser ces macros? ;-) ou dit autrement, est-ce impur
de ne pas
utiliser le package d'origine? Cela me rappelle le débat entre ceux qui
voulaient
n'utiliser que TeX et ceux qui trouvaient
que la surcouche de Lamport était bien pratique.
(appelé aussi plus noblement /noyau/) LaTeX est bien pratique
devraient la respecter. Ceux qui n'utilisent que TeX (en fait
plutôt plain TeX) ont le mérite de ne pas redéfinir les commandes
du noyau...
Voilà, comme ça on a aussi un peu parlé des entrailles de LaTeX ;-)
> Michel
Alain Matthes
May 2, 2013, 4:42:17 AM5/2/13
to
On 2013-01-11 07:21:35 +0000, Paul Gaborit said:
> À (at) Thu, 10 Jan 2013 08:59:13 -0800 (PST),
> michel....@wanadoo.fr écrivait (wrote):
>
> À (at) Thu, 10 Jan 2013 08:59:13 -0800 (PST),
> michel....@wanadoo.fr écrivait (wrote):
>
>> N'y voyez aucun reproche, je cherche seulement à comprendre pourquoi
>> faire une macro "equilatera with" est mieux que d'utiliser le travail
>> de quelqu'un que je tiens à féliciter et remercier encore une fois
>> ici.
>
> Malgré toutes ses qualités (et celles de son auteur), tkz-euclide n'est
> pas du tout écrit dans l'esprit de la syntaxe TikZ et ne s'intègre que
> difficilement avec toutes les autres extensions de TikZ.
>
> L'intérêt de passer par une clé 'equilateral with' vient à la fois de la
> simplicité de la syntaxe et de la possibilité de l'utiliser en de
> nombreuses circonstances en TikZ (par exemple, en plein milieu de la
> définition d'un path) ce que les macros de tkz-euclide ne permettent pas
> sauf à passer par un appel à \pgfextra (et souvent combiné à un appel au
> couple \pgfinterruptpath, \endpgfinterruptpath).
>
> En fait, quand je vois les macros proposées par tkz-euclide, j'ai
> presque l'impression inverse de la vôtre : c'est du code qui en est
> resté à la syntaxe de (La)TeX alors que TikZ offre des mécanismes
> d'extension de sa syntaxe beaucoup plus souples et adaptés !
Une réponse bien tardive mais je n'ai pas lu fctt depuis un bon moment.
>> faire une macro "equilatera with" est mieux que d'utiliser le travail
>> de quelqu'un que je tiens à féliciter et remercier encore une fois
>> ici.
>
> Malgré toutes ses qualités (et celles de son auteur), tkz-euclide n'est
> pas du tout écrit dans l'esprit de la syntaxe TikZ et ne s'intègre que
> difficilement avec toutes les autres extensions de TikZ.
>
> L'intérêt de passer par une clé 'equilateral with' vient à la fois de la
> simplicité de la syntaxe et de la possibilité de l'utiliser en de
> nombreuses circonstances en TikZ (par exemple, en plein milieu de la
> définition d'un path) ce que les macros de tkz-euclide ne permettent pas
> sauf à passer par un appel à \pgfextra (et souvent combiné à un appel au
> couple \pgfinterruptpath, \endpgfinterruptpath).
>
> En fait, quand je vois les macros proposées par tkz-euclide, j'ai
> presque l'impression inverse de la vôtre : c'est du code qui en est
> resté à la syntaxe de (La)TeX alors que TikZ offre des mécanismes
> d'extension de sa syntaxe beaucoup plus souples et adaptés !
Je suis globalement d'accord avec ce que Paul a écrit. Quelques
compléments cependant...
tkz-euclide a été créé pour aider des profs de maths à faire leurs figures
sous latex sans trop se prendre la tête, sans avoir à lire des centaines de
pages de doc et sans forcément apprendre à programmer avec Tikz et Tex.
a) Pour cela, j'ai utilisé une syntaxe proche de latex, également
proche de pst-eucl
pour ceux qui connaissaient déjà ce package sous pstricks.
b) J'ai donné de multiples exemples pour que ces profs puissent avoir
une bibliothèque où puiser leur inspiration et ne pas avoir à programmer
sans arrêt.
D'accord avec Paul, sur les problèmes de syntaxe. J'adore celle de Tikz
et à certains moments, j'ai regretté l'écriture des tkz-??? mais si mon
intention première était d'écrire une librairie tikzienne, je me suis
vite rendu
compte que la mission étaient presque impossible ( à l'époque avant pgfkeys et
la version 2.1 de pgf).
Un clone de pst-eucl était plus aisée, mais dans ce cas je ne pouvais
conserver la syntaxe de Tikz.
Tikz bien sûr est plus souple et plus puissant, mais la question est de savoir
si on veut apprendre à faire n'importe quoi avec TikZ et à le maîtriser
complètement ou bien simplement faire quelques figures de géométrie.
D'accord, avec Paul sur le fait que TkZ pose des problème lorsque l'on
veut définir
des objets au beau milieu d'un path. Il est bien difficile de faire rimer
facilité avec complexité. On peut toutefois placer du code tikzien
entre du code de tkz, même si esthétiquement ce n'est pas très beau et j'avoue
que je déteste le faire et qu'il est préférable de l'éviter.
Ces quelques explications me permettent d'émettre certains avis sur les
solutions proposées:
Premièrement, il faut une douzaine de posts avant d'arriver à une très
bonne solution
tikzienne...
Je trouve assez difficile à digérer : ($($(A)!+.5!(B)$)!2!90:(B)$) qui
devrait être
($($(A)!+.5!(B)$)!sqrt(3)!90:(B)$) . Plus simple serait de proposer la
création intermédiaire
du milieu du segment.
On trouve des explications du code dans le pgfmanual mais il faut déjà que le
lecteur comprenne les subtilités entre
⟨coordinate⟩!⟨number⟩!⟨angle⟩:⟨second coordinate⟩
⟨coordinate⟩!⟨dimension⟩!⟨angle⟩:⟨second coordinate⟩
⟨coordinate⟩!⟨projection coordinate⟩!⟨angle⟩:⟨second coordinate⟩
Pour le non matheux, c'est assez catastrophique.
Ensuite, vous avez proposé \def\equilat#1#2#3{($(#1)!1!-60:(#2)$)
coordinate (#3)}
À la complexité de la formule avec TikZ, s'ajoute une petite couche de
TeX avec manipulation
d'arguments et le résultat au niveau de de la syntaxe de TikZ est, il
me semble, horrible :
\path \equilat{I}{J}{K};
Finalement la bonne voie et la très solution est ($(I)!1!-60:(J)$);
si on comprend que c'est une rotation autour de I.
Si on ne veut pas réinventer la roue à chaque fois:
\tikzset{
equilateral with/.style args={#1 and #2}{
at={($(#1)!1!60:(#2)$)},
}
est excellent mais là il faut avoir jeter un oeil à pgfkeys, (pas si
évident que cela),
connaître "style arg" et surtout "at={(a,b)}" qui n'est pas l'option
la plus représentée
dans le manuel.
CE que je veux faire remarquer ici, est qu'il faut tenir compte du
niveau de l'utilisateur,
de combien de temps, il peut consacrer à son apprentissage.
La conclusion serait qu'il est peut-être intéressant de créer une
librairie "euclide"
pour tikz en regroupant des styles comme "equilateral with". J'ai du
mal à évaluer
si on peut obtenir quelques chose de complet.
Il reste une dernière remarque, c'est la précision des calculs. Si je
suis passé également
avec tkz à une sur-couche au-dessus de tikz, c'était à l'époque pour
pouvoir utiliser
fp.sty, que Tantau ne voulait pas (depuis sa position a évoluée). En effet,
sans fp, je trouve très délicat certains calculs pour des changements
de repères
et positionnement de grille. Certains calculs dans les "projections
modifiers" ne sont pas terribles
comme l'exemple du pgfmanual :
\begin{tikzpicture}
\draw [help lines] (0,0) grid (3,2);
\coordinate (a) at (0,1);
\coordinate (b) at (3,2);
\coordinate (c) at (2.5,0);
\draw (a) -- (b) -- (c) -- cycle;
\draw[red] (a) -- ($(b)!(a)!(c)$);
\draw[orange] (b) -- ($(a)!(b)!(c)$);
\draw[blue] (c) -- ($(a)!(c)!(b)$);
\end{tikzpicture}
Si on effectue un gros zoom, on voit que les hauteurs ne sont pas concourantes.
Dans le document suivant l'auteur a repris de nombreux exemples que
j'ai créé avec tkz
uniquement avec tikz, cela peut donner des idées à ceux qui veulent
uniquement utiliser tikz
http://www.guit.sssup.it/downloads/TikZxGuit2.pdf
Alain
0 new messages