Should 1° be greater or less than 359°?

[Norseman]

Context:
I'm making a fairly simple 2D game with spaceships that build up velocity, with no artificial speed limits. This means they go very fast, so they tend to go off screen unless I zoom out a lot. When they go off screen, I want an arrow at the edge of the screen to point in their direction so that I still know how many ships there are and where to find them. The screen has four corners along its edge, and I need to know which edge to draw the arrow on. That's when the Fun began.

The problem:
Let's say we've got an Origin point and two destination points, the Edge point, and the Random point. Angle A, is the angle from the Origin point to the Edge point and angle B is the angle from the Origin Point to the Random Point. We want to know if angle A is greater than angle B.

In the example seen above, the angle between the Origin and Edge point is probably a little under 90°, and the angle between the Origin and Random point is probably around 100°. This is obviously quite easy to work out, since 100° > 90°. My problem starts when the Random Point is at 359°. It's very close to 1°, so, intuitively, we'd say that it's less than 90°. But the computer disagrees. 359° > 90°.

To fix this, I'm going to have to redefine how we determine if one angle is larger than another. To compare angle A to angle B, I need to determine if angle B is closer in a clockwise direction or in a counter-clockwise direction. If it's closer in a clockwise direction, then it's larger. If it's closer in a counter-clockwise direction, then it's smaller.

I'm not sure that I'm doing this right at all, and I also have another problem. Is 180° > 0°, or is it less than 0°? It's obviously not equal. Perhaps I need some third status?

Quick summary:

1. Is 359° > 1°?
2. Is 180° > 0°? If not, is 180° < 0°? If not, how should this be resolved?
3. Is there an easy way to find out where a line intersects with a rectangle if you know the line originates from the center of the rectangle and if you know the angle of the line?

 

[HallsofIvy]

None of those is true- you can't have an order relation on a circle. As far as finding where a line intersects a rectangle, you can write your line as y= mx where m = tangent of angle. The four sides of the rectangle are x= a, x= -a, y= b, y= -b. Determine the point of intersection of y= mx with each of those then check which are within the bounds of the rectangle. That is, -a< x< a, -b< y< b.

 

[Norseman]

I tried that approach already. The problem is that there are two valid intersections, as shown in the picture below.

So, I need to work out which intersection is the right one. To do that, I need to determine which of the four lines I should intersect with, which brings us back to my problem. I was trying to compare the angles to see where the line should intersect. However, since 359° > 1°, I ended up with some unexpected behavior.

 

[SpectraCat]

I tried that approach already. The problem is that there are two valid intersections, as shown in the picture below.

So, I need to work out which intersection is the right one. To do that, I need to determine which of the four lines I should intersect with, which brings us back to my problem. I was trying to compare the angles to see where the line should intersect. However, since 359° > 1°, I ended up with some unexpected behavior.

The way I have solved this problem when it has come up in my code is to compare the *signs* of the sine and cosine of the angle in question. That uniquely identifies the quadrant where the real intersection is, and once you have the quadrant, you know the proper way to compare angles (you probably don't even need to do that .. you can just use the sines and cosines).

 

[Norseman]

Looking at the signs of the sin and cos would only work if this were a square. Originally, I was using a similar approach that worked very well because I was using a square display surface. However, once I tried to go fullscreen with a hardware-supported resolution, everything got messed up, and I realized that I had just been coding everything in an extremely thoughtless way, since I wasn't really understanding how things were working, I was just pumping out code, messing around with it to make it do what I wanted, and then moving on as quickly as possible to motivate myself with new lots of small achievements. Now that the program is around 60 kb, I'm realizing that it's hard to do that and still figure out where bugs are coming from when my program doesn't do what I expect.

I want to try to refactor my code with a complete understanding of how things work, and simplify everything into pieces that I'll hopefully still be able to understand in the future.

 

[SpectraCat]

Looking at the signs of the sin and cos would only work if this were a square ...

Why should that be true .. the "quadrant" is defined using the origin and the angle .. if you have one point (with the origin), you should know what quadrant you are in from the sin and cos. Any line will only intersect your edge in two places .. all you need to know is which one is the "real intersection" ... knowing the quadrant tells you that.

 

[Norseman]

I've solved the problem of finding which line to use. If anyone Googles this later, here's the solution:

Get the coordinates for all of your corners.
Get the angles for all of your corners.
Start with the smallest angles, and work your way up. Assuming your x and y-axis are normal, then you do something like this (in Python):

top, bottom, left, right = False, False, False, False

if angle <= top_right_corner_angle:

right = True​

elif angle <= top_left_corner_angle:

top = True​

elif angle <= bottom_left_corner_angle:

left = True​

elif angle <= bottom_right_corner_angle:

bottom = True​

elif angle > bottom_left_corner_angle:

right = True​

if right:

#Do whatever​

elif top:

#Do whatever​

elif left:

#Do whatever​

elif bottom:

#Do whatever​

 

[Hurkyl]

For angular position restricted to a wedge, an ordering is quite reasonable -- because the wedge gives you the extra information to talk about separation.

On a line, for three points you can talk about one point being between the other two, and this gives the notion of order. For a circle, the best you can do is for four points you can talk about one pair separating the other two -- i.e. A,C and B,D separate each other if you can't get from A to C without passing through either B or D, and vice versa.



Anyways, that said, what you really want to do is almost surely to take whatever method you use to produce the floating-point number that measures angular position, and use the ordering of floating-point numbers to express the inequalities needed to determine which edge to draw the arrow on. (much like you did in the post you made while I was writing this)

That said, you can avoid the notion of angular position all-together. Draw the line through the NW and SE corners. What you really want to know is on what side of that line your object is on, which can be computed with a dot product. (and similarly for the line through the NE and SW corners)

 

[Norseman]

Why should that be true .. the "quadrant" is defined using the origin and the angle .. if you have one point (with the origin), you should know what quadrant you are in from the sin and cos. Any line will only intersect your edge in two places .. all you need to know is which one is the "real intersection" ... knowing the quadrant tells you that.

Ah, yes this is correct. I was thinking that using the signs of sin and cos would only give you precision to within 90°, and I thought there would be some edge cases where that wouldn't work with a rectangle. You can't use it to accurately determine which side of the four is the one that you want to intersect, but you can use it to determine which of two otherwise valid intersections is the real one.

That said, you can avoid the notion of angular position all-together. Draw the line through the NW and SE corners. What you really want to know is on what side of that line your object is on, which can be computed with a dot product. (and similarly for the line through the NE and SW corners)

Ah, yes, this is pretty simple. It's basically like SpectraCat's approach, but a little bit simpler. I've already written a function to determine if a point is above a line, which is fortunate, since I have no idea how to use dot products to do that.