Mixing
How did the apollo computers evaluate transcendental functions like sine, arctangent, log?
Clash Royale CLAN TAG#URR8PPP
up vote
13
down vote
favorite
Navigation with a sextant or maneuvers using gimbal angles might be two examples of cases where an apollo computer might need to do trigonometry.
Trigonometric functions like sine, arctangent, etc. are transcendental, as are logarithms. You can't evaluate these functions with a simple expression built on multiplication or division for example, without at least an iterative algorithm.
An engineer on the ground would grab a slide rule for two or three digits, and for more go to a book of trig, log and other tables for more digits. Between two lines you could interpolate by hand for even more digits.
But how did the apollo computers evaluate transcendental functions, or how at least were calculations that required the use of transcendental functions implemented in the programs?
apollo-program history mathematics
asked 7 hours ago
uhoh
28.4k1392353
 |Â
show 1 more comment
up vote
13
down vote
favorite
Navigation with a sextant or maneuvers using gimbal angles might be two examples of cases where an apollo computer might need to do trigonometry.
Trigonometric functions like sine, arctangent, etc. are transcendental, as are logarithms. You can't evaluate these functions with a simple expression built on multiplication or division for example, without at least an iterative algorithm.
An engineer on the ground would grab a slide rule for two or three digits, and for more go to a book of trig, log and other tables for more digits. Between two lines you could interpolate by hand for even more digits.
But how did the apollo computers evaluate transcendental functions, or how at least were calculations that required the use of transcendental functions implemented in the programs?
apollo-program history mathematics
asked 7 hours ago
uhoh
28.4k1392353
Are you sure about the need to do trigonometry for gimbaling? I'm pretty sure it would be easier to stay within vector math if you use a linear actuator. Anyway trignonometry functions are usually implemented by table lookup or approximated as a taylor expansion. No source directly related to Apollo, sorry.
– Christoph
6 hours ago
1
...or both, the taylor expansion preparing lookup tables on startup, in case permanent storage is less abundant than RAM.
– SF.
6 hours ago
@Christoph First sentence starts with two instruments that likely produce angular data. Also, what was done in the 1960's in computers in space, is not covered by how things are done now. I'll add thehistorytag to make that even clearer. You might also consider where tables would have to be stored, there was precious little memory in the Apollo computers.
– uhoh
6 hours ago
3
@Christoph: Already in 1956 we had a better algorithm than Taylor, namely CORDIC. I don't know if that was used in Apollo.
– MSalters
5 hours ago
1
Storage (permanent and dynamic both) was at a huge premium so it's not surprising they didn't keep a table.
– Russell Borogove
54 mins ago
 |Â
show 1 more comment
up vote
13
down vote
favorite
up vote
13
down vote
favorite
Navigation with a sextant or maneuvers using gimbal angles might be two examples of cases where an apollo computer might need to do trigonometry.
Trigonometric functions like sine, arctangent, etc. are transcendental, as are logarithms. You can't evaluate these functions with a simple expression built on multiplication or division for example, without at least an iterative algorithm.
An engineer on the ground would grab a slide rule for two or three digits, and for more go to a book of trig, log and other tables for more digits. Between two lines you could interpolate by hand for even more digits.
But how did the apollo computers evaluate transcendental functions, or how at least were calculations that required the use of transcendental functions implemented in the programs?
apollo-program history mathematics
asked 7 hours ago
uhoh
28.4k1392353
Navigation with a sextant or maneuvers using gimbal angles might be two examples of cases where an apollo computer might need to do trigonometry.
Trigonometric functions like sine, arctangent, etc. are transcendental, as are logarithms. You can't evaluate these functions with a simple expression built on multiplication or division for example, without at least an iterative algorithm.
An engineer on the ground would grab a slide rule for two or three digits, and for more go to a book of trig, log and other tables for more digits. Between two lines you could interpolate by hand for even more digits.
But how did the apollo computers evaluate transcendental functions, or how at least were calculations that required the use of transcendental functions implemented in the programs?
apollo-program history mathematics
apollo-program history mathematics
asked 7 hours ago
uhoh
28.4k1392353
asked 7 hours ago
uhoh
28.4k1392353
edited 11 mins ago
asked 7 hours ago
uhoh
28.4k1392353
asked 7 hours ago
uhoh
28.4k1392353
asked 7 hours ago
uhoh
28.4k1392353
28.4k1392353
Are you sure about the need to do trigonometry for gimbaling? I'm pretty sure it would be easier to stay within vector math if you use a linear actuator. Anyway trignonometry functions are usually implemented by table lookup or approximated as a taylor expansion. No source directly related to Apollo, sorry.
– Christoph
6 hours ago
1
...or both, the taylor expansion preparing lookup tables on startup, in case permanent storage is less abundant than RAM.
– SF.
6 hours ago
@Christoph First sentence starts with two instruments that likely produce angular data. Also, what was done in the 1960's in computers in space, is not covered by how things are done now. I'll add thehistorytag to make that even clearer. You might also consider where tables would have to be stored, there was precious little memory in the Apollo computers.
– uhoh
6 hours ago
3
@Christoph: Already in 1956 we had a better algorithm than Taylor, namely CORDIC. I don't know if that was used in Apollo.
– MSalters
5 hours ago
1
Storage (permanent and dynamic both) was at a huge premium so it's not surprising they didn't keep a table.
– Russell Borogove
54 mins ago
 |Â
show 1 more comment
Are you sure about the need to do trigonometry for gimbaling? I'm pretty sure it would be easier to stay within vector math if you use a linear actuator. Anyway trignonometry functions are usually implemented by table lookup or approximated as a taylor expansion. No source directly related to Apollo, sorry.
– Christoph
6 hours ago
1
...or both, the taylor expansion preparing lookup tables on startup, in case permanent storage is less abundant than RAM.
– SF.
6 hours ago
@Christoph First sentence starts with two instruments that likely produce angular data. Also, what was done in the 1960's in computers in space, is not covered by how things are done now. I'll add thehistorytag to make that even clearer. You might also consider where tables would have to be stored, there was precious little memory in the Apollo computers.
– uhoh
6 hours ago
3
@Christoph: Already in 1956 we had a better algorithm than Taylor, namely CORDIC. I don't know if that was used in Apollo.
– MSalters
5 hours ago
1
Storage (permanent and dynamic both) was at a huge premium so it's not surprising they didn't keep a table.
– Russell Borogove
54 mins ago
Are you sure about the need to do trigonometry for gimbaling? I'm pretty sure it would be easier to stay within vector math if you use a linear actuator. Anyway trignonometry functions are usually implemented by table lookup or approximated as a taylor expansion. No source directly related to Apollo, sorry.
– Christoph
6 hours ago
Are you sure about the need to do trigonometry for gimbaling? I'm pretty sure it would be easier to stay within vector math if you use a linear actuator. Anyway trignonometry functions are usually implemented by table lookup or approximated as a taylor expansion. No source directly related to Apollo, sorry.
– Christoph
6 hours ago
1
1
...or both, the taylor expansion preparing lookup tables on startup, in case permanent storage is less abundant than RAM.
– SF.
6 hours ago
...or both, the taylor expansion preparing lookup tables on startup, in case permanent storage is less abundant than RAM.
– SF.
6 hours ago
@Christoph First sentence starts with two instruments that likely produce angular data. Also, what was done in the 1960's in computers in space, is not covered by how things are done now. I'll add the
history tag to make that even clearer. You might also consider where tables would have to be stored, there was precious little memory in the Apollo computers.– uhoh
6 hours ago
@Christoph First sentence starts with two instruments that likely produce angular data. Also, what was done in the 1960's in computers in space, is not covered by how things are done now. I'll add the
history tag to make that even clearer. You might also consider where tables would have to be stored, there was precious little memory in the Apollo computers.– uhoh
6 hours ago
3
3
@Christoph: Already in 1956 we had a better algorithm than Taylor, namely CORDIC. I don't know if that was used in Apollo.
– MSalters
5 hours ago
@Christoph: Already in 1956 we had a better algorithm than Taylor, namely CORDIC. I don't know if that was used in Apollo.
– MSalters
5 hours ago
1
1
Storage (permanent and dynamic both) was at a huge premium so it's not surprising they didn't keep a table.
– Russell Borogove
54 mins ago
Storage (permanent and dynamic both) was at a huge premium so it's not surprising they didn't keep a table.
– Russell Borogove
54 mins ago
 |Â
show 1 more comment
1 Answer
1
active
oldest
votes
up vote
34
down vote
Since the Apollo 11 Code is on Github, i was able to find the code that looks like an implementation of sine and cosine functions: see here for the command module and here for the lunar lander (it looks like it is the same code).
For convenience, here is a copy of the code:
# Page 1102
BLOCK 02
# SINGLE PRECISION SINE AND COSINE
COUNT* $$/INTER
SPCOS AD HALF # ARGUMENTS SCALED AT PI
SPSIN TS TEMK
TCF SPT
CS TEMK
SPT DOUBLE
TS TEMK
TCF POLLEY
XCH TEMK
INDEX TEMK
AD LIMITS
COM
AD TEMK
TS TEMK
TCF POLLEY
TCF ARG90
POLLEY EXTEND
MP TEMK
TS SQ
EXTEND
MP C5/2
AD C3/2
EXTEND
MP SQ
AD C1/2
EXTEND
MP TEMK
DDOUBL
TS TEMK
TC Q
ARG90 INDEX A
CS LIMITS
TC Q # RESULT SCALED AT 1.
The comment
# SINGLE PRECISION SINE AND COSINE
indicates, that the following is indeed an implementation of the sine and cosine functions.
Information about the type of assembler used, can be found on Wikipedia
Partial explanation of the code:
The subroutine SPSIN actually calculates $sin(pi x)$, and SPCOS calculates $cos(pi x)$.
The subroutine SPCOS first adds one half to the input, and then proceeds to calculate the sine
(this is valid because of $cos(pi x) = sin(pi (x+tfrac12))$).
The argument is doubled at the begin of the SPT subroutine.
That is why we now have to calculate $sin(tfracpi2 y)$ for $y=2x$.
The subroutine POLLEY calculates a taylor polynomial approximation of $sin(tfracpi2 x)$.
First, we store $x^2$ in the register SQ (where $x$ denotes the input).
This is used to calculate the polynomial
$$
((( C_5/2 x^2 ) + C_3/2 ) x^2 + C_1/2) x.
$$
The values for the constants can be found in the same github repository and are
$$
C_5/2= .0363551 approx big(fracpi2big)^5 cdot frac12cdot 5!\
C_3/2= -.3216147 approx -big(fracpi2big)^3 cdot frac12cdot 3!\
C_1/2= .7853134 approx fracpi2 cdot frac12\
$$
which look like the first taylor coefficients for the function
$frac12 sin(tfracpi2 x)$.
These values are not exact, but I suspect that the error comes from the low bit resolution.
Finally, the result is doubled with the DDOUBL command, and the subroutine POLLEY returns an approximation to
$sin(tfracpi2 x)$.
As for the scaling (first halve, then double, ...), @Christopher mentioned in the comments, that the 16-Bit Fixed-Point number could only store values from -1 to +1. Therefore, scaling is necessary. See here for a source and further details on the data representation.
How accurate is this taylor approximation? Here you can see a plot on WolframAlpha for the sine, and it looks like a good approximation for $x$ from $-0.6$ to $+.6$.
The cosine function and its approximation is plotted here.
I hope they never had to calculate the cosine for a value $geq tfracpi2$, because then the error would be unpleasantly large.
Note that for the taylor approximation you only need four multiplications and two additions (MP and AD in the code).
There are some ways to increase accuracy and input range, which would have been available for them, but would result in more code and more computation time.
For example, exploiting symmetry and periodicity of sine and cosine, using the taylor expansion for cosine, or simply adding more terms of the taylor expansion would have improved the accuracy and would also allow for arbitrary large input values.
answered 5 hours ago
supinf
30116
New contributor
supinf is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
2
I am reading into it, but it is not easy because i am not familiar with the programming language. At first glance it looks like a taylor approximation, but i am not sure. I will edit when i have more.
– supinf
5 hours ago
3
The scaling is due to the fact that single precision could only store value from -1 to +1 :). Precision is around 13 bits which fits the single precision type (16 bits one of which is the sign bit and one was a parity bit not accessable to software).
– Christoph
4 hours ago
6
Oh lordy... I haven't seen assembly since college, I can't imagine having to write an entire guidance computer using nothing but OP-Codes and low-level functions. Also welcome to the SE, brilliant answer.
– Magic Octopus Urn
4 hours ago
2
On topic: error graph. Maximum error within the domain would be around 0.0001
– SF.
4 hours ago
2
Terrific analysis! I've never had much success trying to read AGC assembly myself. Welcome aboard.
– Russell Borogove
1 hour ago
 |Â
show 12 more comments
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
34
down vote
Since the Apollo 11 Code is on Github, i was able to find the code that looks like an implementation of sine and cosine functions: see here for the command module and here for the lunar lander (it looks like it is the same code).
For convenience, here is a copy of the code:
# Page 1102
BLOCK 02
# SINGLE PRECISION SINE AND COSINE
COUNT* $$/INTER
SPCOS AD HALF # ARGUMENTS SCALED AT PI
SPSIN TS TEMK
TCF SPT
CS TEMK
SPT DOUBLE
TS TEMK
TCF POLLEY
XCH TEMK
INDEX TEMK
AD LIMITS
COM
AD TEMK
TS TEMK
TCF POLLEY
TCF ARG90
POLLEY EXTEND
MP TEMK
TS SQ
EXTEND
MP C5/2
AD C3/2
EXTEND
MP SQ
AD C1/2
EXTEND
MP TEMK
DDOUBL
TS TEMK
TC Q
ARG90 INDEX A
CS LIMITS
TC Q # RESULT SCALED AT 1.
The comment
# SINGLE PRECISION SINE AND COSINE
indicates, that the following is indeed an implementation of the sine and cosine functions.
Information about the type of assembler used, can be found on Wikipedia
Partial explanation of the code:
The subroutine SPSIN actually calculates $sin(pi x)$, and SPCOS calculates $cos(pi x)$.
The subroutine SPCOS first adds one half to the input, and then proceeds to calculate the sine
(this is valid because of $cos(pi x) = sin(pi (x+tfrac12))$).
The argument is doubled at the begin of the SPT subroutine.
That is why we now have to calculate $sin(tfracpi2 y)$ for $y=2x$.
The subroutine POLLEY calculates a taylor polynomial approximation of $sin(tfracpi2 x)$.
First, we store $x^2$ in the register SQ (where $x$ denotes the input).
This is used to calculate the polynomial
$$
((( C_5/2 x^2 ) + C_3/2 ) x^2 + C_1/2) x.
$$
The values for the constants can be found in the same github repository and are
$$
C_5/2= .0363551 approx big(fracpi2big)^5 cdot frac12cdot 5!\
C_3/2= -.3216147 approx -big(fracpi2big)^3 cdot frac12cdot 3!\
C_1/2= .7853134 approx fracpi2 cdot frac12\
$$
which look like the first taylor coefficients for the function
$frac12 sin(tfracpi2 x)$.
These values are not exact, but I suspect that the error comes from the low bit resolution.
Finally, the result is doubled with the DDOUBL command, and the subroutine POLLEY returns an approximation to
$sin(tfracpi2 x)$.
As for the scaling (first halve, then double, ...), @Christopher mentioned in the comments, that the 16-Bit Fixed-Point number could only store values from -1 to +1. Therefore, scaling is necessary. See here for a source and further details on the data representation.
How accurate is this taylor approximation? Here you can see a plot on WolframAlpha for the sine, and it looks like a good approximation for $x$ from $-0.6$ to $+.6$.
The cosine function and its approximation is plotted here.
I hope they never had to calculate the cosine for a value $geq tfracpi2$, because then the error would be unpleasantly large.
Note that for the taylor approximation you only need four multiplications and two additions (MP and AD in the code).
There are some ways to increase accuracy and input range, which would have been available for them, but would result in more code and more computation time.
For example, exploiting symmetry and periodicity of sine and cosine, using the taylor expansion for cosine, or simply adding more terms of the taylor expansion would have improved the accuracy and would also allow for arbitrary large input values.
answered 5 hours ago
supinf
30116
New contributor
supinf is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
2
I am reading into it, but it is not easy because i am not familiar with the programming language. At first glance it looks like a taylor approximation, but i am not sure. I will edit when i have more.
– supinf
5 hours ago
3
The scaling is due to the fact that single precision could only store value from -1 to +1 :). Precision is around 13 bits which fits the single precision type (16 bits one of which is the sign bit and one was a parity bit not accessable to software).
– Christoph
4 hours ago
6
Oh lordy... I haven't seen assembly since college, I can't imagine having to write an entire guidance computer using nothing but OP-Codes and low-level functions. Also welcome to the SE, brilliant answer.
– Magic Octopus Urn
4 hours ago
2
On topic: error graph. Maximum error within the domain would be around 0.0001
– SF.
4 hours ago
2
Terrific analysis! I've never had much success trying to read AGC assembly myself. Welcome aboard.
– Russell Borogove
1 hour ago
 |Â
show 12 more comments
up vote
34
down vote
Since the Apollo 11 Code is on Github, i was able to find the code that looks like an implementation of sine and cosine functions: see here for the command module and here for the lunar lander (it looks like it is the same code).
For convenience, here is a copy of the code:
# Page 1102
BLOCK 02
# SINGLE PRECISION SINE AND COSINE
COUNT* $$/INTER
SPCOS AD HALF # ARGUMENTS SCALED AT PI
SPSIN TS TEMK
TCF SPT
CS TEMK
SPT DOUBLE
TS TEMK
TCF POLLEY
XCH TEMK
INDEX TEMK
AD LIMITS
COM
AD TEMK
TS TEMK
TCF POLLEY
TCF ARG90
POLLEY EXTEND
MP TEMK
TS SQ
EXTEND
MP C5/2
AD C3/2
EXTEND
MP SQ
AD C1/2
EXTEND
MP TEMK
DDOUBL
TS TEMK
TC Q
ARG90 INDEX A
CS LIMITS
TC Q # RESULT SCALED AT 1.
The comment
# SINGLE PRECISION SINE AND COSINE
indicates, that the following is indeed an implementation of the sine and cosine functions.
Information about the type of assembler used, can be found on Wikipedia
Partial explanation of the code:
The subroutine SPSIN actually calculates $sin(pi x)$, and SPCOS calculates $cos(pi x)$.
The subroutine SPCOS first adds one half to the input, and then proceeds to calculate the sine
(this is valid because of $cos(pi x) = sin(pi (x+tfrac12))$).
The argument is doubled at the begin of the SPT subroutine.
That is why we now have to calculate $sin(tfracpi2 y)$ for $y=2x$.
The subroutine POLLEY calculates a taylor polynomial approximation of $sin(tfracpi2 x)$.
First, we store $x^2$ in the register SQ (where $x$ denotes the input).
This is used to calculate the polynomial
$$
((( C_5/2 x^2 ) + C_3/2 ) x^2 + C_1/2) x.
$$
The values for the constants can be found in the same github repository and are
$$
C_5/2= .0363551 approx big(fracpi2big)^5 cdot frac12cdot 5!\
C_3/2= -.3216147 approx -big(fracpi2big)^3 cdot frac12cdot 3!\
C_1/2= .7853134 approx fracpi2 cdot frac12\
$$
which look like the first taylor coefficients for the function
$frac12 sin(tfracpi2 x)$.
These values are not exact, but I suspect that the error comes from the low bit resolution.
Finally, the result is doubled with the DDOUBL command, and the subroutine POLLEY returns an approximation to
$sin(tfracpi2 x)$.
As for the scaling (first halve, then double, ...), @Christopher mentioned in the comments, that the 16-Bit Fixed-Point number could only store values from -1 to +1. Therefore, scaling is necessary. See here for a source and further details on the data representation.
How accurate is this taylor approximation? Here you can see a plot on WolframAlpha for the sine, and it looks like a good approximation for $x$ from $-0.6$ to $+.6$.
The cosine function and its approximation is plotted here.
I hope they never had to calculate the cosine for a value $geq tfracpi2$, because then the error would be unpleasantly large.
Note that for the taylor approximation you only need four multiplications and two additions (MP and AD in the code).
There are some ways to increase accuracy and input range, which would have been available for them, but would result in more code and more computation time.
For example, exploiting symmetry and periodicity of sine and cosine, using the taylor expansion for cosine, or simply adding more terms of the taylor expansion would have improved the accuracy and would also allow for arbitrary large input values.
answered 5 hours ago
supinf
30116
New contributor
supinf is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
2
I am reading into it, but it is not easy because i am not familiar with the programming language. At first glance it looks like a taylor approximation, but i am not sure. I will edit when i have more.
– supinf
5 hours ago
3
The scaling is due to the fact that single precision could only store value from -1 to +1 :). Precision is around 13 bits which fits the single precision type (16 bits one of which is the sign bit and one was a parity bit not accessable to software).
– Christoph
4 hours ago
6
Oh lordy... I haven't seen assembly since college, I can't imagine having to write an entire guidance computer using nothing but OP-Codes and low-level functions. Also welcome to the SE, brilliant answer.
– Magic Octopus Urn
4 hours ago
2
On topic: error graph. Maximum error within the domain would be around 0.0001
– SF.
4 hours ago
2
Terrific analysis! I've never had much success trying to read AGC assembly myself. Welcome aboard.
– Russell Borogove
1 hour ago
 |Â
show 12 more comments
up vote
34
down vote
up vote
34
down vote
Since the Apollo 11 Code is on Github, i was able to find the code that looks like an implementation of sine and cosine functions: see here for the command module and here for the lunar lander (it looks like it is the same code).
For convenience, here is a copy of the code:
# Page 1102
BLOCK 02
# SINGLE PRECISION SINE AND COSINE
COUNT* $$/INTER
SPCOS AD HALF # ARGUMENTS SCALED AT PI
SPSIN TS TEMK
TCF SPT
CS TEMK
SPT DOUBLE
TS TEMK
TCF POLLEY
XCH TEMK
INDEX TEMK
AD LIMITS
COM
AD TEMK
TS TEMK
TCF POLLEY
TCF ARG90
POLLEY EXTEND
MP TEMK
TS SQ
EXTEND
MP C5/2
AD C3/2
EXTEND
MP SQ
AD C1/2
EXTEND
MP TEMK
DDOUBL
TS TEMK
TC Q
ARG90 INDEX A
CS LIMITS
TC Q # RESULT SCALED AT 1.
The comment
# SINGLE PRECISION SINE AND COSINE
indicates, that the following is indeed an implementation of the sine and cosine functions.
Information about the type of assembler used, can be found on Wikipedia
Partial explanation of the code:
The subroutine SPSIN actually calculates $sin(pi x)$, and SPCOS calculates $cos(pi x)$.
The subroutine SPCOS first adds one half to the input, and then proceeds to calculate the sine
(this is valid because of $cos(pi x) = sin(pi (x+tfrac12))$).
The argument is doubled at the begin of the SPT subroutine.
That is why we now have to calculate $sin(tfracpi2 y)$ for $y=2x$.
The subroutine POLLEY calculates a taylor polynomial approximation of $sin(tfracpi2 x)$.
First, we store $x^2$ in the register SQ (where $x$ denotes the input).
This is used to calculate the polynomial
$$
((( C_5/2 x^2 ) + C_3/2 ) x^2 + C_1/2) x.
$$
The values for the constants can be found in the same github repository and are
$$
C_5/2= .0363551 approx big(fracpi2big)^5 cdot frac12cdot 5!\
C_3/2= -.3216147 approx -big(fracpi2big)^3 cdot frac12cdot 3!\
C_1/2= .7853134 approx fracpi2 cdot frac12\
$$
which look like the first taylor coefficients for the function
$frac12 sin(tfracpi2 x)$.
These values are not exact, but I suspect that the error comes from the low bit resolution.
Finally, the result is doubled with the DDOUBL command, and the subroutine POLLEY returns an approximation to
$sin(tfracpi2 x)$.
As for the scaling (first halve, then double, ...), @Christopher mentioned in the comments, that the 16-Bit Fixed-Point number could only store values from -1 to +1. Therefore, scaling is necessary. See here for a source and further details on the data representation.
How accurate is this taylor approximation? Here you can see a plot on WolframAlpha for the sine, and it looks like a good approximation for $x$ from $-0.6$ to $+.6$.
The cosine function and its approximation is plotted here.
I hope they never had to calculate the cosine for a value $geq tfracpi2$, because then the error would be unpleasantly large.
Note that for the taylor approximation you only need four multiplications and two additions (MP and AD in the code).
There are some ways to increase accuracy and input range, which would have been available for them, but would result in more code and more computation time.
For example, exploiting symmetry and periodicity of sine and cosine, using the taylor expansion for cosine, or simply adding more terms of the taylor expansion would have improved the accuracy and would also allow for arbitrary large input values.
answered 5 hours ago
supinf
30116
New contributor
supinf is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Since the Apollo 11 Code is on Github, i was able to find the code that looks like an implementation of sine and cosine functions: see here for the command module and here for the lunar lander (it looks like it is the same code).
For convenience, here is a copy of the code:
# Page 1102
BLOCK 02
# SINGLE PRECISION SINE AND COSINE
COUNT* $$/INTER
SPCOS AD HALF # ARGUMENTS SCALED AT PI
SPSIN TS TEMK
TCF SPT
CS TEMK
SPT DOUBLE
TS TEMK
TCF POLLEY
XCH TEMK
INDEX TEMK
AD LIMITS
COM
AD TEMK
TS TEMK
TCF POLLEY
TCF ARG90
POLLEY EXTEND
MP TEMK
TS SQ
EXTEND
MP C5/2
AD C3/2
EXTEND
MP SQ
AD C1/2
EXTEND
MP TEMK
DDOUBL
TS TEMK
TC Q
ARG90 INDEX A
CS LIMITS
TC Q # RESULT SCALED AT 1.
The comment
# SINGLE PRECISION SINE AND COSINE
indicates, that the following is indeed an implementation of the sine and cosine functions.
Information about the type of assembler used, can be found on Wikipedia
Partial explanation of the code:
The subroutine SPSIN actually calculates $sin(pi x)$, and SPCOS calculates $cos(pi x)$.
The subroutine SPCOS first adds one half to the input, and then proceeds to calculate the sine
(this is valid because of $cos(pi x) = sin(pi (x+tfrac12))$).
The argument is doubled at the begin of the SPT subroutine.
That is why we now have to calculate $sin(tfracpi2 y)$ for $y=2x$.
The subroutine POLLEY calculates a taylor polynomial approximation of $sin(tfracpi2 x)$.
First, we store $x^2$ in the register SQ (where $x$ denotes the input).
This is used to calculate the polynomial
$$
((( C_5/2 x^2 ) + C_3/2 ) x^2 + C_1/2) x.
$$
The values for the constants can be found in the same github repository and are
$$
C_5/2= .0363551 approx big(fracpi2big)^5 cdot frac12cdot 5!\
C_3/2= -.3216147 approx -big(fracpi2big)^3 cdot frac12cdot 3!\
C_1/2= .7853134 approx fracpi2 cdot frac12\
$$
which look like the first taylor coefficients for the function
$frac12 sin(tfracpi2 x)$.
These values are not exact, but I suspect that the error comes from the low bit resolution.
Finally, the result is doubled with the DDOUBL command, and the subroutine POLLEY returns an approximation to
$sin(tfracpi2 x)$.
As for the scaling (first halve, then double, ...), @Christopher mentioned in the comments, that the 16-Bit Fixed-Point number could only store values from -1 to +1. Therefore, scaling is necessary. See here for a source and further details on the data representation.
How accurate is this taylor approximation? Here you can see a plot on WolframAlpha for the sine, and it looks like a good approximation for $x$ from $-0.6$ to $+.6$.
The cosine function and its approximation is plotted here.
I hope they never had to calculate the cosine for a value $geq tfracpi2$, because then the error would be unpleasantly large.
Note that for the taylor approximation you only need four multiplications and two additions (MP and AD in the code).
There are some ways to increase accuracy and input range, which would have been available for them, but would result in more code and more computation time.
For example, exploiting symmetry and periodicity of sine and cosine, using the taylor expansion for cosine, or simply adding more terms of the taylor expansion would have improved the accuracy and would also allow for arbitrary large input values.
answered 5 hours ago
supinf
30116
New contributor
supinf is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
edited 3 hours ago
answered 5 hours ago
supinf
30116
New contributor
supinf is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
answered 5 hours ago
supinf
30116
answered 5 hours ago
supinf
30116
30116
New contributor
supinf is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
supinf is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
supinf is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
2
I am reading into it, but it is not easy because i am not familiar with the programming language. At first glance it looks like a taylor approximation, but i am not sure. I will edit when i have more.
– supinf
5 hours ago
3
The scaling is due to the fact that single precision could only store value from -1 to +1 :). Precision is around 13 bits which fits the single precision type (16 bits one of which is the sign bit and one was a parity bit not accessable to software).
– Christoph
4 hours ago
6
Oh lordy... I haven't seen assembly since college, I can't imagine having to write an entire guidance computer using nothing but OP-Codes and low-level functions. Also welcome to the SE, brilliant answer.
– Magic Octopus Urn
4 hours ago
2
On topic: error graph. Maximum error within the domain would be around 0.0001
– SF.
4 hours ago
2
Terrific analysis! I've never had much success trying to read AGC assembly myself. Welcome aboard.
– Russell Borogove
1 hour ago
 |Â
show 12 more comments
2
I am reading into it, but it is not easy because i am not familiar with the programming language. At first glance it looks like a taylor approximation, but i am not sure. I will edit when i have more.
– supinf
5 hours ago
3
The scaling is due to the fact that single precision could only store value from -1 to +1 :). Precision is around 13 bits which fits the single precision type (16 bits one of which is the sign bit and one was a parity bit not accessable to software).
– Christoph
4 hours ago
6
Oh lordy... I haven't seen assembly since college, I can't imagine having to write an entire guidance computer using nothing but OP-Codes and low-level functions. Also welcome to the SE, brilliant answer.
– Magic Octopus Urn
4 hours ago
2
On topic: error graph. Maximum error within the domain would be around 0.0001
– SF.
4 hours ago
2
Terrific analysis! I've never had much success trying to read AGC assembly myself. Welcome aboard.
– Russell Borogove
1 hour ago
2
2
I am reading into it, but it is not easy because i am not familiar with the programming language. At first glance it looks like a taylor approximation, but i am not sure. I will edit when i have more.
– supinf
5 hours ago
I am reading into it, but it is not easy because i am not familiar with the programming language. At first glance it looks like a taylor approximation, but i am not sure. I will edit when i have more.
– supinf
5 hours ago
3
3
The scaling is due to the fact that single precision could only store value from -1 to +1 :). Precision is around 13 bits which fits the single precision type (16 bits one of which is the sign bit and one was a parity bit not accessable to software).
– Christoph
4 hours ago
The scaling is due to the fact that single precision could only store value from -1 to +1 :). Precision is around 13 bits which fits the single precision type (16 bits one of which is the sign bit and one was a parity bit not accessable to software).
– Christoph
4 hours ago
6
6
Oh lordy... I haven't seen assembly since college, I can't imagine having to write an entire guidance computer using nothing but OP-Codes and low-level functions. Also welcome to the SE, brilliant answer.
– Magic Octopus Urn
4 hours ago
Oh lordy... I haven't seen assembly since college, I can't imagine having to write an entire guidance computer using nothing but OP-Codes and low-level functions. Also welcome to the SE, brilliant answer.
– Magic Octopus Urn
4 hours ago
2
2
On topic: error graph. Maximum error within the domain would be around 0.0001
– SF.
4 hours ago
On topic: error graph. Maximum error within the domain would be around 0.0001
– SF.
4 hours ago
2
2
Terrific analysis! I've never had much success trying to read AGC assembly myself. Welcome aboard.
– Russell Borogove
1 hour ago
Terrific analysis! I've never had much success trying to read AGC assembly myself. Welcome aboard.
– Russell Borogove
1 hour ago
 |Â
show 12 more comments
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fspace.stackexchange.com%2fquestions%2f30952%2fhow-did-the-apollo-computers-evaluate-transcendental-functions-like-sine-arctan%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Are you sure about the need to do trigonometry for gimbaling? I'm pretty sure it would be easier to stay within vector math if you use a linear actuator. Anyway trignonometry functions are usually implemented by table lookup or approximated as a taylor expansion. No source directly related to Apollo, sorry.
– Christoph
6 hours ago
1
...or both, the taylor expansion preparing lookup tables on startup, in case permanent storage is less abundant than RAM.
– SF.
6 hours ago
@Christoph First sentence starts with two instruments that likely produce angular data. Also, what was done in the 1960's in computers in space, is not covered by how things are done now. I'll add the
historytag to make that even clearer. You might also consider where tables would have to be stored, there was precious little memory in the Apollo computers.– uhoh
6 hours ago
3
@Christoph: Already in 1956 we had a better algorithm than Taylor, namely CORDIC. I don't know if that was used in Apollo.
– MSalters
5 hours ago
1
Storage (permanent and dynamic both) was at a huge premium so it's not surprising they didn't keep a table.
– Russell Borogove
54 mins ago