HP-35s Euclid Implementation - VIII : Defining a triangle

Yet another 'data entry' program, this one for defining a triangle in 3D space. It will be needed for solving triangle problems (14-17 of the requirements) but is also usefull to solve plane problems when the plane is defined by three points (problem 9 A of the requirements), so introducing it now.

The program accepts triangle's first point in the Z stack register, second point in Y stack register and third point in the X stack register, all expected to be 3D vectors. Program performs two tasks:

1. Store the points in the variables K (first point), L (second point) and M (third point). These variables will be used later in solving triangle problems.
   
2. Returns in the X stack register a vector normal to the plane defined by the triangle computed as (L-K)x(M-K) (x is here the cross product). This gives the area of the triangle since the length of this vector is twice the area (keystrokes: ABS, 2, /).

Stack Input/Output:

[[x2, y2, z2], [x1, y1, z1], [x0, y0, z0] | L]->XEQ T->[[nx, ny, nz], [x2, y2, z2], [x1, y1, z1], [x0, y0, z0] | L]

Where v0=(x0, y0, z0) is first, v1=(x1, y1, z1) is second, v2=(x2, y2, z2) is the third triangle vertex and [nx, ny, nz] is the cross product (v1-v0)x(v2-v0).

Variables:

Writes:

K : First vertex.
L : Second vertex.
M : Third vertex.

Program:

T001 LBL T
TOO2 5
T003 STO I
T004 STO(I)
T005 RDN
T006 4
T007 STO I
T008 RDN
T009 LASTX
T010 STO(I)
T011 RDN
T012 STO M
T013 RDN
T014 STO L
T015 RDN
T016 STO K
T017 R^
T018 X<>Y
T019 -
T020 RDN
T021 RDN
T022 LASTX
T023 -
T024 X<>Y
T025 RDN
T026 XEQ X001
T027 RCL(I)
T028 ABS
T029 RDN
T030 RCL K
T031 RCL L
T032 RCL M
T033 R^
T034 RTN

Comments:

Terms of use.

Mnemonic: T for triangle.

If end user need to compute the plane's normalized implicit equation she may simply do XEQ P since X stack register contains a vector normal to the plane and Y register a point in the plane (triangle's third vertex).

Change history:

20071018:1950UTC : This program has been modified as a part of providing for Cartesion to Barycentric coordinate transformation.

Allocate memory on the HP-35s or Zero is also a number to remember!

Found errors in my hp-35s programs due to the stupid way memory is managed on it, yea, yea, it's my fault, but still:

While not a bug I think the 35s indirect register handling is pretty ..... stupid ....

Say you want to store N numbers in register 0...N-1, god forbid some or your last numbers happens to be 0 (a perfectly okey number) AND register N,... hapens not to be allocated. You get an INVALID when trying to learn that number N-1 was 0!

What you must do is to allocate your N registers by putting a 'watermark' non zero in register N.

I do not mind allocating and deallocating memory, but this reality of hp-35s is: a) implication not well documented, b) error prone. What I think should been here is commands to allocate registers and to free registers!

HP-35s Euclid Implementation - VII : Defining a plane

Time to start working with the plane: First a data entry program to define a plane given a point in the plane and a vector normal to it.

This program is similar to the L program in that it computes a hyperplane's (now of 3D space) implicit equation (problem 9A of the specification).

The program accepts the defining point in the Y stack register and a vector normal to the plane in X stack register.

It stores the point that defines the plane in variable P (mnemonic: plane's point), the normalized normal vector in variable N (mnemonic: plane's normal) and the constant d of the plane's implicit equation ax+by+cz+d=0 in variable O (mnemonic: distance from origo to plane, true since equation normailized; see comments section). Since [a, b, c] is the plane's normal (stored in variable N) the computation of d=-(N*P) (* is here the dot product) is what is to be done to compute the plane's implicit equation.

Stack Input/Output:

[[nx, ny, nz], [x, y, z], Z, T | L]-> XEQ P->[d, [a, b, c], [x, y, z], Z | [nx, ny, nz]]

Where [nx, ny, nz] is a vector normal to the plane and (x, y, z) is a point in the plane. Output is the constants of the normalized implicit plane equation ax+by+cz+d=0. Content of Y stack register [a, b, c] is [nx, ny, nz] normalized, orginal vector can be found in LASTX register.

Variables:

Writes:

N : Plane's normalized normal vector.
O : Signed distance to origo (0, 0, 0).
P : Defining point in plane.

Program:

POO1 LBL P
P002 XEQ X004
P003 STO N
P004 X<>Y
P005 STO P
P006 eq -(PxN)
P007 STO O
P008 RDN
P009 X<>Y
P010 R^
P011 RTN

Comments:

Terms of use.

Mnemonics: P for Plane.

Importent to remember when entering line P006: Stroke the +/- key not the - operation key to get the equation's sign. Using the - operator key will result in a program that looks fine but causes a SYNTAX error when line P006 is executed.

Reason for normalizing the normal vector defining the plane are:

• Because it is often done. For example planes defined by a triangles found in the dataset of a Computer Graphics application's polygon model typical has normalized normal vectors associated with it's triangles.
  
• When the normal vector defining the plane is normalized the plane's implicit equation is said to be normalized. Representing the plane using the normalized implicit equation has the advantage that some formulas for plane problems becomes simplified.
  

Since the implicit equation is normalized the d term of ax+by+cd+d, the value in the X stack register is the signed distance from the origo (0, 0, 0) to the plane.

Cross product and normalizing a vector on the HP-35s

NOTE: An error has been corrected in this program listing around 20070927 16:30 UTC.

Now need to calculate the cross product of two 3D vector in the HP-35s Euclid Pack implementation. One should think that the cross product would have been a build in function on th 35s, but no, we need to roll our own: Line 001-003 in the following program.

Normalizing a vector (keeping direction but making it of unit length) is a common operation performed on directional only vectors. Subroutine X006 performs normalization.

Stack Input/Output:

Cross product:

[[ux, uy, uz], [vx, vy, vz], Z, T | L]-> XEQ X001 ->[[wx, wy, wz], [ux, uy, uz], [vx, vy, vz], Z | L]

Where the w vector is the result of u*v.

Normalization:

[u, Y, Z, T | L]-> XEQ U004 ->[u/|u|, Y, Z, T | u]

Where u is a 2D or 3D.

Program:

X001 LBL X
X002 eq [([0,1,0]xREGY)x([0,0,1]xREGX)-([0,0,1]xREGY)x([0,1,0]xREGX),
         ([0,0,1]xREGY)x([1,0,0]xREGX)-([1,0,0]xREGY)x([0,0,1]xREGX),
         ([1,0,0]xREGY)x([0,1,0]xREGX)-([0,1,0]xREGY)x([1,0,0]xREGX)]
X003 RTN
X004 ABS
X005 RDN
X006 eq LASTX/REGT
X007 RTN

Comments:

Terms of use.

HP-35s Euclid Implementation - VI : Closest points on two lines

The following program addresses problem 7 and 8 in the requirements, it finds the closest points on two non paralell lines or tells if the lines are paralell. In 2D non paralell lines intersect so if working in 2D this finds the intersection point. For 3D lines the two points found defines the shortest line segment between two non paralell lines. The length of this line segment is the shortest distance between the lines. Ofcourse 3D lines can intersect: The two points found are then the same point.

The first line has been entered using the L program (refered to as l) and the second is given as first point in the Y stack register and the second in the X stack register (refered to as m).

Stack Input/Output:

[[x1, y1, z1], [x0, y0, z0], Z, T | L]-> XEQ M ->[s, t, [x1, y1, z1], [x0, y0, z0] | L]

Where (x0, y0, z0) is the first point defining m, (x1, y1, z1) is the second point defining m, s is the parameter defining the closest point on l to m and t is the parameter defining the closest point on m to l.

If the lines are paralell the message PARALELL is shortly displayed. The stack and LASTX registers are left unchanged in this case.

Variables:

Reads:

A : 'First' line l's first defining point.
B : 'Second' line l's first defining point.

Writes:

D : 'Second' line m's first defining point.
E : 'Second' line m's second defining point.
Z : Scratch data.

Program:

M001 LBL M
M002 XEQ U001
M003 STO E
M004 X<>Y
M005 STO D
M006 -
M007 RCL B
M008 RCL- A
M009 eq [REGXxREGX,REGXxREGY,REGYxREGY]
M010 STO Z
M011 RDN
M012 RCL A
M013 RCL- D
M014 eq [REGYxREGX,REGZxREGX]
M015 eq ([1,0,0]xZ)x([0,0,1]xZ)-([0,1,0]xZ)x([0,1,0]xZ)
M016 eq ([0,1,0]xZ)x([0,1]xREGY)-([0,0,1]xZ)x([1,0]xREGY)
M017 X<>Y
M018 ABS
M019 1E-6
MO20 X>Y?
M021 GOTO M041
M022 RDN
M023 RDN
M024 LASTX
M025 /
M026 eq ([1,0,0]xZ)x([0,1]xREGY)-([0,1,0]xZ)x([1,0]xREGY)
M027 LASTX
MO28 /
M029 X<>Y
M030 4
M031 STO I
M032 RDN
M033 RCL(I)
M034 ABS
M035 RDN
M036 RCL D
M037 RCL E
M038 RDN
M039 RDN
M040 RTN
M041 SF 10
M042 eq PARALELL
M043 PSE
M044 CF 10
M045 XEQ U029
M046 RTN

Comments:

Terms of use.

If end user needs the coordinates for the closest point on l to m she need only do XEQ E. The M program actual stores the defining points for the m line in variables D (first point) and E (second point) so that with the following short program similar to the E program the coordinate for the closest point on line m to line l can be calculated by moving the parameter for the m line to the X register and do XEQ F:

Stack Input/Output:

3D case: [t, Y, Z, T | L]-> XEQ F ->[[x, y, z], Y, Z, T | t]

2D case: [t, Y, Z, T | L]-> XEQ F ->[[x, y], Y, Z, T | t]

Where t is the parameter and (x, y, z) is the evaluated point if a 3D line has been entered using the M program and (x, y) is the evaluated point if a 2D line has been entered using the M program.

Variables:

Reads:

D: First point defining the line, populated by the M program.
E: Second point defining the line, populated by the M program.

Program:

F001 LBL F
F002 ABS
F003 RDN
F004 (1-LASTX)xD+LASTXxE
F005 RTN

Mnemonics: Like the L program the program M stores a line (but the implicit equation constants are not computed for this 'secondary' line) so is put next to the L key. Same for the F program: Put next to the E program (that compute coordinates on l).

Allowed one variable to be used for scratch data: The Z variable register.

Change history:

20070929:2035UTC : Change because of fix in U program.
20071002:1835UTC : Bug fix: Did not take absolute value of denominator value when doing epsilon-zero test!.

Addition to the HP-35s stack save/restore program - I

The following extension to the U001 subroutine allow for simulating unary operation (one that only operates on value in X stack register and saves old value in LASTX register): Get what was in the X register to LASTX, leave what is in X register in X (this is your new operation's result) and restore Y, Z and T registers.

Program:

U050 0
U051 STO I
U052 RDN
U053 RCL(I)
U054 ABS
U055 RDN
U056 3
UO57 STO I
U058 RDN
U059 RCL(I)
U060 2
U061 STO I
UO62 RDN
U063 RCL(I)
U064 1
U065 STO I
U066 RDN
U067 RCL(I)
U068 R^
U069 RTN

Comments:

Terms of use.

So now we have the subroutines:

1. XEQ U001 to save the stack and LASTX.
2. XEQ U029 to restore the stack and LASTX given U001 has been used to save.
3. XEQ U050 to implement operation native unary operation stack and LASTX behaviour given U001 has been used to save.
   

Change history:

20070929:2035UTC : Change because of fix in U program.

HP-35s Euclid Implementation - V : Closest point on a line to a point

The following program finds the parameter giving the closest point (problem 6 (and 5) in the requirements) on the line entered by the L program to a given point.

Remembering that the positional vector for first point defining the line is in variable A, second point is in variable B and saying that the point in question's positional vector is in the X stack register the formula for the parameter is: t=((X-A)*(B-A))/((B-A)*(B-A)).

Stack Input/Output:

[[x, y, z], Y, Z, T | L]-> XEQ C ->[t, Y, Z, T | [x, y, z]]

Where (x, y, z) is the point p in question and t is the parameter defining the closest point on the line to p.

Variables:

Reads:

A: First point defining the line, populated by the L program.
B: Second point defining the line, populated by the L program.

Program:

C001 LBL C
C002 XEQ U001
C003 RCL A
C004 -
C005 RCL B
C006 RCL A
C007 -
C008 x
C009 LASTX
C010 ENTER
C011 x
C012 /
C013 XEQ U050
C014 RTN

Comments:

Terms of use.

Mnemonic: C for closest point.

The program does not calculate the coordinates for the closest point on line since end user may only be interested in the parameter that tells if point is on the defining line segment or on which ray. The coordinates are only one program away: XEQ E.

I decide not to implement a program for problem 5 (distance from a 3D line to a point) in the requirements since end user easily now can find the perpendicular line from the point to the line, and length of it's defining line segment is the distance from line to the point. The operation sequence after this program is run:

LASTX  // Get back point which to find perpendicular line on stored line or distance.
X<>Y   // Parameter back in X stack register.
XEQ E  // Find coordinates to closest point on line.
       // Now Y and X stack registers contains two points defining the perpendicular
       // line, one could now run program L to store this line for further
       // computation relating to that line.
-      // Continuing to find distance: Get perpendicular line segment directional
       // vector of segment's length in X and
ABS    // the length.

This program works for both 2D and 3D data so do not need to check the 2 flag, but if one are to enter the perpendicular line as computed in above paragraph one should remember to have it set if working in 2D so the implicit equation is computed.

Change history:

20070929:2035UTC : Change because of fix in U program.

HP-35s Euclid Implementation - IV : Normalizing a line definition

The following program adjust second point (in register B) so that the line segment defining the line entered using the program L is of unit length (problem 4 of the requirements).

It then becomes easy to produce coordinates of a given distance from the defining segments first point (in register A) using program E since the distance then is the given parameter.

Stack Input/Output:

This program does not take any stack register input, stack register and LASTX register is left unchanged by this program.

Variables:

Reads:

A: First point defining the line, populated by the L program.
B: Second point defining the line, populated by the L program.

Writes:

B: Adjust so line segment becomes of unit length.

Program:

N001 LBL N
N002 XEQ U001
N003 RCL A
N004 eq 1/ABS(B-A)
N005 STOx A
N006 STOx B
N007 RDN
N008 RCL A
N009 -
N010 STO+ A
N011 STO+ B
N012 XEQ U029
N013 RTN

Comments:

Terms of use.

Mnemonic: N for Normal since normalize the vector B-A.

Since this program does not take any input from the stack registers but messes up the stack and LASTX registers it uses the U program to hide this from the end user; line 2 saves stack and LASTX registers and line 14 restores the working registers.

Change history:

20070929:2035UTC : Change because of fix in U program.
20071001:2040UTC : Do no longer recompute implicit equation of 2D line (used to check flag 2) since program L now stores the normalized implicit equation.

Modified HP-35s stack save/restore program

Decided wanted the U program to also save/restore the LASTX register.

Modified program:

U001 LBL U
U002 X<> I
U003 RDN
U004 0
U005 X<> I
U006 STO(I)
U007 RDN
U008 1
U009 STO I
U010 RDN
U011 STO(I)
U012 RDN
U013 2
U014 STO I
U015 RDN
U016 STO(I)
U017 RDN
U018 3
U019 STO I
U020 RDN
U021 STO(I)
U022 4
U023 STO I
U024 LASTX
U025 STO(I)
U026 5
U027 STO I
U028 STO(I)
U029 4
U030 STO I
U031 RCL(I)
U032 ABS
U033 3
U034 STO I
U035 RDN
U036 RCL(I)
U037 2
U038 STO I
U039 RDN
U040 RCL(I)
U041 1
U042 STO I
U043 RDN
U044 RCL(I)
U045 0
U046 STO I
U047 RDN
U048 RCL(I)
U049 RTN

Comments:

Terms of use.

LASTX is saved to register 4 and register 5 gets a non zero to allocate registers for sure.

Recall soubroutine is now U029.

Change history:

20070929:2035UTC : An error has been corrected: The error had to do with not properly allocating indirect registers if happen to store zeros in reg. 4 and downwards in sequence... See here for more on this topic.

Saving HP-35s' stack in indirect registers

NOTE: Program here has bugs and is no longer maintained, use program listed here.

The method of imitating native operations stack and lastx behaviour used here and here is perfect for cases when job can be done with a single equation. For longer and more traditional rpn type of programs one may want to save the stack.

The following program stores X stack register content in register 0, Y stack register in 1, Z stack register in 2 and T stack register in 3.

Program:

U001 LBL U
U002 X<> I
U003 RDN
U004 0
U005 X<> I
U006 STO(I)
U007 RDN
U008 1
U009 STO I
U010 RDN
U011 STO(I)
U012 RDN
U013 2
U014 STO I
U015 RDN
U016 STO(I)
U017 RDN
U018 3
U019 STO I
U020 RDN
U021 STO(I)
U022 3
U023 STO I
U024 RDN
U025 RCL(I)
U026 2
U027 STO I
U028 RDN
U029 RCL(I)
U030 1
U031 STO I
U032 RDN
U033 RCL(I)
U034 0
U035 STO I
U036 RDN
U037 RCL(I)
U038 RTN

Comments:

Terms of use.

The start is a bit tricky since we are storing in indirect registers (do not want to use high valuable variable registers for this) and need to enter index 0 in I but stack is full of stuff not to be lost. Rescue operator is X<> I: Swaps content in I with X, get old I content to T and put index O in X, swap it with old X content which then is stored in register 0. From then on it is straight forward.

This program restore the stack after it is saved (program calling propably would like that...), that is what lines 22-38 does. Note that when 22-38 execute in context of last part of saving the stack there are some redundant lines, but wrote it like this so XEQ U022 can be used in general to recall saved stack.

NOTE: I made a modification and an extension to this program.

HP-35s Euclid Implementation - III : Evaluating points on a line

A simple but important operation is to evaluate points on a line using it's parametric equation (item 3 in the specification); (1-t)p+tq (linear interpolation/extrapolation) where t is the scalar parameter and p is the position vector for first point defining the line and q the position vector for the second point.

The importance of this operation is:

1. More practical to produce points of the line than the implicit equation.
2. Works in any dimension.
3. It is more usefull to have programs that solves problems where the solution is a point on a line produce the parameter giving the point then the actual coordinates: The parameter tells if the point is on the line segment defining the line (0<=t<=1), on the ray starting at first point and traveling away from second point (t<0) or on other ray if t>1. Use this program if want coordinates after parameter inspection.
   

Stack Input/Output:

3D case: [t, Y, Z, T | L]-> XEQ E ->[[x, y, z], Y, Z, T | t]

2D case: [t, Y, Z, T | L]-> XEQ E ->[[x, y], Y, Z, T | t]

Where t is the parameter and (x, y, z) is the evaluated point if a 3D line has been entered using the L program and (x, y) is the evaluated point if a 2D line has been entered using the L program.

Variables:

Reads:

A: First point defining the line, populated by the L program.
B: Second point defining the line, populated by the L program.

Program:

E001 LBL E
E002 ABS
E003 RDN
E004 eq (1-LASTX)xA+LASTXxB
E005 RTN

Comments:

Terms of use.

Mnemonic: E for evaluate.

HP-35s Euclid Implementation - II : Signed distance from a 2D line to a 2D point

NOTE: This program has been modified.

The 2D line is the hyperplane of 2D space meaning a line divide the space (a point is the hyperplane of 1D space and plane the is the hyperplane of 3D space). This manifest itself in that if we use the left side of the implicit equation ax+by+c=0 as a function we get out a number that is 0 if (x, y) is on the line, negative sign if on one side and positive sign if on the other.

In the case that |[a, b]|=1, the implicit equation is said to be normalized and ax+by+c is in fact the (signed) distance from the point (x, y) to the line. Since the program L do store the normalized line equation this program simply computes ax+by+c.

Stack Input/Output:

[[x, y], Y, Z, T | L]-> XEQ S ->[d, Y, Z, T | [x, y]]

Where (x, y) is point to find distance to and d is the signed distance.

Variables:

Reads:

C : [a, b, c], constants of line's normalized implicit equation. Populated by the L program.

Program:

S001 LBL S
S002 ABS
S003 RDN
S004 eq (([1,0,0]xC)x([1, 0]xLASTX))+(([0,1,0]xC)x([0,1]xLASTX))+[0,0,1]xC
S005 RTN

Comments:

Terms of use.

Mnemonic: S for signed distance.

The line distance is computed from is entered using the program L and the point is in the X stack register as a 2D vector.

This program does not test for the 2 flag since it only work on a 2D problem.

An important feature I wanted from this program is that it behaves like a build in function: The argument in the X stack register (the point) goes to LASTX register, result (signed distance) appears in the X stack register and Y, Z and T stack registers are left unchanged. First version fooled around saving stack content in indirect registers, but then I found Valentin Albillo (VA) trick in a MoHPC forum post used here: Thanks VA, expects that to be utilized more!

Change history:

20071001:2010UTC : No longer divide ax+by+c by |[a, b]| since now the normalized implicit equation is stored.
20071001:2210UTC : New version of program.

HP-35s Euclid Implementation - I : Defining a line

The first program in the HP-35s Euclid Pack implementation is one to accept a line defined by two points to be used for further calculations. The program stores first point in variable A and second point in variable B.

What I realy would like is if this program could tell the dimension of vectors or if input is scalar, this could be used for:

1. Check if gets what is expected (vectors). As it is now the program will do nothing more for 3D lines but to store points in correct variables, might as well use STO commands directly in 3D case.

2. For 2D lines I would like it to compute the constants of the lines implicit equation ax+by+c=0 and store it in variable C as a 3D vector [a, b, c] (problem 1 in the specification). Since this is not possible I am introducing a 2D mode: If flag 2 is set then user is working in 2D, programs that need do perform different based on dimension of input will check this flag.

Stack Input/Output:

2D case: [[x1, y1], [x0, y0], Z, T | L]-> XEQ L ->[[a, b, c], [x1, y1], [x0, y0], Z | L]

3D case: [[x1, y1, z1], [x0, y0, z0], Z, T | L]-> XEQ L -> No change.

Where x0, y0, z0 are coordinates for first point defining the line, x1, y1, z1 are coordinates for second point defining the line and in the 2D case a, b, and c are the constants of line's implicit equation ax+by+c.

Variables:

Writes:

A : First point defining line.
B : Second point defining the line.
C : [a, b, c] the constants of 2D line's normalized implicit equation ax+by+c. Not populated if input is a 3D line.

Program:

L001 LBL L
L002 STO B
L003 x<>y
L004 STO A
L005 x<>y
L006 FS? 2
L007 GTO L009
L008 RTN
L009 eq [[0,1]xA+[0,-1]xB,
         [1,0]xB+[-1,0]xA,
         ([1,0]xA)x([0,1]xB)-([1,0]xB)x[0,1]xA)]/(ABS(B-A))
L010 STO C
L011 RTN

Comments:

Terms of use.

Mnemonic: L for line.

The implicit equation (2D case) stored is normalized since the vector [a, b] is made to be of length 1, which means that for a point x, y not on the line ax+by+c is the signed distance to the line (two 2D points has opposite distance sign if not on same side of the 2D line). The program S computes the signed distance. One piece of information one get right away is the line's distance to origo (0, 0): |c|.

I realy like that one can use equations in programs.

All those vectors with signed 1s and 0s elements are mask vectors to get out a vector's components needed since no operation to do so is provided. I knew about that trick long before getting my hands on machine reading MoHPC forum posts...

I actual did ask about the runtime type problem at MoHPC in this thread, if there was a solution I'am sure Katie would have found it...

For all its shortcomings I still find the vector type very usefull because it lets us store vectors of 2D and 3D space in a single register. Sure I got 800 registers, but this type of data I would like to use the A-H, K-Z variable registers for easy access: Without the vector type I would have used 9 variables not 3, also the stack would not been high enough for non prompt input.

Change history:

20071001:2010UTC : Changed to store normalized implicit equation.

Got the HP-35s

Got the HP-35s day before yesterday.

Total cost: Calculator and shipping: 568.74 nok
Custom (tax and handling): 233.00 nok
Total cost: 801.74 nok

Samson Cables told me I did not have to pay taxes, but I had to. Still think my total cost is not that different from what it will cost here when to be had next year, so I am happy.

Actual like it a lot so fare, wrote a first impression post on the MoHPC site's forum.

Serial: CNA 72800529, may be the first 35s in Norway :-)

Euclid Pack - The Geometric Calculator

The idea of this programming project come from my day time job that also include computer graphics (3D visualization and CAD type of problems).

An important module in our software is an API we call Euclid. It do 2D and 3D geometric calculations and is well tested. I think it might be of use to have a version of it on a calculator when testing and debug code that is using the Euclid API. I name the calculator version Euclid Pack.

Initial specification for the problems to solved by the Euclid Pack:

1. Compute the implicit equation for a 2D line given two 2D points. HP-35s
2. Find the signed distance from a 2D line to a 2D point. HP-35s
3. Evaluate points on a lines (2D or 3D) using their parametric equations. HP-35s
4. "Normalize" the segment defining a line (2D or 3D). HP-35s
5. Find the distance from a 3D line to a 3D point. HP-35s
6. Compute the closest point on a line to a point (2D or 3D). HP-35s
7. Find the point of intersection of two 2D lines or learn that the lines are paralell. HP-35s
8. Find the unique shortest line between two 3D lines or learn that the lines intersect or are paralell. HP-35s
   
9. Compute the implicit equation for a plane given A) a point and normal vector or B) three points. HP-35s (A, B)
   
10. Find the signed distance from a plane to a point. HP-35s
    
11. Compute the closest point on a plane to a point. HP-35s
    
12. Find the point of intersection of a plane and a line or learn that the plane and line are paralell. HP-35s
    
13. Find the line of intersection between two planes. HP-35s
    
14. Cartesian coordinates to Barycentric coordinates. HP-35s
    
15. Barycentric coordinates to Cartesian coordinates. HP-35s
    
16. Compute a triangle's inscribed circle. HP-35s
    
17. Compute a triangle's circumscribed circle. HP-35s

The plan is to implement this on the HP-35s once it is available to me. If I managed to get my old HP-41CV repaired I might try to implement it on that as well.

On paper the HP-35s should be a good machine for this since it has 2D and 3D vectors.

Fixing the HP-41CV - I

Had nice e-mail exchanges with Randy at FixThatCalc, discussed the patient (seems there is good hope) and details around getting it to them. Propably will not be to long before send it.

HP Calculator links

The Museum of HP Calculators (MoHPC)

I would say the most important HP calculator site, a virtual museum of vintage HP calculators from the HP-9100s to the HP-48s. Beside presentations of the machines here is a *lot* of information on programming, collecting and more... What nails this as the HP calculator site is the forum. It seems to be the Rick's cafe for HP calculator crowd. Hanging out here and explore it's archive may be the best way to discover the HP calculator online universe.

FixThatCalc

The place that give me hopes my old pal the HP-41CV and me once again will hack together.

Speaking about the HP-41...

Fantastic scan of HP-41's user's manual and card reader manual by this site.

HP-41 machines flew on the early space shuttle missions, here is an article from the Smithsonian Institution's National Air and Space Museum web site about it.

However it must be mention that the HP-41C was not the first hp calculator to go to space, as told by this old HP press release the HP-35 (first scientific handheld calculator) and HP-65 (first magnetic card-programmable handheld calculator) had been there before: A museum visitor's picture and a cool picture from a HP poster.

About

Long time ago before learned high level programming languages such at Pascal, FORTRAN, C, C++ and Java I made my first programs on HP calculators, first on a 33C, then on a 41CV.

My hobby ended when the 41CV stopped working after a short periode of being weightless... I never bought a calculator again, before now...

Lately my work has been of such a nature that I do like to use a calculator now and then, and not wanting to use any other than a rpn calculator I was delighted to learn that HP had made a new reasonable priced RPN calculator: The HP-35s. I ordered it and as I write it should be on it's way to me.

I have been thinking that it's programmable feature will be wasted on me; I was not looking to get back to my old hobby of 'key stroke programming'. But who am I kidding? I am a programmer who love to program, if I am getting something programmable I am gonna program it...

The first programming project for it I have tagged Euclid.

All this excitement of buying a brand new RPN classic type HP calculator got me to hunt down my old pal, the defunced HP-41CV. Well, to get cut a short story shortere: I am going to get it fixed, I tag that project HP41RP (HP-41 Repair Project).

Well, that is what this blog is about, all thing HP Calculator activities I may wanna blog about!