I have a searching problem like this:
"I have five lists of areas, namely list A, B, C, D and E. Each area has a radius and a center which occupies a round area in space. Let's place all areas in all lists on a 2-D map. Each overlaping region in a map is coded by the combination of names of the list of areas that creates the overlap (e.g., "ABCDE" or "ABDE"). How to find the overlapping regions with the the longest code? List them and their associated areas."
It seems like a 2-D version of this:
"Consider a big party where a log register for guest’s entry and exit times is maintained. Find the time at which there are maximum guests in the party. Note that entries in register are not in any order.
Example:
Input:
arrl[] = {1, 2, 9, 5, 5}
exit[] = {4, 5, 12, 9, 12}
First guest in array arrives at 1 and leaves at 4,
second guest arrives at 2 and leaves at 5, and so on.
"
And the answer is here: http://www.geeksforgeeks.org/find-the-point-where-maximum-intervals-overlap/
Anybody knows how to extend the answer to my original problem?
I can think of a brute force algorithm where I segment the whole map into many small squares and find the squares shadowed by the most areas. But it seems silly and time-consumming.
Thanks.
Related
I am new to R and I am trying to determine if a point is contained inside a polygon. I am using the R function, pip2d, to do it. I understand the basic principles of the function, but I am having trouble figuring out the appropriate order in which to put the vertices in my polygon matrix. Since I am going to iterate the function over a lot of data, I need to really understand this part so I don't encounter future problems.
1st try
This is what I did for my first try:
poly1 <- rbind(c(14,36), c(14,63), c(25,63), c(25,36))
points <- rbind(c(20,45), c(20,70), c(35,45), c(35,70))
pip2d(poly1, points)
With these coordinates, I was expecting the function to return this output: 1, -1, -1, -1, meaning that the point (20,45) was inside the borders of the polygon.
Instead, I got this : -1, -1, 1, -1 which didn't make any sense to me.
2nd try
I played around a bit with it and changed the order of the vertices, but kept the same polygon:
poly1 <- rbind(c(14,36), c(25,36), c(25,63), c(14,63))
points <- rbind(c(20,45), c(20,70), c(35,45), c(35,70))
pip2d(poly1, points)
This change gave me the expected output: 1, -1, -1, -1.
What's the difference between the order of the first try and the one of the second try?
Thank you
This is due to the convention used to define polygon interior or polygon exterior.
Although it's not clearly specified in pip2d documentation, reading the referenced articles suggests that the convention used here is the 'right hand rule'.
Follow the vertices sequence with the fingers of your right hand :
if your thumb is pointing at you (you're turning Counter Clock Wise), what is in your hand is the interior of the polygon
if your thumb is pointing in the opposite direction, what is in your hand is an hole not belonging to the polygon
I'm building an Arduino-based control system for a model railway turntable and I need to be able to rotate it clockwise or counterclockwise at will. I have 21 positions on the turntable, which I currently have numbered 0-20. I need to figure out how many "clicks" counterclockwise it will take to get to a given track number. How on earth can I go about finding this?
If there's a math-y way I can do it, that would be fantastic. I don't want to have an endless series of IF statements if I can avoid it.
Never mind. I found a very simple, elegant way.
Let's take my turntable for example. 21 positions, numbered 0-20.
If we are at track 0, and we have 20 tracks total, and we want to go to track 16 counterclockwise, we could do:
moves = 0 + ((20 + 1) - 16)
This yields 5, meaning if we move the turntable counterclockwise 5 tracks, we end up at track 16.
Simple, elegant, and extends to fit an infinite number of possible positions.
Background
This question is very similar to this question asked 3 years ago. Basically, I'm wanting to re-create a rudimentary first-person graphics engine as a learning experience.
So, say for example, that we're in a 3D space where z is representative of depth - x and y map to the x and y coordinates of the 2D space. If this coordinate system's origin is the camera, then a point at (0, 0, 1) would be located directly in front of the camera and a point at (0, 0, -1) would be located directly behind the camera.
Adding depth to this projection simply requires us to divide our x and y components by the depth (in this case, z). In practice, this makes sense to me and it appears to work.
Until...
...the depth becomes negative. If the depth is negative and you divide x and y by the depth, x and y's signs will change. We know that logically, however, this shouldn't be the case.
I've tried a few things so far :
Using the absolute value of depth - this wasn't ideal. Say there's a point (1, 1, 4) and (1, 1, -4). These points will then theoretically project onto the same location.
Trying to approximate negative values as decimals. So, if we have a negative depth, we try to map positive decimal number (between 0 and 1), allowing our x and y coordinates to stretch to infinity. The larger the negative number is, the closer to zero that the representative positive decimal is that we'd calculate. I feel like this might be a potential solution, but I'm still struggling a little bit with the concept.
So, how do you handle negative depths in your perspective projections?
I'm very new to graphics, so if I'm omitting any information that's needed to answer this question, feel free to ask. I wanted to keep this implementation agnostic since I feel like this question tends more towards the theoretical aspect of perspective projection.
EDIT
This video identifies the problem I'm trying to solve. It's a great video and is also what inspired me to start this little project - but I'm just wondering if there was a generally 'agreed-upon' way to handle this particular case.
You are doing a point projection, which means that your projected point in 2D is exactly the point where the line between 3D object and 3D camera would pass through the canvas. For positive depth, that intersection is between object and camera. For negative depth, the intersection is beyond the camera. But it's still the same line, hence swapping signs makes perfect sense.
Of course, actually drawing stuff with negative depth doesn't make that much sense, since usually you won't see things behind your camera. And if you do, then you have some extremely wide angle lense, so assuming the canvas as a plane in space is no longer accurate, and you'll have to switch to more complex projections to simulate fish-eye lenses and similar.
It might however be that you want to draw a triangle or other geometric primitive, and that just one of the corners has negative depth, while the others are positive. The usual approch in such scenarios is to clip the object to the frustrum, more particularly to intersect it with the near plane of the frustrum, thus getting rid of all points with negative depth. Usually your graphics pipeline can take care of this clipping.
I will try to provide a more math-y answer for anyone interested.
The mathemetical theory behind this is called projective geometry. You start with a three dimensional space and then split it into equivalence classes where two points a and b are equivalent if there is a factor f so that f*a == b. So for example (4, 4, 4) would be in the same class as (1, 1, 1) and (3, 6, 9) would be in the same class as (100, 200, 300). Geometrically speaking, you look at the set of straight lines through (0, 0, 0).
If you pick the point with z == 1 from every equivalence class you basically get a 2D space. This is exactly what "perspective projection" is. However, the equivalence classes for points like (1, 1, 0) do not have such a point. So what you actually get is a 2D space + some additional "points at infinity".
You can think of these points as a circle that goes around your coordinate system, but with an infinite radius. Also, opposite points are identical, so stuff that goes out on one end wraps around and comes back in on the opposite side. This means that straight lines are actually just circles that contain a point at infinity.
To make a concrete example. If you want to render a straight line from (1, 1, 4) to (1, 1, -4) you first normalize both of them to z == 1: (0.25, 0.25, 1) and (-0.25, -0.25, 1). But now when you draw the line between them, you need to go "the other way around", i.e. leave the screen in one direction and come back in at the opposite side. (You can skip the "come back in" part though because it is behind the camera.)
For implementation it is unfortunately not sufficient to map (1, 1, -4) to (inf, inf, 1) because that way there would be no way to know the slope of the line. You can either fake it by using a very large number instead of infinity or you can do it properly and handle these special cases throughout your code.
This isn't necessarily CUDA specific.
Basically, on the GPU I have a 1D array, but in the C code, I have a 3d array. I need to copy this array back and forth, and I need to be able to linear-ize the indices properly. That means that I have the pick the correct numbering scheme, as in is (1, 0, 0) linear-ized as 1, or is (0, 1, 0), or (0, 0, 1), in the form (x, y, z)?
The 3d arrays are declared as array[X][Y][Z]. When I copy that 3D array into an equal sized 1d array, how will the computer naturally number it? However the computer collapses down the 3d array, I need to do the exact same when I try to convert between the two. I hope I am making clear what I want to say, but if you have any questions, please ask. Thank you.
Arrays in C are kept in row-major order, see this for more details.
So the first element is array[0][0][0], the second is array[0][0][1], and etc.
I was wondering if there is a formula/trick to calculate what number is to the right or to the left on a standard 6-sided die if you know which number is on top and which is facing you.
Need it to solve a problem, but I don't feel like listing all 24 possibilities in an if-statement...:)
There aren't 24 possibilities.
From Wikipedia:
The sum of the numbers on opposite
faces is seven.
So as you already know two numbers, there are 4 possibilities left.
I'm not sure what you meant with "on the top" and "facing you", but I think you meant two neighbour faces here, so there are only 2 possibilities left as you know there opposite faces numbers, too (and those 2 possiblities only differ by the two numbers being left/right or right/left).
So, for example, using a unfolded dice, you've got "1" on the top, "2" facing you:
X
X1X
2
X
You now know that the opposite faces will be "6" (bottom) and "5" (facing away from you):
5
X1X
2
6
So there are these both possibilites:
5 5
314 413
2 2
6 6
There is only one possibility left when you know if your die is "left-handed" or "right-handed" (again, Wikipedia):
This constraint leaves one more
abstract design choice: the faces
representing 1, 2 and 3 respectively
can be placed in either clockwise or
counterclockwise order about this
vertex. If the 1, 2 and 3 faces run
counterclockwise around their common
vertex, the die is called
"right-handed"; if they run clockwise
it is called "left-handed". Standard
modern Western dice are right-handed,
whereas Chinese dice are often
left-handed
So, for the example above, the left one is a "left-handed" die, the right one is a "right-handed" die.
Opposite sides of a die always add up to 7 (at least, this is the convention).
By process of elimination you can tell what the "invisible" pair will be:
1/6
2/5
3/4
So, for every pair above, if you can see a number from it, remove it. The remaining pair is the one you are looking for.
Since there is no way to determine the "handedness" of the die, it is impossible to tell which of the pair will be to the right and which to the left.
I have no idea why this works, but:
For each pair (top/facing) there is of course only two possibilities, as both the top value and the facing value each eliminate itself and it's opposite from being left and or right: for e.g., If 1 is on the top, and a 2 is facing you, then the left and right must be either a 3 or a 4...
So for each combination, if the sum of the values is odd, and less than 7, or even and greater than 7, the lower of the two possible values is on the left and the higher is on the right.
.. and vice versa
As I am in America, I guess this rule is for a "right-handed" die, reverse it for a left-handed die.
Programattically you could do this quite easily. It is probably a little overkill (because you could use an if statement), you could also create a class such as
public class Dice {
private DiceFace[] sides = new DiceFace[]{DiceFace.ONE, DiceFace.TWO, DiceFace.THREE, DiceFace.FOUR, DiceFace.FIVE, DiceFace.SIX};
class DiceFace {
// set the face number and connecting faces...the below figures are wrong, I don't have a set of dice to check agains
static final DiceFace ONE = new DiceFace(1, 2, 3, 4, 5);
private int face;
private int northFace;
private int southFace;
private int eastFace;
private int westFace;
public DiceFace(int face, int northFace, int southFace, int eastFace, int westFace) {
// set the values
}
}
}
You could then write a method to give you the possible values for your answer by checking the dice and the values to the left and right of it.