NSSBWS (Not-So-Short But Weirdly Sweet ) HP-33s SLC (Single-Letter Challenge) # 01


O.K., we all know the 33s' 33 storage registers and 26.5 program labels would seem to inhibit full utilization of its ~32K memory.

So, how about writing a program that "increases" the number of available registers, while minimizing the use of program labels in the process?

Specifically, using numeric-string manipulation techniques, write a program that stores, maintains and retrieves up to 54 separate values.

These values will necessarily be of lesser precision and/or range than what is available natively in the 33s' registers. How about positive and negative reals with 5 digits of precision, and exponents in the range 10^-99 -- 10^+99?

And how about doing it using only a single program label?

I'll share my solution on Monday.


How about some more introductory information?

Such as...

routine inputs?

To store a number, what? Number in Y and "location" in X?

To retrieve a number, what? "Location" in X?

Does it keep or discard the arguments?

Etc. :-)

I'm very interested in this type of routine, since it might help address one of the basic short-comings of the 33S.


Right -- sorry for being incomplete. I'd edit the original post, but that feature has been disabled (for, I think, good reason), so here's more:

I use label "D" (for "Double Memory") for mine.

To store a value, I put the value itself in stack y, and the storage location (1 <= x <= 54) in stack x, and "XEQ D". The routine stores the value, and returns the value as stored (normalized to 5 digits) in stack x.

To recover a value, I put the negated storage location in stack x (-1 >= x >= -54) and "XEQ D". The routine returns the specified value in stack x.

After a "store" call, stack z is returned in y; for recall, stack y & z are maintained in place. As written, the routine uses flags 3 & 4, but it could probably use other, more obscure flags & leave 3 & 4 to the calling programs.

My solution starts mapping pseudo-registers to actual storage way up in the 6 statistics regs (half-register locations 1-12), and proceeds down to register A (half-registers 53 & 54). So if the calling routine needs a few regs, it can keep its storage low in the alphabet, and limit the range of pseudo-index values employed.

My solution utilizes registers V-Z, and restores the original contents of i before returning.

Potentially, similar techniques could be used to store reals of greater precision but reduced range (6 digits & 10^-9 -- 10^+9), 7-digit integers, or even more, smaller integers (perhaps as many as 81 4-digit values?)

Breaking it apart to utilize several labels would make it shorter overall, faster, and easier to understand & maintain. But I was going for the extremes.

And, I won't feel quite so pathologically geek-ish if someone finds it useful!

Edited: 9 Dec 2005, 2:34 p.m.



I think I may be hip to what you're suggesting. Or I'm waaay off :)

Are you proposing something like this?

1. Have two values, 34.555 and 80977.

2. Convert both to similar format: 3.4555E01 and 8.0997E01

3. Multiply the second by a factor, say 10E5, and add it to the first, and subsequently store in one variable? (Kinda like the method of creating values for i? ie. xxxii.eeee?

I'm interested, in other words.



there were some errors.

I should have said that the second value would be divided by a sufficiently large number (1E+0X). Then the two would be added to equal 34.5550080997 which would be STO'd in 1 variable?

Interesting approach, if this is at all what you're thinking of :P



That's essentially what I'm doing.

Keep playing around. There are more than a few twists.

I'd like to see how someone else would approach the problem.


It sounds like you guys might be onto some form of a data compression algorithm!


Not exactly "data compression" -- more like "data re-purposing" (if that makes sense).

I'm taking the twelve decmial digits of precision, 2.5 digits of exponent, and two signs (value and exponent) available for each HP-33s register, and encoding two "half-registers" in each, with a total of 10 digits of precision, four digits for exponents, and four signs (two value, and two exponent signs).

Over the weekend I rescued two more registers, so the routine can reliably encode and recall 58 different reduced-precision values.

(I've been spending WAY too much time playing with my calculator of late . . . )

I'll post the program listing tonight.


I'm not sure I can meaningfully contribute to this thread, but I can nitpick: do the XYZT stack registers count too?

If so, the HP 33S has 37 registers...

... ;P


One nit-pick deserves another:

Thirty-eight, if we include LASTx.



My solution to the single-letter challenge is posted as
Article # 570.

Let me know if you've got any questions, corrections or optimizations.

(And BTW, I found the Forum note from March of 2004 where I first outlined this scheme.)

-- Paul B.

Edited: 13 Dec 2005, 1:50 p.m.

Possibly Related Threads...
Thread Author Replies Views Last Post
  HP Prime - Short "learning" modules CR Haeger 1 385 11-27-2013, 02:13 PM
Last Post: Jonathan Cameron
  Prime: Placing more than 1 item on the RPN stack in a single program? John Colvin 4 626 11-19-2013, 08:59 AM
Last Post: Miguel Toro
  I have written a short introduction to the HP Prime Michael Carey 7 891 11-18-2013, 08:04 PM
Last Post: Michael Carey
  HP-65 short circuit Ignacio Sánchez 2 460 10-22-2013, 08:27 AM
Last Post: Ignacio Sánchez Reig
  Last HP emulation, 32 & 01 Olivier De Smet 0 288 09-07-2013, 08:27 AM
Last Post: Olivier De Smet
  Identify HP-01 Prototype parts aj04062 3 539 06-11-2013, 09:49 PM
Last Post: aj04062
  FRAM71 for HP-71B, short update #3 Hans Brueggemann 15 1,181 01-20-2013, 10:22 AM
Last Post: Jerry Raia
  RPL long vs. short names peacecalc 5 625 10-30-2012, 01:25 PM
Last Post: peacecalc
  HP-01 Restoration aj04062 4 549 10-01-2012, 08:52 PM
Last Post: BobVA
  Single Level X^2 for HP-35...Any ideas Matt Agajanian 0 282 08-11-2012, 10:01 PM
Last Post: Matt Agajanian

Forum Jump: