HP Forum Archive 15

[ Return to Index | Top of Index ]

NSSBWS (Not-So-Short But Weirdly Sweet ) HP-33s SLC (Single-Letter Challenge) # 01 Message #1 Posted by Paul Brogger on 9 Dec 2005, 12:00 p.m. 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.

Re: NSSBWS (Not-So-Short But Weirdly Sweet ) HP-33s SLC (Single-Letter Challenge) # 01 Message #2 Posted by Gene Wright on 9 Dec 2005, 12:16 p.m., in response to message #1 by Paul Brogger 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.

More: NSSBWS HP-33s SLC # 01 Message #3 Posted by Paul Brogger on 9 Dec 2005, 12:43 p.m., in response to message #2 by Gene Wright 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.

Re: More: NSSBWS HP-33s SLC # 01 Message #4 Posted by ECL on 11 Dec 2005, 5:59 p.m., in response to message #3 by Paul Brogger Paul, 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. ECL

Re: More: NSSBWS HP-33s SLC # 01 Message #5 Posted by ECL on 11 Dec 2005, 6:30 p.m., in response to message #4 by ECL Sorry, 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 ECL

Re: More: NSSBWS HP-33s SLC # 01 Message #6 Posted by Paul Brogger on 12 Dec 2005, 12:32 a.m., in response to message #5 by ECL 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.

Re: More: NSSBWS HP-33s SLC # 01 Message #7 Posted by Ed Look on 12 Dec 2005, 1:12 p.m., in response to message #6 by Paul Brogger It sounds like you guys might be onto some form of a data compression algorithm!

Re: More: NSSBWS HP-33s SLC # 01 Message #8 Posted by Paul Brogger on 12 Dec 2005, 2:01 p.m., in response to message #7 by Ed Look 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.

Re: NSSBWS (Not-So-Short But Weirdly Sweet ) HP-33s SLC (Single-Letter Challenge) # 01 Message #9 Posted by Ed Look on 10 Dec 2005, 8:59 p.m., in response to message #1 by Paul Brogger 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

Re: NSSBWS HP-33s SLC # 01 Message #10 Posted by Paul Brogger on 10 Dec 2005, 11:38 p.m., in response to message #9 by Ed Look One nit-pick deserves another: Thirty-eight, if we include LASTx. ;-}

A Solution: NSSBWS HP-33s SLC # 01 Message #11 Posted by Paul Brogger on 12 Dec 2005, 7:01 p.m., in response to message #1 by Paul Brogger 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.

[ Return to Index | Top of Index ]

Go back to the main exhibit hall