32SII versus 11C



#34

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.


#35

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.


#36

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


#37

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.


#38

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.

#39

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.

#40

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


#41

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.

#42

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]


#43

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]

#44

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


#45

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


#46

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.


#47

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


#48

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.)


#49

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


#50

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.


#51

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

#52

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


#53

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.

#54

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


#55

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.

#56

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.

#57

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.

#58

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 #
# #
###################################################################


#59

The first BASIC line is:

120 FOR K=0 TO 199

Csaba

#60

.

#61

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

#62

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

#63

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.


#64

Thanks for the Opinions!! EOM

#65

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.


#66

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.


Possibly Related Threads...
Thread Author Replies Views Last Post
  HP-Prime_CAS versus MAPLE_CAS CompSystems 0 591 08-18-2013, 11:58 PM
Last Post: CompSystems
  Binary versus Decimal prefixes bill platt 22 3,784 04-27-2013, 11:22 AM
Last Post: Walter B
  HP 28S saw 36V versus 4.5V, damage and repair? Joshua Keena 4 993 09-10-2011, 10:58 PM
Last Post: Joshua Keena
  HP 15c LE - U.S. versus European version Michael Kussmaul 16 2,583 09-09-2011, 12:29 PM
Last Post: Walter B
  A speed comparison of the 41CL versus the 41CX (and my first YOUTUBE video) Geoff Quickfall 6 1,485 08-08-2011, 02:33 AM
Last Post: Ángel Martin
  wp34s Integer Word Size versus 16C Jake Schwartz 7 1,569 05-06-2011, 02:19 AM
Last Post: Walter B
  GolfScript versus RPL Allen 0 595 02-09-2011, 08:00 PM
Last Post: Allen
  ATIME function HP 41CX versus "ATIME" routine for HP42S Geoff Quickfall 16 2,673 10-22-2008, 06:46 AM
Last Post: Walter B
  RPN calculator versus Iphone emulator? Geoff Quickfall 10 1,874 10-07-2008, 01:23 PM
Last Post: V-PN
  HP 82153A WAND revision 1E versus 1F Pierre Hardy 1 724 05-21-2008, 12:42 PM
Last Post: Massimo Gnerucci (Italy)

Forum Jump: