▼
Posts: 1,368
Threads: 212
Joined: Dec 2006
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 displaycrisp, 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 builtin 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 nongraphing RPN programmable calcs go, it seems like it could have a lot of potential.
Les
▼
Posts: 363
Threads: 22
Joined: Jul 2007
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.
Posts: 4,587
Threads: 105
Joined: Jul 2005
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 / rightshifted 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 ;)
Posts: 291
Threads: 43
Joined: Jun 2007
Quote:
I haven't had a chance to test out the builtin solver and integrator.
It's fast...very fast.
Quote:
It has the RPN lover's advantage of keystroke programming and lots of memory to store programs.
The issue most folks have with it is the limited number of labels for your programs (AZ). But that is still quite a few programs.
I agree, the 33s seems like a good little machine to me...the keyboard has a very nuce feel...and note that the keys are hinged on the bottom, just like the great HP machines of the past.
One more point...the fraction mode is quite powerful and easy to work with.
Best regards, Hal
▼
Posts: 1,368
Threads: 212
Joined: Dec 2006
Quote:
The issue most folks have with it is the limited number of labels for your programs (AZ). 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 (AZ), 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
▼
Posts: 1,089
Threads: 32
Joined: Dec 2005
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.
...or on TI programmables. You even have more than just one index register there (on some models, e.g., the TI66). I wonder why HP didn't just took the idea but introduced such harsh limitations to the otherwise brilliant 32S(II) models.
Posts: 1,368
Threads: 212
Joined: Dec 2006
Another limitation I have noted that is driving me wonky
There is no onestep 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 33sstuff 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, 09, 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
▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
Something to add to the list...
Try these on your HP33S (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.
▼
Posts: 1,792
Threads: 62
Joined: Jan 2005
Hi, Gerson 
Good find!
The respective answers (both the correct ones and those of the HP33S) 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:
HP35 (1971): 57296.55162
Casio fx3600P (1981): 57295.77950
HP33S (2004): 57295.7795401
Many of us are aware of the compromises (or, "optimizations") that made the trailblazing HP35 possible. These were eliminated in subsequent models, as documented in the HewlettPackard Journal article wryly titled, "The New Accuracy: Making 2^{3} = 8".
The Casio was a midrange 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 HP33S is in the tenth significant digit, which is downright unacceptable in a modernera 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 HP33, 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
▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
Hello Karl,
You've caught the point: the answers of the HP35 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 HP33, 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: HP35 (1971): 57296.55162
Casio fx3600P (1981): 57295.77950
Panasonic 1403 (year?): 57292.742
Besides the HP35, this is the only other calculator I have that gives an inexact answer. This is a tendigit calculator, but transcendental functions computations are displayed with only eight digits.
Gerson.
▼
Posts: 1,477
Threads: 71
Joined: Jan 2005
I've got a slew of preLCD 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.
Posts: 406
Threads: 47
Joined: Jul 2005
Very interesting. Even the humble 31E (1980) gives tan 89.999 = 57295.77951.
tm
▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
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.
▼
Posts: 406
Threads: 47
Joined: Jul 2005
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
▼
Posts: 1,792
Threads: 62
Joined: Jan 2005
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 HP25C may have been made late in its run during 1978, its "basis" HP25 debuted in 1975, according to the MoHPC website. Thus, they both probably had the same mathematical algorithms developed for the HP35.
Better algorithms had already been developed for the HP67 introduced in 1976, which I'd bet were ported directly to the Spiceseries HP31/32/33/34/37/38 that debuted in 1978.
The HewlettPackard Journal essay titled "The New Accuracy: Making 2^{3} = 8", which I referenced in an earlier post was actually just a sidebar at the bottom of a November 1976 article about the HP67 (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 HP91's result of tan 89.999999 deg = 57,295,779.51 is correct, but the 2004 HP33S'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.
▼
Posts: 291
Threads: 43
Joined: Jun 2007
Quote:
Better algorithms had already been developed for the HP67 introduced in 1976, which I'd bet were ported directly to the Spiceseries HP31/32/33/34/37/38 that debuted in 1978
Even before the Spices, the better algorithms were ported to the 29C (1977), which gives the correct 10 digit results :)
Best regards, Hal
Posts: 1,368
Threads: 212
Joined: Dec 2006
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
▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
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.
▼
Posts: 1,792
Threads: 62
Joined: Jan 2005
Quote:
I guess tangent is computed by dividing sin by cosine. Since (on the HP33S) 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 HP33S because cos 89.999 is inaccurate. It's quite likely that computation of "tan x" is accomplished by (sin x)/(cos x) on the HP33S 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 evermore zeroes appear between the decimal point and the first nonzero 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 HP33S). 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 HP33S' inaccurate calculation of "tan 89.999"  :
cos 89.999 deg (= sin 0.001 deg)
0.0000174532925191 12digit except HP33S
0.0000174532925091 HP33S
 KS
Edited: 26 Nov 2006, 8:02 p.m.
▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
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 HP33S.
Here is what I meant:
On the HP33S the sine function is inaccurate for arguments close to zero. Since cos(x) is generally computed as sin(pi/2  x), on the HP33S cos(x) is also inaccurate for arguments appoaching pi/2.
sin(x)
x (rad) HP32SII HP33S

0.002 1.99999866667E03 1.99999866666E02
0.0002 1.99999998667E04 1.99999998660E04
0.00002 1.99999999987E05 1.99999999980E05
0.000002 2.00000000000E06 2.00000000000E06
As you have correctly observed, in these examples the errors show up in the least significant digit. Since sin(0.000002 rad) = 1.999999999998667e6 (according to the HP200LX calculator app) it is rounded up to 2E06 on both calculators. So, despite the errors for small arguments, the function becomes accurate as they approach zero, contrary to what I had said.
One question still remains: what is causing the error in the least significant digit?
Gerson.
Edited: 26 Nov 2006, 8:38 p.m.
▼
Posts: 1,368
Threads: 212
Joined: Dec 2006
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
▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
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.33E07), 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 HP32SII and the HP33S below we might believe the HP33S trig algorithms are better:
HP32SII 8.99999864267
HP33S 8.99999986001
It appears these tests alone are not enough to determine if the algorithms are troublefree. However, when they say the algorithms are bad we should believe they really are.
Gerson.
Posts: 1,477
Threads: 71
Joined: Jan 2005
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.
Posts: 163
Threads: 7
Joined: Jul 2007
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
decimaltobinary 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
▼
Posts: 1,041
Threads: 15
Joined: Jan 2005
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.
▼
Posts: 163
Threads: 7
Joined: Jul 2007
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
▼
Posts: 1,041
Threads: 15
Joined: Jan 2005
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 15digit mantissa "extended reals" that can be used internally, rounding to a 12digit mantissa for the result that the user finds on the stack.
Regards, James
▼
Posts: 163
Threads: 7
Joined: Jul 2007
I thought as much but I didn't see a smiley at the end ;)
And if you want to make use of the 15digit 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
Cheers, Werner
Posts: 363
Threads: 22
Joined: Jul 2007
Quote: Too bad it's been designed to comply to NCEES requirements.
Most of the issues with the 33S have nothing whatsoever to do with NCEES requirements. NCEES does not require chevron keyboards, hardtosee decimal points, calculation bugs, or shiny metallic bodies, nor does NCEES limit the number of labels and variables.
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 (nongraphing) 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.
▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
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.
▼
Posts: 2,448
Threads: 90
Joined: Jul 2005
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.
▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
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.
▼
Posts: 2,448
Threads: 90
Joined: Jul 2005
I have a a CN404. It is one of the "prerelease" 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.
Posts: 875
Threads: 37
Joined: Jul 2005
Quote:
What is really bad are the different placement of the ENTER key on the 50G and 33S
Of the two, I prefer the location on the 33S. The add, subtract, multiply and divide keys are supposed to be right next to the numeric keypad. At least they were on every hp calculator up to the 49g. I can't tell you how many times I have entered when I wanted to add, or multiplied when I meant to divide, on my 50g. Of course, this would not be an issue if they had left the ENTER key in its classic location, but that has already been discussed at length.
Posts: 363
Threads: 22
Joined: Jul 2007
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.
In theory, yes, HP could improve the 33S in these respects and still receive the NCEES "seal of approval". But from a marketing perspective, it's hard to see why HP would bother to do so.
The 33S, even in its current form, is already the most powerful NCEESapproved 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.
Posts: 1,792
Threads: 62
Joined: Jan 2005
Les 
Here's my critique of the HP33S from two years ago:
http://www.hpmuseum.org/cgisys/cgiwrap/hpmuseum/archv014.cgi?read=62029#62029
It explains why I and many others would have preferred an HP32SII with the original color scheme and at least 2 kB of RAM instead of the HP33S.
 KS
Edited: 23 Nov 2006, 12:22 a.m.
Posts: 95
Threads: 47
Joined: Jan 1970
Les,
I agree, the 33s is a GREAT machine for its size and cost.
I still recall a midterm exam in my numerical methods course which only 2 out of 50 students used HPs' (I was one, of course). Everyone else used Ti89 Titaniums'.
I had written a matrix operation 'assistant' utility, which enabled me to complete the first LUdecomposition 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 dealwinner is the RPN keystroke programming. While there are powerful advanced calculators (for example Clanguageenabled 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
▼
Posts: 1,368
Threads: 212
Joined: Dec 2006
Eric, thank you for your optimistic perspective on the machine, but can you comment more on your impressions of the limitations I have notedthe 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
▼
Posts: 111
Threads: 22
Joined: Jul 2007
Les,
I believe the matrix was a 4x4 (I know, small), with a vector of freeterms. The problem involved using the strength of LU to reevaluate the solutions for various freeterm 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 userintensive, 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 freetime. However, I find that I become very conscious of efficiency (lost on many kids w/ 50 gig HDequipped laptops). In fact, it's limitations, memorywise, 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 Titanic)
I am, by the way, graduating (finally) with my BSME in 2WEEKS!! So, I'm considering a graduation gift in the form of an HP...any suggestions?
ECL
▼
Posts: 673
Threads: 20
Joined: Oct 2008
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.
Posts: 801
Threads: 36
Joined: Nov 2005
I would second the suggestion of obtaining a HP48G+, but only if the price is reasonable, i.e., satisfactorily (to you, that is) less than the price of a brand new HP50G.
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.
Posts: 875
Threads: 37
Joined: Jul 2005
Quote:
I am, by the way, graduating (finally) with my BSME in 2WEEKS!! So, I'm considering a graduation gift in the form of an HP...any suggestions?
Congratulations on your upcoming graduation!
Regarding suggestions for your graduation gift, is this a gift from you to yourself, or from someone else to you? Is cost a driving factor? In my opinion, an HP15C would be a very appropriate gift to celebrate your accomplishments. An HP42S would be also be a very good choice. Unfortunately, neither is inexpensive, but if someone else is footing the bill......
▼
Posts: 111
Threads: 22
Joined: Jul 2007
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 HPalternatives.
The 42s is strongly appealing and still a relevant engineering tool along the design cycle (I'll be entering a job in design of fiberreinforced 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 quasiisotropic laminates ie.: E11 ~= E22)
HPs' ARE long lasting, and certainly (as we can attest) memorable ;)
Plus my Casio watch doesn't have any nonaesthetic issues!
If she won't go for it, I'm considering dipping into my signon bonus, hahaa...
BTW, thanks for the congrats!
ECL
Posts: 801
Threads: 36
Joined: Nov 2005
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 HP34C, my alltime 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 xray 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 FORTRANlike (okay, FORTH or LISPlike) 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 HP33S 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!)
Posts: 489
Threads: 11
Joined: Jan 2005
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.
Posts: 2,448
Threads: 90
Joined: Jul 2005
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"
▼
Posts: 1,755
Threads: 112
Joined: Jan 2005
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.
Best regards from V.
▼
Posts: 901
Threads: 113
Joined: Jun 2007
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 HP41. Does anyone remember the socalled "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 HP35, an HP45, an HP80 or an HP67.
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."
Posts: 887
Threads: 9
Joined: Jul 2007
Does anyone have a reallife 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 superaccurate 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 fixedpoint/scaled integer math (ie, not floatingpoint), the tangent function is one whose range and accuracy would be very problematic if we were to insist on just returning one 16 or 32bit 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.
Email: wilsonmineszdslextremezcom (replace the z's with @ and .)
▼
Posts: 74
Threads: 2
Joined: Jul 2005
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
▼
Posts: 887
Threads: 9
Joined: Jul 2007
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 HP71 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!
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
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.
Posts: 74
Threads: 2
Joined: Jul 2005
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. (0degrees, 0minutes, 0.2seconds) So if I convert this to decimal degrees, I can rather easily measure 0.000055decimal 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 50years 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.
▼
Posts: 887
Threads: 9
Joined: Jul 2007
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 HP71.
Still, it's impressive that something could measure such small angles.
▼
Posts: 776
Threads: 25
Joined: Jun 2007
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!).
Posts: 1,792
Threads: 62
Joined: Jan 2005
Quote:
Does anyone have a reallife 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 superaccurate tangent.
Hi, Garth 
That's a very reasonable question.
Frankly, I doubt that one could identify a reallife situation in which an inaccuracy  comparable to that identified in the HP33S  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 HP33S' 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 slightlyerroneous result using a calculated angle close to 90 degrees. Those who designed software for the Hubble Space Telescope (for example) might care about slightlyerroneous trigonometric functions.
However, the real point of the topic is the actual loss of mathematical expertise in the algorithms programmed into the HP33S. KinHPo started with a basis product  the HP32SII  that exhibited none of the three computational bugs that others found and I discussed. Furthermore, no other modern HPengineered 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.
HP33S HMS bug
HP33S Polar conversion bug
HP33S COMB bug
 KS
▼
Posts: 875
Threads: 37
Joined: Jul 2005
Quote:
Several of the bugs linked below may have been fixed. I don't have a newer version to test.
HP33S HMS bug
HP33S Polar conversion bug
HP33S COMB bug
My CNA532xxxxx unit exhibits none of the above bugs.
▼
Posts: 416
Threads: 78
Joined: Mar 2006
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 HP33S replacement, either as HP33SII (with bugs corrected), or as HP33S toutcourt (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 HP15C!
 Antonio
▼
Posts: 1,792
Threads: 62
Joined: Jan 2005
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 integerdivision bug, I believe that there was another related thread about remainder functions. I remember that there was a difference in results between the HP33S and other models with integer arithmetic, but it was difficult (at least for me) to nail down without a comprehensive, exacting definition of the integerarithmetic functions implemented. I believe that there were also differences between "MOD" on many models (which allows floatingpoint inputs) and "RMD" on the HP16C (for integers only). I would expect that these functions would be consistent with the corresponding integerarithmetic functionality.
Regarding the estimated errors of integrals, I didn't see evidence of a true bug in the HP33S. However, it seemed to use the methods of the HP48G instead of those of its predecessor HP32SII, 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 HP15C!
Oops  I thing you meant "heir", there... ;)
Seriously, I doubt that HP will ever extensively dedicate the paid efforts of "Alist" 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
▼
Posts: 416
Threads: 78
Joined: Mar 2006
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
Posts: 875
Threads: 37
Joined: Jul 2005
Quote:
That's assuming that HP/Agilent still has enough of them....
Hello Karl,
I agree that HP will likely never dedicate the resources to the development of handheld calculators. I'm just not sure that I would lump Agilent in with the current Hewlett Packard. As far as I know, Agilent is now a totally separate company, and it has been said that it embodies the spirit of early HP days, much more than the current HP at least. If you go to the Agilent web site, in my mind it looks like what HP may have looked like in the early 1970's. It looks like they could do the work, if they wanted to. If only Agilent had taken the calculator line with them in the spinoff....
Best regards
Posts: 1,368
Threads: 212
Joined: Dec 2006
Okay, you have all convinced methe thing is crap and I will pass it onto the cats to use as a chew toy....
Les
▼
Posts: 1,755
Threads: 112
Joined: Jan 2005
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.
