Given an array, I would like to be able to define some relationship between its elements so that each element "points to" a given number of elements, such that no element should share more than one target element with any other given element of the array.
I'm pretty sure this can be done easily with some solution from graph theory, but I embarrassingly don't know any graph theory and therefore don't know what I'm looking for. The best I can say is that the graph describing the links between elements is regular and directed.
The XY: what I actually have/want is two-dimensional grid (I don't think the dimension is relevant to the math but is very helpful with the visualization), where each cell points to around 16 (flexible on this) other cells with a minimum of duplication. The grid is a texture so it's anywhere in the 256*256 to 4096*4096 size range, which hopefully doesn't make a significant difference to the algorithm.
Once visualized as a 2D texture, there is an obvious "intuitive" solution based on image masks, but it's totally informal and relies on the implementation details (using fewer targets for the purposes of illustration):
Using a regular pattern for the pointed-to cells is inappropriate:
The next cell along will share seven targets with the origin cell (red, x). Duplication is guaranteed.
An irregular "broken circle" style arrangement intuitively seems like it should work:
If no pair of cells in the group (pointed-to and origin) have an equal difference in position to any other pair of cells in the group, then any given movement of the origin on the grid seems like it shouldn't result in more than one pointed-to cell overlapping with any of those highlighted in the original position, and none of the pointed-to (blue) cells should point back to the origin (red, x) directly (it would be nice if they didn't loop back too quickly, either).
("wrapping around" at the edges of the texture is assumed)
But this is totally informal and intuitive. I don't have any proof of this and don't know how to go about proving it. Is there an algorithm known from graph theory that can produce such a result, without wishy-washy handwaving involving image masks? Not least because the intuitive solution, even assuming it works, doesn't provide any guarantees about whether the target cells will loop back to the origin quickly or not, and whether the entire grid (or most of it, I don't mind a few unused cells) forms a single connected graph, which is absolutely essential.
Alternatively, if the "broken circle" model actually works, how would one go about formalizing this back down to an abstract algorithm operating on a sequence (I guess it's effectively just an integer sequence), rather than relying on a mask image, which is totally getting confused by implementation details? (The fact that I want to apply this to a texture should be irrelevant)
The mathematical description of what you want to do is to build a (strongly?) connected high-girth Cayley graph on the group Z/w × Z/h (where w is the width of the texture and h is the height) such that no two vertices have more than one out-neighbor in common.
Practically speaking, each vertex (i.e., pixel) points to the pixels at a fixed list of offsets. If a vertex at (0, 0) (w.l.o.g. by the vertex-transitivity of Cayley graphs) and a vertex at (x, y) have two out-neighbors in common, then there exist offsets (dx1, dy1), (dx2, dy2), (dx3, dy3), (dx4, dy4) such that (dx1, dy1) = (x + dx2, y + dy2) and (dx3, dy3) = (x + dx4, y + dy4), and (dx1, dy1) ≠ (dx3, dy3) (equivalently, (dx2, dy2) ≠ (dx4, dy4)). This condition can be verified programmatically, and for random sets of offsets within a close distance, it doesn't take long to find a suitable set. Here's some Python to generate and test them.
from random import randrange
# random pattern of offsets within the square [-k, k] x [-k, k]
def pattern(k, n):
return [(randrange(-k, k + 1), randrange(-k, k + 1)) for i in range(n)]
def valid(pat):
s = set()
for (x1, y1) in pat:
for (x2, y2) in pat:
if ((x1, y1) != (x2, y2)):
(dx, dy) = (x2 - x1, y2 - y1)
if (dx, dy) in s:
return False
s.add((dx, dy))
return True
if __name__ == '__main__':
while True:
pat = pattern(10, 16)
if valid(pat):
break
print(pat)
This code does not verify strong connectivity. I would conjecture that strong connectivity is very likely to be satisfied by random offset sets. You might want to write more code to check for short cycles, which can be found by breadth-first search.
The code above gives a list of offsets like
[(3, -4), (-8, -9), (2, 7), (-9, 3), (-4, 7), (-2, -7), (-6, 3), (-7, -2), (9, -10), (8, -2), (-6, -3), (2, -8), (-6, 6), (-9, -7), (-7, 10), (3, 10)]
(no idea if that one's any good). To figure out which vertices (x, y) points to, iterate (dx, dy) through the list above and yield the neighbor ((x + dx) & (w - 1), (y + dy) & (h - 1)), assuming that w and h are powers of two and that we're two's complement.
Related
Assuming that the polygon does not self-intersect, what would be the most efficient way to do this? The polygon has N vertices.
I know that it can be calculated with the coordinates but is there another general way?
The signed area, A(T), of the triangle T = ((x1, y1), (x2, y2), (x3, y3)) is defined to be 1/2 times the determinant of the following matrix:
|x1 y1 1|
|x2 y2 1|
|x3 y3 1|
The determinant is -y1*x2 + x1*y2 + y1*x3 - y2*x3 - x1*y3 + x2*y3.
Given a polygon (convex or concave) defined by the vertices p[0], p[1], ..., p[N - 1], you can compute the area of the polygon as follows.
area = 0
for i in [0, N - 2]:
area += A((0, 0), p[i], p[i + 1])
area += A((0, 0), p[N - 1], p[0])
area = abs(area)
Using the expression for the determinant above, you can compute A((0, 0), p, q) efficiently as 0.5 * (-p.y*q.x + p.x*q.y). A further improvement is to do the multiplication by 0.5 only once:
area = 0
for i in [0, N - 2]:
area += -p[i].y * p[i+1].x + p[i].x * p[i+1].y
area += -p[N-1].y * p[0].x + p[N-1].x * p[0].y
area = 0.5 * abs(area)
This is a linear time algorithm, and it is trivial to parallelize. Note also that it is an exact algorithm when the coordinates of your vertices are all integer-valued.
Link to Wikipedia article on this algorithm
The best way to approach this problem that I can think of is to consider the polygon as several triangles, find their areas separately, and sum them for the total area. All polygons, regular, or irregular, are essentially just a bunch of triangle (cut a quadrilateral diagonally to make two triangles, a pentagon in two cuts from one corner to the two most opposite ones, and the pattern continues on). This is quite simple to put to code.
A general algorithm for this can be coded as follows:
function polygonArea(Xcoords, Ycoords) {
numPoints = len(Xcoords)
area = 0; // Accumulates area in the loop
j = numPoints-1; // The last vertex is the 'previous' one to the first
for (i=0; i<numPoints; i++)
{ area = area + (Xcoords[j]+Xcoords[i]) * (Ycoords[j]-Ycoords[i]);
j = i; //j is previous vertex to i
}
return area/2;
}
Xcoords and Ycoords are arrays, where Xcoords stores the X coordinates, and Ycoords the Y coordinates.
The algorithm iteratively constructs the triangles from previous vertices.
I modified this from the algorithm provided Here by Math Open Ref
It should be relatively painless to adapt this to whatever form you are storing your coordinates in, and whatever language you are using for your project.
The "Tear one ear at a time" algorithm works, provided the triangle you remove does not contain "holes" (other vertices of the polygon).
That is, you need to choose the green triangle below, not the red one:
However, it is always possible to do so (Can't prove it mathematically right now, but you'l have to trust me). You just need to walk the polygon's vertices and perform some inclusion tests until you find a suitable triple.
Source: I once implemented a triangulation of arbitrary, non-intersecting polygons based on what I read in Computational Geometry in C by Joseph O'Rourke.
Take 3 consecutive points from the polygon.
Calculate the area of the resulting triangle.
Remove the middle of the 3 points from the polygon.
Do a test to see if the removed point is inside the remaining polygon or not. If it's inside subtract the triangle area from the total, otherwise add it.
Repeat until the polygon consists of a single triangle, and add that triangle's area to the total.
Edit: to solve the problem given by #NicolasMiari simply make two passes, on the first pass only process the vertices that are inside the remainder polygon, on the second pass process the remainder.
Bresenham's algorithm is used to draw a line on a square grid as are pixels for example.
The algorithm is partly based on the subdivision of the plane into 8 parts called octants.
The trick is to use symmetries to generalize the algorithm regardless of where the second point is located: firstly we "move" it to the first octant, then the calculations are made, and finally the generated points are converted back to their original octant.
Wikipedia provides a basic function to perform the trick.
function switchToOctantZeroFrom(octant, x, y)
switch(octant)
case 1: return (x, y)
case 2: return (y, x)
case 3: return (y, -x)
case 4: return (-x, y)
case 5: return (-x, -y)
case 6: return (-y, -x)
case 7: return (-y, x)
case 8: return (x, -y)
Moreover, it is written that we just have to:
flip the co-ordinate system on the input and output
This is based on the fact that these transpositions are in fact involutions: f(f(x)) = x
Without paying much attention to it, I first thought it would work.
But for cases 3 and 7, it does not work because it is not an involution.
For example:
Case 4: (-5, 1) => (5, 1) => (-5, 1) // Good
Case 3: (-1, 5) => (5, 1) => (1, -5) // Not good
We have to do the trick once again:
Case 3: (-1, 5) => (5, 1) => (1, -5) => (-5, -1) => (-1, 5) // Good
So, did I misunderstand something?
Or is it in fact a lack of precision in the drafting of the article on Wikipedia and should someone improve it?
Is there not a better way to make these transitions without that I need to use two functions switchToOctant_onInput and switchToOctant_onOutput (the obvious solution to this problem that I see now)?
Octants 2, 4, 6, 8 are mapped to octant 1 by reflections which are involutive (self-inverse). Octant 5 is mapped to octant 1 by a 180 degree rotation which is also involutive. However, octants 7 and 3 are mapped to octant 1 by +-90 degree rotations which are not involutive. The mappings simply aren't involutive so there's nothing you can do about it. If you want an inverse function you have to write it.
The Wikipedia page is misleading because it says the function is a "flip" which suggests an involution.
There are three approaches I can think of to address the issue: 1) create an inverse function which is very similar except the cases for 3 and 7 are swapped (don't rename the existing function); 2) add cases for negative octants which represent the inverse function so that the inverse of switchOctant(3,x,y) is switchOctant(-3,x,y) which is the same as switchOctant(7,x,y) (however you have to think carefully about octant 0 if you do this); or 3) reduce or eliminate the need for the geometric transformation function by enhancing your line drawing function. In particular, if you enhance the line drawing function to handle any line in the first quadrant (not just first octant!) you can use a geometric transformation mapping any quadrant to the first quadrant which is involutive.
Update
I just thought of one more "angle" on this question (so to speak): it is possible to map your 3rd octant to 1st octant by a reflection. A reflection by a line through the origin with inclination theta is given by
x' = x * cos(2*theta) + y * sin(2*theta)
y' = x * sin(2*theta) - y * cos(2*theta)
The line of reflection between 1st and 3rd octants has inclination theta = 45 + 45/2.0 degrees, so 2*theta = 135 degrees and we have
x' = -sqrt(2)/2 * x + sqrt(2)/2 * y
y' = sqrt(2)/2 * x + sqrt(2)/2 * y
Similar formulas can be used to map the 7th octant to the 1st. So it is possible to find an involution which maps each octant to the first octant. However, there are two problems with this mapping: 1) it's not continuous whereas the mapping given in the Wikipedia article is continuous (meaning there are no sudden jumps in the image of (x,y) as the point moves around the plane); and 2) it's not clear how to use integer arithmetic to effect the mapping.
Continuity is not just a theoretical issue. It becomes practical when you consider how you're going to map a point on the boundary between two octants. If you don't do that very carefully with a discontinuous map, you will definitely get incorrect results.
So this idea is not good, but I just thought I'd mention it for the sake of completeness.
The octant discussion in the Bresenham algorithm is based on obvious axial symmetries with respect to the medians and diagonals. No involution property is required. (If you need the inverse of f, well, use... the inverse of f; but this is not explicitly required).
A simple variant is the digital version of the parametric equation of the line:
X = X0 + (k.(X1 - X0)) / D
Y = Y0 + (k.(Y1 - Y0)) / D
where
D = Max(|X1 - X0|, |Y1 - Y0|)
and k in range [0..D].
The problem is as it follows:
Given N (N <= 100,000) points by their Cartesian coordinates, test if every rectangle (with an area > 0) built using any two of them contains at least another point from that list either inside the rectangle or on his margin.
I know the algorithm for O(N^2) time complexity. I want to find the solution for O(N * logN). Memory is not a problem.
When I say two points define a rectangle, I mean that those two points are in two of its opposite corners. The sides of the rectangles are parallel to the Cartesian axes.
Here are two examples:
N = 4
Points:
1 1
3 5
2 4
8 8
INCORRECT: (the rectangle (1, 1) - (2, 4) doesn't have any point inside of it or on its margin).
N = 3
Points:
10 9
13 9
10 8
CORRECT.
Sort the points in order of the max of their coordinate pairs, from lowest to highest (O(n*log(n))). Starting with the lower-left point (lowest max coordinate), if the next point in the ordering does not share either the original point's x-value or its y-value (e.g. (1,2) and (5,2) share a y-coordinate of 2, but (1,2) and (2, 1) have neither coordinate in common), the set of points fails the test. Otherwise, move to the next point. If you reach the final point in this way (O(n)), the set is valid. The algorithm overall is O(n*log(n)).
Explanation
Two points that share a coordinate value lie along a line parallel to one of the axes, so there is no rectangle drawn between them (since such a rectangle would have area=0).
For a given point p1, if the next "bigger" point in the ordering, p2, is directly vertical or horizontal from p1 (i.e. it shares a coordinate value), then all points to the upper-right of p2 form rectangles with p1 that include p2, so there are no rectangles in the set that have p1 as the lower-left corner and lack an internal point.
If, however, the next-bigger point is diagonal from p2, then the p1 <-> p2 rectangle has no points from the set inside it, so the set is invalid.
For every point P = (a, b) in the set, search the nearest points of the form Y = (x, b) and X = (a, y) such that x > a and y > b.
Then, find if the rectangle defined by the two points X, Y contains any* internal point R besides P, X and Y. If that is the case, it's easy to see that the rectangle P, R does not contain any other point in the set.
If no point in the set exists matching the restrictions for X or Y, then you have to use (a, ∞) or (∞, b) respectively instead.
The computational cost of the algorithm is O(NlogN):
Looking for X or Y can be done using binary search [O(logN)] over a presorted list [O(NlogN)].
Looking for R can be done using some spatial tree structure as a quadtree or a k-d tree [O(logN)].
*) If X, Y contains more than one internal point, R should be selected as the nearest to P.
Update: the algorithm above works for rectangles defined by its botton-left and upper-right corners. In order to make it work also for rectangles defined by its botton-right and upper-left corners, a new point X' (such that it is the nearest one to P of the form X' = (a, y') where y' < b) and the corresponding rectangle defined by X', Y should also be considered for every point in the set.
So, I have this algorithm to calculate cross-section of 3D shape with plane given with normal vector.
However, my current problem is, that the cross-section is set of 3D points (all lying on that given plane) and to display it I need to map this coordinates to XY plane.
This works perfect if the plane normal is something like (0,0,c) - I just copy x and y coordinates discarding z.
And here is my question: Since I have no idea how to convert any other plain could anybody give me any hint as to what should I do now?
Your pane is defined by a normal vector
n=(xn,yn,zn)
For coordination transformation we need 2 base vectors and a zero point for the pane
Base vectors
We chose those "naturally" fitting to the x/y pane (see later for edge case):
b1=(1,0,zb1)
b2=(0,1,zb2)
And we want
b1 x b2 = n*c (c const scalar)
to make sure these two are really bases
Now solve this:
b1 x b2= (0*zb2-zb1*1,zb1*0-1*zb2,1*1-0*0) = (zb1,zb2,1)
zb1*c=xn
zb2*c=yn
1*c=zn
c=zn,
zb2=yn/c=yn/zn
zb1=xn/c=xn/zn
b1=(1,0,yn/zn)
b2=(0,1,xn/zn)
and normalize it
bv1=(1,0,yn/zn)*sqrt(1+(yn/zn*yn/zn))
bv2=(0,1,yn/zn)*sqrt(1+(xn/zn*xn/zn))
An edge case is, when zn=0: In this case the normal vector is parallel to the x/y pane and no natural base vectors exist, ind this case you have to chose base b1 and b2 vectors by an esthetic POV and go through the same solution process or just chose bv1 and bv2.
Zero point
you spoke of no anchor point for your pane in the OQ, but it is necessary to differentiate your pane from the infinite family of parallel panes.
If your anchor point is (0,0,0) this is a perfect anchor point for the coordinate transformation and your pane has
x*xn+y*yn+z*zn=0,
(y0,y0,z0)=(0,0,0)
If not, I assume you have an anchor point of (xa,ya,za) and your pane has
x*xn+y*yn+z*zn=d
with d const scalar. A natural fit would be the point of the pane, that is defined by normal projection of the original zero point onto the pane:
P0=(x0,y0,z0)
with
(x0, y0, z0) = c * (xn,yn,zn)
Solving this against
x*xn+y*yn+z*zn=d
gives
c*xn*xn+c*yn*yn+c*zn*zn=d
and
c=d/(xn*xn+yn*yn+zn*zn)
thus
P0=(x0,y0,z0)=c*(xn,yn,zn)
is found.
Final transformation
is achieved by representing every point of your pane (i.e. those points you want to show) as
P0+x'*bv1+y'*bv2
with x' and y' being the new coordinates. Since we know P0, bv1 and bv2 this is quite trivial. If we are not on the edge case, we have zeroes in bv1.y and bv2.x further reducing the problem.
x' and y' are the new coordinates you want.
I would like to add to Eugen's answer, a suggestion for the case where zn=0 extending his answer and also offer an alternative solution (which is similar).
In the case of zn=0, you can actually think of all the planes as points in a circle around the z-axis and the radius depends on the parameters of the plane.
Any vector orthogonal to the radius should be parallel to the plane, while the radius being the normal of the plane.
So in some way, the problem is reduced to a 2D-space.
The normal to the plane is (xn, yn, 0).
By using a technique to find orthogonal vectors in 2D, we get that a base vector could therefore be (-yn, xn, 0).
The second base vector is (0, 0, 1) which is just the normalized vector of their cross product. We can see that by developing the following expression:
corss_product((-yn, xn, 0), (xn, yn, 0)) =
(xn*0 - 0*yn, 0*xn - (-yn)*0, (-b)*b - a*a) =
(0, 0, -(xn^2 + yn^2)).
Which after normalizing and negating becomes (0, 0, 1).
From here, I suggest b1=normalize(-yn, xn, 0) and b2=(0, 0, 1).
Now, there's an even more general solution using this approach.
If you'll develop the dot product of (-yn, xn, 0) and (xn, yn, zn), you'll see that they are orthogonal for any zn while (-yn, xn, 0) also being part of the plane in question (when d=0). Thus, this actually works as long at least one of xn and yn is not zero (because otherwise (-yn, xn, 0) is actually just (0, 0, 0)).
Just to make sure it's clear, the second base vector is again their cross product, that is: b1=(-yn, xn, 0) and b2=cross_product(b1, n).
Well then, what about the case where both xn and yn are zero? In this case the plane is parallel to the xy plane. Now that's an easy one, just choose b1=(1, 0, 0) and b2=(0, 1, 0).
And as the other approach, use an anchor vector when d is not 0, exactly as it is described there, no changes needed.
Summary: 2 different solutions:
Use Eugen's answer answer and for the case of zn=0, take: b1=(-yn, xn, 0) and b2=(0, 0, 1).
A different approach: If both xn and yn equal 0, take b1=(1, 0, 0) and b2=(0, 1, 0), otherwise take b1=(-yn, xn, 0) and b2=cross_product(b1, n).
In both solutions, use an anchor vector P0 as described by the aforementioned answer.
Actually this is a classic problem as SO user Victor put it (in another SO question regarding which tasks to ask during an interview).
I couldn't do it in an hour (sigh) so what is the algorithm that calculates the number of integer points within a triangle?
EDIT: Assume that the vertices are at integer coordinates. (otherwise it becomes a problem of finding all points within the triangle and then subtracting all the floating points to be left with only the integer points; a less elegant problem).
Assuming the vertices are at integer coordinates, you can get the answer by constructing a rectangle around the triangle as explained in Kyle Schultz's An Investigation of Pick's Theorem.
For a j x k rectangle, the number of interior points is
I = (j – 1)(k – 1).
For the 5 x 3 rectangle below, there are 8 interior points.
(source: uga.edu)
For triangles with a vertical leg (j) and a horizontal leg (k) the number of interior points is given by
I = ((j – 1)(k – 1) - h) / 2
where h is the number of points interior to the rectangle that are coincident to the hypotenuse of the triangles (not the length).
(source: uga.edu)
For triangles with a vertical side or a horizontal side, the number of interior points (I) is given by
(source: uga.edu)
where j, k, h1, h2, and b are marked in the following diagram
(source: uga.edu)
Finally, the case of triangles with no vertical or horizontal sides can be split into two sub-cases, one where the area surrounding the triangle forms three triangles, and one where the surrounding area forms three triangles and a rectangle (see the diagrams below).
The number of interior points (I) in the first sub-case is given by
(source: uga.edu)
where all the variables are marked in the following diagram
(source: uga.edu)
The number of interior points (I) in the second sub-case is given by
(source: uga.edu)
where all the variables are marked in the following diagram
(source: uga.edu)
Pick's theorem (http://en.wikipedia.org/wiki/Pick%27s_theorem) states that the surface of a simple polygon placed on integer points is given by:
A = i + b/2 - 1
Here A is the surface of the triangle, i is the number of interior points and b is the number of boundary points. The number of boundary points b can be calculated easily by summing the greatest common divisor of the slopes of each line:
b = gcd(abs(p0x - p1x), abs(p0y - p1y))
+ gcd(abs(p1x - p2x), abs(p1y - p2y))
+ gcd(abs(p2x - p0x), abs(p2y - p0y))
The surface can also be calculated. For a formula which calculates the surface see https://stackoverflow.com/a/14382692/2491535 . Combining these known values i can be calculated by:
i = A + 1 - b/2
My knee-jerk reaction would be to brute-force it:
Find the maximum and minimum extent of the triangle in the x and y directions.
Loop over all combinations of integer points within those extents.
For each set of points, use one of the standard tests (Same side or Barycentric techniques, for example) to see if the point lies within the triangle. Since this sort of computation is a component of algorithms for detecting intersections between rays/line segments and triangles, you can also check this link for more info.
This is called the "Point in the Triangle" test.
Here is an article with several solutions to this problem: Point in the Triangle Test.
A common way to check if a point is in a triangle is to find the vectors connecting the point to each of the triangle's three vertices and sum the angles between those vectors. If the sum of the angles is 2*pi (360-degrees) then the point is inside the triangle, otherwise it is not.
Ok I will propose one algorithm, it won't be brilliant, but it will work.
First, we will need a point in triangle test. I propose to use the "Barycentric Technique" as explained in this excellent post:
http://www.blackpawn.com/texts/pointinpoly/default.html
Now to the algorithm:
let (x1,y1) (x2,y2) (x3,y3) be the triangle vertices
let ymin = floor(min(y1,y2,y3)) ymax = ceiling(max(y1,y2,y3)) xmin = floor(min(x1,x2,x3)) ymax = ceiling(max(x1,x2,3))
iterating from xmin to xmax and ymin to ymax you can enumerate all the integer points in the rectangular region that contains the triangle
using the point in triangle test you can test for each point in the enumeration to see if it's on the triangle.
It's simple, I think it can be programmed in less than half hour.
I only have half an answer for a non-brute-force method. If the vertices were integer, you could reduce it to figuring out how to find how many integer points the edges intersect. With that number and the area of the triangle (Heron's formula), you can use Pick's theorem to find the number of interior integer points.
Edit: for the other half, finding the integer points that intersect the edge, I suspect that it's the greatest common denominator between the x and y difference between the points minus one, or if the distance minus one if one of the x or y differences is zero.
Here's another method, not necessarily the best, but sure to impress any interviewer.
First, call the point with the lowest X co-ord 'L', the point with the highest X co-ord 'R', and the remaining point 'M' (Left, Right, and Middle).
Then, set up two instances of Bresenham's line algorithm. Parameterize one instance to draw from L to R, and the second to draw from L to M. Run the algorithms simultaneously for X = X[L] to X[M]. But instead of drawing any lines or turning on any pixels, count the pixels between the lines.
After stepping from X[L] to X[M], change the parameters of the second Bresenham to draw from M to R, then continue to run the algorithms simultaneously for X = X[M] to X[R].
This is very similar to the solution proposed by Erwin Smout 7 hours ago, but using Bresenham instead of a line-slope formula.
I think that in order to count the columns of pixels, you will need to determine whether M lies above or below the line LR, and of course special cases will arise when two points have the same X or Y co-ordinate. But by the time this comes up, your interviewer will be suitably awed and you can move on to the next question.
Quick n'dirty pseudocode:
-- Declare triangle
p1 2DPoint = (x1, y1);
p2 2DPoint = (x2, y2);
p3 2DPoint = (x3, y3);
triangle [2DPoint] := [p1, p2, p3];
-- Bounding box
xmin float = min(triangle[][0]);
xmax float = max(triangle[][0]);
ymin float = min(triangle[][1]);
ymax float = max(triangle[][1]);
result [[float]];
-- Points in bounding box might be inside the triangle
for x in xmin .. xmax {
for y in ymin .. ymax {
if a line starting in (x, y) and going in any direction crosses one, and only one, of the lines between the points in the triangle, or hits exactly one of the corners of the triangle {
result[result.count] = (x, y);
}
}
}
I have this idea -
Let A(x1, y1), B(x2, y2) and C(x3, y3) be the vertices of the triangle. Let 'count' be the number of integer points forming the triangle.
If we need the points on the triangle edges then using Euclidean Distance formula http://en.wikipedia.org/wiki/Euclidean_distance, the length of all three sides can be ascertained.
The sum of length of all three sides - 3, would give that count.
To find the number of points inside the triangle we need to use a triangle fill algorithm and instead of doing the actual rendering i.e. executing drawpixel(x,y), just go through the loops and keep updating the count as we loop though.
A triangle fill algorithm from
Fundamentals of Computer Graphics by
Peter Shirley,Michael Ashikhmin
should help. Its referred here http://www.gidforums.com/t-20838.html
cheers
I'd go like this :
Take the uppermost point of the triangle (the one with the highest Y coordinate). There are two "slopes" starting at that point. It's not the general solution, but for easy visualisation, think of one of both "going to the left" (decreasing x coordinates) and the other one "going to the right".
From those two slopes and any given Y coordinate less than the highest point, you should be able to compute the number of integer points that appear within the bounds set by the slopes. Iterating over decreasing Y coordinates, add all those number of points together.
Stop when your decreasing Y coordinates reach the second-highest point of the triangle.
You have now counted all points "above the second-highest point", and you are now left with the problem of "counting all the points within some (much smaller !!!) triangle, of which you know that its upper side parallels the X-axis.
Repeat the same procedure, but now with taking the "leftmost point" instead of the "uppermost", and with proceedding "by increasing x", instead of by "decreasing y".
After that, you are left with the problem of counting all the integer points within a, once again much smaller, triangle, of which you know that its upper side parallels the X-axis, and its left side parallels the Y-axis.
Keep repeating (recurring), until you count no points in the triangle you're left with.
(Have I now made your homework for you ?)
(wierd) pseudo-code for a bit-better-than-brute-force (it should have O(n))
i hope you understand what i mean
n=0
p1,p2,p3 = order points by xcoordinate(p1,p2,p3)
for int i between p1.x and p2.x do
a = (intersection point of the line p1-p2 and the line with x==i).y
b = (intersection point of the line p1-p3 and the line with x==i).y
n += number of integers between floats (a, b)
end
for i between p2.x+1 and p3.x do
a = (intersection point of the line p2-p3 and the line with x==i).y
b = (intersection point of the line p1-p3 and the line with x==i).y
n += number of integers between floats (a, b)
end
this algorithm is rather easy to extend for vertices of type float (only needs some round at the "for i.." part, with a special case for p2.x being integer (there, rounded down=rounded up))
and there are some opportunities for optimization in a real implementation
Here is a Python implementation of #Prabhala's solution:
from collections import namedtuple
from fractions import gcd
def get_points(vertices):
Point = namedtuple('Point', 'x,y')
vertices = [Point(x, y) for x, y in vertices]
a, b, c = vertices
triangle_area = abs((a.x - b.x) * (a.y + b.y) + (b.x - c.x) * (b.y + c.y) + (c.x - a.x) * (c.y + a.y))
triangle_area /= 2
triangle_area += 1
interior = abs(gcd(a.x - b.x, a.y - b.y)) + abs(gcd(b.x - c.x, b.y - c.y)) + abs(gcd(c.x - a.x, c.y - a.y))
interior /= 2
return triangle_area - interior
Usage:
print(get_points([(-1, -1), (1, 0), (0, 1)])) # 1
print(get_points([[2, 3], [6, 9], [10, 160]])) # 289
I found a quite useful link which clearly explains the solution to this problem. I am weak in coordinate geometry so I used this solution and coded it in Java which works (at least for the test cases I tried..)
Link
public int points(int[][] vertices){
int interiorPoints = 0;
double triangleArea = 0;
int x1 = vertices[0][0], x2 = vertices[1][0], x3 = vertices[2][0];
int y1 = vertices[0][1], y2 = vertices[1][1], y3 = vertices[2][1];
triangleArea = Math.abs(((x1-x2)*(y1+y2))
+ ((x2-x3)*(y2+y3))
+ ((x3-x1)*(y3+y1)));
triangleArea /=2;
triangleArea++;
interiorPoints = Math.abs(gcd(x1-x2,y1-y2))
+ Math.abs(gcd(x2-x3, y2-y3))
+ Math.abs(gcd(x3-x1, y3-y1));
interiorPoints /=2;
return (int)(triangleArea - interiorPoints);
}