HP 33S instructions



#2

Hello,

some claimed that HP 33S memory capacity (more than 31000 bytes) is more than 80 times bigger than HP 32SII poor and lonely 384 bytes. It was on a site where this model was sold (don't remember which).

Sadly, HP 32SII had some good features that HP 33S has not:

I) first of all instructions on the 33S take 3 average bytes instead of the 32SII 1.5 bytes; this quite halves the total ratio!
II) second, integer numbers in the range 0÷254 (that were optimized in the 32SII to 1.5 bytes instead of the 9.5 of all other numbers) are not more optimized in the 33S;
III) any number now takes 15 bytes (integer or not). This reduces again the total ratio, that now is around 25 times.

I think necessity sharpens the brains, and that programming was much more beautiful on my now dead HP 32SII; probably I'll get used with this impersonal machine, and I'll start to love it, some day. But for the moment, I miss my HP 32SII!

-- Antonio

Edited: 14 Mar 2006, 10:33 a.m. after one or more responses were posted


#3

Hi Antonio,

Yes, I figure that in typical usage, the effective memory size is a bout 1/4 of the reported, so around 8 kb.

Take a look at the recent threaad regarding the statistics registers and the abiltiy to enter negative (n) on the pioneers, but not on the 33s.

If you liked using the equation list feature on the 32sii, you will find the 33s is superior, because it has eliminated the inconsistency of the unary minus as parsed in the 32sii.

But you should also pay close attentions to the difference in how "solve" works in some instances. Jordi Hidalgo wrote a goot short article on this in DATAFILE a year or so ago.


#4

Yep, I noted the solve difference when developing one of the 33S learning modules. I was trying to get a root for X^2-4=0 and it would only get one answer, no matter what guess was supplied. This was the direct solve result.

So, had to modify that example.

Gene


#5

Gene,

I couldn't believe my new HP 33S was bugged, but after your post I tried: your equation X^2-4=0 input in EQN mode gives always 2.0000 as result with SOLVE, no matter what initial estimates you put into X and on TOS! It's a shame!

How can I trust it anymore? Maybe there's a bug even into other routines (integration, for example)! My older and beloved HP 32SII (now broken) gives the right answers (2.0000 and -2.0000) to it!

Luckly, SOLVE seems to work correctly if you input the equation into PRGM mode, as the older HP 32S did. But this makes no difference at all: 33S seems to me a mistaken model the same.

What about it? Is there a way to know what happens and why, and how to override this behaviour?

-- Antonio

Edited: 14 Mar 2006, 10:31 a.m. after one or more responses were posted


#6

Quote:
How can I trust it anymore?

The 32SII too had a bug in the solver. It has been discovered in 2005 and was discussed right here. I don't remember the details but it had something to do with breaking a solver operation and starting a new one without clearing the stack. Anyone knows better? Sorry to the poster about not remembering his name:(. Anyway, these machines (the software in the first place) have reached a complexity over the years that makes it impossible to test every detail. You have to live with it.

Thomas


#7

Hi, Thomas:

Thomas posted:

"Anyway, these machines (the software in the first place) have reached a complexity over the years that makes it impossible to test every detail. You have to live with it."

    I don't quite agree, matter of fact it seems to me a pretty lame excuse for not doing the job properly and reducing costs by outsourcing engineering to mediocre third parties and cutting on the testing and Q&A phases.

    The HP-15C certainly has much greater algorithmic complexity than the HP33S, what with extensive complex and matrix functionality, yet it's nearly absolutely bugless, never ever have I heard about or experienced an HP-15C bug, however slight, after decades of heavy use. The HP42S is in the same league, despite being still much more complex.

    So it's not a case of "increased complexity over the years that makes it impossible to test every detail", as these old machines are far more complex, but a case of lack of quality in their products and procedures and a lack of respect for their customers and users, which are nothing but paying beta-testers for their DbD (defective-by-default) products.

    The one and only thing that is impossible is for HP to ever revert to a tiny fraction of their past quality and attention to the customer, pioneered in the seminal "The HP Way" by its founding fathers and long discarded into oblivion by its recent management.

    As for "you have to live with it", there seems to be a number of people who have adopted that philosophy but I'm not one of them. These people probably forgot that quality was their initial aspiration and that's what attracted them to HP in the first place. Now they're mixing affections and stick with HP for the sake of it, long after the quality's been irretrievably gone.

    You may live with it, if you feel like it. I chose to live with quality, and lately "HP quality" has become a book example for the term "oxymoron".

Best regards from V.


Edited: 14 Mar 2006, 12:11 p.m.


#8

And, just for the record, while there are bugs in early versions of the 33s, the direct solve I mentioned is not one of them - it was a conscious design choice, I believe.

And, while it might be a bit too much to expect non-bug-roms for a machine like the 49g+, a machine like the 33s should not ship with bugs.

Of course, the 41c shipped with bugs too. Let's not forget about that. Bug 1 (non-save of LastX when Sigma+) and Bug 4 (or 5? bad SIN for small values of x) were in machines over the first year or so of it's sale.

Most machines ship with bugs...and the more complex the machine, the greater the number of them.

The 15c is truly a marvel and I too am not aware of any bugs.

The 33S should not have had any, IMO.

Valentin, did you see the response on timing of your trig program on the "parentheses 12cp"?


#9

Hi, Gene !

"And, just for the record, while there are bugs in early versions of the 33s, the direct solve I mentioned is not one of them - it was a conscious design choice, I believe"

    Yes, I know. But seems to me as just another instance of "turning a bug into a feature", if you know what I mean ...
"a machine like the 33s should not ship with bugs."
    Agreed.
"Most machines ship with bugs...and the more complex the machine, the greater the number of them."
    Except for the HP-15C and the rest of the Voyagers, that were virtually bug-free despite being much more complex than their predecessors, some of which did have well-known bugs. I'm also not aware of any significant bugs in the HP42S.
"The 15c is truly a marvel and I too am not aware of any bugs."
    Indeed it is. It even has some 'synthetic' possibilities. But no bugs so far.
"The 33S should not have had any, IMO."
    IMO, too.
"Valentin, did you see the response on timing of your trig program on the "parentheses 12cp"? "
    Yes, I saw it, thank you very much for telling me. The times are
    very good, though I don't know exactly why but I was expecting
    even faster ones.

    Thanks for your reply, and don't get too upset with my derogatory comments. They're well deserved ... someday you'll see the light, too. :-)

Best regards from V.

#10

Derogatory comments? Never taken that way. :-)

Like everyone else, I sometimes post when I'm in too "testy" a mood.

I certainly don't want "buggy" products and I want higher quality machines.

Would be interesting to test the new 12cp on one of your "root" problems against other contenders. Perhaps when I have time...

#11

The "Bugs" section of the Forum contains the following statement:

"Early HP-11Cs had a bug in which if you entered a number in the form 0.0xxx, backspaced over all the digits and then pressed ENTER, 1.00 was entered rather than 0.00. HP allowed users of buggy calculators to swap for fixed units."

I have one of those buggy units (S/N 2217A03623) in my collection. I also have a later, properly operating unit.


#12

Hi, Palmer O:

Palmer O posted:

"Early HP-11Cs had a bug in which if you entered a number in the form 0.0xxx, backspaced over all the digits and then pressed ENTER, 1.00 was entered rather than 0.00 [...]
HP allowed users of buggy calculators to swap for fixed units."

I hope you'll agree with me that:

  • Such a 'contrived' bug that only happens when you do some unnatural series of operations, which are non-programmable to boot, whose usefulness is nil, the remedy being as simple as not doing that nonsense to begin with, as is the case with the one "bug" you mention, is in a vastly different league than most of the ones reported for the HP33, say, such as the polar-rectangular conversions for instance, and simply can't be compared: plainly saying that they're both "bugs", so that the HP-11C "also has a bug" is *highly* misleading.

  • The HP-15C which was the precise model I mentioned never had this "bug". Also, you'll not be able to tell me of any other bug for the HP-11C (10C, 15C, 16C, ...) because none has ever been reported, to the best of my knowledge. I knew about the 11C "bug" you mention but never considered it a proper bug worth worrying or talking about. The fact that HP of old nevertheless replaced machines having this inconsequential and inoffensive "bug" says volumes about HP's former commitment to quality and user satisfaction, i.e., the "HP Way" once more.

Best regards from V.


#13

The fact that HP of old nevertheless replaced machines having this inconsequential and inoffensive "bug" says volumes about HP's former commitment to quality and user satisfaction, i.e., the "HP Way" once more.

Amen :-)

#14

Hi, Valentin --

The original issue:

Quote:

"Early HP-11Cs had a bug in which if you entered a number in the form 0.0xxx, backspaced over all the digits and then pressed ENTER, 1.00 was entered rather than 0.00 [...] HP allowed users of buggy calculators to swap for fixed units."

To which you stated,

Quote:
Such a 'contrived' bug that only happens when you do some unnatural series of operations, which are non-programmable to boot, whose usefulness is nil, the remedy being as simple as not doing that nonsense to begin with, as is the case with the one "bug" you mention...

I beg to differ about this. If a zero-quantity is present in the display, no matter how it was produced, ENTER should not convert it to 1.00. That is a bug in every cyber-based sense of the the word; HP was justified in fixing it and offering free replacements. In fact, the individual(s) who discovered and reported it may have prevented a similar problem from being introduced into the HP-15C and HP-16C (but not the HP-10C and HP-12C, which had no backspace operation).

Quote:
...is in a vastly different league than most of the ones reported for the HP33, say, such as the polar-rectangular conversions for instance, and simply can't be compared: plainly saying that they're both "bugs"...

As one who spelled out the flaws, I absolutely agree with this statement. The first HP-33S had unacceptable shortcomings in representation of arguments (e.g., -0) mathematical algorithms, and validation of output. These problems were beyond mere "bugs" that would have been unacceptable in real HP's.

Regards,

-- KS

#15

Valentin,

I'm not aware of a test setup to check a particular calculator for any bugs. Something like that wasn't available when the 15C came out and it is not available today.

Even the HP-35 had bugs.

If I or anyone else chooses to live or to not live with the potential risk of a bug is completely irrelevant. A company might be able to reduce the number of bugs in their products by carefully designing it but it won't be able to guarantee their reliable operation.

I understand your point and appreciate it much but it is not related to what I said.

#16

Anyway, these machines (the software in the first place) have reached a complexity over the years that makes it impossible to test every detail. You have to live with it.

No, I have not. Certainly, almost every HP calculator has a few bugs (including HP-35, HP-41C, HP-71B, HP-42S, HP-48SX, HP-48GX, ...). But the number of bugs in the later HP/ACO/Kinpo/... calculators is just too big for my taste. For example, they are "fixing" bugs in HP-49G+ for the last two years and still haven't fixed all of them. Not to forget that they were fixing HP-49G for a few years before ...

Edited: 15 Mar 2006, 2:17 a.m.


#17

Quote:
Anyway, these machines (the software in the first place) have reached a complexity over the years that makes it impossible to test every detail. You have to live with it.

No, I have not. [...]


Yes you have. As long as you cannot give a prove for a calulator to operate in line with its manual, my statement is true.
Quote:
[...] But the number of bugs in the later HP/ACO/Kinpo/... calculators is just too big for my taste.

Also for mine. But that was not the point here. Please re-read to post that I replied to.

Thomas


#18

Yes you have.

No, I have not.

As long as you cannot give a prove for a calulator to operate in line with its manual, my statement is true.

In the HP-49G+ manual you will (probably) find that when you press some key the calculator will register it. Well, this is sometimes true and sometimes not. What more do you want?

This thread is about HP-33S so talking about HP-49G+ is off-topic here. But, you said "these machines" so I supposed you were talking about all new HP calculators ...

But that was not the point here. Please re-read to post that I replied to.

I re-read it. It is the same as the last time I read it: "Anyway, these machines (the software in the first place) have reached a complexity over the years that makes it impossible to test every detail. You have to live with it."

So, what was the point? That HP isn't capable to produce a "HP quality" calculator anymore and that we "have to live with it"? I would rather say that I can live without it (I mean: without any new HP calc) ...


Edited: 15 Mar 2006, 5:01 a.m.


#19

Quote:
In the HP-49G+ manual you will (probably) find that when you press some key the calculator will register it. Well, this is sometimes true and sometimes not. What more do you want?

If thats in the manual, then you have proven that the 49G+ is buggy. The tricky part ist to prove the opposite (i.e., that there are no further undocumented bugs).

Suppose someone asks you whether he can trust a particular calculator or not. He already knows about some bugs, so the question turns into whether there are more bugs that haven't been discovered yet. I said (in other words): It is impossible to test all functions in any situation in reasonable time. Therefore, you cannot trust it. I gave him an example about a calculator that has been in the marked for a long time but only recently revealed a really nasty bug. Was I clear this time?

One is certainly better off using a 15C instead of a 33S (if applicable) but still, he is not on the safe side.

Quote:
This thread is about HP-33S so talking about HP-49G+ is off-topic here. But, you said "these machines" so I supposed you were talking about all new HP calculators ...

No, I was taking about calculators in general.
Quote:
So, what was the point? That HP isn't capable to produce a "HP quality" calculator anymore and that we "have to live with it"? I would rather say that I can live without it ...

Once again, even when HP did a better job, there was no reason at all to trust a calculator. I think, I am clear by now.

Thomas


#20

... there was no reason at all to trust a calculator.

If I don't trust it then why would I use it?

Anyway, yes, I trust all HP calculators I am using (HP-48GX including and before) and that's why they are built: to use them because you trust them. I am sure I'm not the only one :-)


#21

Quote:
If I don't trust it then why would I use it?

I can only speak for myself. I use them because I need to. Thus far, my calcs haven't dissapointed me, including the 32SII. Knock on wood;-).

Thomas

#22

Hi Antonio.

These are not new revelations but have been documented even here on the forum.

I also do not believe they are "bugs", but behavior chosen for a purpose.

It works like this:

When an equation has one occurrence of a variable, and only one occurence, the 33S solver will use the direct solver to estimate a root. That is why the X^2-4=0 finds the solution x=2 and only x=2. It does not use an input value as a guess in this instance, since it uses the direct solver.

An equation such as X^2-5x-6 will use input guesses and find more than one root, since X occurs more than once in the equation.

To force the 33S to solve X^2-4=0 and find multiple roots, you must enter the equation as something like this:

X^2-0*X-4=0

This will use input guesses and find more than one root.

This is documented in the 33s learning modules available on HP's site.

You will have no luck claiming this is a bug to HP because this behavior was chosen and is considered the "way it is supposed to work".

So, to get around this behavior, if you have an equation with only one variable that is taken to a power, enter an extra term including 0 multiplied by the variable.

We might disagree with whether this should be the way it ought to operate, but that's the hand of cards we've been dealt.

If you haven't looked over the learning modules on HP's webpage for the 33S, you can find them here:

http://h20331.www2.hp.com/Hpsub/downloads/33s.zip

which will download all the modules in one zip file.

The two specific 33s modules dealing with the solver (which were written by Wlodek!) can be found here:

http://h20331.www2.hp.com/Hpsub/downloads/33sSolver.pdf

http://h20331.www2.hp.com/Hpsub/downloads/33sSolver2.pdf

The second module (33sSolver2.pdf) has a discussion of the "Direct Solve" "feature".

Hope these help!

Gene

#23

Antonio (and others who are interested)--


I agree completely with your sentiments.

Here's a link to a thread from September 2004 regarding the direct-method implementation of SOLVE on the HP-33S. It includes some dialogue between Gene and me.

One thing I didn't realize at the time was that the celebrated algebraic solver from the HP-17B/17BII/27S did the same thing -- always providing the direct-solution value whenever possible, even when the initial-guess value of the variable of interest is at or near another valid solution.

Regards,

-- KS


#24

Thank you all.

-- Antonio

P.S. I do agree with those who think HP should not lower down its quality only because "it's complex". Its history is a confirmation of that.

Thanks again


Possibly Related Threads...
Thread Author Replies Views Last Post
  Non-Prime question alert: Hp-41 and synthetic instructions Marcel Samek 11 1,548 11-04-2013, 09:31 PM
Last Post: sjthomas
  WP-34s: Crystal and capacitor instructions? W. Bruce Maguire II 2 519 05-03-2012, 02:04 PM
Last Post: W. Bruce Maguire II
  Instructions for building WP-34s loads. Dominic Richens 27 2,087 09-27-2011, 01:39 AM
Last Post: Walter B
  Instructions from HP for disassembling calculators Eric Smith 9 901 05-03-2011, 09:59 AM
Last Post: exschr
  Video Instructions designnut 1 320 05-19-2009, 12:20 PM
Last Post: hpnut
  No 50G instructions update designnut 1 371 04-17-2008, 03:41 PM
Last Post: Eric Smith
  HP-35S instructions on CD designnut 5 641 01-25-2008, 05:12 PM
Last Post: designnut
  Integration Times "Old" 33s vs "New" 33s John Smitherman 21 1,856 12-14-2005, 12:04 AM
Last Post: Karl Schneider
  HP 59306A Relay Actuator - instructions needed Artur-Brazil 6 735 06-15-2005, 08:37 PM
Last Post: Artur - Brasil
  Instructions Stacey Bower (Oregon) 1 333 08-30-2004, 04:37 PM
Last Post: Vieira, Luiz C. (Brazil)

Forum Jump: