HP35s Revisited Trig Quandary Bug # 2

[MarkHaysHarris777]

HP35s bug # 2 states:

2) Cos(x) for x near 90 is dud. For what appears to be the same reason, Tan(x) for x near 90 is also dud.

So, today I'm playing with COS(89.9999). I'm planning to avoid the entire discussion of whether this is equivalent to COS(90) for all practical engineering purposes, also that the anwwer (0) zero is for all practical purposes also correct, in all engineering circles (as a caveat), and any answer even close to that (zero) is about all we can expect.

I can confirm that both of my HP35s units [A] & [B] give the following answer at FIX(4):

[89.9999] [COS] X=1.7453E-6

... a more than acceptable response from any engineering calculator within bounds of all practical measurement and well within all acceptable margins of error... not to mention, more accurate than most early generation scientific calculators, including the original HP35. Actually, both of my units [A] & [B] give the following internal answer, which considering everything is astounding:

174532925000 ... yes the answer is truncated, but hey, for the intermediate results registers in the HP35s that is precisely what 'should' happen. Also, this answer is 'accurate' in the last significant displayed decimal place. This does not look like a 'dud' in my estimation.

(Could someone who has a real 1972 HP35 that works try this and post the results?)

My HP35 bit the dust many moons ago (and sadly, I disposed of it). I powered up my 1977 TI30 this afternoon, and got the following result from COS(89.9999):



It took almost two(2) full seconds to calculate this cosine (and its off by 1 in the last place); and even though its correctly rounded in the last place this answer (which is zero by all engineering standard) is not nearly as accurate as the answer I get from the HP35s!

One of my small tiny claims to fame is that I wrote the scientific and transcendental functions library (pdeclib) PythonDecimalLibrary for the Python Decimal module (you can find the source on google code by searching for pdeclib, or you may download the module with PIP from PyPI). The Python Decimal module is an arbitrary precision IEEE module for maths (very fast maths). With pdeclib you may calculate transcendental functions to thousands of places accurately and quickly (with pdeclib you will get pilib which is a collection of PI calculation routines using ARCTAN and AGM--- routines going back to Machin, Euler, and others)

So, here is COS(89.9999) calculated to 500 digits:

>>> dscale(500)
42
>>> cos(d('89.9999')*piagm2()/180)
Decimal('0.000001745329251993443480767989605432786337627037312316176388873390931​43155446041360462904334365249335531055809287604438274442522096084140764859073443​37847119448948828512712058055726413331807627260020175652982884954161960424446318​96997714175132577300742842685207613919951602005662147690953427519610453528493822​29130888239017050032565967537592386621092663154955614255895040086322506359476098​78673580982632745296514824299930490272874039749943660184410685301981172847714229​781608738522219431997542244860388785')

Yes, its off in the last six places... set dscale(1001) and knock your socks off...!

So, here is the answer from the WP34s running double mode:

[89.9999] [gold] [cos] [gold] [<] [blue] [>]

1.745,329,251,993,443... 480,767,989,605,432,792 -006

You'll notice two things: 1) this is VERY impressive double mode, and VERY impressive use of available display resources (whoohoo, nice job!), and 2) this answer is wrong (that's right, its wrong, that is its off in the last two places... I'm shocked). :-p

BUT, what does it all mean? The answer I would have gotten in 1977 from my TI30 is perfectly acceptable! The answer I get from my HP35s is more than perfectly acceptable, its down-right overkill... not to mention really meaningless after the fourth decimal place...

So, why do we call the HP35s a 'trig dud' ? Obviously I think that judgement is unfair, but I also think it shows how far we have come in our expectations, even though the rules of engagement have not changed and the laws of significant figures has not changed either.

Conclusion: Bug # 2 is not a bug... its a petty annoyance. The HP35s can be relied upon for trigonometric calculations (in professional engineering and academia) for years to come; really.


PS I calculated COS(89.9999) on my phone... using QPython on Droid... with pdeclib.

Cheers,
marcus

[Paul Dale]

(02-16-2015 11:53 PM)MarkHaysHarris777 Wrote:  You'll notice two things: 1) this is VERY impressive double mode, and VERY impressive use of available display resources (whoohoo, nice job!), and 2) this answer is wrong (that's right, its wrong, that is is off in the last two places... I'm shocked). :-p

Fortunately, double precision mode is documented as not being necessarily accurate


Now consider the 42S which gets twelve correct digits, in a much older calculator with fewer resources or the 15C which gets ten correctly rounded digits with even less.

The 35S has taken a retrograde step here.


- Pauli

[Jeff_Kearns]

(02-16-2015 11:53 PM)MarkHaysHarris777 Wrote:  (Could someone who has a real 1972 HP35 that works try this and post the results?)

My HP35 bit the dust many moons ago (and sadly, I disposed of it). I powered up my 1977 TI30 this afternoon, and got the following result from COS(89.9999):

It took almost two(2) full seconds to calculate this cosine (and its off by 1 in the last place); and even though its correctly rounded in the last place this answer (which is zero by all engineering standard) is not nearly as accurate as the answer I get from the HP35s!


Cheers,
marcus

My 1973 HP-35 gives: 1.7451419E-06

Interestingly, I get 0.0000017 on the TI-55 compared to 0.00000175 the TI-30. I can't figure out how to insert the image (looks like I have to upload it to a url...???). What is the easiest way to upload images for insertion?

Jeff K

   

[MarkHaysHarris777]

(02-17-2015 12:03 AM)Paul Dale Wrote:  Now consider the 42S which gets twelve correct digits, in a much older calculator with fewer resources or the 15C which gets ten correctly rounded digits with even less.

Quite true. Now, I have a question (and I'm not busting anyone in the chops, nor am I being trite. Would it be fair, in your estimation, for me to call the WP34s a 'trig dud,' because, in comparison, it is not able to calculate transcendental values as nearly accurately as pdeclib on my Droid phone?

Its not a fair comparison.

Now I have another question for you 'specifically,' and the other developers, of WP34s. Is it not time, considering the fact that memory is relatively cheap and available, that we would permit the user to not only select the number of digits they will display, but also allow the user to configure the number of digits used internally for intermediate result calculation? In other words, why do we not give the user the ability to configure arbitrary decimal arithmetic? If I want to calculate transcendentals to 30 digits, great. If the next person wants 42 digits, fabulous. If all we need is 12 digits, that's fine too. How difficult would it be to make the internal accuracy a matter of user configurability?

PS... if a person wants to calculate cosines of values close to pi/2, then they really need to 'double' the number of internal digits they want... if they want 12 they better configure 24-30... and so on.

Cheers,
marcus

[MarkHaysHarris777]

(02-17-2015 02:36 AM)Jeff_Kearns Wrote:  

(02-16-2015 11:53 PM)MarkHaysHarris777 Wrote:  (Could someone who has a real 1972 HP35 that works try this and post the results?)

My 1973 HP-35 gives: 1.7451419E-06

Interestingly, I get 0.0000017 on the TI-55 compared to 0.00000175 the TI-30. I can't figure out how to insert the image (looks like I have to upload it to a url...???). What is the easiest way to upload images for insertion?

Jeff K

Thanks for this post! Do you have cloud storage? I upload my pics to charter's webspace and then I point this site at those URL's. It is cumbersome to say the least, but it works... unless your cloud gets grumpy because of the hits, or because of the size... mine has been grumpy for both!

PS Here is the 1973 HP35 COS(89.9999) from Jeff K... thanks Jeff !




Cheers
marcus

[Paul Dale]

(02-17-2015 02:40 AM)MarkHaysHarris777 Wrote:  Quite true. Now, I have a question (and I'm not busting anyone in the chops, nor am I being trite. Would it be fair, in your estimation, for me to call the WP34s a 'trig dud,' because, in comparison, it is not able to calculate transcendental values as nearly accurately as pdeclib on my Droid phone?

The 34S gives sixteen correct digits in single precision mode here which was always our target -- 1 ULP was the goal rather than correctly rounded BTW. We know it isn't accurate in double precision mode -- this is documented in the manual. At least the 34S isn't worse than what came before.

I'm pretty sure I conned the "dud" term in the 35S bug list too It loses a lot more than two digits in the worst case. Anyway, feel free to call the 34S a dud too, it is only fair.

Quote:Is it not time, considering the fact that memory is relatively cheap and available, that we would permit the user to not only select the number of digits they will display, but also allow the user to configure the number of digits used internally for intermediate result calculation?

The memory is not available on the 30b hardware. We've used it all. There are some operations that fill the volatile RAM (some statistical functions and matrix operations). Non-volatile RAM has a couple of bits left so there'd be nowhere to store the extra state information. Flash isn't quite full but anything used reduces library space.

If we assume that memory were available, the task would be possible but wouldn't be easy. Several of the algorithms in the 34S are designed with the number of digits used in mind. The basic arithmetic and square root functions will work. Some of the other functions might, quite a few won't. Gamma e.g. uses a fixed series expansion which won't scale to arbitrary digit counts.

It would be possible to reimplement the internal functions that are limited but it would be a good chunk of work. Bringing in and using another decimal library would also be a possibility.


- Pauli

[MarkHaysHarris777]

(02-17-2015 03:38 AM)Paul Dale Wrote:  Anyway, feel free to call the 34S a dud too, it is only fair.

Gawd Forbid! I have nothing but praise for the WP34s... I'm not saying I would have made every design choice you folks made, but I appreciate EVERY one of the design choices that you did make... ! Very nice work, really.

(02-17-2015 03:38 AM)Paul Dale Wrote:  . . .
The memory is not available on the 30b hardware. We've used it all.
. . .
If we assume that memory were available, the task would be possible but wouldn't be easy. Several of the algorithms in the 34S are designed with the number of digits used in mind. The basic arithmetic and square root functions will work. Some of the other functions might, quite a few won't. Gamma e.g. uses a fixed series expansion which won't scale to arbitrary digit counts.

Yes, I gathered as much from the discussions I've found on-line, in this forum, and other places. I'm really thinking out-loud here for the 43s prototype coming up. Keep arbitrary digits in mind for that release (it would be true innovation coming to the fore front).

Thanks for the dialogue.

Cheers,
marcus

[MarkHaysHarris777]

(02-17-2015 02:36 AM)Jeff_Kearns Wrote:  My 1973 HP-35 gives: 1.7451419E-06

Thanks for the candor, Jeff... and for the data.

So, the 1973 HP35 (in fact the one that has the 2.02 bug fixed, I think) is showing significant figures that are not correct (which you should expect since the HP35 did not double the internal digits for intermediate results on its series expansion; QED, the digits after 1.745 are wrong.

Back in the day folks were not aware of this, mostly... and most people back in the day did not have a good way to cross check, like we do today. Mathematicians of course would know that working trig convergences near pi/2 or -pi/2 would be a problem... in fact, I think there was a warning about it in the literature that came with the HP35 in the beginning (someone with a book could check for me... please)

At any rate, the revised HP35s 'improved' upon its predecessor in a BIG way... and since the HP35s was supposed to be a celebration of the HP35 original, that is what is important... in other words, I do not look upon the HP35s as a step backwards (compared to the 42s, 15C), rather, as a step-up from the original HP35!

PS I'm wondering if the engineers at HP (Kinpo) compared the HP35s against the HP42s, or HP15C? I'll bet not. I know that seems unbelievable, but I'll bet (if I was a betting man, and I'm not) that I'm right... be interesting to find out (anybody want to speak up?)

Cheers,
marcus

[Jlouis]

(02-16-2015 11:53 PM)MarkHaysHarris777 Wrote:  HP35s bug # 2 states:

2) Cos(x) for x near 90 is dud. For what appears to be the same reason, Tan(x) for x near 90 is also dud.

So, today I'm playing with COS(89.9999). I'm planning to avoid the entire discussion of whether this is equivalent to COS(90) for all practical engineering purposes, also that the anwwer (0) zero is for all practical purposes also correct, in all engineering circles (as a caveat), and any answer even close to that (zero) is about all we can expect.

I can confirm that both of my HP35s units [A] & [B] give the following answer at FIX(4):

[89.9999] [COS] X=1.7453E-6

... a more than acceptable response from any engineering calculator within bounds of all practical measurement and well within all acceptable margins of error... not to mention, more accurate than most early generation scientific calculators, including the original HP35. Actually, both of my units [A] & [B] give the following internal answer, which considering everything is astounding:

174532925000 ... yes the answer is truncated, but hey, for the intermediate results registers in the HP35s that is precisely what 'should' happen. Also, this answer is 'accurate' in the last significant displayed decimal place. This does not look like a 'dud' in my estimation.

(Could someone who has a real 1972 HP35 that works try this and post the results?)

My HP35 bit the dust many moons ago (and sadly, I disposed of it). I powered up my 1977 TI30 this afternoon, and got the following result from COS(89.9999):



It took almost two(2) full seconds to calculate this cosine (and its off by 1 in the last place); and even though its correctly rounded in the last place this answer (which is zero by all engineering standard) is not nearly as accurate as the answer I get from the HP35s!

One of my small tiny claims to fame is that I wrote the scientific and transcendental functions library (pdeclib) PythonDecimalLibrary for the Python Decimal module (you can find the source on google code by searching for pdeclib, or you may download the module with PIP from PyPI). The Python Decimal module is an arbitrary precision IEEE module for maths (very fast maths). With pdeclib you may calculate transcendental functions to thousands of places accurately and quickly (with pdeclib you will get pilib which is a collection of PI calculation routines using ARCTAN and AGM--- routines going back to Machin, Euler, and others)

So, here is COS(89.9999) calculated to 500 digits:

>>> dscale(500)
42
>>> cos(d('89.9999')*piagm2()/180)
Decimal('0.000001745329251993443480767989605432786337627037312316176388873390931​43155446041360462904334365249335531055809287604438274442522096084140764859073443​37847119448948828512712058055726413331807627260020175652982884954161960424446318​96997714175132577300742842685207613919951602005662147690953427519610453528493822​29130888239017050032565967537592386621092663154955614255895040086322506359476098​78673580982632745296514824299930490272874039749943660184410685301981172847714229​781608738522219431997542244860388785')

Yes, its off in the last six places... set dscale(1001) and knock your socks off...!

So, here is the answer from the WP34s running double mode:

[89.9999] [gold] [cos] [gold] [<] [blue] [>]

1.745,329,251,993,443... 480,767,989,605,432,792 -006

You'll notice two things: 1) this is VERY impressive double mode, and VERY impressive use of available display resources (whoohoo, nice job!), and 2) this answer is wrong (that's right, its wrong, that is its off in the last two places... I'm shocked). :-p

BUT, what does it all mean? The answer I would have gotten in 1977 from my TI30 is perfectly acceptable! The answer I get from my HP35s is more than perfectly acceptable, its down-right overkill... not to mention really meaningless after the fourth decimal place...

So, why do we call the HP35s a 'trig dud' ? Obviously I think that judgement is unfair, but I also think it shows how far we have come in our expectations, even though the rules of engagement have not changed and the laws of significant figures has not changed either.

Conclusion: Bug # 2 is not a bug... its a petty annoyance. The HP35s can be relied upon for trigonometric calculations (in professional engineering and academia) for years to come; really.


PS I calculated COS(89.9999) on my phone... using QPython on Droid... with pdeclib.

Cheers,
marcus

Very impressive. Thanks for showing your point só brilliantly.

My conclusion is, if I have to send my boss to mars, I will use a TI 30.

Health and Peace.

[MarkHaysHarris777]

(02-17-2015 04:09 PM)Jlouis Wrote:  . . .
Very impressive. Thanks for showing your point só brilliantly.

My conclusion is, if I have to send my boss to mars, I will use a TI 30.

Health and Peace.

Dude, if you can con your boss to go to Mars, power to you, and it won't matter what calc you use because at this point its a one-way-ticket! (he|she won't be coming back)

;-)

PS Here is the pic from Jeff Kearns' 1973 HP35 calculating COS(89.9999):




(the last four digits are wrong, of course, but in 1973 not too many folks could cross check it)


Thanks Jeff !


Cheers,
marcus

[Manolo Sobrino]

No series in there Marcus, but precomputed tables and CORDIC.

I don't think (now) that the 35s has a real trig bug, but some idiosyncrasies and not an entirely consistent behaviour. In fact, after having a look at it again, I'm reconsidering the 35s. Maybe I'll get one after all.

I've checked the tables from Karl Schneider (message #27) in:

http://www.hpmuseum.org/cgi-sys/cgiwrap/...ead=123814


The "dud" results resemble what I'd expect from a single precision calculation, that is, for an x precision calculator you can't have x significant figures in every trig function value because that would mean that you can work to double precision, but except for these special cases you can't, so these figures are basically pointless (and might lead you to "wrong" results, check thread below). It would be even better if for values closer to pi/2 in the cosine of (pi/2-x) this calculator would keep the consistent policy instead of returning the "perfect" 12 digit results everywhere that many HP fans are so fond of (but I must confess make me cringe).

(More on this: http://www.hpmuseum.org/forum/thread-1033.html)

[Jlouis]

(02-17-2015 04:44 PM)MarkHaysHarris777 Wrote:  

(02-17-2015 04:09 PM)Jlouis Wrote:  . . .
Very impressive. Thanks for showing your point só brilliantly.

My conclusion is, if I have to send my boss to mars, I will use a TI 30.

Health and Peace.

Dude, if you can con your boss to go to Mars, power to you, and it won't matter what calc you use because at this point its a one-way-ticket! (he|she won't be coming back)

That's was only a joke about using TI.

But If she can't come back really, I'll manage a way to send her anyway.

Seriously, I think you are ressuracting the 35s.

Again, you showed briliantly your point.

Health and Peace

[Thomas Klemm]

(02-16-2015 11:53 PM)MarkHaysHarris777 Wrote:  So, here is COS(89.9999) calculated to 500 digits:

Any reason for not using mpmath?

>>> from mpmath import *
>>> mp.dps = 500; mp.pretty = True
>>> arg = mpf('89.9999')
>>> cos(arg*degree)
0.000001745329251993443480767989605432786337627037312316176388873390931431554460​41360462904334365249335531055809287604438274442522096084140764859073443378471194​48948828512712058055726413331807627260020175652982884954161960424446318969977141​75132577300742842685207613919951602005662147690953427519610453528493822291308882​39017050032565967537592386621092663154955614255895040086322506359476098786735809​82632745296514824299930490272874039749943660184410685301981172847714229781608738​522219431997542244860816323

Cheers
Thomas

[MarkHaysHarris777]

(02-17-2015 05:41 PM)Thomas Klemm Wrote:  

(02-16-2015 11:53 PM)MarkHaysHarris777 Wrote:  So, here is COS(89.9999) calculated to 500 digits:

Any reason for not using mpmath?

>>> from mpmath import *
>>> mp.dps = 500; mp.pretty = True
>>> arg = mpf('89.9999')
>>> cos(arg*degree)
0.000001745329251993443480767989605432786337627037312316176388873390931431554460​41360462904334365249335531055809287604438274442522096084140764859073443378471194​48948828512712058055726413331807627260020175652982884954161960424446318969977141​75132577300742842685207613919951602005662147690953427519610453528493822291308882​39017050032565967537592386621092663154955614255895040086322506359476098786735809​82632745296514824299930490272874039749943660184410685301981172847714229781608738​522219431997542244860816323

Your answer is wrong-- again, I'm shocked. The last five digits are not correct; should be
... 448, 608, 060, 010, 428, 3...

mpmath is a fabulous package (depending on what else is installed with it (gmpy, sage) but the main problem with it (for my purposes) is speed. mpmath uses Python's long integers by default (not the new Decimal module). Consequently, its too slow for calculating millions of digits of PI, or multiple transcendentals of hundreds of thousands of digits (not that many people except geeks like me do that, I get it). its been a while since I looked into mpmath as a package; my interest was the new C implementation of the Decimal module for Python 3.2+ because it is incredibly fast! I'm using Python 3.4 now, and the Decimal module there screams. Just say'n. Having said all of that, I must admit that I have not run mpmath with gmpy, nor sage. So, I don't have a fair comparison.

Cheers,
marcus

[Thomas Klemm]

(02-16-2015 11:53 PM)MarkHaysHarris777 Wrote:  Conclusion: Bug # 2 is not a bug... its a petty annoyance.

You may try this simple program with 0, 1, 2, 3, ... as input. Just make sure to use DEG mode.

Code:

0001 10^x
0002 ENTER
0003 1/x
0004 SIN
0005 ×
0006 RTN

This is the result that the HP-35s produces (using ALL mode):

0: 1.74524064373E^-2
1: 1.7453283659E^-2
2: 1.74532924306E^-2
3: 1.74532925091E^-2
4: 0.0174532925
5: 0.017453292
6: 0.01745329
7: 0.0174532
8: 1.74532925199E^-2
9: 1.74532925199E^-2

For comparison here are the correct values:

0: 0.0174524064373
1: 0.0174532836590
2: 0.0174532924313
3: 0.0174532925191
4: 0.0174532925199
5: 0.0174532925199
6: 0.0174532925199
7: 0.0174532925199
8: 0.0174532925199
9: 0.0174532925199

Thus it's not that the SIN function of the HP-35s is inaccurate for small numbers.

Cheers
Thomas

[Tugdual]

15C : 1.745329252 e-6
35S: 1.74532925000 e-6
Difference is: 2E-15

Distance earth moon: 384 400km
So if I was launching a rocket to the moon, I would miss the target from
384 400 000 * 2e-15 = 768 nanometers

Oh well... good enough.

[MarkHaysHarris777]

(02-17-2015 07:52 PM)Thomas Klemm Wrote:  

(02-16-2015 11:53 PM)MarkHaysHarris777 Wrote:  Conclusion: Bug # 2 is not a bug... its a petty annoyance.

You may try this simple program with 0, 1, 2, 3, ... as input. Just make sure to use DEG mode.

Code:

0001 10^x
0002 ENTER
0003 1/x
0004 SIN
0005 ×
0006 RTN

This is the result that the HP-35s produces (using ALL mode):

0: 1.74524064373E^-2
1: 1.7453283659E^-2
2: 1.74532924306E^-2
3: 1.74532925091E^-2
4: 0.0174532925
5: 0.017453292
6: 0.01745329
7: 0.0174532
8: 1.74532925199E^-2
9: 1.74532925199E^-2

hi Thomas, you're making my point for me splendidly... 'nobody' (at least not engineers, nor scientists) runs their calculator in 'all' mode. Perhaps educators, some mathematicians, or the curious, but usually we set the machine to some realistic scope in scientific or engineering format so that the results make sense within bounds and according to the laws of significant figures... I hate being pedantic, but hey, what ever it takes; right?

So, using your program on my HP35s (both units) these are the results with FIX 6 (I normally run my units in FIX 4, because it makes the most sense) :

1: 0.017453
2: 0.017453
3: 0.017453
4: 0.017453
5: 0.017453
6: 0.017453
7: 0.017453
8: 0.017453
9: 0.017453

Your example is a fine excursion down the bunny trail of 'see how messy I can make this petty annoyance look'... when really, there is no problem within the realm of reasonableness and fair representation. Round-trips on an extreme end are also not representative of what most folks (engineers and scientists) are going to run into in everyday work.

Some people are irked by the fact that many real numbers cannot be held in computer memory accurately. The memory of the computer is a 'model' of what's going on in Platonic space; Aristotle is just going to have to live with it-! We do the best we can, with what we have; and my point is that the HP35s is doing not a bad job of it... maybe not up the the 42s or 15C expectation, but reasonably well none-the-less.

Cheers,
marcus

[Paul Dale]

Quote:'nobody' (at least not engineers, nor scientists) runs their calculator in 'all' mode

I pretty much always run my calculator in ALL mode and I'm in that nobody group


- Pauli

[Thomas Klemm]

(02-17-2015 06:00 PM)MarkHaysHarris777 Wrote:  Consequently, its too slow for calculating millions of digits of PI, or multiple transcendentals of hundreds of thousands of digits (not that many people except geeks like me do that, I get it).

(02-17-2015 08:45 PM)MarkHaysHarris777 Wrote:  (I normally run my units in FIX 4, because it makes the most sense)

At least you are consistent.

Cheers
Thomas

[MarkHaysHarris777]

(02-17-2015 09:07 PM)Thomas Klemm Wrote:  

(02-17-2015 06:00 PM)MarkHaysHarris777 Wrote:  Consequently, its too slow for calculating millions of digits of PI, or multiple transcendentals of hundreds of thousands of digits (not that many people except geeks like me do that, I get it).

(02-17-2015 08:45 PM)MarkHaysHarris777 Wrote:  (I normally run my units in FIX 4, because it makes the most sense)

At least you are consistent.

I am most certainly consistent... and your argument is a non sequitur. As an interest in high speed number crunching (a personal excursion into number theory, prime research, and encryption) I run my -- PC -- late at night while I'm asleep crunching out transcendentals to many hundreds of thousands of digits.

I set my calculator (HP35s) to FIX 4, or ENG 4.

PS SIN has the same problem on the ZERO end, that COSINE has at pi/2. Set your HP35s to FIX 4 and run SIN(.0001) ; similar to COS(89.9999)
Oh look, its the same value either way-> 1.7453E-6 (very reasonable answer)

PSS its also the same internal value either way... 174532925000

Cheers,
marcus