Two features I learned to love when programming the 35s: Vector type and equations.

Vector type

The vector type has been critizised for missing key features:

- No cross product. Must make a program.
- No native way to unpack or address vector components. Must use 'dot product mask vectors'.
- No operation to tell a vector's dimension (dim or size).

Some focus has been on using 3D vectors to augment the machine's 800 indirect registers. For the things I do and the fact that it is a closed system (no I/O), I can't imagine applications using a large fraction of the 800 registers even without packing 3 real numbers in one register!

But, I find the data packing offered by 3D vectors to be very valuable in the 'more valuable real estate territories' of near end user variable registers (A-Z) and working registers (stack and lastx).

For example, for the design of the euclid pack project I ended up with wanting to store definition of two lines (four 2D or 3D points), two planes (two 3D points and two normal vectors) and one triangle (three 3D points) in variables.

If all data entered is in 3D, that would require minimum use 33 registers! And this is data I would like to be close to the end user, so I would like to use variables: Unless had vector type would not have room. Since have the vector type minimum register use is 11.

And implementation actual ended up storing additional data in variables to make certain computations easy and results handy. And I still did not use up all variable registers...

Also now we can have 12 real numbers on the stack! That becomes usefull when using programs that take more than 4 numbers as input. For example to define a 3D triangle (the T program) end user must give in nine numbers (three 3D numbers), without the ability to just put the points on the stack and run the program, the program would had to prompt for the data.

Also the vector type, RPN paradigm and the use of equation is very powerfull when programming:

Equations in programs

I find programming complex calculations in need of much intermediate results to be easy on the 35s by combining the RPN paradigm, vector type and equations:

- The vector type allows 12 values to be stored on the stack.
- Equations in programs can use all these number while being evaluated, only when done is maximum three numbers lost on the stack: A 3D vector in the T stack register.
- The result of evaluating an equation may very well be a 3D vector: A single line in a program may execute three equation which result raises the stack only once.

A very nice feature of the HP 35s that helps programming this way is that when in programming mode and to insert a stack register as a variable in an equation using the RDN key one sees the content of the registers user side. If one has a worked example of the problem being programmed and is programming equation by equation and running the program before programming a new equation then when programming the equation it is easy to see where on the stack needed numbers are.

One drawback of this style of programming is that the evaluation of equation makes for much slower execution then a pure RPN version. For programs that intention is to be called a large (or small...) number of times as subroutines by other programs this style of programming may not be appropiate.

On an improved HP 35s (HP 35s+ :-) perhaps one could have some kind of equation compilation?

No need for me to get into any of the now well known short commings or bugs of the device documented by the community of the MoHPC here, except to say that the reported vector syntax bug is indeed real on some machines and makes this type of programming much harder than needed. I know, I got one... Still I have been able to do whatever I did without ever needing to reset the thing.