# Tikz-Euclid, Incircle, and Calculated Coordinates

MWE:

\documentclass[tikz, border=1cm]{standalone}
\usepackage{tkz-euclide}
\begin{document}
\begin{tikzpicture}
\coordinate (A) at (0,0);
\coordinate (B) at (4,0);
% \coordinate (C) at ($(A) + ({-60}:4)$);
\coordinate (C) at (2,-3);

\draw (A)--(B)--(C)--cycle;

% circumcircle
\tkzCircumCenter(A,B,C)\tkzGetPoint{O}
% \tkzDrawPoint(O)
\tkzDrawCircle(O,A)

% incircle
\tkzDefCircle[in](A,B,C)\tkzGetPoint{I}\tkzGetLength{rIN}
\tkzDrawPoint(I)
\tkzDrawCircle[R](I,\rIN pt)
\end{tikzpicture}
\end{document}


Gives,

But

\documentclass[tikz, border=1cm]{standalone}
\usepackage{tkz-euclide}
\begin{document}
\begin{tikzpicture}
\coordinate (A) at (0,0);
\coordinate (B) at (4,0);
\coordinate (C) at ($(A) + ({-60}:4)$);
% \coordinate (C) at (2,-3);

\draw (A)--(B)--(C)--cycle;

% circumcircle
\tkzCircumCenter(A,B,C)\tkzGetPoint{O}
% \tkzDrawPoint(O)
\tkzDrawCircle(O,A)

% incircle
\tkzDefCircle[in](A,B,C)\tkzGetPoint{I}\tkzGetLength{rIN}
\tkzDrawPoint(I)
\tkzDrawCircle[R](I,\rIN pt)
\end{tikzpicture}
\end{document}


Gives,

Am I missing something, or there is a problem with tikz-euclid doing its calculations with the calculated coordinate? (Why should it?)

This purely tikz-euclid way also seems problematic:

\documentclass[tikz, border=1cm]{standalone}
\usepackage{tkz-euclide}
\usetkzobj{all}
\begin{document}
\begin{tikzpicture}
\tkzDefPoint(0,0){A}
\tkzDefPoint(4,0){B}
\tkzDefTriangle[equilateral](B,A)
\tkzGetPoint{D}
\tkzDrawPolygon(B,A,D)

% circumcircle
\tkzCircumCenter(A,B,D)\tkzGetPoint{O}
\tkzDrawCircle(O,A)

% incircle
\tkzDefCircle[in](A,B,D)\tkzGetPoint{I}\tkzGetLength{rIN}
\tkzDrawPoint(I)
\tkzDrawCircle[R](I,\rIN pt)
\end{tikzpicture}
\end{document}


Gives:

• If you do \coordinate (C) at ($(A) + (2,-3)$);, you are back at the first result. I guess that this simply means that there is a problem with setting C at ({-60}:4), but not with using the calc syntax to set the coordinates. This is confirmed by the fact that just doing \coordinate (C) at ({-60}:4); also leads to the incorrect incircle. That is, there might be an issue in tkz-euclide, but as far as I can see it is not tied to using the calc syntax. – user121799 Nov 17 '18 at 17:40

IMHO there is a numerical instability in the computations done by the macros of the tkz-euclide package. This has nothing to do with the coordinates set via the calc syntax. To see this, consider

\documentclass[tikz, border=1cm]{standalone}
\usepackage{tkz-euclide}
\begin{document}
\begin{tikzpicture}
\coordinate (A) at (0,0);
\coordinate (B) at (4,0);
% \coordinate (C) at ($(A) + (2,-3)$); %({-60}:4)
\coordinate (C) at ({-60.01}:4); %({-60}:4)
% \coordinate (C) at (2,-3);

\draw (A)--(B)--(C)--cycle;

% circumcircle
\tkzCircumCenter(A,B,C)\tkzGetPoint{O}
% \tkzDrawPoint(O)
\tkzDrawCircle(O,A)

% incircle
\tkzDefCircle[in](A,B,C)\tkzGetPoint{I}\tkzGetLength{rIN}
\tkzDrawPoint(I)
\tkzDrawCircle[R](I,\rIN pt)
\end{tikzpicture}
\end{document}


Everything is cool (except for the bounding box, which could be computed correctly if tkz-euclide were to put overlay when it is computing the auxiliary paths, but this is off-topic here).

However, if I remove the last digit of the angle that defines C, i.e. do

\coordinate (C) at ({-60}:4);


I get what you got

I stress that I have even made an attempt to figure out what's going on internally, simply because I don't speak French and don't understand many things in the manual or code.

Bottom-line: To me it seems that you have discovered an issue in tkz-euclide.

ADDENDUM: Why does that happen here? To understand this, let us recall how incircles are computed. To this end, I follow this nice answer, which uses Heron's formula to compute the radius \inrad of the incircle. This tells us that the incircle is where the lines that are parallel to the edges with distance \incircle intersect. However, for a given edge there are two parallel lines with that distance.

\documentclass[tikz, border=1cm]{standalone}
\usepackage{tkz-euclide}
\begin{document}
% from https://tex.stackexchange.com/a/299451/121799
% calculate semiperimeter
% \pgfmathsetmacro{\semip}{(\sideA+\sideB+\sideC)/2}
% calculate radius of incircle: area (given by Heron's formula) divided by semiperimeter

\begin{tikzpicture}[globalize/.code n args={2}{\xdef#2{#1}}]
\coordinate (A) at (0,0);
\coordinate (B) at (4,0);
% \coordinate (C) at ($(A) + (2,-3)$); %({-60}:4)
\coordinate (C) at ({-60.01}:4); %({-60}:4)
% \coordinate (C) at (2,-3);
\path let \p1=($(A)-(B)$), \p2=($(B)-(C)$),\p3=($(C)-(A)$),
\n1={0.5*(veclen(\x1,\y1)+veclen(\x2,\y2)+veclen(\x3,\y3))},
\n2={sqrt(((\n1-veclen(\x1,\y1))/\n1))*sqrt((\n1-veclen(\x2,\y2))*(\n1-veclen(\x3,\y3)))}
\foreach \X/\Y in {A/B,B/C,C/A}
{\draw[gray,thin] ($(\X)!\inrad!90:(\Y)$) -- ($(\Y)!\inrad!-90:(\X)$);
\draw[gray,thin] ($(\X)!\inrad!-90:(\Y)$) -- ($(\Y)!\inrad!90:(\X)$);}
\draw (A)--(B)--(C)--cycle;

% circumcircle
\tkzCircumCenter(A,B,C)\tkzGetPoint{O}
% \tkzDrawPoint(O)
\tkzDrawCircle(O,A)

% incircle
\tkzDefCircle[in](A,B,C)\tkzGetPoint{I}\tkzGetLength{rIN}
\tkzDrawPoint(I)
\tkzDrawCircle[R](I,\rIN pt)
\end{tikzpicture}
\end{document}


Looking at this picture, I think that tkz-euclide computes the intersection of the wrong (i.e. outer) parallels. This picture also shows that the incircle center is not precisely at the intersection of the parallel lines.

This suggest that, at least as long tkz-euclide requires proficiency in the French language, to compute the incircle radius and center without that package, but following this nice answer.

\documentclass[tikz,border=3.14mm]{standalone}
\usetikzlibrary{calc,intersections}
\begin{document}
\begin{tikzpicture}[globalize/.code n args={2}{\xdef#2{#1}}]
\coordinate (A) at (0,0);
\coordinate (B) at (4,0);
\coordinate (C) at ($(A)+({-60}:4)$);
\draw (A) -- (B) -- (C) -- cycle;
%
\path let \p1=($(A)-(B)$), \p2=($(B)-(C)$),\p3=($(C)-(A)$),
\n1={0.5*(veclen(\x1,\y1)+veclen(\x2,\y2)+veclen(\x3,\y3))},
\n2={sqrt(((\n1-veclen(\x1,\y1))/\n1))*sqrt((\n1-veclen(\x2,\y2))*(\n1-veclen(\x3,\y3)))}
\foreach \X/\Y in {A/B,B/C,C/A}
{\path[name path global=path-\X-\Y-1] ($(\X)!\inrad!90:(\Y)$) -- ($(\Y)!\inrad!-90:(\X)$);
\path[name path global=path-\X-\Y-2] ($(\X)!\inrad!-90:(\Y)$) -- ($(\Y)!\inrad!90:(\X)$);}
\foreach \X in {1,2}
{\foreach \Y in {1,2}
{\path[name intersections={of={path-A-B-\X} and {path-B-C-\Y},total=\t}]
\ifnum\t=1
(intersection-1) coordinate (incenter)
\else
\fi
;}
}
\end{tikzpicture}
\end{document}


One can even go a step further and get rid of the intersections library, and make things more TikZy by using elementary trigonometry the determination of the center based on Cartesian coordinates.

\documentclass[tikz,border=3.14mm]{standalone}
\usetikzlibrary{calc}
\begin{document}
\begin{tikzpicture}[incircle/.style n args={3}{%
insert path={
let \p1=($(#2)-(#1)$), \p2=($(#3)-(#1)$),\p3=($(#2)-(#3)$),
\n1={0.5*(veclen(\x1,\y1)+veclen(\x2,\y2)+veclen(\x3,\y3))},
\n2={sqrt(((\n1-veclen(\x1,\y1))/\n1))*sqrt((\n1-veclen(\x2,\y2))*(\n1-veclen(\x3,\y3)))},
\n3={veclen(\x1,\y1)}, % length #1 -- #2
\n4={veclen(\x2,\y2)}, % length #1 -- #3
\n5={veclen(\x3,\y3)}, % length #2 -- #3
\n6={\n3+\n4+\n5}
in % \pgfextra{\typeout{\n1,\n2,\n3,\n4,\n5,\n6}}
(${(\n5/\n6)}*(#1)+{(\n4/\n6)}*(#2)+{(\n3/\n6)}*(#3)$) circle (\n2)
}}]
\coordinate (A) at (0,0);
\coordinate (B) at (4,0);
\coordinate (C) at ($(A)+({-60}:4)$);
\draw (A) -- (B) -- (C) -- cycle;
%
\draw[incircle={A}{B}{C}];
\end{tikzpicture}
\end{document}


This leads the same output as above. (When writing this, I found it is not at all trivial to grasp all cases, and there is no guarantee that I did. That is, I am really deeply impressed by Alain Matthes' achievements. In other words, even though I do think that there might be an issue with tkz-euclide, one should also highlight that it overall works great.)

• +1, I also think there are bugs in tkz-euclide. This package was very useful for me to start with Tikz since the documentation is in French and I almost exclusively build elementary geometric figures in my work. Starting with LaTeX, I thought I was doing the wrong thing at first. But over time and with the problems, I turned to Tikz which is more complex in approach, but with fewer bugs. – AndréC Nov 17 '18 at 20:23
• @AndréC I guess it is very hard to come up with a bug-free package, but as you say at a given point it is probably a good idea to switch to calc, also because in the end it is IMHO more powerful even though it does not seem so at first sight simply because there are less examples in the manual. – user121799 Nov 17 '18 at 20:26
• I find TikZ very difficult to learn because the manual is very long and has a strange structure. In France, the manuals are exhaustive and methodically constructed. So when you talk about a subject, you explore it in depth. With TikZ, the documentation is scattered throughout the pages. For example, the notion of bounding box explained in several page 1032; 1033; 766; 173; 175; 562; but none of these pages really explain what it is or how it is calculated! You have to read page 969 to understand it. The TikZ manual is a real maquis, the tkz-euclide manual is much better built. – AndréC Nov 17 '18 at 20:47
• @AndréC Except that those who do not speak French are excluded from that. (And there are different opinions on how one may explain things in the most efficient way. The pgfmanual has a very basic tutorial and then it explains everything in greater depth. I guess the main problem is that most users think they can skip the intro, and then get lost. I am one of those who has tried that. ;-) – user121799 Nov 17 '18 at 20:51
• We're not skipping the introduction by chance, but because of lack of time! – AndréC Nov 17 '18 at 20:57