The Museum of HP Calculators

HP Forum Archive 14

[ Return to Index | Top of Index ]

32SII versus 11C
Message #1 Posted by Boyd Zander on 22 Feb 2004, 10:59 p.m.

I have a need to obtain an HP RPN scientific calculator. I have a 41CX purchased in 85 that is still functional but cannot be used on upcoming exams. I don't have much need to program anymore due to computers so I need a RPN that can handle typical engineering calculations.

Does anyone have any opinions on what would be better for ease of use and productivity - the 32SII or the 11C? I can wait for the 33 to become readily available but it just looks like such a prissy piece of hardware and why do I need one that can handle algebraic calcs. I suppose there is a reason for it since HP came up with it but I'd rather not have a machine that is made more buzy with it. - I'd rather spend the dough for a more manly looking machine.

      
Re: 32SII versus 11C
Message #2 Posted by Karl Schneider on 23 Feb 2004, 12:06 a.m.,
in response to message #1 by Boyd Zander

Boyd --

A very good question, and I agree with your sentiments.

I have a 32Sii (2002 Indonesia, unattractive color scheme) and a 15C, which is a substantially-advanced 11C in an identical package.

For utility, I would recommend the 32Sii. It has every function the 11C has, plus all of the following:

  • Solve and Integrate
  • Easy-to-use non-graphical equation editor
  • Complex-number capability (albeit crude)
  • Alphanumeric program-instruction keycodes
  • Prompted input to programs
  • Four bidirectional metric-unit conversions
  • Fractions
  • 12 digits (instead of only 10)
  • All 12 conditional tests (instead of only 8)

Speed: The Pioneer-series 32Sii is about 4 times as fast as the Voyager-series 11C.

Portability: The vertically-oriented 32Sii is only a tad longer than the 11C.

Viewability: The 32Sii has the most-legible dot-matrix display made by HP, with the largest characters and a recessed, non-glare screen that is dust-resistant. It's much better than that of the 42S and the 33S, and almost as good as the 7-segment display of the 11C and all Voyagers.

Now, a 15C vs. a 32Sii -- that's a much tougher call, but I'd give the nod to the 15C because it's a more complete, better-engineered unit. Still, the 32Sii has many of the practical advantages over the 15C, listed above.

Regards,

-- Karl S.

Edited: 23 Feb 2004, 2:18 a.m.

            
Re: 32SII versus 11C
Message #3 Posted by Mark Ordal on 23 Feb 2004, 9:23 a.m.,
in response to message #2 by Karl Schneider

I agree with most of what Karl S. says regarding the 32SII vs 11C/15C comparison.

What I take exception to is the comment about the 32SII being about 4 times faster than the 11C. In my experience, benchmarking my own program, the 32SII is about 18 times faster than the 11C and about 25 times faster than the 15C. (Yes, despite its superior functionality---or perhaps because of it---the 15C is significantly slower than the 11C.)

I would expect similar timings for the built in functions.

--Mark

                  
32Sii vs. 15C vs. 11C speeds
Message #4 Posted by Karl Schneider on 24 Feb 2004, 1:33 a.m.,
in response to message #3 by Mark Ordal

Mark --

My parapharased claim "Pioneer (e.g. 32Sii) is 4x as fast as Voyager (e.g., 15C)" probably understates the difference between the platforms, but I find "32Sii is 25 times as fast as a 15C" quite hard to believe.

Benchmarking tests can give radically different results, depending on how they are devised, and the state of the machines tested. Valentin Albillo posted a good discussion about this a few months ago.

For example, I've noticed that the 41C models tend to be slower to execute named functions when more ROM's are plugged in.

Does your benchmarking test involve executing a function over and over again in a loop? I'd suspect that the loop would take longer on the 15C with much programming in memory, because it searches the entire program memory in one direction.

I'll try a program that utilizes built-in computational functions in a realistic manner, and provide the results tomorrow.

-- Karl S.

                        
Re: 32Sii vs. 15C vs. 11C speeds
Message #5 Posted by bill platt on 24 Feb 2004, 9:17 a.m.,
in response to message #4 by Karl Schneider

Hi Karl,

I tested the32 vs the voyagers some time ago and had similar dramatic results in speed. I know my thread is in the archives---probably 2 archives back.

                        
Re: 32Sii vs. 15C speeds
Message #6 Posted by Karl Schneider on 24 Feb 2004, 11:40 p.m.,
in response to message #4 by Karl Schneider

Regarding speeds of the 32Sii vs. the 15C:

I picked a function that the 15C would execute slowly (includes SIN, LN, and y^x), and ran integration with two different function accuracies. Plenty of number-crunching:

INTEG [1, pi, f(x)= 5*sin(x)/((ln(x)+1)^3)]

In each case, the function was programmed as an RPN routine, residing first in program memory:

Accuracy   Answer    ---- Time [sec] ----    Ratio   
                     41CX/Adv 15C   32Sii   (15C/32Sii)

FIX 5 2.47783 69 115 10 11.5 FIX 6 2.477838 244 450 37 12.2

So, for this fair test, the 32Sii was about 12 times as fast as the 15C -- much more than 4 times, but also well short of 25 times.

Edited: 24 Feb 2004, 11:59 p.m.

                        
Re: 32Sii vs. 15C vs. 11C speeds
Message #7 Posted by Mark Ordal on 26 Feb 2004, 10:51 a.m.,
in response to message #4 by Karl Schneider

Regarding my benchmarking of calculators, I use a little program that implements an algorithm to calculate something useful to me (never mind what). So we aren't just talking about an empty loop here! The old version of the program iterated 227 times and was used to time the 11C versus 15C speeds (as well as some others). In both the 11C and 15C cases, mine was the only user program in the calculator. (That was also the case with the 28C, the 32SII and the 42S.)

A newer version of the program (implementing a slightly different algorithm to do the same calculation) goes through its main loop 245 times. That improved program is the basis of my comparisons among various other calculators including newer HP models and some TI models. The improved algorithm is slower but has the advantages of being numerically stable for small arguments and being a smaller more compact program.

The old program ran in 611 seconds on the 15C; 443 seconds on the 11C; 116 seconds on my original 41CX; 68 seconds on the 42S; 24 seconds on both the 32SII and 28C; 16 seconds on the 28S; 11.8 seconds on the 48SX; and 7.1 seconds on the 48G.

I didn't have the 11C available for timing the newer program. For the newer program, my timings were: 1368 seconds for 15C (average from two machines); 228 seconds for 41CX (average from two machines); 105 seconds for 42S; 39 seconds for 32SII; 30 seconds for 28C; 25 seconds for TI-86; 22.9 seconds for TI Voyage200; 19 seconds for 28S; 15.3 seconds for TI-83; 14.5 seconds for 48SX; 13.3 seconds TI-85; 8.8 seconds for 48G; 8.3 seconds for 49G (consistent on two machines) and 4.1 seconds for 49G+.

The "new" method was timed on two different 15C calculators: one took 1600 seconds and one took 1136 seconds for the 1368 second average quoted above. I didn't note which of the two 15C specimens was used for timing the "old" program. (Most of the timings for the "old" method were done in 1988, as were the "new" method timings for the 15C, 28C, 28S, 32SII and 42S.)

The 41CX timings are a bit different between old and new methods too. My original 41CX returned the 116 seconds for the "old" method and 206 seconds for the "new" method sometime in 1988. A rebuilt 41CX obtained in the spring of 2003 takes 250 seconds on the "new" method, giving an average of 228 seconds as quoted above.

A final quirk to note concerns the 49G: I have two different implementations of my "new" algorithm, one that I describe as "optimized for readability"---i.e., using named variables and storing and recalling them, and the other "stack optimized"---making heavy use of the the stack---effectively "storing" and updating 3 "variables" on the stack during execution of the main loop. The variable-heavy approach takes 12 seconds consistently on both of my 49G calculators (one with firmware revision 1.16, the other with 1.18). The "stack optimized" program has consistent run times too--usually 8.3 seconds (as quoted above), but sometimes for a period of up to a few weeks it takes a consistent 24 seconds to run. This unexplained slowdown occurs with both the 1.16 and 1.18 firmware revisions. Note that the "stack optimized" program was used for all the RPL timings quoted in the fourth paragraph of this posting.

So my 49G experience has been that a program making heavy use of the stack can experience degraded performance for an extended period of time, but one that avoids the stack as much as possible performs the same all the time.

Well, I didn't mean for this posting to grow so long. Sorry about that. (-:

--Mark

                              
32Sii/15C/11C speeds !!???
Message #8 Posted by Valentin Albillo on 26 Feb 2004, 11:32 a.m.,
in response to message #7 by Mark Ordal

Mark posted:

"For the newer program, my timings were: 1368 seconds for 15C (average from two machines); 228 seconds for 41CX (average from two machines); 105 seconds for 42S; 39 seconds for 32SII;"

Not to doubt your word, but I find these timings highly suspicious. The following relative speeds stem from your data:

     Model      Relative speed (15C = 1.00)
--------------------------------------------
     HP-15C         1.00 x
     HP-41CX        6.00 x
     HP42S         13.03 x
     HP32SII       35.07 x
From my extensive experience since nearly 30 years using and programming HP calculators, including the ones you mention, I find it absolutely unbelievable that a 41CX would be 6 times faster than a 15C, that a 42S would be only 2 times faster than a 41CX, and that a 32SII would be nearly 3 times faster than a 42S.

Either

  • your data are wrong, or
  • the algorithm being run is not implemented equivalently in all machines, or
  • the quality of the implementation varies a lot among models

or some combination of the three. The only way out of this dilemma is that you let us see the four programs implemented in their respective machines, so that we can test your results independently and analyze the listings for an explanation.

Else, your data seems completely unacceptable, at least to me. In my own experience, the HP-41CX is roughly 2-2.5 times faster than an HP-15C, the HP-42S is 4-6 times faster than a 41CX, and the HP32SII is 1.5-1.8 times faster than a 42S. Your figures don't come even close.

Best regards from V.

                              
Re: 32Sii vs. 15C vs. 11C speeds
Message #9 Posted by Veli-Pekka Nousiainen on 26 Feb 2004, 9:21 p.m.,
in response to message #7 by Mark Ordal

What is your program (for each model) and what it does?

GENERAL STUFF:
For any calculator (28,48,49)capable of shutting off LASTARG (up to five possibly long object stored before each UserRPL command execution)
and LAST STACK eg. UNDO, should have timings with these features shut off.
Also one might consider having a Garbage Collection first by executing MEM DROP prior to test program execution.
Last: Tell your timing method and statistics eg. average of three runs, etc.
[VPN]

                                    
Re: 32Sii vs. 15C vs. 11C speeds
Message #10 Posted by Veli-Pekka Nousiainen on 26 Feb 2004, 9:45 p.m.,
in response to message #9 by Veli-Pekka Nousiainen

Too tired I am: IMVVHO only one test can not reveale enough info about the speed.
I like to test (two different problems each):
- Solve (symbolic, numeric and polynomial)
- Integration (symbolic / numeric)
- Double and triple Integration
- Solve CALLS Integrate & vice versa
- DIFFEQ solving (symbolic / numeric)
- MATRIX INVersion (symbolic / numeric) sizes 8, 32

- Empty loop (real. integer #binary)
- Loop with simple calculations (real/complex arguments)
- Loop with complicated calculations (real/complex arguments)
- plotting a simple/complicated function, BAR plot, statistical plot (8 values, 32 values), TRUTH plot
- IRR solving
- FFT, IFFT (1024 values, 4096 values) Real/Complex - etc...
NOTE 1: The 71B and 75C may have different variable types (Integer, Short, Real) with different speeds
NOTE 2: Integration is usually limited by accuracy, so let's have Integration using 12, 10, 6 and 3 digits of accuracy (when possible)
[VPN]

                                    
??? RPL calcs are not RPN calcs
Message #11 Posted by Karl Schneider on 27 Feb 2004, 2:50 a.m.,
in response to message #9 by Veli-Pekka Nousiainen

Veli-Pekka --

Your last two post describe some benchmarking procedures and available commands for RPL units (28/48/49). The 11C, 15C, and 11C, which are the subjects of the thread, are RPN units. Please note the context when posting responses.

-- Karl

                                          
Re: ??? RPL calcs are not RPN calcs
Message #12 Posted by James M. Prange on 29 Feb 2004, 4:31 a.m.,
in response to message #11 by Karl Schneider

Well, first off, Veli-Pekka was responding to a message that discussed the 49G a bit, so he wasn't at all out of line discussing the RPL models.

Where did you get the idea that "RPL calcs are not RPN calcs"? They're enhanced RPN calculators. To be sure, they aren't restricted to the 4-register stack that the earlier models use, but except for program structures and within algebraic objects, they still use the "arguments first, operator last" paradigm that defines RPN. Arguably, they're even more strictly RPN than the other models.

Regards,
James

                                                
Re: ??? RPL calcs are not RPN calcs
Message #13 Posted by Karl Schneider on 29 Feb 2004, 4:04 p.m.,
in response to message #12 by James M. Prange

James Prange posted,

Quote:
Well, first off, Veli-Pekka was responding to a message that discussed the 49G a bit, so he wasn't at all out of line discussing the RPL models.

"Point taken" there, but Mark Ordal's rambling message (to which VPN replied) itself had strayed from the original topic (11/15/32 performance), to which VPN's material was almost completely inapplicable. Hey, one should at least change the subject header if he's going in a different direction.

Quote:
Where did you get the idea that "RPL calcs are not RPN calcs"? They're enhanced RPN calculators. To be sure, they aren't restricted to the 4-register stack that the earlier models use, but except for program structures and within algebraic objects, they still use the "arguments first, operator last" paradigm that defines RPN. Arguably, they're even more strictly RPN than the other models.

Where did I "get the idea"? I'll tell you: From owning and using both true RPN models (15C/17Bii/32Sii/34C/41C*) and RPL models (28C/48G/49G). What you stated is true about the characteristics of the platforms, but RPL calc's are very different from RPN calc's.

In their operating paradigm, about the only thing they have in common is postfix notation for mathematical functions. Programming, stack management, retrieval and storage of data, representation of multiple-element data objects (e.g., complex numbers, programs, matrices) are quite dissimilar.

One could argue that a late-model Corvette or Mustang is simply an enhanced version of its 1960's namesake, but they are very different automobiles. One crucial differece in this analogy: There's no arguing that the modern Corvette and Mustang are clearly better-engineered vehicles than the earlier ones. I wouldn't say the same about RPL.

Regards,

-- Karl S.

                                                      
Re: ??? RPL calcs are not RPN calcs
Message #14 Posted by James M. Prange on 1 Mar 2004, 11:27 a.m.,
in response to message #13 by Karl Schneider

Quote:
Hey, one should at least change the subject header if he's going in a different direction.
Agreed, one should. But it seems to me that I've often seen messages that didn't seem to have anything to do with the subject header; it's not as if he were the first to neglect changing the header.

I suppose that the habit of not changing the subject header may well be partially due to the way the Google newsgroup archives thread (in my opinion, mis-thread) posts. There, a different subject header is treated as belonging to a different thread; hey, if I wanted to start a new thread I wouldn't use "Reply". Perhaps just as bad, a new thread will be attached to a previous thread that just happens to have the same subject header. Yes, I know, that's not a good excuse; this forum isn't usenet, and I very much doubt that Google archives it.

Quote:
RPL calc's are very different from RPN calc's.

Well, yes, they are different. Perhaps if you're used to the "true RPN" models, very different, but for me, being used to RPL models, a little different. I expect that my 16C would qualify as a "true RPN" calculator. Granted, I seldom use the 16C and I've only written a few rather simple programs of my own for it after working through the examples in the manual. I find it to be not as easy to work with as an RPL calculator of course, but not at all difficult. I think it to be sort of a rather rudimentary version of RPL with a few rather backwards features, and lacking many features.

I find the 16C to be much easier to use than an "algebraic input" calculator. For that matter, easier than writing a BASIC program for my Sharp EL-5520. Those are what I consider to be very different.

In my opinion, the problem with the RPL models is the poor documentation (or maybe the flakey keyboards and various bugs on the 49 series), in particular with the more recent models, not with the (intended) design of the RPL language.

Regards,
James

                                                            
Re: ??? RPL calcs are not RPN calcs
Message #15 Posted by Wayne Brown on 1 Mar 2004, 11:43 a.m.,
in response to message #14 by James M. Prange

Quote:
I expect that my 16C would qualify as a "true RPN" calculator. Granted, I seldom use the 16C and I've only written a few rather simple programs of my own for it after working through the examples in the manual. I find it to be not as easy to work with as an RPL calculator of course, but not at all difficult. I think it to be sort of a rather rudimentary version of RPL with a few rather backwards features, and lacking many features.

I'd agree that the 16C is a "true RPN" calculator. Since the 16C was my first experience with RPN, I regard it as "normal" and view RPL as a rather confusing and overly-complicated extension of RPN. (Actually, my second RPN calculator -- the HP-41 -- is my favorite for programming. I love synthetic programming, and that is the main reason I chose a 41. I've been playing with learning RPL on my 48GX for a while, but have a hard time staying interested; it just isn't fun for me in the way that programming my 41CX is.)

                                                                  
[Long] Programming fun, and my calculator history
Message #16 Posted by James M. Prange on 3 Mar 2004, 4:32 p.m.,
in response to message #15 by Wayne Brown

Quote:
I love synthetic programming, and that is the main reason I chose a 41. I've been playing with learning RPL on my 48GX for a while, but have a hard time staying interested; it just isn't fun for me in the way that programming my 41CX is.)
I haven't any experience with synthetic programming, so I've missed out on that fun. But if UserRPL isn't interesting enough for you, assuming that you've got the basics of it down and are willing to have it crash and even lose memory sometimes, maybe try SysRPL or even assembly language on the 48GX. And a few of the folks at comp.sys.hp48 are getting started at getting the 49g+ to access the underlying ARM processor that the Saturn emulator runs on; that should be somewhat "interesting" and even very useful, although I certainly expect some "crashing surprises" before they get it all figured out and learn to write really useful ARM code that works reliably on the calculator.

I suppose that the main reason that I like UserRPL is that it's so easy to quickly write very useful ad hoc programs that (usually) work as intended, even though very likely not optimal in size or execution speed. And when I have the time to spare or just feeling like playing around, I can write better optimized, or longer, more complicated programs or whole directories (occasionally even as source code for libraries) that do things that most people wouldn't expect a calculator to be capable of. I guess that I really ought to try SysRPL programming for programs that are frequently used and worth the effort of optimizing, and just for the fun of it.

Well, I suppose that a lot of it does depends on which calculator the user first "fell in love with".

The first electronic calculator that I ever used was a Canon that belonged to one of my shipmates. It cost him a small fortune (for us), had to be plugged in, had a Nixie tube display, and only did addition, subtraction, multiplication, and division, not even square roots, but it was certainly a marvel to us.

I have a TI SR-51A, but the battery life was a problem and the NiCad battery pack required rebuilding all too often, so it's been dead in a box with the disassembled battery pack for decades. I don't know whether installing batteries into the battery pack yet again would get it working. Maybe someday I'll give it a try, just to have a working "collector's item" with an LED display.

I used to have a shirt-pocket-sized Sharp "scientific", and another that included some statistical functions, but I gave those to my niece and nephew when I stopped using them.

I have a Sharp EL-5520, a Radio Shack EC-4004 (rebadged Casio, I think) keystroke programmable "scientific", and a few "4-bangers", all working, but these are rarely used now except for maybe a credit-card sized model that I carry for comparing prices when shopping. It tends to confuse me every time that I use it; I really do wish for a relatively low cost shirt-pocket-sized RPN model.

The cheap 8-digit "LLOYD'S ACCUMATIC 608 AUTOMATIC SHUT-OFF", still runs on it's original batteries after more the 20 years, and the Radio shack on the original battery after about 17 years, which amazes me every time that I turn one of them on.

The first HP that I tried was a 28S. It took me maybe a minute to realize that it actually worked the way that a calculator should work and I quickly decided that it was a "must-have", even though it lacked any way to input anything except by the keyboard, and I soon found that the battery cover was a real pain, and never really liked the folding design. I kept printouts of my programs attached to large index cards, with notes about the sizes, checksums (the checksums obtained by using a third-party program), any variables that they required, and any programs that called them written on the cards. But the first time that I got a low battery indicator and replaced the batteries, when I pressed the ON key, the display momentarily flickered and went out. It turned out that the "new" N cells that I'd purchased must've been "on the shelf" for way too long; with a high-impedance voltmeter, they all checked well below 1 volt; just imagine what they'd be under load. Replacing the "new" batteries with the old "low" batteries showed me "Memory Lost". Well, that's one way to get rid of unneeded programs (of course most of them were never put back into the 28S), and now I always use a battery tester before putting any battery into any electronic device (and yes, I occasionally find one battery out of the same package that checks significantly lower than the others). But for all of it's faults, I still think that the 28S is a good calculator.

Of course, almost as soon as the 48SX came out, with real I/O and expansion card capability, and even more the common AAA cells, I bought one. It's a big improvement over the 28S, particularly the I/O. I can save anything on the PC, and write large programs with commented source code in my text editor. But I don't understand why they removed the catalog and, if I recall correctly, there were some other "backward steps", and the "Programmers Reference Manual" was an added expense.

I eventually got a 48GX after it was available for a few years. Ok, it's faster and has some additional commands and enhanced list processing, but I'm used to using loops to "process" lists and already had an equation library card, and the 48SX is fast enough for me. The system flag browser is perhaps what I find to be the biggest improvement, but I already had a program to display the system flag states and usage. The character browser is nice too, but I already had an admittedly less convenient but functional menu for the more "difficult" characters. Input forms can be nice when several things have to be set for what I want to do, but in general, I usually find input forms and especially "choose box" style menus more of a nuisance to be avoided than a convenience. I don't know that I've ever found anything that I can do on the 48GX that I can't do easily enough on the 48SX. The documentation isn't as good as the 48SX, although not too bad if you're already familiar with RPL and make the extra purchase of the AUR.

I got a 49G when I saw one as a display item, but having mine turn on in "ALG" mode was a nasty shock! Hey, the one on display worked! Who asked for that nonsense? If I'd wanted something like that, I would've bought a TI! Oh well, I soon found out how to easily switch it to "RPN" mode and keep it there. The keyboard doesn't feel as nice, and I've had it miss keystrokes, something that's never happened on my earlier HPs; not often, but I consider any missed keystrokes to be a defect. The lack of IR and expansion card capabilities are other shortcomings. The way that it decompiles "NUL", """, and "/" is incompatible with the 48 series (and of course, binary transfers to the 48 series aren't compatible either), although an improvement if the decompiled object is to be used on the 49 series only. I do have some (I'm almost certain workable) ideas on translating the results to be compatible with the 48 series; I've done it "manually", but any attempt to write a program to do it is still on my to-do list. The OS still has far too many bugs, even though HP could at least try to fix them and a new "ROM" can be loaded into the flash memory. I sometimes get unexpectedly complicated results; I expect from the "CAS" getting in the way, perhaps more so when in "Exact" mode. Cursor movement keys that aren't shared with alpha characters are an advantage, but moving EVAL and ' to a shifted key plane and ENTER to a small corner key, for example, doesn't make any sense at all. Some of the new commands, such as SREPL, UNPICK, NIP, and PICK3 are a real advantage. Maybe math students might appreciate the new CAS commands, but I have very little, if any, use for them. Yes, exact mode and the (practically) unlimited length integers can be nice, but I usually just want to get a simple numeric answer and 12 significant digits is normally easily "close enough". Being able to use "styles" and change fonts in a character string is cute, and so are greyscale grobs, but they're just fluff to me. The documentation is disgraceful; it doesn't explain well how to best use the calculator, and lacks complete references for system flags and reserved variables (you have to go to hpcalc.org for those), and the printed AUG doesn't document the "non-CAS" commands. But at least the complete AUG can be downloaded at no extra cost (save a little time online), the PDF files can be searched, and printing them on an impact dot matrix printer isn't too expensive, although certainly time-consuming.

I inherited the 16C. Yes, the binary integer functions are great, but it lacks functions that I frequently use, and the binary integer capabilities of the RPL calculators are almost always sufficient for my purposes.

But just in case anyone's wondering, no, I'm not about to part with the 16C, or any of my other calculators, for that matter. Well, I might loan or give some to my grandnieces or grandnephews, but they're special.

I bought a 28C with all of its manuals cheap on eBay, mostly out of curiosity about how it differed from the 28S. Ok, I don't have any need for it, but it does work and I rather like having it.

I'm a real sucker for new RPL calculators, because I purchased an early production unit 49g+. It has some improvements over the 49G, but it misses a lot of keystrokes, and that's a real disgrace. Yeah, I know, just press "firmly", and just use some starter spray if my car doesn't start every time. Well, it's on it's way to California at the moment, and I hope that the warranty replacement actually does have a reliable keyboard. Other than the defective keyboard, it's probably an improvement over the 49G. Some of the more important keys have been moved back to the unshifted key plane. IR I/O has (sort of) been restored; it does work with the 82240A/B printers, but with the range drastically reduced to 2 or 3 inches, and I haven't found a way to get it to communicate directly with the 48 series. It does have IrDA capabilities, but I don't have any other IrDA devices; I suppose that I really ought to splurge and spend about $100 on a good (self-powered, that is) RS-232 to IrDA adapter. The USB is a lot faster than the RS-232 style I/O, but can be used only with a USB host with the 49g+ drivers loaded. I wish that they'd also kept RS-232 style I/O for communicating with other devices. The SD expansion card capability is nice, and SD cards are a lot cheaper (and much larger capacity) than the cards for the 48 series, and they can be used for transfers to the PC. The files that the 49g+ stores on the SD card are stored as compiled objects with a binary transfer header, so getting a file suitable for editing in a text editor to the PC is easier to do via USB, although with a few extra keypresses, I can decompile/compile and translate the objects either way on the calculator. The user's guide is better than the one that came with the 49G, but an AUG with a complete command reference is lacking, although the AUG for the 49G serves well enough.

And I've purchased a few extra used RPL calculators while they were cheap, just in case the originals die before I do.

It seems to me that HP can never take a few steps forward with their calculators without also taking a few (maybe sometimes more) steps backward.

The 49 series are interesting gadgets to play with, but for any "real work", I'll use a 48 series every time.

I occasionally use the 28 series for quick calculations, but I don't use any large programs in them; it would be too difficult to restore them if I should manage to get another "Memory lost".

I think that the 48SX is still my favorite calculator for getting any work done, although the 48GX does come very close, and the 49 series are, in some ways, more fun to play with.

Regards,
James

                                                                        
Re: Programming fun, and your calculator history
Message #17 Posted by Jeff on 4 Mar 2004, 10:36 p.m.,
in response to message #16 by James M. Prange

James,
Thanks for the interesting, entertaining and enlightening essay. I have noticed for quite some time that if there is a 48 series question, you can generally provide the answer.

I wish I found userRPL as simple and intuitive as you. I haven't been able to make the transition from "classic" keystroke programming, although admittedly I have never made determined effort to write some program or another in userRPL.

By the way, I and I’m sure many others would like to hear some examples of “programs or ... directories .... that do things that most people wouldn't expect a calculator to be capable of.”

Take care, keep up the good work and helpful posts.

Edited: 5 Mar 2004, 6:59 a.m.

                                                                              
Re: Programming fun, and your calculator history
Message #18 Posted by James M. Prange on 9 Mar 2004, 11:14 a.m.,
in response to message #17 by Jeff

Well, thanks for the kind words. I generally do try to be helpful, but sometimes I do get a bit irate when I read something that I feel treats the RPL calculators unfairly, and then after posting, I think "these people probably all think that I'm just a troll". Well, it seems not all but I suspect that there are those who consider any kind words about anything but "true RPN" to be the work of trolls (or worse).

Quote:
I wish I found userRPL as simple and intuitive as you. I haven't been able to make the transition from "classic" keystroke programming, although admittedly I have never made determined effort to write some program or another in userRPL.

Well, if your calculator does everything that you want it to, then there's no need to switch. But if you ever do feel a real need to switch to an RPL model, learning to use and program it shouldn't be all that difficult. Perhaps the most important thing is motivation.

Quote:
By the way, I and I'm sure many others would like to hear some examples of "programs or ... directories .... that do things that most people wouldn't expect a calculator to be capable of."

By "most people". I mean the kind of folks who perhaps use a "scientific" calculator, but have never actually attempted to write a program for it. For those who read this Forum, or comp.sys.hp48, a triangle solver program hardly rates a yawn. For the real RPL wizards, read comp.sys.hp48 and see what's available at hpcalc.org.

But as Andrés suggested, I plan to make a contribution to the "Memories Forum", and will add some such examples.

Regards,
James

                                                                        
Memories Forum
Message #19 Posted by Andrés C. Rodríguez (Argentina) on 5 Mar 2004, 9:17 p.m.,
in response to message #16 by James M. Prange

Would you consider posting your interesting story in the Memories Forum?

                                                                              
Re: Memories Forum
Message #20 Posted by Chan Tran on 9 Mar 2004, 10:25 a.m.,
in response to message #19 by Andrés C. Rodríguez (Argentina)

I use and like both RPN and RPL. Yes they are different. There are things I have to get used to with RPL and it did bother me at first. I prefer to program in User RPL than on a true RPN calculator.

                                    
Re: 32Sii vs. 15C vs. 11C speeds
Message #21 Posted by Mark Ordal on 27 Feb 2004, 12:08 p.m.,
in response to message #9 by Veli-Pekka Nousiainen

Regarding Veli-Pekka Nousiainen's comments:

1) I agree that turning off such functions as LASTARG, LAST STACK (or UNDO) can affect program runtimes. I'm not offering my timings as a definitive test of innate hardware speed, but rather of the speed delivered in "typical usage" for a user-written program.

2) On the RPL models, I found run times more consistent if I did MEM DROP before execution, just as suggested.

3) Timings for 48 and 49 series calculators were done with the internal clock using a program of the form:

<< TICKS -> T << PROGNAME TICKS B->R T B-R - 8192 / >> >>

Before trusting the internal timing, I also checked the time with a digital stopwatch.

The 28 series, all of the RPN models and the Texas Instruments models were timed with a digital stopwatch. I didn't calculate statistics on the runtimes.

-----

As for Valentin Albillo's consternation over the times cited, I can only speculate that his numbers must come from programs that make heavy use of the built-in "higher level" routines such as SOLVE and INTEGRATE. My little program is just doing basic math (+, -, *, /, SQRT, IP and MOD) in a FOR loop.

I would rate my HP41 program as "highly optimized". The same for the "speed optimized" RPL program. The programs for the other RPN models are just as close to straight translations of the HP41 program as possible. For example, substituting 2 * FP 2 * on the HP32SII for the HP41's 2 MOD instructions.

Just to set the record straight: the times I cited are for "normal usage" of the calculator: I don't know about you, but I normally leave the "undo related" features turned ON. So keep this qualification in mind.

-----

In case anyone is interested, I have timings from my m505 Palm PDA (which uses a 33 MHz Motorola "Dragonball" processor):

120 s for version 0.12 of Charles Lee's "P41CX" emulator running my HP41 program.

8.9 s for version 3.10 of Russell Y. Webb's "RPN" program <http://www.nthlab.com>

5.3 s for version 3.02 of Russell Y. Webb's "RPN" program <http://www.nthlab.com>

3.1 s for version 2.4.4 of "MathU-Pro" <http://www.creativecreek.com>

NOTES:

1) "RPN" and "MathU-Pro" are stack-based calculators but NOT emulators or simulators of an HP calculator. The programming "language" of MathU-Pro bears more resemblance to HP RPN code than the "language" for RPN does. The onscreen appearance of MathU-Pro somewhat resembles an HP calculator.

2) version 3.10 of RPN was the first to include native code for both the "Dragonball" and "StrongARM/XScale/OMAP" processors---apparently to the detriment of Dragonball run times.

3) Version 2.5 of "MathU-Pro" is out now---I haven't had a chance to upgrade to it yet.

-----

Finally, just in case it matters to anyone, I have over 28 years of experience with HP calculators. However, Valentin has clearly delved more deeply into them than I have.

--Mark

                                          
Re: 32Sii vs. 15C vs. 11C speeds
Message #22 Posted by Valentin Albillo on 27 Feb 2004, 1:29 p.m.,
in response to message #21 by Mark Ordal

Hi, Mark:

Mark posted: "My little program is just doing basic math (+, -, *, /, SQRT, IP and MOD) in a FOR loop. I would rate my HP41 program as 'highly optimized'. The same for the "speed optimized" RPL program. The programs for the other RPN models are just as close to straight translations of the HP41 program as possible."

Fine. Would you please produce the different program's versions for the four calculator mentioned, so that we can run them in said models and verify your timings ? If them timings come out as you stated, we will then be able to point out exactly what's happening, to everyone's enlightment.

Frankly, unless your program is a national- or trade-secret or else, I see no reason why you wouldn't be amenable to let us have a look at it. It will be interesting to verify your times first hand, a 'peer's review' of sorts.

Thanks in advance and best regards from V.

                                    
Timing issues (mostly RPL models)
Message #23 Posted by James M. Prange on 29 Feb 2004, 4:35 a.m.,
in response to message #9 by Veli-Pekka Nousiainen

Hi Veli-Pekka,

I understand your points about disabling last arguments and last stack saves (if timing something still in the command line editor, maybe last command line saves too?) on RPL calculators before doing a program timing, but most users leave these enabled except when there's a low memory problem, so is disabling them for the timings really appropriate? Or is it better to have them enabled to match the situation in which the program is actually more likely to be used?

What about other mode settings? On the 49 series, I expect that, for example, exact/approximate mode may well make a difference in some cases.

On the 49 series at least, how deep the stack is also makes a difference (deeper is slower), so I do my timings with nothing except the object to be timed on the stack. As far as I've noticed, the stack depth doesn't (unless it's so deep that a garbage collection is needed) affect the timing on the 48 series.

I wonder whether having an expansion card plugged in makes a difference.

And yes indeed, it's best to force a garbage collection before timing, or as part of the timer program.

Also note that none of the timers that I'm familiar with include the time to display the results. This is appropriate when a program is being used as a subroutine, but not quite right otherwise.

When timing routines on different models, it may not be possible to use the identical routine, so it can be a bit of a "comparing oranges and apples" situation. Is it "fair" to use methods that are possible on one model but not another? Or should one try to restrict oneself to methods that are similar, if not identical, on the various models involved? Or should one use the "fastest algorithm" on each model? If using the "fastest algorithm", are you entirely certain that it really is the fastest? So I think that it's best to show the algorithm and yes, state the timing method.

But in any case, perhaps the timers are best used to compare the execution times of programs or subroutines on the same calculator, so as long as the timings are done under substantially the same conditions, I'm not too terribly concerned with their absolute accuracy, but rather that they can reliably tell me how much (if any) faster one routine is than another.

Regards,
James

Edited: 29 Feb 2004, 5:05 a.m.

                              
Timing methods (RPL models)
Message #24 Posted by James M. Prange on 29 Feb 2004, 4:59 a.m.,
in response to message #7 by Mark Ordal

The increased evaluation time for an extended time might be explained by a decrease in the amount of free memory, which could make a garbage collection necessary. Usually, using the stack instead of variables results in a faster program, but the increased likelyhood of a garbage collection could indeed make it slower (particularly if elements from a list are on the stack).

The 49 series has the built-in command TEVAL (Timed EVALuation) which displays the evaluation time in seconds rounded to 4 decimal places. According to NOSY, the SysRPL source code for TEVAL (on 49G ROM revision 1.19-6) is:

::
  CK1&Dispatch
  BINT0
  ::
    GARBAGE
    CLKTICKS
    PTR 2B8BE
    EVAL
    CLKTICKS
    PTR 2B8E6
    bit-
    HXS>%
    % 8192.
    %/
    %4
    RNDXY
    "s"
    >TAG
  ;
;
PTR 2B8BE and PTR 2B8E6 are the unsupported commands OBJ>R (which pushes an object into the return stack) and R>OBJ (which gets an object from the return stack), respectively.

TEVAL doesn't compensate for the time to do the OBJ>R and a CLKTICKS, so the value it returns is a bit high (about .023 second on the 49G and about .010 second on the 49g+). On the other hand, it doesn't include the time to actually display the stack again, so maybe that more or less balances it out. But at least it does force a garbage collection before doing the actual timing. But of course a program that uses the stack a lot or is running in a low memory situation may still need to do garbage collection anyway. TEVAL is perhaps "close enough" for most purposes.

For whatever it's worth, here's my own timer program (modified from TIMED by Bill Wickes):

%%HP: T(3)A(D)F(.);
@ Output from BYTES command (on 49G and 49g+):
@ # EF43h
@ 136.
@ Output from BYTES command (on 48SX and 48GX):
@ # 4829h
@ 136
\<<                     @ Start program.
  MEM                   @ Force a garbage collection.
  \-> t                 @ use result from MEM as dummy value for local
                        @ variable t.
  \<<                   @ Start defining procedure for local variable
                        @ structure.
    TICKS               @ Get system time before evaluation.
    't' STO             @ Save it in the local variable.
    EVAL                @ Evaluate the object on stack level 1.
    TICKS               @ Get system time after evaluation.
    RCWS                @ Get current word size.
    64. STWS            @ Ensure full 64-bit arithmetic on system times.
    SWAP                @ Move "after" system time back to level 1.
    t -                 @ Find difference in system times.
    B\->R               @ Convert "binary" time to "real number" time.
    94. -               @ Compensate for time to do TICKS 't' STO; see
                        @ the note below.
    "Ticks" \->TAG      @ Tag this time as being in Ticks.
    DUP                 @ Make a copy.
    8192. / '1_s' *     @ Convert the time to seconds.
    ROT                 @ Move original word size to level 1.
    STWS                @ Restore the original word size.
  \>>                   @ End local variable structure.
\>>                     @ End program.
Note: The value to make the compensation for a TICKS 't' STO (94. in the above) varies with the individual calculator (perhaps also with battery condition and ambient temperature?) and especially with the model (and the phase of the moon and position of the stars for the 49 series?). To determine the "correct" value, use the timer program on something that is executed very quickly, such as the real number 1. (less than half of a tick) or the empty string "", preferably with the various "last" saves disabled. Adjust the value accordingly until the timer program returns (about) zero. The result from the 49 series tends to vary by several ticks, so check it a few times. For my calculators, I currently use a value of 104 for the 48SX, 72 for the 48GX, 242. for the 49G, and 94. for the 49g+. Of course, changing the compensation value also changes the checksum from BYTES.

If you use the above program (or TEVAL) on a variable name, then the timing includes the time that it takes the calculator to resolve and execute the name. I normally recall the object to the stack before running a timer on it, but in some cases, such as when a program will be called by name from another program, you may want to include the name resolution and execution time.

You could modify my program to first check the object type, and if it's a name, then replace the name with the stored object. This would prevent the timer's including the name resolution and execution time.

My timer program, like TEVAL and all of the other timer programs that I'm familiar with, doesn't include the time to actually display the stack.

The 28 series doesn't have a built-in TICKS command, but you can substitute the following SYSEVAL sequences for it to get the system time. The addresses are in hexadecimal, so be sure to enter them with the calculator in HEX mode, and on the 28S, it's perhaps better to type in the trailing h. The usual dire warnings about SYSEVAL apply, and perhaps even more so because of the difficulty in backing up and restoring in the 28 series.

28C Version 1BB: #123E SYSEVAL
28C Version 1CC: #1266 SYSEVAL
28S Version 2BB: #11CAh SYSEVAL

Regards,
James

Edited: 29 Feb 2004, 5:30 a.m.

                        
My benchmarks
Message #25 Posted by Tizedes Csaba on 27 Feb 2004, 7:02 p.m.,
in response to message #4 by Karl Schneider

Hello, these are my fresh timings - enjoy it! ;)

==================================
Benchmark 1 - BUILT-IN LOOPING

120 FOR K=1 TO 1000 130 NEXT K - - - - - - - - - - - - HP32SII version:

LBL B ISG K GTO B RTN

0.19901 STO K XEQ B

Running times: 4.51s / 4.46s / 4.32s

Average time: 4.43s - - - - - - - - - - - - HP15C version:

LBL B ISG 0 GTO B RTN

0.19901 STO 0 f B

Running times: 65.40s / 65.51s / 65.32s

Average time: 65.41s ================================== Benchmark 2 - COUNTING

120 K=0 130 K=K+1 140 IF K<200 THEN 130 - - - - - - - - - - - - HP32SII version:

LBL B 1 STO+ K RCL K 200 x>y? GTO B RTN

0 STO K XEQ B

Running times: 8.40s / 8.35s / 8.38s

Average time: 8.38s - - - - - - - - - - - - HP15C version:

LBL B 1 STO+ 0 RCL0 200 x>y? (TEST7) GTO B RTN

0 STO 0 f B

Running times: 135.11s / 135.10s

Average time: 135.11s ================================== Benchmark 3 - STORING

120 K=0 130 K=K+1 140 A=K 150 IF K<200 THEN 130 - - - - - - - - - - - - HP32SII version:

LBL B 1 STO+ K RCL K STO A 200 x>y? GTO B RTN

0 STO K XEQ B

Running times: 9.33s / 9.40s / 9.35s

Average time: 9.36s - - - - - - - - - - - - HP15C version:

LBL B 1 STO+ 0 RCL0 STO1 200 x>y? (TEST7) GTO B RTN

0 STO 0 f B

Running times: 149.22s / 149.25s

Average time: 149.24s ================================== Benchmark 4 - VARIABLE ARITHMETICS

120 K=0 130 K=K+1 140 A=A*K/K+K-K 150 IF K<50 THEN 130 - - - - - - - - - - - - HP32SII version:

LBL B 1 STO+ K RCL K STO* A STO/ A STO+ A STO- A 50 x>y? GTO B RTN

0 STO K XEQ B

Running times: 4.28s / 4.25s / 4.22s

Average time: 4.25s - - - - - - - - - - - - HP15C version:

LBL B 1 STO+ 0 RCL0 STO*1 STO/1 STO+1 STO-1 50 x>y? (TEST7) GTO B RTN

0 STO 0 f B

Running times: 54.46s / 54.40s / 54.54s

Average time: 54.47s ================================== Benchmark 5 - CALLING SUBROUTINES

120 K=0 130 K=K+1 140 A=A*K/K+K-K 150 GOSUB 180 160 IF K<50 THEN 130 170 END 180 RETURN - - - - - - - - - - - - HP32SII version:

LBL B 1 STO+ K RCL K STO* A STO/ A STO+ A STO- A XEQ S 50 x>y? GTO B RTN LBL S RTN

0 STO K XEQ B

Running times: 5.29s / 5.23s / 5.20s

Average time: 5.24s - - - - - - - - - - - - HP15C version:

LBL B 1 STO+0 RCL0 STO*1 STO/1 STO+1 STO-1 GSB 0 50 x>y? (TEST7) GTO B RTN LBL 0 RTN

0 STO 0 f B

Running times: 64.73s / 64.60s / 64.55s

Average time: 64.63s ==================================

The result is:

################################################################### # # # Test Unit HP32SII HP15C Speed ratio # # # # BM1: [s/loop] 0.0222 0.3221 14.5 # # BM2: [s/loop] 0.0419 0.6756 16.1 # # BM3-BM2: [s/STO] 0.0049 0.0707 14.4 # # BM4-BM2: [s/(STO*/+-)] 0.0431 0.4138 9.6 # # BM5-BM4: [s/(GSB...RTN)] 0.0198 0.2032 10.3 # # # ###################################################################

                              
Re: My benchmarks - Err... A little mistyping
Message #26 Posted by Tizedes Csaba on 27 Feb 2004, 7:06 p.m.,
in response to message #25 by Tizedes Csaba

The first BASIC line is:

120 FOR K=0 TO 199

Csaba

                              
The result is at the end of ^^^ with speed ratios! Comments? [No text]
Message #27 Posted by Tizedes Csaba on 28 Feb 2004, 1:59 p.m.,
in response to message #25 by Tizedes Csaba

.

                              
My benchmarks using 32sii and 33s
Message #28 Posted by Brent on 28 Feb 2004, 9:35 p.m.,
in response to message #25 by Tizedes Csaba

My 32sii was slightly faster than Tizedes'. I'm not sure what to make of BM1, for some reason the 33s is slower.

My 32sii and 33s Benchmark times

HP 32sii HP33s ------------------------------ BM1: 3.7 s 7.6 s* BM2: 7.0 s 3.0 s BM3: 7.8 s 3.2 s BM4: 3.8 s 1.8 s BM5: 4.3 s 2.0 s ------------------------------

*Go figure

                              
How the result is born
Message #29 Posted by Tizedes Csaba on 29 Feb 2004, 4:33 a.m.,
in response to message #25 by Tizedes Csaba

Hello,

I was made this little progs for timing one instruction speed. All of this programs (except BM1->BM2) different in one instruction than previous (BM2->BM3, BM2->BM4, BM4->BM5).

The correct calculation is substract the running times (see the 'Test' coloumn), then divide that with number of cycles.

Csaba

      
Re: 32SII versus 11C
Message #30 Posted by Norris on 23 Feb 2004, 1:38 a.m.,
in response to message #1 by Boyd Zander

So you need to solve engineering calculations, already have a 41CX, but can't use it on upcoming exams. It sounds like you may be planning to take the EIT or PE exams, and have been victimized by the new NCEES calculator policy. NCEES has explicitly banned all the best RPN calculators, including the 41, 42, 48, and 49 series.

The most popular NCEES-compliant alternatives are the old 11C, 15C, 32S, and 32SII, plus the new 33S. These are all viable choices. I agree with the previous post that the 32SII is a better choice than the 11C. If you are taking the electrical engineering test, you might well prefer the 15C over both, because of its superior support for complex numbers and matrices.

However, if you are in fact taking the EIT or PE exam, then another factor to consider is future NCEES policies. NCEES has compiled lists of "banned" and "acceptable" calculators, but neither list is even close to complete, and new models are coming out all the time. Thus, the status of many calculators is ambiguous; they are neither "banned" nor "approved" by NCEES.

The state boards who administer the exams are unhappy with this situation. If someone has an unlisted calculator, then the exam proctors have to make an on-the-spot determination as to its acceptability, and they are typically not calculator experts. So NCEES is leaning towards a new policy: in the future, calculators may have to be selected from a relatively short list of "approved" models. *All* other models will be banned, even if they are technically compliant with NCEES criteria, in order to make life simpler for the proctors.

Right now, the only RPN calculators on the "approved" list are the 32S and 33S (NCEES reps have confirmed that the "32S" also includes the "32SII"). The 11C and 15C do meet current NCEES criteria, and should be acceptable for use on the April 2004 NCEES exams. However, there is a good chance that these models will be banned in the future, if NCEES moves to an even more restrictive policy.

So the safest investment for NCEES exam purposes is probably the 32SII or 33S. The 33S is much uglier. However, a new 33S for $55-60 is also a lot cheaper than a used 32SII for $200-300.

            
Re: 32SII versus 11C
Message #31 Posted by Boyd Zander on 23 Feb 2004, 1:21 p.m.,
in response to message #30 by Norris

Thanks for the Opinions!! EOM

      
Re: 32SII versus 11C
Message #32 Posted by Bernardo Vargas on 27 Feb 2004, 2:31 p.m.,
in response to message #1 by Boyd Zander

I would choose a 11C over a 32SII because of its superior SIMPLICITY. That's the feature I appreciate the most on a pocket calculator. I rather use my good old 41CV instead of my 48G just because of that.

Unfortunately, the 11C has become RIDICULOUSLY expensive at eBay. I bought a NEW 11C at a normal store, no discount, in Laredo, Texas, back in 1987 and it costed me 60 dollars. Now a USED one costs $150 at least. That's just crazy.

            
Re: 32SII versus 11C (enter 33s)
Message #33 Posted by Andrés C. Rodríguez (Argentina) on 29 Feb 2004, 10:12 a.m.,
in response to message #32 by Bernardo Vargas

I would quote the Spanish poet Antonio Machado:

"Todo necio

confunde valor

con precio"

(Any fool confuses value with price)

If people pay a certain amount for something, it is because of the value, or worthiness, such thing has. It is part objective, and part subjective when the buyer is just a person, not an organization.

Now, if 11C are that expensive (which also astounds me), is it because they have a collectible value (as a work of art, sort of), or is it because their functionality? The first case offers little hope for lower prices; the second may be more benign if there are current, substitutive products like the 33s or others.

Just my thoughts, and frankly not very original this time....

Edited: 29 Feb 2004, 10:15 a.m.


[ Return to Index | Top of Index ]

Go back to the main exhibit hall