11-18-2020, 01:51 PM
(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.
(11-18-2020 07:17 AM)ThomasF Wrote: [ -> ]Are these known in broader public? Someone interested in the complete list?
(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.
(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.
(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.
(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.
?
(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).
(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.
(11-20-2020 09:34 AM)Paul Dale Wrote: [ -> ]My guess would be that \( e^{y log x} \) is used.
(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.
(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.
(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
(11-18-2020 03:31 PM)ThomasF Wrote: [ -> ]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 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.
(06-13-2021 02:17 PM)Roberto Volpi Wrote: [ -> ]Well, it means that our beloved HP35S is not alone in the universe.
Why is it so unfairly bashed?