I finally got my PGF upgraded to 3.0 and I am happy to see all the wonderful new features it has compared to my
old friend PGF 2.0!
I have played a little bit with the use of the intersections package where I now can determine intersections between
more general paths than, say, the circle and the line. Great!
During this work I have observed the following:
For two line segments which does not meet, but does meet when one or both segments are extended, the intersection algorithm always finds this intersection point (if the calculation does not overflow).
The intersection algorithm for a circle C and a line (segment) L sometimes extends the L to determine an
existing intersection point, but not always! And, I have example that the algorithm only finds one of two existing intersection points.
The intersection algorithm for an ellipse E and a line (segment) L never seems to extend the L to determine an
existing intersection point. This means that for an ellipse E with axes of equal length (i.e. chosen such that E == C)
may give different results for these equivalent E and C. Since an ellipse is a closed curve, I find this (i.e. not extending the L in the search for an intersection) a bit surprising and may be even unnecessary restrictive. (I understand that general paths cannot be extended for the search for intersections since a parabola for example has two infinite branches etc., but line segments could always be extended for this search.)
I welcome any comment.
Anybody?
Best regards,
Kent
Graphics, Figures & Tables ⇒ intersections in pgf - a comment
NEW: TikZ book now 40% off at Amazon.com for a short time.
And: Currently, Packt sells ebooks for $4.99 each if you buy 5 of their over 1000 ebooks. If you choose only a single one, $9.99. How about combining 3 LaTeX books with Python, gnuplot, mathplotlib, Matlab, ChatGPT or other AI books? Epub and PDF. Bundle (3 books, add more for higher discount): https://packt.link/MDH5p
-
Stefan Kottwitz
- Site Admin
- Posts: 10326
- Joined: Mon Mar 10, 2008 9:44 pm
intersections in pgf - a comment
Hi Kent,
that's a bit theoretical.
Do you still have the examples of your tests, to post here?
Stefan
that's a bit theoretical.
Do you still have the examples of your tests, to post here?Stefan
LaTeX.org admin
intersections in pgf - a comment
As wanted, I will illustrate some of the issues mentioned below by two examples.
Two concentric and non-intersecting circles C1 and C2 and a line segment L (defined by its endpoints)
are given such that L lies completely inside C1 and completely outside C2. (See the attached graphics files.)
We shall discuss the intersections (if any) between C1 and L (C1 x L case) and C2 and L (C2 x L case).
For the C1 x L case there is no (real) intersection points for sure. But, for the C2 x L case, we may
claim that there is no intersection points as well, but we can also say that there is two different
intersection points if we allow L to be extended in both directions to meet C2.
We have made a Latex file (see the attached file pgf20and30testcases.tex) where we can use either PGF 2.0 or
PGF 3.0 for generating the graphics files pgf20graphics.pdf and pgf30graphics.pdf, respectively attached below.
Now, we observe the following:
Case C1 x L:
Both versions of PGF seem to report two identical intersection points X == XX, which is incorrect.
Also, note that X (XX) does not even lie on C1! Here PGF 3.0 can be used with or without the use of
\usetikzlibrary{intersections}, but both these alternatives give the same result.
Case C2 x L:
PGF 2.0 reports two different intersection points X1 and X2 which we may say is correct.
Curiously, PGF 3.0 reports two intersection points X1 and X2 where X1 is correct, but X2 is incorrect
(given as X2 == X == XX).
Using the \path [name intersections …] construct of PGF 3.0, PGF reports no intersection points for both
the C1 x L case and the C2 x L case, which is correct if we don’t allow line segments to be extended in
the search for intersections.
In these cases, PGF 3.0 reports that neither intersection-1 nor intersection-2 exists when we try to access
these points and Latex halts. Fair enough. But, I thought the macro \t in \path [name intersections = {of = #1 and #4, total=\t}] would here give 0 and therefore could be used to avoid error messages when running the Latex code
after the intersections calculations.
I hope that my input is correct since these results are somewhat disturbing.
Kent
Two concentric and non-intersecting circles C1 and C2 and a line segment L (defined by its endpoints)
are given such that L lies completely inside C1 and completely outside C2. (See the attached graphics files.)
We shall discuss the intersections (if any) between C1 and L (C1 x L case) and C2 and L (C2 x L case).
For the C1 x L case there is no (real) intersection points for sure. But, for the C2 x L case, we may
claim that there is no intersection points as well, but we can also say that there is two different
intersection points if we allow L to be extended in both directions to meet C2.
We have made a Latex file (see the attached file pgf20and30testcases.tex) where we can use either PGF 2.0 or
PGF 3.0 for generating the graphics files pgf20graphics.pdf and pgf30graphics.pdf, respectively attached below.
Now, we observe the following:
Case C1 x L:
Both versions of PGF seem to report two identical intersection points X == XX, which is incorrect.
Also, note that X (XX) does not even lie on C1! Here PGF 3.0 can be used with or without the use of
\usetikzlibrary{intersections}, but both these alternatives give the same result.
Case C2 x L:
PGF 2.0 reports two different intersection points X1 and X2 which we may say is correct.
Curiously, PGF 3.0 reports two intersection points X1 and X2 where X1 is correct, but X2 is incorrect
(given as X2 == X == XX).
Using the \path [name intersections …] construct of PGF 3.0, PGF reports no intersection points for both
the C1 x L case and the C2 x L case, which is correct if we don’t allow line segments to be extended in
the search for intersections.
In these cases, PGF 3.0 reports that neither intersection-1 nor intersection-2 exists when we try to access
these points and Latex halts. Fair enough. But, I thought the macro \t in \path [name intersections = {of = #1 and #4, total=\t}] would here give 0 and therefore could be used to avoid error messages when running the Latex code
after the intersections calculations.
I hope that my input is correct since these results are somewhat disturbing.
Kent
- Attachments
-
- pgf20graphics.pdf
- (9.31 KiB) Downloaded 233 times
-
- pgf30graphics.pdf
- (24.73 KiB) Downloaded 210 times
-
- pgf20and30testcases.tex
- (7.39 KiB) Downloaded 213 times
intersections in pgf - a comment
I want to reiterate on the last point from my last posting on this issue:
In cases where PGF 3.0 reports that no intersections exists, it would be nice to use the macro \t in \path [name intersections = {of = path1 and path2, total=\t}] construct for the paths path1 and path2, i.e. using it to avoid that Latex (PGF) halts if \t is 0 if we access the coordinates of intersection-1 etc. later in the code.
I tried this, but could not get it to work. Any advice on this matter is appreciated.
And, I am still puzzled with the other issues I raised previously.
Kent
In cases where PGF 3.0 reports that no intersections exists, it would be nice to use the macro \t in \path [name intersections = {of = path1 and path2, total=\t}] construct for the paths path1 and path2, i.e. using it to avoid that Latex (PGF) halts if \t is 0 if we access the coordinates of intersection-1 etc. later in the code.
I tried this, but could not get it to work. Any advice on this matter is appreciated.
And, I am still puzzled with the other issues I raised previously.
Kent