current community

your communities

more stack exchange communities

company blog
Stack Exchange Inbox Reputation and Badges
tour help
TeX - LaTeX Stack Exchange is a question and answer site for users of TeX, LaTeX, ConTeXt, and related typesetting systems. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top
up vote 14 down vote favorite
1

The perpendicular line from point b using $(a)!(b)!(c)$ is different from $(c)!(b)!(a)$:

\documentclass[tikz,border=12pt]{standalone}

\usetikzlibrary{calc}

\begin{document}
    \begin{tikzpicture}
        \coordinate [label=above : $A$](a) at (0,10);
        \coordinate [label=above : $B$](b) at (12,9);
        \coordinate [label=below : $C$](c) at (10,4);
        \draw (a)--(b)--(c)--cycle;
        \draw [blue] (b) -- ($(c)!(b)!(a)$) coordinate[label=left:$E$] (e);
        \draw [red] (b) -- ($(a)!(b)!(c)$) coordinate[label=right:$F$] (f);
    \end{tikzpicture}
\end{document}

enter image description here

Shouldn't the lines be exactly the same?

share|improve this question
    
This is indeed strange. Especially since the same happens for projection of A onto the line BC, but not for C projected onto AB – JMP 21 hours ago
up vote 11 down vote accepted

Those inaccuracies are one of the reasons why Alain Matthes created the tkz-euclide package, which doesn't have the same problems. If you work with these kinds of geometric drawings a lot, it's definitely worth getting to know the package.

\documentclass[border=12pt]{standalone}

\usepackage{tkz-euclide}
\usetkzobj{all}

\begin{document}    
    \begin{tikzpicture}
        % Define points
        \tkzDefPoint(0,10){A}
        \tkzDefPoint(12,9){B}
        \tkzDefPoint(10,4){C}

        % Calculate projection, don't update bounding box
        \begin{pgfinterruptboundingbox}
            \tkzDefPointBy[projection=onto A--C](B) \tkzGetPoint{E}
            \tkzDefPointBy[projection=onto C--A](B) \tkzGetPoint{F}   
        \end{pgfinterruptboundingbox}

        % Draw objects
        \tkzDrawPolygon(A,B,C)
        \tkzDrawSegment[blue](B,E)
        \tkzDrawSegment[red](B,F)
        \tkzDrawPoints(A,B,C, E, F)

        % Labels
        \tkzLabelPoint[anchor=30](E){E}
        \tkzLabelPoint[below](F){F}
        \tkzLabelPoint[left](A){A}
        \tkzLabelPoint[above right](B){B}
        \tkzLabelPoint[below right](C){C}

    \end{tikzpicture}
\end{document}
share|improve this answer
up vote 4 down vote

run with xelatex:

\documentclass[border=12pt,pstricks]{standalone}
\usepackage{pst-eucl}
\begin{document}    
\begin{pspicture}(-1,3)(13,11)
  \pstTriangle[linewidth=1.5pt](0,10){A}(12,9){B}(10,4){C}
  \pstProjection{C}{A}{B}[F]
  \psline(B)(F)
  \pstRightAngle[linecolor=red,RightAngleType=german]{C}{F}{B}
\end{pspicture}
\end{document}

enter image description here

share|improve this answer
up vote 3 down vote

If you drew the same figure in Metapost, (defining the projection from two different directions in the same way as you did in TikZ), you would also find that the points are not identical. However the error is much smaller - typically less than 0.01 mm, which is usually too small to be noticed.

enter image description here

prologues := 3;
outputtemplate := "%j%c.eps";

beginfig(1);
u := 1cm;
pair A, B, C, E, F;
A = (0,10u);
B = (12u,9u);
C = (10u,4u);

% define F back-to-front...
E = whatever[A,C]; B-E = whatever * (A-C) rotated 90;
F = whatever[C,A]; B-F = whatever * (A-C) rotated 90;

show E, F, abs(E-F);

draw A--B--C--cycle;
draw B--E withcolor blue;
draw B--F withcolor red;

label.top("A", A);
label.top("B", B);
label.bot("C", C);
label.llft("E", E) withcolor red;
label.lrt ("F", F) withcolor blue;
endfig;
end.

With the default number system the show command produces this:

>> (262.62154,125.88998)
>> (262.6223,125.89125)
>> 0.00148

So E does not equal F but it's pretty close. The units are points 72 = 1in, so the distance is 0.00148 points, which is about 0.5 µm, which is pretty hard to see.

If you use -numbersystem=double you get:

>> (262.62152205882353,125.89158676470589)
>> (262.62152205882353,125.89158676470583)
>> 5.6843418860808015e-14

which is rather closer but still not exactly the same. But with -numbersystem=decimal you get:

>> (262.6215220588235294117647058823529,125.8915867647058823529411764705883)
>> (262.6215220588235294117647058823529,125.8915867647058823529411764705883)
>> 0

In all three cases the output looks exactly the same to me.

share|improve this answer
up vote 2 down vote

If there is no other bug is lying in some corner, that's typical TeX precision failing. The calc syntax actually rotates things around and gets the angles accordingly in a fashion that is not-so-relevant.

But because the trigonometry functions work with look up tables the inbetween behavior can lead the inaccuracies. For example for the C coordinate try the x-coord values 9.65,9.8,10, and 10.15 and you will see the pattern.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.