How can we write the angle expression for analog clock? - java

This is the expression given as solution in the book I referred to but it seems to be beyond my understanding. Please anyone help to understand how are we exactly writing this angle? Why subtract pi/2? I really have no idea
xs=(int)(Math.cos(s*3.14f/30-3.14f/2)*45+xcentre);
ys=(int)(Math.sin(s*3.14f/30-3.14f/2)*45+ycentre);
xm=(int)(Math.cos(m*3.14f/30-3.14f/2)*40+xcentre);
ym=(int)(Math.sin(m*3.14f/30-3.14f/2)*40+ycentre);
xh=(int)(Math.cos((h*30+m/2)*3.14f/180-3.14f/2)*30+xcentre);
yh=(int)(Math.sin((h*30+m/2)*3.14f/180-3.14f/2)*30+ycentre);

Seems like it's giving the cartesian coordinates of the ends of the three hands of a clock centered at the origin, with up being negative y, and right being positive x. I can say this just by trying some values.
I wrapped your basic code like this:
static class ClockCoords {
int xs, ys;
int xm, ym;
int xh, yh;
public String toString() {
return String.format("h: %3d,%3d m: %3d,%3d s: %3d,%3d", xh, yh, xm, ym, xs, ys);
}
}
public static ClockCoords coords(int h, int m, int s) {
ClockCoords r = new ClockCoords();
int xcentre = 0;
int ycentre = 0;
r.xs = (int) (Math.cos(s * 3.14f / 30 - 3.14f / 2) * 45 + xcentre);
r.ys = (int) (Math.sin(s * 3.14f / 30 - 3.14f / 2) * 45 + ycentre);
r.xm = (int) (Math.cos(m * 3.14f / 30 - 3.14f / 2) * 40 + xcentre);
r.ym = (int) (Math.sin(m * 3.14f / 30 - 3.14f / 2) * 40 + ycentre);
r.xh = (int) (Math.cos((h * 30 + m / 2) * 3.14f / 180 - 3.14f / 2) * 30 + xcentre);
r.yh = (int) (Math.sin((h * 30 + m / 2) * 3.14f / 180 - 3.14f / 2) * 30 + ycentre);
return r;
}
public static void main(String[] args) throws IOException {
System.out.println(coords(0, 0, 0));
System.out.println(coords(0, 0, 45));
System.out.println(coords(6, 0, 0));
System.out.println(coords(6, 30, 0));
}
which gives me this:
h: 0,-29 m: 0,-39 s: 0,-44
h: 0,-29 m: 0,-39 s: -44, 0
h: 0, 29 m: 0,-39 s: 0,-44
h: -7, 28 m: 0, 39 s: 0,-44
So, if I haven't messed this up, the hour hand is 29 units long, the minute hand is 39 units long, and the second hand is 44 units long. At the start of the day, the first entry, they're all pointing straight up. 45 seconds into the day, the second entry, sees the second hand pointing off to the left, but the other two hands are still point straight up given integer granularity and hands that aren't too long. The third entry, 6:00, just flips the hour hand to point down. The fourth entry is interesting, 6:30, in that it points the minute hand down, but also moves the hour hand a little to the left and up...our first hand in a position not at a 90 degree angle to center. Interesting stuff. As to the WHY of all of this...I assume it's all basic trig and cartesian math.
Wait a sec...there one thing strange I don't get...I see in the formulas where each hand is given a different length. Why are the hand lengths I see off by 1 from what's in the formulas? My guess is that it has to do with the very rough approximation of PI that's used. I think those hands aren't pointing quite straight up. That's all I can think of. Maybe tomorrow I'll try plugging in a better value for PI.

Let me provide you some background information as well.
Trigonometry
is all about a circle, having a radius of 1 unit, centered in the origo, that is, point (0, 0). The coordinates of a point on the circle can be calculated as x = cos(alpha), y = sin(alpha), where alpha is the angle. Since all the points of the circle are of equal distance from the center, you only need to know the angle to compute the coordinates, which are (cos(alpha), sin(alpha)).
Reason: Look at Pythagoras's theorem, which is, by the way, a consequence of the law of cosines, where the largest angle of the triangle is of 90 degree.
Pythagoras's theorem states that
where a, b and c are lengths of sides of the triangle, the triangle being perpendicular and a < c > b is true. So, the cos and sin is due to trigonometrical coordinates.
Radians, PI/2
Units of angle can be measured in degrees (360 degrees being the full circle) or radians (2 PI being the full circle). Let's talk in radians. In math, 0 radians is the angle of the upmost point of the circle. pi/2 is the left-most. pi is the downmost. 3pi/2 is the rightmost. Notice, that as the angle increases your point moves counter-clockwise.
Since this is periodic, it is true that
2 * k * pi + alpha = alpha
On screens, y points downwards, by contrast to the standard in math, where y vertex points upwards. So, if you start from 0 radians, that will be the downmost point when shown on the screen and due to the invert y, as you increase the angle, you move to the clockwise direction. Removing pi / 2 from 0 points you to the rightmost point.
Variables
(xh, yh) are the hour coordinates
(xm, ym) are the minute coordinates
(xs, ys) are the second coordinates
They are the hands of a traditional clock.
h is the hour angle
m is the minute angle
s is the second angle
(xcentre, ycentre) are the coordinates of the center. They might be different from (0, 0), so coordinate moving, the so-called translation is supported.
Step sizes
There are 60 seconds in a minute and there are 60 minutes in an hour, so the angle step needs to be the same for them, even though, the frequency of steps is different, while there are 24 hours in a day, so the angle step of hour needs to be both less frequent and larger (12 positions on a traditional clock).
Length of hands
Hour, minute and second hands (no pun intended) differ in their length, this is why the unit of the trigonometric circle is multiplied by 45, 40 and 30, respectively.
As time passes, presumably the angles are changed and subsequently their coordinates change.

A less-exhaustive explanation, looking only at seconds:
xs = (int)(Math.cos(s*3.14f/30-3.14f/2)*45+xcentre);
ys = (int)(Math.sin(s*3.14f/30-3.14f/2)*45+ycentre);
As Steve's answer notes, drawing a line from (xcentre, ycentre) to (xs, ys) would display a seconds-hand, with "up" being "y = 0" -- so that axis is reversed compare to traditional plots. This actually works in our favor: normally, as angles grow, they are displayed as going anti-clockwise. Since the y axis is reversed in screen coordinates, this is fine for us: our hands will advance clockwise, as expected.
Let us look at the maths, using xs:
xs = Math.cos(s*3.14f/30-3.14f/2)*45; // removed rounding & using xcentre=0
xs = Math.cos((s/30)*PI - PI/2) * sHandLength; // use PI=3.14..., sHandLength=45
Now, at time 0, we want the seconds-hand to look straight up. But normally cos(0) = 1. If we substract 90º (PI/2), it will be looking straight up:
xs = Math.cos((s/30)*PI - zeroIsUp) * sHandLength;
We can undo this to keep on reasoning about the remaining expression:
xs = Math.cos((s/30)*PI); // sHandlength of 1, time 0 is left
All that is missing is that mysterious s/30*PI. Let's make a small table:
seconds(s) radians(argument to Math.cos())
0 0
15 PI/2 -- a quarter-turn of the hand
30 PI -- a half-turn
45 3*PI/2 -- a three-quarters turn
60 2*PI, or 0 -- a full turn
So it seems that it is simply that (s/30) * PI is short for (s/60) * (2*PI).
For a book on Java, I would have expected a much clearer way of writing this. My personal preference would have been:
xs = (int)(Math.cos(base60toRadians(s) - zeroIsUp) * secondHandLength + xCentre);
ys = (int)(Math.sin(base60toRadians(s) - zeroIsUp) * secondHandLength + yCentre);
// ... somewhere else
private float base60toRadians(int b60) { return (b60 / 60) * (2 * Math.PI); }

The coordinates of the clock's centre are (xcentre, ycentre).
With a geometric affine translation to the centre you can calculate like from (0, 0).
The hands are rotating clock wise, in the negative direction.
Now the hands of a clock start at the top, and (0, 1), which has an angle π/2 (90°). (1, 0) being where the angle starts, (-1, 0) halfways having angle π (180°).
The full 360° angle being 2π, 1/60th thereof becomes:
Seconds: 60 seconds = 2π; angle 2π / 60 = π / 30
double startAngle = Math.PI / 2; // Value 0 has angle π/2
double rs = 45;
xs = (int)(Math.cos(-s * Math.PI / 30 - startAngle) * rs + xcentre);
ys = ... sin ...
Hours: 24 hours = 2π; angle 2π / 24 = π / 12

Related

Add exact distance to GPS coordinates

I want to be able to add an exact distance to some GPS coordinates.
I have a longitude and a latitude and I want to add a distance, let's say 30 meters.
I found below formula but when I test it, it does not seem to be that accurate because the resulting long and lat are 37m away from the beginning coords.
public static Coordinates addDistanceToCoordinates(String lat, String lon, double distance) {
Double latitude = Double.valueOf(lat);
Double longitude = Double.valueOf(lon);
double lat0 = cos(Math.PI / 180.0 * latitude);
double x = longitude + (180/Math.PI)*(distance/6378137)/cos(lat0);
double y = latitude + (180/Math.PI)*(distance/6378137);
return Coordinates.builder().lon(x).lat(y).build();
}
If you have a center (x,y) and you move on the x axis by 30 meters and on the y axis by another 30 meters your distance from the center won't be 30.
It will be Math.sqrt( Math.pow(x, 2) + Math.pow(y, 2) );.
Specifically, there are an infinite number of points that are 30 meters distant from the center (or your initial coordinates).
If you want to move in only one direction, then you can simply add/subtract 30 meters in either of your axis.
As you already did:
double x = longitude + (180/Math.PI)*(distance/6378137)/cos(lat0);
or
double y = latitude + (180/Math.PI)*(distance/6378137);
but not both...
You are still better off by using angles in your calculations, which will turn handy when you move on both axis.
By knowing which direction you are headed to, for example 50° from the x axis,
double a = Math.toRadians(50); // degrees
double x = longitude + (180/Math.PI) * (30 / 6378137)/cos(lat0) * Math.cos(a);
double y = latitude + (180/Math.PI) * (30 / 6378137) * Math.sin(a);
Coming back to your question, if you want to move on the x axis and the y axis by the same distance and end up exactly 30 meters away from the center, then your angle will be double a = Math.toRadians(45); (if you head North-East) *
In fact you will obtain for both (30 / 6378137) * Math.cos(a) and (30 / 6378137) * Math.sin(a) a result of x1 = y1 = 3.325924707417923e-06.
If you then apply Pythagoras
double finalDistance = Math.sqrt(Math.pow(x1, 2) + Math.pow(y1, 2)) * 6378137;
you will find finalDistance to be 30 meters from your initial coordinates.
*
The correct calculation would be Math.toRadians(45 * (2 * n - 1)); | where n = [1, 2, 3, 4]
Your code adds 30 meters north and 30 meters east, resulting in 42.4 meters northeast.
The calculation is assuming earth as a sphere instead of an ellipsoid, but that's mostly OK, can make a difference of max. 0.2 percent. It uses the biggest earth diameter (equator - equator) instead of some mean value, which will result in points too close to the starting point most of the time, but agian, taht can give an error of maybe 0.2 percent.
The calculation assumes the lat/lon grid to be rectangular, which is OK as long as the distances are short and you stay away from north or south pole.
So, all of this doesn't explain the 20 percent error you are reporting. The problem must be outside of the code you showed us.
The most suspicious remaining aspect is the string conversion. You'll need at least 5 decimal places for lat / lon degree values to get a 1 meter resolution.
Or maybe the tool that told you about the 37 meters isn't correct or somehow incompatible with the data...

Calculating speed from set of longitude and latitudes values obtained in one minute?

I need to calculate speed after each 10 seconds or less (currently i am using fused location api to get the location after each 10 seconds). The problem is that the equipment is too slow and sometimes it gives the distance covers equal to zero.
I have tried using Location.distanceBetween() but it also produces zeros even when the equipment is moving. I have tried to calculate distance by a formula but sometimes distance is too small that it gives zero.
Now i want to calculate average speed. I want to save the points obtained in 1 minute (6 lat long values). And then after each 10 seconds, i want to calculate average speed between them. Thus after each 10 seconds I will add one points at the end and remove one point from the start. That will remove the possibility of zero.
Now is there any formula that can calculate speed or distance from set of lat long values or any better approach will be highly appreciated.
You can calculate distance between two point, that are close enough, using simple geometry
deltaLngMeters = R * cos(latitude) * deltaLongitudeRadians;
deltaLatMeters = R * deltaLatitudeRadians;
whereas deltas are in radians, deltaLatitudeRadians = deltaLatitudeDegrees * pi / 180
Hence distance = sqrt(deltaLngMeters ^2 + deltaLatMeters ^ 2).
To sum up
function distance(point1, point2) {
var degToRad = Math.PI / 180;
return R * degToRad * Math.sqrt(Math.pow(Math.cos(point1.lat * degToRad ) * (point1.lng - point2.lng) , 2) + Math.pow(point1.lat - point2.lat, 2));
}
If you have array of six points, you can calculate average speed.
points = [{lat: .., lng: ..}, ... ]; // 6 points
distancesSum = 0;
for(i = 0; i < distances.length - 1; i++) {
distancesSum += distance(points[i], points[i + 1]);
}
return (distancesSum / (points.length - 1));
Yes, R is for the Earth radius, R = 6371000;// meters
You can use multi threading(Thread.sleep()) to calculate a formula repeatedly for every 10 seconds. You can verify it here https://beginnersbook.com/2013/03/multithreading-in-java/.
For small distances(hope the device won't move at speeds above 1 km/s), earth's surface can be treated as a plane. Then the latitude and longitude will be the coordinates of the device on the Cartesian plane attached to earth. Hence you can calculate the distance by this formula:
√(delta(longitude)^2 + delta(latitude)^2)
delta: difference

Recursively create apollonian gaskets [With solution]

Apollonian gaskets = They are planar fractals generated from triples of circles, where each circle is tangent to the other two. In his drawing of the gasket, we start with two externally tangent circles which diameter is D1 and D2. Then we add a third circle which diameter is D1+D2 and to which the two original circles are internally tangent. This is the first generation of circles.
Each subsequent generation of circles is constructed by applying the following scheme:
For any three circles A, B C of any previous generations which are tangent to each other a new circle is constructed which is tangent to A,B,C. The new circle must differ from all circles constructed so far. When a generation is complete, i.e no other circle can be added, then the next generation of circles can start being constructed.
There is an additional stopping rule which prevents from generating infinitesimally small circles. A circle can be added to the gasket if and only if the lenght of its diameter is least minD which is a fixed positive value.
Input consists of one line with three decimal numbers D1, D2 and minD. The number are separated by spaces. The format is usual decimal format (see also the examples bellow) with no exponent part.
It holds that 1.0 ≤ D1, D2 ≤ 1000.0, 0.001 ≤ minD ≤ D1+D2.
Ouput consists of one text line containing two decimal numbers L1 and L2. L1 represents the sum of areas of all circles in the gasket except for the bigggest circle. L2 represents the sum of perimeters of all circles in tin the gasket except for the bigggest circle. Both output values are rounded to 6 decimal digits. Decimal digits must be always present in the output even if some of them are zeros.
Maximim output value is less than 107.
Input
17.000000 40.000000 1.000000
Output
2439.258588 835.263228
2
For given D1 and D2, I create this two circles like this (first iteration):
double D1 = 17.00;
double D2 = 40.00;
double minD = 1.00;
int i = 250, j = 350;
comp.addCircle(i, j, (int) D2, randomColor);
comp.addCircle(i + (int) D2 / 2 + (int) D1 / 2, j, (int) D1, randomColor);
comp.addCircle(i + (int) D1 / 2, j, (int) (D1 + D2), randomColor);
UPDATE:
So, solution is based on Descartes' theorem. We well work with radius, not diameter, and Curvature, with is 1/r.
We will use double for all calculation, but if you work with significantly small numbers, I would prefer BigDecimal. It will slow algorithm, and you should use external method for finding square root, because BigDecimal doesn't have any.
For given D1, D2, minD we modify code above for efficiency:
Some preparation:
double D1 = sc.nextDouble() / 2;
double D2 = sc.nextDouble() / 2;
minD = sc.nextDouble() / 2;
double D3 = D1 + D2;
So, first step looks like this:
Next step looks a little bit more complicated.
Assume we want to write a recursion to solve this problem, and according to Descartes' theorem, for given curvatures of three circles, tangent to each other, (pic. below)
, we could find curvatures of two circles, but for our purposes, we need only small one, so, we can simplify formula to
this.curve = a.curve + b.curve + c.curve + 2 * Math.sqrt(Math.abs(a.curve * b.curve + a.curve * c.curve + b.curve * c.curve));
Lets take a look at Apollonian gaskets again: try to play with it.
See? It is same gaskets, but with different start condition. And whats more important for us, is that it is symmetrical! So, we will calculate just a half, and then multiply result by two!
Lets write a recursion! Inputs will be curvatures of three circles. No output, we will use change our global variables.
double radius_sum = 0.0;
double square_radius_sum = 0.0;
void createAG(double a, double b, double c){
double n = a + b + c + Math.sqrt(a*b + a*c + b*c + 4.0);
if ((minD * n) < 1){
radius_sum += 2. / n; //Remember about symmetry?
square_radius_sum += 2. * (1. / n) * (1. / n); //Remember about symmetry?
createAG(a, b, n);
createAG(a, c, n);
createAG(b, c, n);
}
}
To find the result, we will use formulas to calculate area and perimeter of circle.
Perimeter is length of circumference and equal to .
Area is equal to , as you already know, because we already calculated it in previous step, otherwise we had to store every radius and do more calculations.
radius_sum = 2 * Math.Pi * radius_sum;
square_radius_sum = Math.Pi * square_radius_sum;
But we forget about our first two circles! Let's fix it!
radius_sum += D1*2 + D2*2;
square_radius_sum += D1*D1 + D2*D2;
radius_sum = 2 * Math.Pi * radius_sum;
square_radius_sum = Math.Pi * square_radius_sum;
And there is always a room for improvement. For example, to use IEEE 754 in better way, I assume you will use 1. / x instead of 1 / x.
Thank you!
P.S. Copyright! This task (text and first picture of Apollonian gasket) is created by teachers at CTU, for course ALG. Picture of formulas is from Wikipedia. Everything else is public domain, if not patented, registered e.t.c.
So, solution is based on Descartes' theorem. We well work with radius, not diameter, and Curvature, with is 1/r.
We will use double for all calculation, but if you work with significantly small numbers, I would prefer BigDecimal. It will slow algorithm, and you should use external method for finding square root, because BigDecimal doesn't have any.
For given D1, D2, minD we modify code above for efficiency:
Some preparation:
double D1 = sc.nextDouble() / 2;
double D2 = sc.nextDouble() / 2;
minD = sc.nextDouble() / 2;
double D3 = D1 + D2;
So, first step looks like this:
Next step looks a little bit more complicated.
Assume we want to write a recursion to solve this problem, and according to Descartes' theorem, for given curvatures of three circles, tangent to each other, (pic. below)
, we could find curvatures of two circles, but for our purposes, we need only small one, so, we can simplify formula to
this.curve = a.curve + b.curve + c.curve + 2 * Math.sqrt(Math.abs(a.curve * b.curve + a.curve * c.curve + b.curve * c.curve));
Lets take a look at Apollonian gaskets again: try to play with it.
See? It is same gaskets, but with different start condition. And whats more important for us, is that it is symmetrical! So, we will calculate just a half, and then multiply result by two!
Lets write a recursion! Inputs will be curvatures of three circles. No output, we will use change our global variables.
double radius_sum = 0.0;
double square_radius_sum = 0.0;
void createAG(double a, double b, double c){
double n = a + b + c + Math.sqrt(a*b + a*c + b*c + 4.0);
if ((minD * n) < 1){
radius_sum += 2. / n; //Remember about symmetry?
square_radius_sum += 2. * (1. / n) * (1. / n); //Remember about symmetry?
createAG(a, b, n);
createAG(a, c, n);
createAG(b, c, n);
}
}
To find the result, we will use formulas to calculate area and perimeter of circle.
Perimeter is length of circumference and equal to .
Area is equal to , as you already know, because we already calculated it in previous step, otherwise we had to store every radius and do more calculations.
radius_sum = 2 * Math.Pi * radius_sum;
square_radius_sum = Math.Pi * square_radius_sum;
But we forget about our first two circles! Let's fix it!
radius_sum += D1*2 + D2*2;
square_radius_sum += D1*D1 + D2*D2;
radius_sum = 2 * Math.Pi * radius_sum;
square_radius_sum = Math.Pi * square_radius_sum;
And there is always a room for improvement. For example, to use IEEE 754 in better way, I assume you will use 1. / x instead of 1 / x.
Thank you!
P.S. Copyright! This task (text and first picture of Apollonian gasket) is created by teachers at CTU, for course ALG. Picture of formulas is from Wikipedia. Everything else is public domain, if not patented, registered e.t.c.

Libgdx, physics, acceleration and FPS

I am making a platform game in the Libgdx framework. I want to implement the ability to jump for my character. I use the simply formula:
speed += acceleration * delta_time
r += speed * delta_time
It works well, but only for constant frames per second. The lower FPS is, the lower my character jumps. I have no idea what is the cause of this behavior, the height of jumps should be the same :/
There is a fragment of my code:
delta_time=Gdx.graphics.getDeltaTime();
if(input.getUpArrow()){
if(is_in_air==false){
is_in_air=true;
speed_y=speed_y_0;
}
}
if(is_in_air==true){
speed_y-=acceleration*delta_time;
}
else{
speed_y=0;
}
x+=speed_x*delta_time;
y+=speed_y*delta_time;
And here is an illustration (black dots are character positions):
http://i.imgur.com/tfSTM.jpg
This is perfectly normal behaviour given the very simple and highly inaccurate integrator that you use. It is pretty easy to do the math and show that.
Let's take a single time span of 1/30 seconds. When the game runs at 30 FPS there would be only one update to speed_y and y, so after 1/30 s the new position y' would be:
speed_y' = speed_y - a*dt
y' = y + speed_y'*dt = y + speed_y*dt - a*dt^2
Here dt is the time delta of 1/30 seconds.
When the game runs at 60 FPS, in the same 1/30 seconds there would be two updates happening with twice as shorter time delta, dt/2:
// First update
speed_y' = speed_y - a*(dt/2)
y' = y + speed_y'*(dt/2) = y + speed_y*(dt/2) - a*(dt/2)^2
// Second update
speed_y'' = speed_y' - a*(dt/2) = speed_y - a*dt
y'' = y' + speed_y''*(dt/2) = y + speed_y*dt - 3*a*(dt/2)^2
Now compare both updated y positions:
at 30 FPS it is: y + speed_y*dt - a*dt^2
at 60 FPS it is: y + speed_y*dt - a*(3/4)*dt^2
Obviously at 60 FPS the new position of y would be higher than that at 30 FPS because the subtracted value is lower.
This only affects the vertical motion. The horizontal speed is constant and it doesn't matter if you update x once or twice with twice as short time delta, hence when your character jumps it always travels the same horizontal distance to the place where it hits the ground, no matter what the FPS.
To solve this you have to take a closer look at the equation of motion under constant acceleration:
y(t) = y(t=0) + v(t=0)*t - (1/2)*a*t^2
The choice of t=0 is arbitrary since laws of physics are invariant under time shifts, so one may take t=0 to be the beginning of the update interval and then t=delta_time would give the position after the current update. The correct update algorithm as follows:
x += speed_x*delta_time;
if (is_in_air) {
y += (speed_y - 0.5*acceleration*delta_time)*delta_time;
speed_y -= acceleration*delta_time;
}
Note that speed_y should be updated after the vertical position as per the values found in the equation of motion.

To determine the time when the angle between the clock hands is known in analog clock in android

I want to set time from the analog clock in an Android Application. For this I have overridden the Analogclock.java class and have established the Ontouchevent listener. I followed this method and this formula to calculate the angle between the hour and the minute hand from the obtained Coordinates. Now I'm able to move the hand to a new position. And I can also fetch the new angle between the needles from this. This is the code for the same :
case MotionEvent.ACTION_MOVE:
x = (int)event.getX();
y = (int)event.getY();
double dx = x - minuteRect.centerX();
double dy = -(y - minuteRect.centerY());
double inRads = Math.atan2(dy,dx);
if (inRads < 0)
inRads = Math.abs(inRads);
else
inRads = 2*Math.PI - inRads;
double newDegree = Math.toDegrees(inRads);
if(isMove()){
setAngle(newDegree);
invalidate();
}
I now want to set the time where the needle is being moved.
Is there any way I can calculate the time from the Coordinates or from the angle between the two needles?
I don't know the code, but the math is not hard:
Divide the angle of the hour hand by 2PI, multiply by 12 and truncate, and you have the hours.
Divide the angle of the minute hand by 2PI, multiply by 60 and truncate, and you have the minutes.
Example : 06:15:
The hour angle is a little bit more than PI. (PI / 2PI) * 12 = 6
The minute angle is PI/2. ((PI/2) / 2PI) * 60 = 15

Categories