HP-25 purpose

[Matt Agajanian]

Hi all.

Lacking looping and subroutines, what was the objective for creating the HP-25/25C?

[Thomas Okken]

Creating an affordable programmable calculator, more powerful than the HP-55 yet also cheaper?

(More powerful may be debatable because the HP-55 had more registers, unit conversions, linear regression, and a timer, but then again the HP-25 had merged keystrokes which meant you could do a lot more with it in terms of programming.)

[Steve Simpkin]

Consider that this was only the third programmable calculator that HP had designed and ROM and transistors were still expensive to make. From the HP Museum HP-25 page. "The HP-25 started on the drawing board as a scientific calculator with a much larger set of functions than the HP-21. By the time it was done, it was that and it was programmable with 49 lines of memory, making it the least expensive and smallest of HP's programmable calculators. Like the HP-65, the HP-25 caused disbelief in many. It seemed much too small to do so much. "

See the description of the development of the HP-25 on page 4 of the following Nov 1975 HP Journal extract.
http://hparchive.com/Journals/HPJ-1975-11.pdf

[BobVA]

(11-03-2020 01:04 AM)Matt Agajanian Wrote:  Lacking looping...

The lack of special loop instructions (e.g. ISG) was a little inconvenient, but the HP-25's direct register arithmetic made the use of conditionals for looping not too much of a bother.

I'd speculate that the above noted ROM constraints, the small program memory and lack of program storage all tilted the balance of features towards math functions vs. programming features.

Along the lines Thomas noted, I'd always thought the programmabilty was designed mostly for on-the-fly automation of repetitive calculations, much like the HP-55. It's perfect for the kind of short programs you could create directly from the keyboard, perhaps without even first writing them down.
.
That was pretty much how I used mine in college, despite having a tiny notebook of programs stuffed in the case with it.

[Dave Britten]

If you ever have doubts about the capability of the 25, just spend a little time reading the included Applications book, or the remarkable programs that were printed in the PPC Journal.

[RPZ]

It does indeed have looping and conditionals. Must branch to a line number and not a label.

The HP 25 is one of my new favorites. Leds are great for my old eyes.

[Valentin Albillo]

.
Hi,

(11-03-2020 01:04 AM)Matt Agajanian Wrote:  Lacking looping and subroutines, what was the objective for creating the HP-25/25C?

Seems to me you're asking that (IMHO, pretty dumb) question from a modern perspective, where we've been used to "looping" and "subroutines" for many decades now so a machine lacking both seems (to you) purposeless.

However, I'm older than you and can vividly remember how portable computing was at the time the HP-25 was released back in 1975. At that time, portable RPN compùting was essentially almost nonexistent, with just the unaffordable HP-65 and the very expensive (yet minimally able as far as programming was concerned) HP-55, so your options as an HP, RPN lover wanting decent programmability were next to nil.

Enter the HP-25. Nice size and form factor, many storage registers with arithmetic, all mandatory scientific functions, statistics, *AND* very decent affordable programmability, allowing for quite complex, useful programs, far surpassing what the HP-55 could do, at a much lower price.

Seems you haven't read it (or else you wouldn't be asking that question) but I suggest you have a look at this PDF article, which will make the point crystal-clear:

      Long Live the HP-25 (includes a program which calls a two-variable function f(x,y) four times with different arguments, from four different places, without subroutines)


In short: at the time it was released it was not that the HP-25 lacked "looping" and "subroutines", it was that it HAD everything else !

V.

[Steve Simpkin]

Matt, To more directly answer your question. It appears that the HP-25 was originally intended to be a low cost replacement for the HP-45 with more memory registers. It was allocated 2k words of ROM, the same amount as used in the HP-45. Due to improvements in the new ACT chip and the incredible talents of people like Randall B. Neff, they managed to include the main features of the HP-45 and add programmability using just 2k words of ROM. There simply was no room to add features like a looping counter and subroutines. This is all the more amazing since the HP-55 required 3k words of ROM to achieve a similar capability. It would take HP another 2 years to add looping, subroutines and a few more features to the Woodstock family with the HP-29C/19C models. And that required 4k words of ROM.
https://www.hpmuseum.org/cgi-bin/compare...ON&diff=ON

[Gene]

Hey Matt.

As others have noted, the HP-25 did have looping of the sort where a counter register is decreased once per loop with an X not equal 0? test at the end and a GTO instruction. Cheap looping? yes, but useful.

I for one have not ever thought that subroutines were ** that ** useful on a 49 step machine given the overhead required to call and return from one. I am CERTAIN there are good uses to which they could be put - I have no doubt Valentin :-) - but in general, 49 steps seems small for that. I ** know ** it was pointless on the TI-57, but would have been better on the HP-25 than that for sure.

Remember, the announcement date of the HP-25 was in FEBRUARY of 1975 with the first newspaper ad (that I have found) in late July of 1975.

It would be nearly a year after the introduction date of the HP-25 before Texas Instruments would introduce their first programmable - the SR-52 in early 1976.

I think you may simply have been thrown off by not realizing how very early in the calculator world-time-line the HP-25 came on the scene?

Look over the HP-25 Library of programs from the PPC Journal (50+ of these) and you will likely be amazed at what could be done with it. :-)

[Valentin Albillo]

 
Hi, Gene:

Gene Wrote:I for one have not ever thought that subroutines were ** that ** useful on a 49 step machine given the overhead required to call and return from one.

You're wrong, it's precisely the opposite: the less program steps you have available, the more useful is a subroutine capability. The number of steps saved by replacing a sequence of #instructions repeated #times is given by the formula:

      #Saved steps = (#instructions - 1) * (#times - 1) - 2

For instance, if you have a 7-step sequence that is repeated 5 times then replacing them by 5 subroutine calls will save:

      #Saved steps = (7 - 1) * (5 - 1) - 2 = 22 steps saved

A few values are given in the following table:
\begin{array}{|c|c|}
\hline Instructions & 1  time & 2  times & 3  times & 4  times & 5  times \\\hline
1 & -2 & -2 & -2 & -2 & -2 \\\hline
2 & -2 & -1 & 0 & 1 & 2 \\\hline
3 & -2 & 0 & 2 & 4 & 6 \\\hline
4 & -2 & 1 & 4 & 7 & 10 \\\hline
5 & -2 & 2 & 6 & 10 & 14 \\\hline
6 & -2 & 3 & 8 & 13 & 18 \\\hline
7 & -2 & 4 & 10 & 16 & 22 \\\hline
\end{array}
As you can see from the table above, even just 2 instructions repeated 4 or more times will save steps if converted to a subroutine. Same with 3 instructions repeated 3 or more times and 4 or more instructions repeated at least twice.

Also, there are times when you can save an additional step, for instance if you can have the last call immediately before the n-step subroutine, in which case you can omit it altogether and save one extra step.

Best regards.
V.

[Gene]

You are quite right, that table does show that!

I should have prefaced my comments that in my experience, programmables with such a (relatively) small number of steps did not lend themselves to my problems using subroutines very well.

Just my viewpoint... empirically, your table is of course correct!

[Dave Britten]

My experience kind of mirrors Gene's here. Yes, there are definitely some scenarios where subroutines could be practical even with only 49 program steps (e.g. the famous prime factor finder with 12 XEQ calls to a single label), but in a lot of cases, the program space just isn't large enough to fully take advantage of subroutines.