HP Forums

(11-18-2020 07:17 AM)ThomasF Wrote: [ -> ]Are these known in broader public? Someone interested in the complete list?

Yes, please, Thomas!
Thank you.

Ok - sure, no problem!

This is a list I compiled back in november 1981 (39 years ago ... ) for our members letter for the PPC Chapter of Gothenburg, Sweden.

It contained 6 bugs collected (I guess some of them are variants of each other), but here is a raw translated list of these bugs.

Note, it's been a while, and I don't recall the numbering of the bugs (maybe different reporters of the bugs), nor can I validate since I have no HP-34C anymore to test with.
I can however reproduce most of them on my phone with the go34c application.

Bon apetit!

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

BUG 1:
If you in PRGM-mode press "GTO . 9 9 A" followed by a number (0-9), 'A' or 'B' this will insert a hex-code in program memory. The code is between 0xA0 and 0xAB (depending on the number/letter you entered). Similar if you press 'B' instead for the first 'A' (ie. "GTO . 9 9 B"), then you will get code between 0xB0 and 0xBB.
Reproduced on my phone.

BUG 2:
If you enter "h F? A" followed by a number (0-9), 'A' or 'B' you will enter a code between 0x20 and 0x2B. And if you replace the first 'A' with 'B' you get codes between 0x30 and 0x3B.
Reproduced on my phone, note that this is a simple way to enter the only spare instruction (0x26) in a program. See http://www.brouhaha.com/~eric/hpcalc/hp3...table.html

BUG 3:
If you move the switch over to PRGM-mode and at the same time press a key that show the current program line in memory, ie. SST, R/S, GSB n or SOLVE n (but not BST), then the calculator, when you release the key, copy that line to the following line in memory.
Can't reproduce on my phone - can someone with a HP34C?

BUG A:
If you press "GTO . 9 9 f 9" in that order, then the keys 0-9, +, -, *, / and x<>y will not work anymore, either in RUN or PRGM-mode. You can leave this state by pressing any other key.
Reproduced on my phone.

BUG B:
Directly after pressing "GTO . 9 9 f 9" the keyboard will be "shifted", eg. you will get "f TAN" by pressing "f COS". This will go away as soon as any key has been pressed once. "GTO . 9 9 f 9 9" gives similar result but now "f TAN" is placed on "f 0". Other combinations of "GTO . 9 9" with 'f', 'g' or 'h' and a number 1-9 have similar effects. The number zero '0' appears different and we will issue a warning for it will sometimes start the integration instuction.
Reproduced on my phone but with a bit different result. "GTO . 9 9 f 9" result in "f SIN" by pressing "f COS". "GTO . 9 9 f 9 9" generates "->H.MS" by pressing "f COS" etc.

BUG C:
Enter 15 lines of instructions and press "GTO . f n" where 'n' is a number 1-9. Then the calculator jumps to line 'n+2'. If you replace the number n with the key '-', '+', '*' or '/' will give similar result, but then the calculator jumps to line 012, 013, 014 resp. 015. Even the R/S-key work in a similar way, but jumps to line 011.
Reproduced on my phone.

(08-05-2017 04:54 AM)Joe Horn Wrote: [ -> ]At HHC 2010 (aka HHC MMX) I gave a brief talk about bug hunting and presented a short list of "My Favorite Bugs" in HP calculators. Please note that the list is by no means complete; it's just my favorites. Some are not really bugs, but hidden features or anomalies or simply unexpected weirdness.

I don’t consider the -65 items on your list to be bugs; rather, undocumented aspects or features (especially considering many steps useful). The deletion of the primary pointer while in a subroutine call crashing the calculator might be more of a bug.
Correction: for the last one, it’s not simply interrupting power that’s the trigger. You need to be recording a card (typically the default 5 program steps); the card will then have gaps which get misinterpreted when the card is read. This allows entering into program memory opcodes which don’t correspond to actual keystrokes, but are used by the internal logic. These include things like the primary and secondary pointers as well as the top of memory marker, there was a big article in 65 notes by Lou Cargil and one other person whose name escapes me right now that explained all of this.

Short power interruptions did cause some anomalous behavior on the -67, although I can’t remember what it was right now. That was also documented in a later issue of 65 Notes or the PPC Journal.

(08-05-2017 08:55 AM)Sadsilence Wrote: [ -> ]Not a real bug, but all classics and most woodstocks are not able to calculate 2^32 correctly. They tell us 4294967304, correct would be 4294967296. Even more strange, that HP-19C can, HP-25 cannot.

The HP-29c does it correctly as well.

In addition to multiplying directly, using x**2 repeatedly also works.

(08-05-2017 08:55 AM)Sadsilence Wrote: [ -> ]Not a real bug, but all classics and most woodstocks are not able to calculate 2^32 correctly. They tell us 4294967304, correct would be 4294967296. Even more strange, that HP-19C can, HP-25 cannot.

The HP-29c does it correctly as well and so does the 97s (and presumably the 67 and 97).

There was a significant algorithm change between the 25[c] and 67/97: Machines prior to the 67/97 appear to use a logarithm-based algorithm; later machines have exceptions built in for certain cases. The primary visibility on those machines is the ability to raise negative numbers to integral powers, which can be done by multiplication as an alternative to using logarithms. This requires soecial-casing integers, do I expect the 2**n issue to use the multiplication code as well.

The only intervening machine is the HP-27, which oddly has no y**x function built in.

In addition to multiplying directly, using x**2 repeatedly also works.

The HP-27 has Y^X on the second row, last button on the right.

?

(11-19-2020 10:07 PM)Gene Wrote: [ -> ]The HP-27 has Y^X on the second row, last button on the right.

?

Doh! Guess I was looking too hard for a shifted function. Seems to be shifted on Classics and Woodstock’s after -35, but mixed on the business calls that have it: 70, 80 and 27 are unshifted; 22 is.

Anyway both the 22 and 27 have the newer algorithm that give correct answer for 2**n and also allows negative bases with integral exponents.
-kby

(11-19-2020 07:32 PM)[kby] Wrote: [ -> ]The HP-29c does it correctly as well and so does the 97s (and presumably the 67 and 97).

Both 67 and 97 emulators are correct so I assume the reals ones are too :-)

cheers

Tony

(11-20-2020 02:57 AM)teenix Wrote: [ -> ]Both 67 and 97 emulators are correct so I assume the reals ones are too :-)

You assumed correctly. I tried on real ones and the compute 2^32 correctly.
My HP-55 and HP-25 do not.

.
I wonder, are all integer powers computing by squaring and multiplying partial powers? Or are powers of two special cased? William Kahan suggests we compare 3^201 with 729^33.5

My guess would be that \( e^{y log x} \) is used.

Integer powers via squaring and multiplication is an approach but early devices wouldn't have had the ROM space to include this in addition to a real version.


Pauli

(11-20-2020 09:34 AM)Paul Dale Wrote: [ -> ]My guess would be that \( e^{y log x} \) is used.

Exactly. See this HP Journal issue, specifically, the sidebar titled "The New Accuracy: Making 2^3 = 8*" on pages 16-17. The improved accuracy was achieved by avoiding rounding on the intermediate results.

(11-20-2020 11:23 AM)Thomas Okken Wrote: [ -> ]

(11-20-2020 09:34 AM)Paul Dale Wrote: [ -> ]My guess would be that \( e^{y log x} \) is used.

Exactly. See this HP Journal issue, specifically, the sidebar titled "The New Accuracy: Making 2^3 = 8*" on pages 16-17. The improved accuracy was achieved by avoiding rounding on the intermediate results.

Contents of the article aside, there is more than just avoiding intermediate round-off in allowing negative bases. That can’t be done with a logarithm-based algorithm regardless of the accuracy.-kby

Hello!

Problem to me is lack of featurers.
Bugs can be fixed, however lack of features are hard to solve.

(11-21-2020 05:55 AM)CMarangon Wrote: [ -> ]Hello!

Problem to me is lack of featurers.
Bugs can be fixed, however lack of features are hard to solve.

Whether I agree with that or no t kind of depends on the featureless is “missing.” If it’s a mathematical function on a p rogrammable calculator I would
Be less concerned as it could simply be programmed. If it were a more “fundamental” feature like looping , branching or a PAUSE function,the I’d be more persuadable.

I am going to be provocative here, by nominating the HP-9825 as the calculator with no known bugs.

In http://hp9825.com/html/hpl.html it mentions that The language ROMs were never replaced in the field due to a bug.

So while not a calculator as we think about them, it was marketed as a calculator and it had no bugs.

**vp

http://www.series80.org

(11-23-2020 10:43 AM)vassilisprevelakis Wrote: [ -> ]I am going to be provocative here, by nominating the HP-9825 as the calculator with no known bugs.

In http://hp9825.com/html/hpl.html it mentions that The language ROMs were never replaced in the field due to a bug.

So while not a calculator as we think about them, it was marketed as a calculator and it had no bugs.

**vp

http://www.series80.org

If the criterion is ROM replacements then probably many things qualify. Did the -45, -80, -65, -55 have ROM replacements? I guess technically the 045 had one to reverse the storage register arithmetic, although I wouldn’t put that in the category of bug. The museum has no bugs listed for the Stings or Woodstocks, but Bernhard started this thread talking about a Woodstock.