Posts: 120
Threads: 21
Joined: Oct 2005
I'm working in the R&D department of an aircraft manufacturer. I have ordered a larger quantity of HP-35s for our engineers. While talking to the main importer for Switzerland I mentioned that a few bugs have already been found. The importer had heard about the bugs and had a meeting with HP where HP told them that this was all just negative publicity, possibly spread on the internet by their competitors. What do you guys think of HPs position here?
The importer offered me to pass a buglist to HP if I could provide it. I know of the cos(x) bug for x= near to 90. I have also heard about the checksum error.
Could we please collect all known bugs in this thread and I'll pass them to HP. I also made them clear that in aviation industry there's little room for errors. If we find out the HP-35s has unacceptable bugs I'll return them all to HP. I'm quite a HP fan but since about 10 years we have been let down with lousy hardware. The hardware of my personal HP-35s feels very good to me. But I can't believe that HP haven't fixed known bugs since the HP-33s.
I understand that the HP-35s would have never been realised without a lot of pressure from the enthusiasts here. Now I think we should keep the pressure up in order to get back the quality we expect.
Thanks for all your contribution.
Daniel Diggelmann
Edited: 22 Aug 2007, 5:03 p.m.
Posts: 3,229
Threads: 42
Joined: Jul 2006
I've put this list up as an article and will try to keep that current rather than editing here all the time. Check the article for the current state of affairs.
Here is a quick list I've made up. Feel free to expand and/or correct these:
- Vector input bug has been mentioned and very weird behavior shows up
but I'm not aware of this being isolated or repeatable. I do have enough
trust in the people reporting problems to believe there is something
to them.
- Cos(x) for x near 90 is dud.
- Checksums are meaningless. Seems to be related to numbers in programs
but nothing definitely proven yet.
- Program sizes are also meaningless. Again seems to be number related
and again nothing proven.
- Bad error message on indirection on J. You get "INVALID (I)" error
message if done from the keyboard, from a program it gives the correct
message: 1000 ; STO J ; x<>(J)
- Bad radix. If you are in RADIX, mode and you enter RADIX, in program
mode it is displayed as RADIX.
- Program entry bug for large programs. Create a 999 step program
and then try to enter a new LBL. You're not allowed. Delete one step,
create the LBL and put the step back and all is fine.
- GTO.a ENTER doesn't work as expected. GTO.a000 does.
- INPUT (i) for i>=0 doesn't work. Strictly this is documented in
the manual and so isn't really a bug.
- Poor choice for the grahpic for the "theta".
It is much too close to the graphic for "8". Again, not strictly a bug.
This probably should go up as an article rather than being lost in the forum section.
- Pauli
<edited to include checksum and program size bugs>
<edited to include theta vs 8 discrimination problems>
<pointed to the article in progress>
Edited: 22 Aug 2007, 8:02 p.m. after one or more responses were posted
Posts: 1,755
Threads: 112
Joined: Jan 2005
Posts: 3,229
Threads: 42
Joined: Jul 2006
The checksum was mentioned in the initial post, but I should have remembered it too. Also the program size is screwy. I'll add both to my list.
- Pauli
Posts: 553
Threads: 57
Joined: Sep 2006
Agreed. Some common, visible location would be the best. A wiki, in some respects.
Seems like several folks would like to consider the poor character layout choice for "theta" as a "bug" -- I'd at least pass it along to HP.
thanks,
bruce
Posts: 55
Threads: 5
Joined: Jul 2007
10. Theta sign in complex display mode is hard to differentiate from an eight.
11. Missing re/img extraction may be considered as bug?
Posts: 3,229
Threads: 42
Joined: Jul 2006
I've put the list into an article.
I'll keep it updated as new bugs are found and errors in the list reported.
I've also split the list into genuine bugs and annoyances that are harder to classify as bugs. Feel free to dispute my classifications.
- Pauli
Posts: 1,477
Threads: 71
Joined: Jan 2005
Also, in a program:
VIEW (I)
PSE
will show the wrong value of I
Posts: 1,089
Threads: 32
Joined: Dec 2005
It has already been mentioned that only improper fractions can be entered, i.e., the expression a..b, resulting in a/b on the 32SII, cannot be entered. I'd consider this a design flaw.
Edit: Not quiet correct, of course 0.a.b can be entered but this seems to be unnecessarily laborious.
Edited: 22 Aug 2007, 6:46 p.m.
Posts: 9
Threads: 0
Joined: Aug 2007
Since you mentioned it for another item you listed, it's worth noting that the "Cos(x) for x near 90 degrees" bug is also alluded to in the documentation (pg. 4-4 in the English User's Guide).
Quote:
Here is a quick list I've made up. Feel free to expand and/or correct these:
- Vector input bug has been mentioned and very weird behavior shows up
but I'm not aware of this being isolated or repeatable. I do have enough
trust in the people reporting problems to believe there is something
to them.
- Cos(x) for x near 90 is dud.
blah...blah
Posts: 4,587
Threads: 105
Joined: Jul 2005
Hallo Thomas,
to reach a/b, you are free to enter .a.b - same number of keystrokes as the a..b you miss AND more logical ;-)
Posts: 1,089
Threads: 32
Joined: Dec 2005
How could I possibly miss *that*? Oh well...
Thanks Walter :-)
Posts: 2,761
Threads: 100
Joined: Jul 2005
Nope, at page 4-4 they say sin(pi) is not equal to zero because pi is represented internally with fifteen places (although the computed answer appears to have been taken with pi to only twelve places). In fact, sin(3.14159265359 rad) = -2.0676153735661672045E-13, to 20 places, whose first 12 digits agree to the answer given by the 33s, after rounding.
The point here is cos(x) -- and tan(x) -- not being correctly computed for x near 90 degrees. For instance, cos(89.999) returns 1.745329091E-5. The correct result at this precision is 1.74532925191E-5. Even worse, tan(89.99999) returns 5,729,578.122 instead of 5,729,577.95131. These mistakes might not affect practical applications, but should not occur in a XXIst-century calculator...
Gerson.
Edited: 22 Aug 2007, 9:29 p.m.
Posts: 2,761
Threads: 100
Joined: Jul 2005
Not exactly bugs, rather a feature. Anyway, suggestions for improvement:
1) XEQ [label] ENTER is rather cumbersome. Also, since XEQ stands for 'execute', ENTER appears to be redundant. Besides, the ENTER key always seems to be so far far away to me :-)... Why not simply XEQ [label]? XEQ [.] nnn should be used for a particular line.
2) In ALL mode, the mantissa should be properly rounded so that the exponent fits in the screen, a la 32S, 32Sii, 33s, etc... Or, at least, a flag should be provided for this option.
3) 2*2 lin. solve and 3*3 lin. solve look strange. 2x2 and 3x3 seems better. I would guess that was the original idea, but then some 'translated' that x as *.
4) Exchange the positions of Sigma+ and R/S keys.
Regards,
Gerson.
Edited: 22 Aug 2007, 10:27 p.m.
Posts: 9
Threads: 0
Joined: Aug 2007
Thanks for the clarification; I just assumed it was a related "rounding error." And it appears that pi is definitely *not* 15 places internally, but only the 12 places that you noted is actually being used. So the documentation is wrong about that. (As a technical writer myself, I never like discovering that!)
Posts: 1,841
Threads: 54
Joined: Jul 2005
For your first note:
AFAIK they made the XEQ work the way it does because you can
use it to jump to a specific program line in another program.
Consider you're in line A012, and want to call
a specific line in program B, say B056.
Then you will enter XEQ B056, followed by pressing ENTER.
I still don't like the programming model,
which is a blown-up 32S/33s programming model,
but at least you _can_ call code slices
which you otherwise could not reach.
Besides, IMHO the ENTER bar is in the perfect position;-)
Raymond
Posts: 1,841
Threads: 54
Joined: Jul 2005
The Saturn-based calcs, like the original HP-32S and HP-32SII,
have an internal accuracy of fifteen digits plus sign.
But please note that the 35s is not a Saturn-based machine,
and thus it isn't necessarily 100 percent compatible.
Maybe the docs haven't been updated accordingly...
Raymond
Posts: 2,761
Threads: 100
Joined: Jul 2005
In fact, it's been shown that pi is a double-precision constant in all Saturn-based calculators. This is true on the HP-35s as well. Do the following, in RAD and in ALL display mode:
pi
9E-11
-
ENTER
SIN
1E22
*
You'll get
3.1415926535
897,932,384,626
That's pi to 23 digits:
3.1415926535897932384626
This was already discussed here, some years ago:
http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv014.cgi?read=62301
When pi is shown in the display, it is rounded up to 12 digits. Therefore the calculator's answer for sin(pi) is equivalent to sin(3.14159265359 rad), which is absolutely correct.
Regards,
Gerson.
Edited 4 grammar.
Edited: 23 Aug 2007, 10:58 p.m. after one or more responses were posted
Posts: 2,761
Threads: 100
Joined: Jul 2005
Quote:
Besides, IMHO the ENTER bar is in the perfect position;-)
IMEMHO, you are right! Now, I wish there were also a big-ENTER-key 50g. It would be a perfect companion to the 35s.
Regards,
Gerson.
Posts: 2,761
Threads: 100
Joined: Jul 2005
Quote:
Consider you're in line A012, and want to call
a specific line in program B, say B056.
Then you will enter XEQ B056, followed by pressing ENTER.
I think XEQ .B056 to accomplish this would be better:
- same number of keystrokes;
- Only two keystrokes when calling B001 (XEQ B).
Or would this present some inconsistency I have not perceived?
Gerson.
P.S.: ENTER could be reserved for shortcuts:
XEQ .B7 ENTER, rather than XEQ .B007
Edited: 23 Aug 2007, 9:55 a.m.
Posts: 2,448
Threads: 90
Joined: Jul 2005
Another desirable feature to be suggested for addition:
composition and decomposition of Vectors. Also cross product.
Posts: 120
Threads: 21
Joined: Oct 2005
Dear colleagues,
Thanks very much for all your responses to the bug list. I've passed them on the importer which has already passed them to HP Europe. Let's hope they fix them in the next series.
Regards from Switzerland, Daniel
Posts: 9
Threads: 0
Joined: Aug 2007
Gerson --
Maybe I'm just dense then, but (ignoring symbolic-mode calculators for a moment) why is sin(pi) on a "double-precision" 35s equiv. to sin(3.14159265359 rad), and not sin(3.1415926535897932384626 rad)?
-- DLF
Posts: 2,761
Threads: 100
Joined: Jul 2005
I think I didn't make myself clear, sorry! When I wrote sin(pi), I meant pi rounded up to 12 digits, not the internal double-precision constant used in the trigonometric routines to ensure better accuracy.
An example might help us understand how this works:
Let's consider the HP-15C, whose internal pi constant is 3.14159265359. So on the HP-15C sin(3.141592654) will return -sin(3.141592654 - 3.14159265359)= -sin(4.1E-10) = -4.1E-10. In the third quadrant, sin(x) = -sin(x - pi). If the argument is the second quadrant, for instance, x = 3.14159265 then sin(x) = sin(pi - x). In this case, the HP-15C returns sin(3.14159265359 - 3.14159265) = sin (0.00000000359). For very small arguments, sin(x) = x. So, what we get here are the last three digits of the 12-digit internal pi constant: 3.14159265359. Had the HP-15C a double-precision pi internally, we would obtain 0.000000003589793239, that is, 3.1415926535897932385 - 3.14159265.
Gerson.
Posts: 1,792
Threads: 62
Joined: Jan 2005
Hi, Gerson --
Quote:
Why not simply XEQ [label]? XEQ [.] nnn should be used for a particular line.
Good idea, but we'd need XEQ [.] Lnnn, where L is a letter label.
Quote:
In ALL mode, the mantissa should be properly rounded so that the exponent fits in the screen, a la 32S, 32Sii, 33s, etc
Or in any mode for which the display length is too short to accommodate the full number. I, too, preferred the "legacy" method (which actually pre-dates Pioneer models) because it shows the full exponent, providing the magnitude of the number that cannot be overlooked.
However, the HP-35s, with its 14 display positions, cannot display a complete "longest-possible" complex number, even if the mantissa were rounded to only one digit. 15 display positions would be required to show such a number, e.g.:
1.0111x10-234 + i*5.0555x10-432
would have to be displayed as
-1E-234i-5E-432
The HP-42S did not have this problem; it could display up to 22 characters on one line, with each decimal point requiring a position.
-- KS
Edited: 24 Aug 2007, 3:27 a.m.
Posts: 3,283
Threads: 104
Joined: Jul 2005
Quote:
I think XEQ .B056 to accomplish this would be better:
The dot notation is used in program mode to navigate to a different line without changing the program, at least on my 33s. So it is not free for your intended purpose.
Posts: 2,761
Threads: 100
Joined: Jul 2005
Hello Karl,
Quote:
Quote:
Why not simply XEQ [label]? XEQ [.] nnn should be used for a particular line.
Good idea, but we'd need XEQ [.] Lnnn, where L is a letter label.
That was a typo. Thanks for pointing out the mistake! Anyway, I don't think an extra keystroke in these cases should be a problem because they will not occur very often. Also, it's unlikely anyone will use all 26 labels in a calculator which has no I/O system. Chances are only a few programs will reside in memory at a time, so there will be plenty of letter labels left. If M constains some matrix routines for determinant, inverse matrix, etc., it would be better using XEQ D, XEQ I, etc., instead of XEQ .M065, XEQ M.110, etc., for instance.
Quote:
The HP-42S did not have this problem; it could display up to 22 characters on one line, with each decimal point requiring a position.
On the other hand, some consider the tiny characters in the HP-42S a weakness. I like the larger characters in the HP-35s, so that's ok for me. Perhaps providing a way to use both display lines to show a complex number could be offered as an option:
1.0111111E-234
i5.0555555E-432
The user would know this is only one complex number, otherwise the bottom display line would show
0i5.055556E-432
Also, as someone has suggested, HMS-> should be changed to ->H.
Regards,
Gerson.
Posts: 9
Threads: 0
Joined: Aug 2007
Gotcha! And thanks for humoring me.
Posts: 2,761
Threads: 100
Joined: Jul 2005
Would you please explain? I know how GTO.Lnnn works in run mode, but I haven't been able to see how XEQ.Lnnn would work in program mode.
Thanks,
Gerson.
Posts: 2,761
Threads: 100
Joined: Jul 2005
You're welcome!
FWIW, with the HP CALC application on the HP-200LX, in the proper modes, we can easilly get pi to 32 digits:
PI
ENTER
SIN
-> 3.141592653589793
2.384626433832795e-16
Posts: 21
Threads: 2
Joined: Aug 2007
is this a bug?
p5-4 & 5-5 of the manual say that you can show the value of the maximum denominator '/c' by issuing the commands: '1 (f) /c'.
i cannot get this to work in alg mode although entering a number between 2-4095 works and entering 0 works to set the default of 4095. entering a '1' seems to have no effect whatsoever.
in other words, i can issue '64 (f) /c' in alg mode, then switch to rpn mode and issue '1 (f) /c' and the display will show '64'.
i could not find a sequence of commands that would show the value of '/c' in alg mode.
/guy
Posts: 21
Threads: 2
Joined: Aug 2007
this question seems to have gotten lost or orphaned, but i didn't know where the 'official' bug list was being kept.
upon reflection, this might simply be a owners manual 'bug' rather than a hardware/software bug.
/guy
Posts: 3,229
Threads: 42
Joined: Jul 2006
The bug list is kept here: HP-35s bugs. I've added this one.
- Pauli
Posts: 2,761
Threads: 100
Joined: Jul 2005
Quote: The bug list is kept here: HP-35s bugs.
Quote:
Cos(x) for x near 90 is dud.
Tan(x) is duff too :-)
Edited: 28 Aug 2007, 8:17 a.m.
|