Just why is the HP-35s so slooow?


Hi everyone,

I am a new poster, having only responded to a couple of other posts here and there but I visit the forum frequently. I received my new HP35s last week and was at first quite pleased that the display was not noticeably askew. I am somewhat disappointed however at the relatively slow speed of the calculator and would like some feedback on this issue. I know it has been discussed that the 35s is slower that the 33s (I managed to sell mine), but when I compare it to the trusty 32sii, it just doesn't measure up, especially for definite integral evaluation and I do not understand why. One example is the evaluation of Vardi's integral (you can find this and other great examples on the Wolfram Mathworld website under definite integrals) to 5 decimal places; the 35s takes 00:01:46 to evaluate this integral compared to 00:01:28 on the 32sii. It takes more than 20% longer on the 35s. I have had even worse results with other programs. What's the logic behind this lack of speed, when you consider that the 33s was quite a bit faster that the Pioneers. It still outperforms the 41CX and the 15C, mind you (except for matrices...). One poster mentioned that there is always a trade-off between speed and battery life, however I will gladly bet that my faster Pioneer will still be going strong on its years-old button cells after many battery changes in the 35s. Thanks,




Jeff, my theory on the slowness of the 35S is this. The register size is 37 bytes, to allow for all kinds of different data types, like vectors and so on. That means every operation involving a register must move 37 bytes into the CPU, versus maybe 8 bytes for an older series calculator that does not have this overhead. I think that must add up. I don't know this is the real reason, but my intuition tells me so.



these 37 bytes are a virtual boundary only.

Since each so-called 'register' is preceeded by a status byte,

it isn't necessary to always read the whole 'three-in-one' quantity.

Register operations should be even faster than in the 33s,

since type checking can be done by reading a single byte.

Of course I don't know how they actually implemented it...

Maybe the read and write routines always access the whole '3-in-1'

quantity of 37 bytes, even for real numbers, in a way like:

Write real number, then two or three times zero, and finally the marker byte, or alike.

That would be easy to implement, but plain dumb from a performance point of view.

Let's hope they lowered the CPU clock rate instead, to preserve batts;-)



Welcome, Jeff --

.. but when I compare (the HP-35s) to the trusty 32sii, it just doesn't measure up, especially for definite integral evaluation and I do not understand why. One example is the evaluation of Vardi's integral ... to 5 decimal places;

There's an unobvious, but important difference between the HP-32SII and the HP-33s/35s in the meaning of the display setting for specifying the "uncertainty" of the user's integrand function.

On the HP-35SII, "FIX 5" sets an absolute uncertainty of 0.000005 -- i.e., the fifth decimal digit is assumed to show the correct rounded function value. On the HP-33s and HP-35s, "FIX 5" sets a relative uncertainty of 0.00001 -- i.e., the uncertainty is the absolute value of the function multiplied by 1E-05.

So, if the magnitude of the integrand function is small (say, less than 0.1), "FIX n" specifies a tighter tolerance for the integrand on the HP-35s than on the HP-32SII. This will prompt more evalutations of the functions, and longer execution time for integration. Conversely, if the magnitude of the integrand function is large (say, greater than 10), the HP-35s, er, might be faster for a "FIX n" setting.

That difference having been acknowledged, the HP-35s does seem to be substantially slower for integration than the HP-33s. My favorite example is that of integrating

f(x) = sqrt(x)/(x-1) - 1/ln(x)

for x between 0 and 1.

(This problem was originally presented in the HP Journal article from 1980 describing the INTEG function on the HP-34C. The example was later presented in the HP-15C Advanced Functions Handbook, the HP-71B Math ROM manual, and probably others.)

With a "FIX 6" setting, the HP-33s and HP-35s return the same results (0.0364899763890 with estimated error 3.648998E-08). Representing f(x) as a keystroke program (not an equation), the HP-35s takes 4:05 minutes; the HP-33s takes 2:15 minutes.

Neither the HP-33s nor the HP-35s manuals explain the details of the integrand accuracy setting. I inferred it from comparisons with the HP-48G, for which the methods are explained and the results are identical. Please see the following article and thread:

HP SOLVE-INTEG on all RPN-based models

Uncertainty and accuracy for numerical integration

-- KS

Edited: 4 Sept 2007, 11:38 p.m. after one or more responses were posted


As usual, Karl's post is simple, clear and complete.

-- Antonio


-- for the compliment. I do admit that the post took some time to prepare and edit. I'll have to update article #556 to include the HP-35s.

-- KS



Thanks for your reply. I appreciate that it took time to prepare. I also enjoyed (re)reading your previous posts on this same subject and the back and forth with Valentin. The 15C had a very elegant implementation of the Romberg method.



I thought I'd see how the 50g handles Vardi's integral. First I tried in exact mode, then approximate, and after 5 minutes my low bat indicator came on so I stopped the operation. Is this a case of operator error?

Very Respectfully,




My HP 49G+ with ROM Build 92, takes 01:01:12 to evaluate this integral (-0.260443) in exact mode with Number Format set to FIX 6. I suspect you have your Number Format set to Standard.


Correction, I meant 00:01:12. Sorry. - JeffK


You were exactly right. Thanks for the tip!

Very respectfully,


Possibly Related Threads...
Thread Author Replies Views Last Post
  slooow 49g Eric Lundgren 2 705 06-17-2003, 05:18 PM
Last Post: Mark Ordal

Forum Jump: