# intersections package does not find second point of intersection of a circle and an ellipse

I want to find the intersection of two paths, a circle and an ellipse. Only one intersection is found. Why? Thanks.

Here is the MWE:

\documentclass[12pt]{article}
\usepackage[pdftex]{graphicx}
\usepackage{tikz}
\usepackage{pgfplots}
\usetikzlibrary{calc,3d,shapes, intersections}
\usepackage{xcolor}
\usepackage{tikz-3dplot}

\begin{document}
\begin{tikzpicture}
\coordinate (O) at (0,0);

\def\R{3cm}
\def\c1{(O) circle (\R)}
\fill[ball color=white!10, opacity=0.3, name path=c1] \c1;
\draw[rotate=42, name path=c3, yscale=0.5, color=red] \c1;
\path [name intersections={of=c1 and c3, by={c131, c132}}];
\node[] at (c131) {c131};
\node[] at (c132) {c132};
\end{tikzpicture}
\end{document}


Here the graph:

To expand a bit. It finds intersections in many cases but not in this. Here is my complete code so far:

\documentclass[12pt]{article}
\usepackage{pgfplots}
\usepackage{tikz}
\usetikzlibrary{calc,3d,shapes, pgfplots.external, intersections}

\begin{document}

\begin{tikzpicture}[]
\coordinate (O) at (0,0);

\def\R{3cm}

%outside sphere
\def\c1{(O) circle (\R)}
\fill[ball color=white!10, opacity=0.3, name path=c1] \c1;

%one lune side
\draw[rotate=96, name path=c2, yscale=0.5] \c1;
%the other lune side
\draw[rotate=42, name path=c3, yscale=0.5, color=red] \c1;

% find intersections of each lune side with outside circle
\path [name intersections={of=c1 and c2,
by={c121, c122}}];

% perhaps a bug in intersections but I need to reverse the sign of c123
\path [name intersections={of=c1 and c3,
by={c131, c132}}];

% find intersections between c2 and c3
\path [name intersections={of=c2 and c3,
by={c231, c232, c233, c234}}];

% Locate points (a preview) uncomment the following lines
% to better understand the figure
\node[] at (c121) {c121};
\node[] at (c122) {c122};
\node[] at (c131) {c131};
\node[] at (c132) {c132};
\node[] at (c231) {c231};
\node[] at (c232) {c232};
\node[] at (c233) {c233};
\node[] at (c234) {c234};

\path[name path=c4, yscale=0.25 , rotate=42] \c1;
\end{tikzpicture}

\end{document}


and here my figure:

Why does it find all the intersections in the other couple of ellipses and not in the points c131, c132?

• You can't say \def\c1{...} or, rather, you can't say this to mean what you want. The number is not allowed unless you change the cat codes or it is a single character command. – cfr Nov 17 '15 at 0:01
• @cfr : I will add more information to the question in a minute. – Herman Jaramillo Nov 17 '15 at 0:03
• There are an infinite number of intersections. You've only named the first two. I think. Remember that the calculations are not going to be very exact as this is TeX. Mathematically, there may be only 2. But that assumes precision. Depending on the details, I think you are or are not getting infinite numbers. The rotation is affecting the distinctness of the paths at the relevant places. This is just a guess. – cfr Nov 17 '15 at 0:19
• \def\c1 does not define a macro with the name c1 which is, I think, what you believe it is doing. It defines a macro \c which must always be followed by 1, which is entirely pointless. \newcommand* is much safer here anyway and should always be preferred in LaTeX. (Isn't always possible, of course. But it is here.) – cfr Nov 17 '15 at 0:25
• Right now, you are overwriting the definition of \c. This is not at all wise. It means that e.g. \c a will give an error. If you used \newcommand* you'd get some sort of error or warning. \def won't complain - it just redefines \c regardless of the fact that it is a basic, standard command. – cfr Nov 17 '15 at 0:29

The problem was that the intersection of two ellipses (one of them could be a circle) has 4 points (no two). For some reason three points are up and one is down (I expected two up and two down, but I do not care about this at this point). Here is the code:

\documentclass[12pt]{article}
\usepackage{pgfplots}
\usepackage{tikz}
\usetikzlibrary{calc,3d,shapes, pgfplots.external, intersections}

\begin{document}

\begin{tikzpicture}[]
\coordinate (O) at (0,0);

\def\R{3cm}

%outside sphere
\def\c1{(O) circle (\R)}
\fill[ball color=white!10, opacity=0.3, name path=c1] \c1;

%one lune side
\draw[rotate=96, name path=c2, yscale=0.5] \c1;
%the other lune side
\draw[rotate=42, name path=c3, yscale=0.5, color=red] \c1;

% find intersections of each lune side with outside circle
\path [name intersections={of=c1 and c2,
by={c121, c122}}];

% perhaps a bug in intersections but I need to reverse the sign of c123
\path [name intersections={of=c1 and c3,
by={c131, c132,c133,c134}}];

% find intersections between c2 and c3
\path [name intersections={of=c2 and c3,
by={c231, c232, c233, c234}}];

% Locate points (a preview) uncomment the following lines
% to better understand the figure
\node[] at (c121) {c121};
\node[] at (c122) {c122};
\node[] at (c131) {c131};
\node[] at (c132) {c132};
\node[] at (c133) {c133};
\node[] at (c134) {c134};
\node[] at (c231) {c231};
\node[] at (c232) {c232};
\node[] at (c233) {c233};
\node[] at (c234) {c234};

\path[name path=c4, yscale=0.25 , rotate=42] \c1;
\end{tikzpicture}

\end{document}


Here is the figure:

• The problem is that you are looking at two unstable intersections. If you enlarge the ellipse by a factor of 1.0000000001, the two intersections become four; if you shrink the ellipse by a factor of 0.999999999999, the two intersections become zero. In a situation like this, you should never rely on finite-precision computer calculations (such as those performed by TikZ) to get it right. – Charles Staats Dec 17 '15 at 4:25
• @CharlesStaats I agree with you. Unfortunately this type of intersections is quite common, specially for anything in the field of spherical geometry where you have to differentiate between what is in the front or what is in the back of a sphere. Yes, TikZ is not reliable for this level of precision, hence we should print labels to know what is what and then after that choose (by trial an error, which is not painful since the number of intersections is small) the one that works for the figure to look right. – Herman Jaramillo Dec 17 '15 at 19:14