HP Forums

I recently acquired a near new 33s for a good price and have just been getting to know it, and I have a confession to make: I really like it.

I find the much maligned chevron design actually looks better close up than in pics. The keys feel good to me, and even though I like a big enter key I can get used to the little one here. I got one with a good display--crisp, and the much criticized tiny decimal point is not so bad on mine. It has the RPN lover's advantage of keystroke programming and lots of memory to store programs. I haven't had a chance to test out the built-in solver and integrator. The overloaded keyboard is not to everyone's taste but I actually think it looks really cool and I am sure in time I will find what I need. The rubber side grips give the thing a nice feel in the hand. And it is thin and shirt pocket size.

I think I may really get to like this calculator for daily use once I get the hang of it. I know it is likely not as well made as the beloved vintage models we all cherish, but since I spent under $50 on this compared to $300+ each in recent months for a 42s and 15c, I won't weep too much if it croaks in a few short years.

There doesn't seem to be much championing or advocacy for the 33s in this Forum, and I would be curious to know why. As far as non-graphing RPN programmable calcs go, it seems like it could have a lot of potential.

Les

I have the opposite experience to report. I bought an early 33S out of necessity -- I was a PE candidate, and the 33S was the only acceptable RPN model. So I put aside my old 11C and 48GX; instead, I used the 33S heavily (and almost exclusively) for months, as I prepared for the PE exam. And I passed the exam with the 33S on the first attempt, which ought to generate warm fuzzy feelings for it.

But now that the exam is over, I find that I rarely use my 33S. I've gone back to the 11C for quick calculations, and to the 48GX for more complicated ones.

I would still recommend the 33S for NCEES examinees, and I take it on the road and in the field. It's not a bad calculator, but it's not a great calculator either. So I find myself using the 11C and 48GX -- which are both great calculators -- instead.

Edited: 22 Nov 2006, 5:58 p.m.

As long as I have the opportunity to choose between different models, I'll take my 42S if I expect I'll need some programming, and my 11C or 15C for pure number crunching.

I agree with you the chevron design does not kill the 33S. But the overloaded key plate combined with the very poor contrast of left- / right-shifted functions on the 33S are forbidding in my eyes. OK, the LCD of the 33S is the best 2 line dot matrix display of an RPN calc I know. However, this rank is not very hard to reach ;-)

Quote:

---

I haven't had a chance to test out the built-in solver and integrator.

---

Quote:

---

It has the RPN lover's advantage of keystroke programming and lots of memory to store programs.

---

Quote:

---

The issue most folks have with it is the limited number of labels for your programs (A-Z). But that is still quite a few programs.

---

Analagous to this, I have discovered there is no way to repartition memory between programs and registers, as one can do on an HP41. One is restricted to 26 labelled variable (A-Z), the i register, and the 6 stats registers which are accessible only indirectly. This essentially rules anything that requires fairly large arrays, like matrix computations of reasonable size. The 42s and 15c clearly are superior here. Even the HP41CV and CX can handle reasonably big matrices with either the Advantage Pac or Math Pac installed.

I find it a shame that with about 32K of user memory (5 times more than the 42s and about 15 times as much as the 41CV) one cannot create space for more variables/registers at the expense of less program memory. You can do this with the 15c, the 41 series, the 42s and, at least indirectly, the 12c and 12cp. If there is a work around for this (i.e., using the equation catalog) I would like to learn more.

Les

Les --

Here's my critique of the HP-33S from two years ago:

http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv014.cgi?read=62029#62029

It explains why I and many others would have preferred an HP-32SII with the original color scheme and at least 2 kB of RAM instead of the HP-33S.

-- KS

Edited: 23 Nov 2006, 12:22 a.m.

Quote:

---

Analagous to this, I have discovered there is no way to repartition memory between programs and registers, as one can do on an HP41.

---

Another limitation I have noted that is driving me wonky--

There is no one-step way to recall from or store to stack registers, e.g. STO ST T or RCL ST Z on the 41c or 42s. This is disappointing to me. I was interested in porting a 41c program from this website that computes the error functions via series or continued fraction (recently updated at http://www.hpmuseum.org/software/41/41errorj.htm), and to keep it short it relies greatly on storage arithmetic carried out on the stack, e.g., ST+ X doubles the contents of the X register in one step while leaving the stack unmolested. Clever! I run it on Free 42 on my Palm TX and it is really fast. A challenge to port this one to 33s--stuff on the stack will need to be stored to variables and manipulated that way, adding steps and complexity.

I am still hung up on the paradox of lots more memory, yet fewer labels and storage registers to fully capitalize on this. Even the venerable 15c allows 25 program and subroutine labels (A thru E, 0-9, and .0 thru .9), only one less than that on hand in the 33s (A thru E). In the 33s there is no facility for numbered labels and subroutines within programs, or alphanumeric labels beyond a single letter. Given this, what does one do with the superficially impressive 31K? I guess store lots of equations and expressions, but sometimes you need to right programs if branching is required and things of that ilk.

So far I do like the integrator. Seems much faster than the 15c, on a par at least with 42s, and perhaps a little easier to use.

If I have any success porting that erf program I will post it.

Les

Les,

I agree, the 33s is a GREAT machine for its size and cost.

I still recall a mid-term exam in my numerical methods course which only 2 out of 50 students used HPs' (I was one, of course). Everyone else used Ti-89 Titaniums'.

I had written a matrix operation 'assistant' utility, which enabled me to complete the first LU-decomposition problem in about six minutes. I was able to write a similar problem (during the exam), and use it to solve the next two problems. I walked out of the room with a 100% in about 25 minutes (We were given 1hr 15min).

The real deal-winner is the RPN keystroke programming. While there are powerful advanced calculators (for example C-language-enabled HP 50g, via HP GCC), development often takes me similar time investments as I'd put into a C or MATLAB application on my PC.

ECL

Eric, thank you for your optimistic perspective on the machine, but can you comment more on your impressions of the limitations I have noted--the limited number of storage variables/registers without any means to repartition memory, the similarly limited number of program/subroutine labels, and the inability to access the stack registers directly with STO, RCL, and storage arithmetic?

In your LU decomp problem in the exam, how big were the matrices you were working with? With only 33 storage variables/registers available, that must have limited the size of the problem.

Les

Les, I was one of the early bigmouths who trashed the arrangement of the keyboard on the 33S; in fact, if I'm not hollowly boasting, I suspect I might have been (one of the?) first to dub a "chevron", in a whining lament to the legendary Norm about it. And, I think I also might have said that I was going to hate it.

I bought one nevertheless.

But it turned out that my ONLY real complaint was the small decimal point! (Old eyes and all that... ) It evokes (yes, I still use it often, though as a scientist rather than an engineer, my pounding on it will be lighter than yours) the feel (almost) of an old HP-34C, my all-time favorite calculator, for its balance of power and ease of use.

The 33S is indeed fast, packed with features, even a few my beloved old 34C didn't have, such as dedicated memory space for an equation library, a preloaded constants library (which I do make use of), and really, sufficient programming space AND labels... I mean, if you need more programming power, the machine you should look to would be more like a 48S or G series, 49/50G series, etc.

In fact, that's what I do- I use my 33S for most calculations and shorter, quicker programs while the 48G and G+ and 49G+ are used for more involved programs (oh yeah, I finally [last night, actually, after Thanksgiving dinner] finished and corrected my program to calculate the Miller indices of cubic [any lower symmetry unit cells I leave to you engineers... maybe a physicist :) ] crystal planes from the x-ray powder pattern... unfortunately, you have to know beforehand the lattice parameter and stick it in the program code first; maybe I'll try to allow for user entry of that datum tonight... ) because the FORTRAN-like (okay, FORTH or LISP-like) programming language of these latter, larger (in memory as well as physical dimension) graphing machines makes it easier to do so on them.

All in all, I think I much prefer to generally use the HP-33S much more over a 48, 49/50 or such. Besides, I either "graph" on a computer or (still) by hand on paper. The dinky little calculator screen sizes almost defeat the purpose and power of a graphing calculator. (Maybe HP or TI or Sharp or Casio can come up with a unit that will allow calc signals to be either IR transmitted or by cable to a TV!! lol.)

(Oh, by the way, if anyone wants the program posted here somewhere, it's my only one I'm not ashamed to do so, so let me know!)

Something to add to the list...

Try these on your HP-33S (angles in degrees, of course):

tan(89.999), tan(89.9999)      => the last three significant figures in the results are wrong;

tan(89.99999), tan(89.999999)  => even worse: only the first half of them is right.

Gerson.

Hi, Gerson --

Good find!

The respective answers (both the correct ones and those of the HP-33S) differ by almost exactly an an order of magnitude as the next "9" is added as a decimal digit. Here is the reason:

theta = 89.999 deg, 89.9999 deg, etc. can be expressed as

theta = (90 - x), where x = 0.001, 0.0001, etc. 

tan (90 - x) = (cos x)/(sin x) = 1/(tan x)  

tan x ~= x (for small x)

=>  tan (90 - x) ~= 1/x

So, as x decreases by an order of magnitude, tan (90 - x) increases by almost exactly an order of magnitude.

Using the MS Windows calculator as the standard, I saw that the ratio of (tan 89.9999)/(tan 89.999) = 10.000000001005..., and that ratio gets even closer to 10 as more nines are added. This would be expected from the equations above.

I tried "tan 89.999" on a variety of calculators -- old and new; cheap and expensive. The only ones that didn't give the correct answer of 57295.7795073 or 57295.77951 (within their limits of display) were the following:

HP-35 (1971):           57296.55162

Casio fx-3600P (1981):  57295.77950

HP-33S (2004):          57295.7795401

Many of us are aware of the compromises (or, "optimizations") that made the trailblazing HP-35 possible. These were eliminated in subsequent models, as documented in the Hewlett-Packard Journal article wryly titled, "The New Accuracy: Making 2³ = 8".

The Casio was a mid-range model of 25 years ago, and its error showed up as the wrong roundoff in the last digit.

The error in the results of the HP-33S is in the tenth significant digit, which is downright unacceptable in a modern-era calculator that displays 12 significant digits.

In fact, the ratio of (tan 89.9999)/(tan 89.999) is incorrectly calculated as 10.0000000067, but it continues to regress: The ratio of (tan 89.999999)/(tan 89.99999) is incorrectly calculated as 10.0000011459.

Clearly, many computational functions weren't entirely sound with the HP-33, and I don't know if this one has been fixed.

-- KS

Edited: 26 Nov 2006, 7:59 p.m. after one or more responses were posted

Hello Karl,

You've caught the point: the answers of the HP-35 to tangents of arcs close to 90 degrees should not be considered a bug, given the limited resources at the disposal of the designers back in 1971. Nowadays such answers are clearly unacceptable, since nothing seems to justify them.

Quote:

---

Clearly, many computational functions weren't entirely sound with the HP-33, and I don't know if this one has been fixed.

---

Perhaps this one has been considered not critical, if ever noticed. Both CNA411 and CN601 give the same answers.

Quote:

---

HP-35 (1971):           57296.55162

Casio fx-3600P (1981):  57295.77950 

---

     Panasonic 1403 (year?): 57292.742

Besides the HP-35, this is the only other calculator I have that gives an inexact answer. This is a ten-digit calculator, but transcendental functions computations are displayed with only eight digits.

Gerson.

Very interesting. Even the humble 31E (1980) gives tan 89.999 = 57295.77951.

tm

Could it be an internal rounding issue?

I have not been able to find anything that confirms that the 33s carries extra guard digits beyond the 12 displayed.

In any case it is a pretty discouraging bug. But I must say I really seem to like the calculator in many ways nonetheless.

Les

Quote:

---

Even the humble 31E (1980) gives tan 89.999 = 57295.77951.

---

It was exactly because of this that I decided to report the bug (let's call it so), after noticing the 33C didn't choke with that calculation. The older 25 returns 57296.55162, just like the 35.

Gerson.

Quote:

---

I have not been able to find anything that confirms that the 33s carries extra guard digits beyond the 12 displayed.

---

I guess tangent is computed by dividing sin by cosine. Since sin(89.999)/cos(89.999) returns 57295.77954 and tan(89.999) returns 57295.7795401, the difference might be due to internal guard digits. The answer is inaccurate because cos(x) is inaccurate when x gets close to 90 degrees (since sin(x) becomes inaccurate as x aproaches zero).

Quote:

---

But I must say I really seem to like the calculator in many ways nonetheless.

---

I don't dislike it. I particularly appreciate its being fast and lots of functions accessible right from the keyboard. Too bad it's been designed to comply to NCEES requirements.

Gerson.

I've got a slew of pre-LCD calculators that don't even come close to the right answer. In fact just about every battery powered calculator I have from prior to 1977 (or so) is way off, the notable exception being the Compucorp 300 series -- but they were pretty hard to hold in your hand!

I agree, there's no excuse for the 33S to be inaccurate at all, even the 6S gets this right.

-Katie

Edited: 26 Nov 2006, 11:02 a.m.

Quote:

---

I guess tangent is computed by dividing sin by cosine. Since (on the HP-33S) sin(89.999)/cos(89.999) returns 57295.77954 and tan(89.999) returns 57295.7795401, the difference might be due to internal guard digits. The answer is inaccurate because cos(x) is inaccurate when x gets close to 90 degrees (since sin(x) becomes inaccurate as x aproaches zero).

---

Hello, Gerson --

I suspect that you have identified the "smoking gun" -- tan 89.999 is inaccurate on the HP-33S because cos 89.999 is inaccurate. It's quite likely that computation of "tan x" is accomplished by (sin x)/(cos x) on the HP-33S and most other calculators. However, I disagree with the premise that "cos x" should become inaccurate as x approaches 90 degrees, or that "sin x" should become inaccurate as x approaches 0.

Of course, sin x ~= x for very small values of x, and that relationship is easily applied to "cos x" as x approaches 90 degrees. As ever-more zeroes appear between the decimal point and the first non-zero digit, accuracy is not lost if more significant digits are obtained -- there is room for them. As an example, calculate "sin 3.14159265358" in radians mode on any HP calculator with the Saturn processor (or even the HP-33S). You will see the next 12 significant digits of pi -- a result of "sin x ~= x" for small x.

Here's the apparent root cause of the HP-33S' inaccurate calculation of "tan 89.999" -- :

cos 89.999 deg (= sin 0.001 deg)

0.0000174532925191    12-digit except HP-33S

0.0000174532925091    HP-33S

-- KS

Edited: 26 Nov 2006, 8:02 p.m.

Quote:

---

However, I disagree with the premise that "cos x" should become inaccurate as x approaches 90 degrees, or that "sin x" should become inaccurate as x approaches 0.

---

Hello Karl,

You're right. Anyway, I haven't made myself clear in my earlier post. Instead of "sin(x) should become inaccurate" I should have said "sin(x) becomes inaccurate as x approaches 0". I didn't mean this happens because of an intrinsic feature of the sine function, instead I meant this happens on the HP-33S.

Here is what I meant:

On the HP-33S the sine function is inaccurate for arguments close to zero. Since cos(x) is generally computed as sin(pi/2 - x), on the HP-33S cos(x) is also inaccurate for arguments appoaching pi/2.

sin(x)

 x (rad)            HP-32SII                HP-33S 

---------------------------------------------------------

0.002          1.99999866667E-03        1.99999866666E-02        

0.0002         1.99999998667E-04        1.99999998660E-04        

0.00002        1.99999999987E-05        1.99999999980E-05

0.000002       2.00000000000E-06        2.00000000000E-06

One question still remains: what is causing the error in the least significant digit?

Gerson.

Edited: 26 Nov 2006, 8:38 p.m.

Interesting. Quote: "the older 25 returns 57296.55162, juat like the 35".

Ditto. The same with my 25C. It was made in January 1978, while the 31E was made in September 1979. I guess in those days as now, a period of less than two years is like eons.

tm

Quote:

---

"the older 25 returns 57296.55162, just like the 35".

Ditto. The same with my 25C. It was made in January 1978, while the 31E was made in September 1979. I guess in those days as now, a period of less than two years is like eons.

---

Hi, Trent --

While your HP-25C may have been made late in its run during 1978, its "basis" HP-25 debuted in 1975, according to the MoHPC website. Thus, they both probably had the same mathematical algorithms developed for the HP-35.

Better algorithms had already been developed for the HP-67 introduced in 1976, which I'd bet were ported directly to the Spice-series HP-31/32/33/34/37/38 that debuted in 1978.

The Hewlett-Packard Journal essay titled "The New Accuracy: Making 2³ = 8", which I referenced in an earlier post was actually just a sidebar at the bottom of a November 1976 article about the HP-67 (available as "76nov67.pdf"
on CD #3 of the MoHPC set). An excerpt:

Quote:

---

The second method of improving accuracy is to trap critical arguments and calculate the functions at these arguments in a special way. These critical arguments include numbers near 1 when calculating ln or log, numbers near 0 when calculating sin^-1, cos^-1, or tan^-1, and numbers near 0 or multiples of (pi)/2 when calcuating sin, cos, or tan.

---

The 1976 HP-91's result of tan 89.999999 deg = 57,295,779.51 is correct, but the 2004 HP-33S's 57,295,787.7856 is incorrect in the seventh significant digit! Not very good. Maybe we should send a copy of the sidebar to KinHPo...

-- KS

Edited: 27 Nov 2006, 1:09 a.m.

There is something out there called the voidware torture test. In radians mode, compute tan(355/226). The correct 12 digit answer is -7497258.18533. HP33S gives -7497089.2551.

This is not so horrible, paradoxically, given the issues with tan(89.999 degrees). HP48G gives -7497089.06508, and the beatified HP41CV and HP15C both give the rather unimpressive -7507225.705.

I don't know what to make of it all....

Les

That's because tan(355/226) is actually computed as sin(355/226)/sin(pi/2 - 355/226). Since pi/2 - 355/226 is very close to zero (-1.33E-07), sin(pi/2 - 355/226) will be accurate to 12 digits, as we have seen above.

Also, if we compare the forensic results for the HP-32SII and the HP-33S below we might believe the HP-33S trig algorithms are better:

HP-32SII  8.99999864267 

HP-33S    8.99999986001 

It appears these tests alone are not enough to determine if the algorithms are trouble-free. However, when they say the algorithms are bad we should believe they really are.

Gerson.

The cheesy 30S gives this answer accurately to more than 12 decimal places. I really like the (hidden) 24 digit accuracy of this calculator, but that's the only think I like about it.

Quote:

---

There is something out there called the voidware torture test. In radians mode, compute tan(355/226). The correct 12 digit answer is -7497258.18533. HP33S gives -7497089.2551.

This is not so horrible, paradoxically, given the issues with tan(89.999 degrees). HP48G gives -7497089.06508, and the beatified HP41CV and HP15C both give the rather unimpressive -7507225.705.

I don't know what to make of it all....

Les

---

Les, the 42/48/49 give the exact answer - well, to 12 digits.

Unless you meant the symbolical (355/226), but none of the machines handle it symbolically.

355/226 is (to 12 digits) 1.57079646018, and the tangent of this number (which is what the machines compute, after all) is

-7497089.065076010587196877092..

(which you can verify on functions.wolfram.com, entering an argument of 1.57079646018000000000001 to avoid the slight 

decimal-to-binary conversion error)

When working with 10 digits only (like the 41 and 15), you compute

TAN(1.57079646)= 7507219.87836667109..  so their answer is not *that* bad.

Cheers, Werner

Quote:

---

There doesn't seem to be much championing or advocacy for the 33s in this Forum, and I would be curious to know why.

---

That keyboard just repels me too much. I've seen it close up, and it's just as repellant for me in person as in the pictures.

Actually, the 49 series can handle it "symbolically". 355 226 / returns '355/226', and executing TAN with that argument returns 'TAN(355/226)'. That's an exact result.

Regards,
James

Edited: 27 Nov 2006, 12:22 p.m.

Quote:

---

There doesn't seem to be much championing or advocacy for the 33s in this Forum, and I would be curious to know why.

---

Easy answer: because we are into the antiques. You'd need a forum like "HotNewCalculators.com"

Does anyone have a real-life application where this kind of error on the tangent of angles so close to 90 degrees matters? The very unwieldiness of such results indicates it's an extreme situation that could probably be solved by taking a different approach instead of focusing on a super-accurate tangent.

It reminds me of the very bad mechanical design of an assembly used at my last place of work where all the parts were given .010" tolerance but the tolerance of a dimension involving a bunch of these was also .010". The parts could all be within tolerance and still add up to put this other critical dimension outside its .010" tolerance by nearly an order of magnitude. Clearly the problem was approached entirely wrong, and the parts' dimensions could have been far less critical if it were done a different way.

When we do software control of things on the workbench with fixed-point/scaled integer math (ie, not floating-point), the tangent function is one whose range and accuracy would be very problematic if we were to insist on just returning one 16- or 32-bit number. The easy way around it is to make the tangent function return both the sin & cos. We're not mathematicians here-- we just have a way of solving problems with our existing resources.

E-mail: wilsonmineszdslextremezcom (replace the z's with @ and .)

Hi, Bill:

Bill posted:

"Easy answer: because we are into the antiques. You'd need a forum like "HotNewCalculators.com"
"HotNewCalculators.com" !?

You mean "KinHPo_crap.com", right ? ;-)

By the way, it's not that "we are into the antiques". More like "we are into utmost quality", something that the KinHPo 33S misses by a parsec or two.

Les,

I believe the matrix was a 4x4 (I know, small), with a vector of free-terms. The problem involved using the strength of LU to re-evaluate the solutions for various free-term vectors.

Despite the small size, we were required to clearly write out each row manipulation (really, its quite elementary, I know). My short program was user-intensive, and required me to make decisions as to what value and +/- I wanted to apply to each row. So, instead of having to laboriously write out several intermediate steps, I was able to breeze through the problems quickly (and most importantly w/o careless ERRORs).

As far as the limited programming capabilities by virtue of low variable count- I agree, it has robbed me of much free-time. However, I find that I become very conscious of efficiency (lost on many kids w/ 50 gig HD-equipped laptops). In fact, it's limitations, memory-wise, were, for a time, what gave me such satisfaction (that is, being able to be productive and quick while using it instead of the ubiquitous 89 Ti-tanic)

I am, by the way, graduating (finally) with my BSME in 2-WEEKS!! So, I'm considering a graduation gift in the form of an HP...any suggestions?

ECL

Garth,

Typically you can find practical problems dealing with errors of this type in surveying, astronomy, guidance systems calculations, etc.

For instance the State Plane Cordinates where I live are Northing: 1,214,689.1990 and Easting: 347,792.9821. A typical surveyor would want to carry these coordinate numbers to four decimal places to avoid roundoff into the third and second place during traverse calculations. Preparing traverse calculations requires the use of angles and distances and many times these angles approach the cardinal directions of North, South, East, and West where these types of errors are common. Similar large numbers are found in geodetic calculations.

Forrest

Quote:

---

Does anyone have a real-life application where this kind of error on the tangent of angles so close to 90 degrees matters? The very unwieldiness of such results indicates it's an extreme situation that could probably be solved by taking a different approach instead of focusing on a super-accurate tangent.

---

Hi, Garth --

That's a very reasonable question.

Frankly, I doubt that one could identify a real-life situation in which an inaccuracy -- comparable to that identified in the HP-33S -- of calculating cosine and tangent very near 90 degrees made a significant difference. First of all, it's extremely difficult to measure anything to within six significant digits (e.g, 89.9999), and the HP-33S' error of tan(89.9999) and cos(89.9999) is in the tenth significant digit.

The best example I can conjure is a program utilizing the positions of celestial objects that might produce a slightly-erroneous result using a calculated angle close to 90 degrees. Those who designed software for the Hubble Space Telescope (for example) might care about slightly-erroneous trigonometric functions.

However, the real point of the topic is the actual loss of mathematical expertise in the algorithms programmed into the HP-33S. KinHPo started with a basis product -- the HP-32SII -- that exhibited none of the three computational bugs that others found and I discussed. Furthermore, no other modern HP-engineered calculator or even one by a competitor has exhibited these errors.

Several of the bugs linked below may have been fixed. I don't have a newer version to test.

HP-33S HMS bug

HP-33S Polar conversion bug

HP-33S COMB bug

-- KS

Yes, well.. my point is that once you want to evaluate it, the fraction is calculated to 12 digits, and then the tangent is taken.
There's no higher precision used intermediately.

Cheers, Werner

Quote:

---

Better algorithms had already been developed for the HP-67 introduced in 1976, which I'd bet were ported directly to the Spice-series HP-31/32/33/34/37/38 that debuted in 1978

---

Quite so; I was mostly just kidding. 'TAN(355/226)' as a final result would be pretty useless to me, and if I have the 49 series evaluate it to a "real number", then it evaluates the 355/226 to a real before finding the tangent.

Whether it first finds the sine and cosine to a much higher accuracy and then divides to get the tangent to an acceptable accuracy, or it uses some other method, I really don't know.

Of course, the RPL models have 15-digit mantissa "extended reals" that can be used internally, rounding to a 12-digit mantissa for the result that the user finds on the stack.

Regards,
James

Okay, you have all convinced me--the thing is crap and I will pass it onto the cats to use as a chew toy....

Les

I thought as much but I didn't see a smiley at the end ;-)

And if you want to make use of the 15-digit precision, you'll have

to program it yourself - evaluation of algebraics does not use it.

And TAN is a separate routine - but even if it uses 15 digits

internally, the routines are written to achieve 12 digits of

precision only, so you won't win much converting it to 15 digits

(save for the argument, that carries three more significant digits)

Rounded to 12 digits, the result of TAN(355/226) is -7497258.18533

The UserRPL version

\<< 355 226 / TAN \>> delivers -7497089.06508, which is correct to

12 digits - for the argument delivered to the TAN function, at

least.  It is the division that rounds the argument to 12 digits,

and since it is close to PI/2 (where every input error is

magnified), the result is quite a bit different from the 'true'

result.

The SysRPL 

:: 

  %% 355

  %% 226

  %%/

  %%TANRAD

  %%>%

;

@

results in -7497258.24999, carrying three more significant digits -

precisely the ones we provided as input to %%%TANRAD

If you do that, I'll report your action to the Animal Care program immediately for alleged AWA transgression.

You've been warned.

Best regards from V.

Edited: 28 Nov 2006, 5:19 a.m.

Quote:

---

Several of the bugs linked below may have been fixed. I don't have a newer version to test.


HP-33S HMS bug


HP-33S Polar conversion bug


HP-33S COMB bug

---

Well, I don't remember a HP calculator having so much bugs: remember that, in addition to these three bugs (that may have been corrected in later models) other have been exposed in this Forum, like the integer division bug here, or the weird estimated error in integrals here, all reported by myself. Probably more are yet to be discovered.

Now, a question: if you ever hear about a HP-33S replacement, either as HP-33SII (with bugs corrected), or as HP-33S tout-court (as a new redesign), please: write immediately to this Forum!
I want to know!

Now, my confession: I like this calculator. Yes, I hated it, in the beginning, and still have some ugly feelings. But my hope is that a new model can be issued and make us HP lovers say: here's the real hair of the glorious HP-15C!

-- Antonio

Well the new Hp50G does feel nice in comparision to the now discontinued Hp49g series. However, it doesn't have a track record and I cannot endorse it until it does, as the past Hp49g burned so many with failed/broken keyboards.

I still like using an Hp48g better and find myself still using mine more than the newer Hp's. However, it is a poor (more accurately SLOOOOWW!) graphics calculator if you use it as a graphing calculator. But they are cheap and easy to find (and in great condition) on ebay in comparision to all other older RPN HPs.

While it may have a small amount of RAM (32K or buy the Hp48G+ with 128K for $50 more), the basic platform is a quality device and fast enough for other calculations outside of graphing.

32K RAM is plenty for personal programming, but limited / tight if you download anything from hpcalc.org (a site you might check before you buy). This site also sells newer HPs as well, I have bought several from him.

Just my two cents worth.

I was not able to find out exactly what state plane coordinates are, but back to the original numbers and what I'm proposing is an unreasonable demand for accuracy in the answer-- starting with 89.9999 degrees (not 89.99990) assumes the real starting number could have been anywhere from 89.99985 to 89.99995, which, according to my HP-71 have tangents of 381,971.86342 to 1,145,915.59026. In other words, someone wants 12 digits of accuracy when the result could vary by a factor of about three to one!

Quote:

---

Well, I don't remember a HP calculator having so much bugs: remember that, in addition to these three bugs (that may have been corrected in later models) other have been exposed in this Forum, like the integer division bug, or the weird estimated error in integrals...

---

Hi, Antonio!

Regarding the integer-division bug, I believe that there was another related thread about remainder functions. I remember that there was a difference in results between the HP-33S and other models with integer arithmetic, but it was difficult (at least for me) to nail down without a comprehensive, exacting definition of the integer-arithmetic functions implemented. I believe that there were also differences between "MOD" on many models (which allows floating-point inputs) and "RMD" on the HP-16C (for integers only). I would expect that these functions would be consistent with the corresponding integer-arithmetic functionality.

Regarding the estimated errors of integrals, I didn't see evidence of a true bug in the HP-33S. However, it seemed to use the methods of the HP-48G instead of those of its predecessor HP-32SII, with absolutely no documentation thereof. I replied at length on that thread, which ran for several weeks.

Quote:

---

Probably more (bugs) are yet to be discovered.

---

"True that!" (to use a contemporary slang phrase among young people in the US, meaning "That is true.")

Quote:

---

But my hope is that a new model can be issued and make us HP lovers say: here's the real hair of the glorious HP-15C!

---

Oops -- I thing you meant "heir", there... ;-)

Seriously, I doubt that HP will ever extensively dedicate the paid efforts of "A-list" talented and expert personnel -- mathematicians, programmers, mechanical engineers, technical writers -- to the development of any handheld calculator ever again. That's assuming that HP/Agilent still has enough of them, because I've seen little evidence that Kinpo does.

Regards,

-- KS

hair is just the wrong word, heir is just the right word. Excuse me. I know the difference, but my fingers don't.

Thanks.

-- Antonio

That's the well known (?) problem of error propagation :-)

During my last 12 years in light engineering I've observed a very strong belief in infinite precision of calculation. Even statistical means of small samples of - let's say 5 or 10 - pieces are taken as if they are pinned down to 4 decimals while the sample standard deviation starts at the 2nd already. Maybe a local problem, but I doubt it.

Most of these people still believe in their technical calculations, otherwise they would sit in a corner of their workplace trembling and never report technical results with n decimals again (taken from inputs having n/2 decimals precision only). But it's such a nice and warm feeling to have some fixed pinnacles in a cold and uncertain world d;-? *** end of rant ***

Nevertheless, I agree one shall not fall back behind the state of precision reached once.

Quote:

---

That's assuming that HP/Agilent still has enough of them....

---

Quote:

---

Too bad it's been designed to comply to NCEES requirements.

---

NCEES does have two general requirements for exam calculators: (1) no I/O, and (2) no text editing. However, these are not features that are normally found on scientific (non-graphing) calculators anyway. The 33S has exactly the same capabilities in these respects as its immediate predecessor, the 32SII.

In fact, NCEES has arguably cut the 33S some slack in regards to the text editing requirement. It is actually possible to store text strings on the 33S (as dummy equations), and to "edit" them using the backspace key. But NCEES looks the other way, probably because these capabilities are so primitive and because they want to make an RPN model available.

My guess is that HP didn't consider NCEES at all when designing the 33S. They probably just wanted to "update" the 32SII with an algebraic mode and other "improvements", in exactly the same way that they "updated" the 48G, the 12C, and other classic models.

Edited: 29 Nov 2006, 11:55 p.m.

Hi Garth,

I probably missunderstood your statement. I thought you were saying that the inaccuracy of the calculations in the HP33S would not fall in an area of practical concern.

Being a surveyor, I deal with angles and distances. Sometimes very small angles and long distances, so I do believe that the inaccuracy in the HP33s is a practical issue. HP has had a very long history in serving the Land Surveying community. When a surveyor goes into the field he is usually either making polar measurements of object locations that he will need to convert to rectangular coordinates, or he (she) is doing the reverse and setting out points in a polar manner. He should always try and do this as precise as possible, but different needs have different precision requirements. He is always converting these angular and distance measurements.

I have a Swiss made survey instrument in my closet that will measure directly to one arc second and I can estimate to maybe 0.2 arc seconds. (0-degrees, 0-minutes, 0.2-seconds) So if I convert this to decimal degrees, I can rather easily measure 0.000055-decimal degrees of angle. Now this is not a digital instrument but is a fairly common Wild T2 theodolite, and there is probably one or two for sale on eBay at any time. This theodolite is about 50-years old, and the Wild company also manufactured other theodolites that could measure more precisely than the T2. I believe there were thousands of the T2 theodolites made, so there is obviously a need to measure angles very precisely in Land Surveying.

The United States has a survey control system that consists of triangulation stations spread throughout the states, and was created a number of years ago. These triangulation points may have been coarse (points far distant apart) when the system was initially created, but has continued to infill over the years. Some of these stations were long distances apart (ten to eighty miles apart). Thus the need to measure angles very precisely, and the need not to loose precision while calculating the sines and cosines while converting these polar measurements into a retangular control system (currently a State Plane Coordinate System).

The interesting question is how do you set up an instrument and measure angles between two triangulation stations when they are far apart. The partial answer is: you create towers and then set up the instruments in the towers and make your observations and measurements on cool nights using lights as targets.

I must agree with your statements regarding unreasonable demands, but certainly there should be no excuse for throwing away possible precision either.

I would second the suggestion of obtaining a HP-48G+, but only if the price is reasonable, i.e., satisfactorily (to you, that is) less than the price of a brand new HP-50G.

The 48G+ can be easily programmed, has a good storage capacity so you can stash quite a few programs in it, depending on their size of course, and its form and is aesthetically (to me anyway) superior to that of the 48GII, 49G,49G+, and 50G, along with its ease of use.

But the 50G can accept memory expansion via a secure digital card, which to me while adds extra storage space, is good primarily for backing up, which in a 48G+ boils down to a personal decision.

Thanks for the explanation of the triangulation stations and towers and so on. It's interesting and makes complete sense, except that the difference made by 10 microdegrees (not to mention 55 microdegrees) at 89.9999 when taking the tangent is huge, and is not worthy of 3 digits, let alone 12.

The tangents of 89.9999 and 89.9999000001 degrees (different by 100 picodegrees, or .00000036 arc second, are different in their 6th digits, according to my HP-71.

Still, it's impressive that something could measure such small angles.

Quote:

---

I am, by the way, graduating (finally) with my BSME in 2-WEEKS!! So, I'm considering a graduation gift in the form of an HP...any suggestions?

---

So there's still hope for an improved 33S. I think an improved 33S with 26 global labels, at least up to 20 local labels each, matrix capability, better complex number handling and more would be the calculator of choice of many exam candidates.

What I hate most about the 33s (aside from the bugs, whcih so far haven't destroyed its pedestrian utility) is the button action. Nowhere near as good as either the voyager or the pioneer keyboards.

On my CNA411 they are really bad and too noisy, not to mention the decimal point key that became loose in less than ten months of light use. On later units they appear to be better (softer and no broken key so far).

What is really bad are the different placement of the ENTER key on the 50G and 33S.

I have a a CN404. It is one of the "pre-release" ones that sold from Wallyworld before the NCEES exam. It has the algebraic swap that is documented in Gene/Wlodek's learning module. All the later ones have a different swap behavior.

re: "Still, it's impressive that something could measure such small angles."

That (a few tenths of an arcsecond) is a BIG angle - when compared to the radio astronomy technique called Very Long Baseline Interferometry (VLBI). The NASA VLBI program I used to support routinely measures the absolute positions of radio sources to better than 0.001 arcsecond (a few nanoradians). Differential VLBI can measure relative positions (over a few degrees on the sky) at the 5 to 10 microarcsecond level (tens of picoradians!).

Quote:

---

So there's still hope for an improved 33S. I think an improved 33S with 26 global labels, at least up to 20 local labels each, matrix capability, better complex number handling and more would be the calculator of choice of many exam candidates.

---

The 33S, even in its current form, is already the most powerful NCEES-approved calculator. Any examinee that wants a programmable model has to buy a 33S, since the only approved alternatives aren't programmable at all. In other words, the "power users" already buy the 33S for NCEES exams, so the proposed improvements would do little or nothing to increase HP's share of this market.

The factor that limits the 33S in the NCEES exam market is not power or quality, but price. The 33S (at $50) costs two to three times as much as the TI and Casio competition ($15 - $20). I'm sure that no one on this board wants to hear this, but the harsh reality is that HP would probably attract more new users to the 33S by cutting costs and lowering its price, rather than by improving its power or quality.

Edited: 30 Nov 2006, 6:12 p.m.

Quotes:

"Easy answer: because we are into the antiques. You'd need a forum like "HotNewCalculators.com"

"By the way, it's not that "we are into the antiques". More like "we are into utmost quality", something that the KinHPo 33S misses by a parsec or two."

To this latecomer to the Forum many of the rants sound as if they come from either Luddites or from angry old men. Let's take a look at one of the hallowed old HP calculators, the HP-41. Does anyone remember the so-called "tall keys" that were inflicted on the purchasers of the early units? Not only did the keys make it difficult to read the nomenclature but some of the keys actually lacked any tactile feel. Then there were several "bugs". But worst of all was the design of the battery pack compartment such that battery leakage could easily reach and destroy the printed circuitry. To see how battery pack compartments should be designed look at an HP-35, an HP-45, an HP-80 or an HP-67.

A recent clue for a New York Times crossword policy was "The start of a treatise on ancient history". The answer was "When I was your age."

Quote:

---

What is really bad are the different placement of the ENTER key on the 50G and 33S

---

Jeff,

Well...the wife is flirting with the idea of a lasting and memorable item such as a nice engraved analog wristwatch...but knowing the cost of those things I quickly began to consider HP-alternatives.

The 42s is strongly appealing and still a relevant engineering tool along the design cycle- (I'll be entering a job in design of fiber-reinforced aerostructures...so since it has matrix support I could port my 48g's ABD matrix utility..)

I should ammend that: It is really only an 'A' matrix utility as I used it primarily to compute reduced stiffness, global/material rotations, and for computing various quasi-isotropic laminates ie.: E11 ~= E22)

HPs' ARE long lasting, and certainly (as we can attest) memorable ;)

Plus my Casio watch doesn't have any non-aesthetic issues!

If she won't go for it, I'm considering dipping into my sign-on bonus, hahaa...

BTW, thanks for the congrats!

ECL