EXC/ x<>Rn for stack efficiency
|
06-27-2017, 09:42 PM
(This post was last modified: 06-27-2017 09:46 PM by Matt Agajanian.)
Post: #41
|
|||
|
|||
RE: EXC/ x<>Rn for stack efficiency
(06-19-2017 05:44 PM)GrampaDave Wrote:Quote:Herman the moonshiner Yea, these were what added to the fun & enjoyment of learning how to use our HP calculators. On another note, as advanced and to compete with the SR-52, I wonder why HP did not include an EXC function on the 67, but waited until the HP-41. |
|||
06-28-2017, 12:42 AM
(This post was last modified: 06-28-2017 12:43 AM by Thomas Okken.)
Post: #42
|
|||
|
|||
RE: EXC/ x<>Rn for stack efficiency
(06-27-2017 09:42 PM)Matt Agajanian Wrote:(06-19-2017 05:44 PM)GrampaDave Wrote: But HP had better names, whose sly humor made them memorable, at least to native English speakers. Because the HP-67 had "merged keystrokes," meaning every instruction was one byte. PANAMATIK posted this very enlightening link the other day: http://www.panamatik.de/ProgramCodes.pdf With the HP-41C, HP let go of the one-byte-per-instruction thing, and that enabled them to do what TI was doing, i.e. allow register numbers from 00 to 99, and add new functions like EXC a.k.a. X<>. In the HP-42S, they took this even further, adding RCL+ etc., and alphanumeric variable names. |
|||
06-28-2017, 01:37 AM
(This post was last modified: 06-28-2017 01:57 AM by Matt Agajanian.)
Post: #43
|
|||
|
|||
RE: EXC/ x<>Rn for stack efficiency
Yes, I saw that table when it was posted. Maybe I'm missing something in your explanation. How would [f] [x<>] n (or [x<>] n) consume more than one/two bytes? HP had room for [STO] +, -, x, / n. So. wouldn't the exchange function consume one/two bytes?
ADDENDUM Okay, upon inspecting the HP-67 table, I think I see what you're saying. Each instruction had to be given a one-byte hex code. After all was said and done, if I read the 67 table correctly, there are only four vacant spaces. So, there was no way to give 11 (0-9, (i) ) op codes for register exchange functionality. And, limiting exchange to four registers doesn't make sense. Right? |
|||
07-20-2022, 07:03 PM
Post: #44
|
|||
|
|||
RE: EXC/ x<>Rn for stack efficiency
This looks like an XY problem to me.
Here is a program to calculate the great circle distance between two points A and B on a sphere. Since no registers are used, the initial question X is not relevant. All you ever wanted is a solution for Y. Program This program works for most HP calculators: HP-25 Code: 01: 21 : x<->y HP-15C Code: 001 { 34 } x↔y HP-42S Code: 00 { 24-Byte Prgm } Example This is the example provided for the SR-56: Point A: \(33^\circ 54.5'\) N, \(94^\circ 56.2'\) W Point B: \(33^\circ 59.6'\) S, \(151^\circ 25.6'\) E DEG 33.5430 →HR 33.908333 94.5612 →HR 94.936667 -33.5936 →HR -33.993333 -151.2536 →HR -151.426667 R/S 125.999888 If we want to get the result in nautical miles we can multiply the result by 60: 60 × 7559.993276 Or then we could convert degrees to radians and multiply the result by earth's radius. Formula (06-15-2017 10:29 AM)Paul Dale Wrote: It ought to be possible to calculate the distance using the modified Vincenty formula on the 25: These programs use the same formula as the original program for the SR-56: \( \Delta \sigma =\arccos \left ( \sin \phi _{1}\sin \phi _{2}+\cos \phi _{1}\cos \phi _{2}\cos(\Delta \lambda ) \right ) \) Conversion (06-15-2017 09:01 AM)Dieter Wrote: This will for instance show that the complete routine in the first steps (which is called several times as SBR 00) is obsolete since it does a simple d.ms to decimal degrees conversion (e.g. it turns 42°50' into 42,8333°). The 25 and 33 have a dedicated function for this. Well, not exactly. Therefore we have to convert e.g. \(94^\circ {56.2}'\) to \(94^\circ {56}' {12}''\) in our heads. References The original link to this document appears to be broken. (06-15-2017 09:01 AM)Dieter Wrote: But I am sure that HP25 great circle programs already exist. ;-)
Code: 01: 24 00 : RCL 0 |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 2 Guest(s)