...

Given this problem description, I would think in terms of avoiding
calculating angles at all. Can't you turn this into a comparison of
tans, rather than of angles? Within the primary quadrant, the tan is a
monotonic increasing function of the angle, or monotonic decreasing
function of your Angle.

Note also that the dot product of two unit vectors gives a cheap
representation of the angle between them. If you only need to compare,
you can skip last step.
http://members.tripod.com/~Paul_Kirby/vector/Vdotproduct.html#findangle

Patricia

None of that requires computing angles. You can represent a scan arc
with a pair of intersecting lines. To determine if a point is within the
arc, ask on which side of each line the point lies. Your scan arc is
then the intersection of two half planes. To find the closest, you can
skip the sqrt and just compare the squares of distances. You might find
a book on computational geometry helpful.

Mark Thornton

    An important technique for problems of this general flavor
is to recognize that the information developed during one scan
may be helpful in speeding up subsequent scans.  For example,
if your Robots are not moving at high speed, the result of two
consecutive scans by the same Robot in the same arc are likely
to be identical: If Fred and Ginger are close at time t0, they
are probably also close at time t0+0.1 second.  Similarly, if
Fred is close to Ginger at 30 degrees, then at the same time
Ginger is close to Fred at 210 degrees.

    How might you exploit this sort of knowledge?  Depends on how
your application is organized, of course.  Maybe each Robot could
keep a record of the closest neighbor as of the last time each
arc was scanned, and begin a new scan by asking "Is that neighbor
still in the scan arc, and is there any closer neighbor (in any
direction at all)?"  If the answers are Yes and No, then that
neighbor is still the closest in the chosen direction and you
needn't bother figuring out the angles of the others.

    You'd need to measure, and to realize that the measurement
might come out differently on different machines.  Comparing
squared distances is likely to be faster than comparing distances.
Noticing that the distance from Robot r1 to r2 is the same as the
distance from r2 to r1 has the potential to cut the work in half.

    The big wins will probably come from finding ways to avoid
the O(N^2) search.  Exploiting spatial and temporal continuity
("The situation doesn't change much over a short time interval")
may be a way to do this; you're betting that a quick search will
suffice most of the time, with a full-scale rummaging needed only
every now and then.

    You may even be able to forecast the time at which the situation
will change.  For example, if you know something about the motions
of the Robots you may be able to solve an equation and say "The
angle from r0 to r1 will remain in its current arc until time t"
and thus completely avoid any angle calculations until that time.
Even if the Robots occasionally maneuver and change course, forcing
you to discard the predictions already made, it may turn out that
they save enough work to justify making them.

...

Here's a different approach.

Your problem would be much easier if the scanning robot were at the
origin, with the right hand edge of its scan arc lying along the X axis.

Fortunately, any combination of rotation, translation, and stretching
can be applied a series of points by calculating one transformation
matrix, and multiplying each point's coordinates by it.

So, calculate a transformation matrix that puts the scanning robot at
the origin, with the right hand edge of the scan arc along the X axis.

Also you will need the slope of the left hand edge of the scan arc in
the same coordinate system, the tan of the scan angle. Call that m.
Since it is a property of the scanner, you can cache it.

Calculating these values involves trig, but it is only done once for
each scan request, and I think it is all simple forwards operations that
you already have cached.

For each other robot R:

1. Do any filtering to ignore robots that have no chance of being visible.

2. Multiply R's coordinates by the transformation matrix, getting xR and
yR, its coordinates in the scanner-centric coordinate system.

3. Robot R is visible to the scanning robot if, and only if:

xR >= 0 && yR >= 0 && m*xR >= yR

[The last test checks whether the left hand edge of the scan arc has a
greater y value than R at R's x coordinate]

4. If R is visible, calculate xR*xR + yR*yR. If R is the first robot to
pass the visibility test during this scan, or if the squared distance is
less than the best previous, record R and its squared distance as the
closest so far.

[Adjust the treatment of equality in the comparisons according to your
rules]

The work that is done for every robot for every scan contains only
multiplications, additions, and comparisons, the fastest floating point
operations. No atan2. No square root. Not even a divide.

Patricia

Ok I woke up and I still think I made sense...  lets consider the
geometry of the matter, and do it in another way.

Consider the case of two robots in the arena... R1 and R2.
R1 wants to know if R2 is in his scanning arc...
First R1 needs to know what dirrection he is facing, he may keep this
information in an angle like you are currently intent on doing or keep
this information in a dirrection vector (which would simply future
calculations and remove your bottle neck)...  f you restrict yoursef to
using vectors then a vector solution will do.

So you need an accuracy of 1/256th of a circle... instead of
precomputing the trig functions why not precompute a table of
normalized direction vectors?
Please bear with me if I go slowly but by slow I hope to be clear.

Calculating your table of normalized direction vectors...
you know that sin(a) = y/r  and that cos(a) = x/r
Since the lenth of the vector is to be of unit length (normalized) we
know that r = 1 thus, each vector is defined by:
y = sin(a),
x = cos(a)
where a in your case is the sequence of numbers from 0 - 2pi in 2pi/256
(in radians of course) increments best to precompute these values and
store them as an array of static final floats, i would just make even
the y component and x the cos component.

So now you have a nice table of direction vectors... the robot would
then keep an int that would index into this table
(direction_vector_int). The range of the variable is between 0 and 256
(to find the index in the precomputed direction vectors you would of
course multiply by 2 since the x and y components are side be side)...

Now to find if R2 is in R1 scanner....
The scanner has an angle too,  the angle that is may sweep within...
Since the rotation of the robots in your world is restriced to  changes
of 1/256 deg why not represent the angle as an int which represents x
number of 1/256 deg increments?

Say: scan_angle_ int = getScanAngleInt(int degrees);  //same for all
robots right?
public int getScanAngleInt(int degrees){
   return degrees * 256.0f / 360.0f
}

Now why do this? Well the scan_angle_int is the whole angle of the
scanner sweep, you know the direction vector already, well if you
divide the scan angle by two you know that half has to be on either
side of the dirrection vector of the robot, right?  So half of the
scan_angle_int added or subtracted from the direction_vector _int of
the robot will give you two new vectors, these vectors are the lines
that define the range of the scanner (you dont need to keep track of
these just the direction_vector_int which will remain constant over the
duration of your program, actually as you'll see this is just an
intermediary value you will not even need to keep).

Next we need to see if the direction vector between R1 and R2 falls
between the range of the scanner... simply normalize the direction
vector between R1 and R2...

now consider this on paper so it is crystal clear:
you have your robot at the center of a circle, the radius of the circle
is 1 unit, from the robot to the diameter extends a direction vector.
Half of the scanner angle to the left is the left scanner vector bound,
half the scanner angle to the right is the right scanner angle bound
(and we know how to find these already).
Some where else there is a direction vector to another robot...
Consider now the x,y values of the direction vector, and the x,y values
of one of the sweep vector bounds... you can see that if you construct
a circle centered on the terminating position of the direction vector
with a radius extending out to the scanner bounding vectors that the
direction vector to the other robot must be inside this circle, right?

So, then find the distance between the Scanner Direction vector (the
way the robot is facing) and the bounding vectors, this is the radius
of that circle (we will call this radius the scan_radius, and it will
be constant for the duration of your program for this robot), next find
the distance from the Scanner Direction vector and the direction vector
to the other robot, if it is less than or equal to the  scan_radius
then it is in the scanner sweep.

In summary, setting up your program as discribed will require you to
keep:
- the current heading of the robot (scanner_direction_vector)
- and to find a normalized direction vector to each other robot
(direction_vector)
- the scan_radius (a magic number that will tell you if the distance
between the scanner_direction_vector and the direction_vector places
the robot in the line of sight.

I agree with Mark that it is unneeded...

Ok I woke up and I still think I made sense...  lets consider the
geometry of the matter.

Consider the case of two robots in the arena... R1 and R2.
R1 wants to know if R2 is in his scanning arc...
First R1 needs to know what direction he is facing, he may keep this
information in an angle like you are currently intent on doing or keep
this information in a direction vector (which would simply future
calculations and remove your bottle neck)...  f you restrict yourself
to using vectors then a vector solution will do.

So you need an accuracy of 1/256th of a circle... instead of
precomputing the trig functions why not precompute a table of
normalized direction vectors?
Please bear with me if I go slowly but by slow I hope to be clear.

Calculating your table of normalized direction vectors...
you know that sin(a) = y/r  and that cos(a) = x/r
Since the length of the vector is to be of unit length (normalized) we
know that r = 1 thus, each vector is defined by:
y = sin(a),
x = cos(a)
where a in your case is the sequence of numbers from 0 - 2pi in 2pi/256
(in radians of course) increments best to precompute these values and
store them as an array of static final floats, i would just make even
the y component and x the cos component.

So now you have a nice table of direction vectors... the robot would
then keep an int that would index into this table
(direction_vector_int). The range of the variable is between 0 and 256
(to find the index in the precomputed direction vectors you would of
course multiply by 2 since the x and y components are side be side)...

Now to find if R2 is in R1 scanner....
The scanner has an angle too,  the angle that is may sweep within...
Since the rotation of the robots in your world is restricted to
changes of 1/256 deg why not represent the angle as an int which
represents x number of 1/256 deg increments?

Say: scan_angle_ int = getScanAngleInt(int degrees);  //same for all
robots right?
public int getScanAngleInt(int degrees){
   return degrees * 256.0f / 360.0f
}

Now why do this? Well the scan_angle_int is the whole angle of the
scanner sweep, you know the direction vector already, well if you
divide the scan angle by two you know that half has to be on either
side of the direction vector of the robot, right?  So half of the
scan_angle_int added or subtracted from the direction_vector _int of
the robot will give you two new vectors, these vectors are the lines
that define the range of the scanner (you don't need to keep track of
these just the direction_vector_int which will remain constant over the
duration of your program, actually as you'll see this is just an
intermediary value you will not even need to keep).

Next we need to see if the direction vector between R1 and R2 falls
between the range of the scanner... simply normalize the direction
vector between R1 and R2...

now consider this on paper so it is crystal clear:
you have your robot at the center of a circle, the radius of the circle
is 1 unit, from the robot to the diameter extends a direction vector.
Half of the scanner angle to the left is the left scanner vector bound,
half the scanner angle to the right is the right scanner angle bound
(and we know how to find these already).
Some where else there is a direction vector to another robot...
Consider now the x,y values of the direction vector, and the x,y values
of one of the sweep vector bounds... you can see that if you construct
a circle centered on the terminating position of the direction vector
with a radius extending out to the scanner bounding vectors that the
direction vector to the other robot must be inside this circle, right?

So, then find the distance between the Scanner Direction vector (the
way the robot is facing) and the bounding vectors, this is the radius
of that circle (we will call this radius the scan_radius, and it will
be constant for the duration of your program for this robot), next find
the distance from the Scanner Direction vector and the direction vector
to the other robot, if it is less than or equal to the  scan_radius
then it is in the scanner sweep.

In summary, setting up your program as described will require you to
keep:
- the current heading of the robot (scanner_direction_vector)
- and to find a normalized direction vector to each other robot
(direction_vector)
- the scan_radius (a magic number that will tell you if the distance
between the scanner_direction_vector and the direction_vector places
the robot in the line of sight.

I agree with Mark that it is unneeded...

Ok I woke up and I still think I made sense...  lets consider the
geometry of the matter, and another way to solve it.

Consider the case of two robots in the arena... R1 and R2.
R1 wants to know if R2 is in his scanning arc...
First R1 needs to know what direction he is facing, he may keep this
information in an angle like you are currently intent on doing or keep
this information in a direction vector (which would simplify future
calculations and remove your bottle neck)...  if you restrict yourself
to using vectors then a vector solution will do.

So you need an accuracy of 1/256th of a circle... instead of
precomputing the trig functions why not precompute a table of
normalized direction vectors?
Please bear with me if I go slowly but by slow I hope to be clear.

Calculating your table of normalized direction vectors...
you know that sin(a) = y/r  and that cos(a) = x/r
Since the length of the vector is to be of unit length (normalized) we
know that r = 1 thus, each vector is defined by:
y = sin(a),
x = cos(a)
where a in your case is the sequence of numbers from 0 - 2pi in 2pi/256
(in radians of course) increments. It is best to precompute these
values and
store them as an array of static final floats, i would just make the
the y component the even index's and x the odd index's.

So now you have a nice table of direction vectors... the robot would
then keep an int that would index into this table
(direction_vector_int). The range of the variable is between 0 and 256
(to find the index in the precomputed direction vectors you would of
course multiply by 2 since the x and y components are side be side)...

Now to find if R2 is in R1 scanner....
The scanner has an angle too,  the angle that is may sweep within...
Since the rotation of the robots in your world is restricted to
changes of 1/256 deg why not represent the angle as an int which
represents x number of 1/256 deg increments?

Say: scan_angle_ int = getScanAngleInt(int degrees);  //same for all
robots right?
public int getScanAngleInt(int degrees){
   return degrees * 256.0f / 360.0f

}

Now why do this? Well the scan_angle_int is the whole angle of the
scanner sweep, you know the direction vector already, well if you
divide the scan angle by two you know that half has to be on either
side of the direction vector of the robot, right?  So half of the
scan_angle_int added or subtracted from the direction_vector _int of
the robot will give you two new vectors, these vectors are the lines
that define the range of the scanner (you don't need to keep track of
these just the direction_vector_int which will remain constant over the
duration of your program, actually as you'll see this is just an
intermediary value you will not even need to keep). You may wish to
note
that due to integer issues you will want to select scan angles that
result in scan_angle_int values which are evenly divisible by two
or you will loose further accuracy.

Next we need to see if the direction vector between R1 and R2 falls
between the range of the scanner... simply normalize the direction
vector between R1 and R2...

Now consider this on paper so it is crystal clear:
you have your robot at the center of a circle, the radius of the circle
is 1 unit, from the robot to the diameter extends a direction vector.
Half of the scanner angle to the left is the left scanner vector bound,
half the scanner angle to the right is the right scanner angle bound
(and we know how to find these already).
Some where else there is a direction vector to another robot...
Consider now the x,y values of the direction vector, and the x,y values
of one of the sweep vector bounds... you can see that if you construct
a circle centered on the terminating position of the direction vector
with a radius extending out to the scanner bounding vectors that the
direction vector to the other robot must be inside this circle, right?

So, then find the distance between the Scanner Direction vector (the
way the robot is facing) and the bounding vectors, this is the radius
of that circle (we will call this radius the scan_radius, and it will
be constant for the duration of your program for this robot), next find
the distance from the Scanner Direction vector and the direction vector
to the other robot, if it is less than or equal to the  scan_radius
then it is in the scanner sweep.

In summary, setting up your program as described will require you to
keep:
- the current heading of the robot (scanner_direction_vector)
- and to find a normalized direction vector to each other robot
(direction_vector)
- the scan_radius (a magic number that will tell you if the distance
between the scanner_direction_vector and the direction_vector places
the robot in the line of sight.

This results in the most expensive operations being two square root
calculations when considering a robot relative to another.

Excuse me I did remove this message and reposted it.