## Sunday, September 30, 2007

### 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 TTOO2 5T003 STO IT004 STO(I)T005 RDNT006 4T007 STO IT008 RDNT009 LASTXT010 STO(I)T011 RDNT012 STO MT013 RDNT014 STO LT015 RDNT016 STO KT017 R^T018 X<>YT019 -T020 RDNT021 RDNT022 LASTXT023 -T024 X<>YT025 RDNT026 XEQ X001T027 RCL(I)T028 ABST029 RDNT030 RCL KT031 RCL LT032 RCL MT033 R^T034 RTN`

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.

## Saturday, September 29, 2007

### 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!

## Wednesday, September 26, 2007

### 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 PP002 XEQ X004P003 STO NP004 X<>YP005 STO PP006 eq -(PxN)P007 STO OP008 RDNP009 X<>YP010 R^P011 RTN`

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 from the origo (0, 0, 0) to the plane.

## Tuesday, September 25, 2007

### 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 XX002 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 RTNX004 ABSX005 RDNX006 eq LASTX/REGTX007 RTN`

## Sunday, September 23, 2007

### 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:

`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 MM002 XEQ U001M003 STO EM004 X<>YM005 STO DM006 -M007 RCL BM008 RCL- AM009 eq [REGXxREGX,REGXxREGY,REGYxREGY]M010 STO ZM011 RDNM012 RCL AM013 RCL- DM014 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<>YM018 ABSM019 1E-6MO20 X>Y?M021 GOTO M041M022 RDNM023 RDNM024 LASTXM025 /M026 eq ([1,0,0]xZ)x([0,1]xREGY)-([0,1,0]xZ)x([1,0]xREGY)M027 LASTXMO28 /M029 X<>YM030 4M031 STO IM032 RDNM033 RCL(I)M034 ABSM035 RDNM036 RCL DM037 RCL EM038 RDNM039 RDNM040 RTNM041 SF 10M042 eq PARALELLM043 PSEM044 CF 10M045 XEQ U029M046 RTN`

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:

`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 FF002 ABSF003 RDNF004 (1-LASTX)xD+LASTXxEF005 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 0U051 STO IU052 RDNU053 RCL(I)U054 ABSU055 RDNU056 3UO57 STO IU058 RDNU059 RCL(I)U060 2U061 STO IUO62 RDNU063 RCL(I)U064 1U065 STO IU066 RDNU067 RCL(I)U068 R^U069 RTN`

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:

`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 CC002 XEQ U001C003 RCL AC004 -C005 RCL BC006 RCL AC007 -C008 xC009 LASTXC010 ENTERC011 xC012 /C013 XEQ U050C014 RTN`

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 andABS    // 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.

## Saturday, September 22, 2007

### 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:

`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 NN002 XEQ U001N003 RCL AN004 eq 1/ABS(B-A)N005 STOx AN006 STOx BN007 RDNN008 RCL AN009 -N010 STO+ AN011 STO+ BN012 XEQ U029N013 RTN`

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 UU002 X<> IU003 RDNU004 0U005 X<> IU006 STO(I)U007 RDNU008 1U009 STO IU010 RDNU011 STO(I)U012 RDNU013 2U014 STO IU015 RDNU016 STO(I)U017 RDNU018 3U019 STO IU020 RDNU021 STO(I)U022 4U023 STO IU024 LASTXU025 STO(I)U026 5U027 STO IU028 STO(I)U029 4U030 STO IU031 RCL(I)U032 ABSU033 3U034 STO IU035 RDNU036 RCL(I)U037 2U038 STO IU039 RDNU040 RCL(I)U041 1U042 STO IU043 RDNU044 RCL(I)U045 0U046 STO IU047 RDNU048 RCL(I)U049 RTN`

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 UU002 X<> IU003 RDNU004 0U005 X<> IU006 STO(I)U007 RDNU008 1U009 STO IU010 RDNU011 STO(I)U012 RDNU013 2U014 STO IU015 RDNU016 STO(I)U017 RDNU018 3U019 STO IU020 RDNU021 STO(I)U022 3U023 STO IU024 RDNU025 RCL(I)U026 2U027 STO IU028 RDNU029 RCL(I)U030 1U031 STO IU032 RDNU033 RCL(I)U034 0U035 STO IU036 RDNU037 RCL(I)U038 RTN`

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.

## Friday, September 21, 2007

### 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:

`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 EE002 ABSE003 RDNE004 eq (1-LASTX)xA+LASTXxBE005 RTN`

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:

`C : [a, b, c], constants of line's normalized implicit equation. Populated by the L program.`
Program:
`S001 LBL SS002 ABSS003 RDNS004 eq (([1,0,0]xC)x([1, 0]xLASTX))+(([0,1,0]xC)x([0,1]xLASTX))+[0,0,1]xCS005 RTN`

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 LL002 STO BL003 x<>yL004 STO AL005 x<>yL006 FS? 2L007 GTO L009L008 RTNL009 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 CL011 RTN`

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 :-)

## Tuesday, September 11, 2007

### 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.

## Saturday, September 8, 2007

### 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.

## Wednesday, September 5, 2007

### 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.

## Tuesday, September 4, 2007

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!