The Museum of HP Calculators

HP Forum Archive 14

[ Return to Index | Top of Index ]

33S: nCr weirdness
Message #1 Posted by KC on 18 May 2004, 1:42 a.m.

I newly acquired a hp 33S, and tested its speed for nCr operation. I entered the following:

2000 Enter 1000 nCr

and the calculated result : 1.8099e499

I compared with my 32SII. To my surprise, my 32SII showed an Overflow message and displayed 1e500. My 48G displayed 9.999e499. Apparently, the result of 33S is strange. I continued increasing the value, everytime keeping r=n/2, and see how large the number goes before it gives an overflow message, and the result:

2000C1000 = 1.8099e499

3000C1500 = 1.7674e499

5000C2500 = 2.000e499

7000C3500 = 2.2301e499

8994C4497 = 9.9827e499

8995C4497 = Overflow = 1e500

So the largest value for n without getting an overflow message is 8994, with r=n/2=4997. IN all cases, the 32SII gave overflow message. Does anybody have any idea what happens with this nCr operation?

MY second question: I examined my equation library of 33S, and found the following equation preinstalled at the time of buying: V=.25pi d^2 l. This is the equation explained by the 33S manual. Does anybody also have such equation in their 33S? My serial: CNA4110.

KC

      
Re: 33S: nCr weirdness
Message #2 Posted by Ralf Fritzsch on 18 May 2004, 6:56 a.m.,
in response to message #1 by KC

KC wrote:

>... a hp 33S, and tested ... >2000 Enter 1000 nCr >and the calculated result : 1.8099e499 >... my 32SII showed an Overflow message and displayed 1e500

E.g. Mathematica shows:

N[Binomial[2000, 1000]]

2.048151626989490*10^600

which is also shown on calculators which allow greater exponents than 10^499.

Whereas the old 32SII and 48G give correct answers (Overflow), the new 33S has obviously a problem with the nCr implementation, or, in other words, there is a bug.

Many greetings from Hamburg, Ralf.

            
Re: 33S: nCr weirdness
Message #3 Posted by Massimo (Italy) on 18 May 2004, 9:31 a.m.,
in response to message #2 by Ralf Fritzsch

Quote:
2.048151626989490*10^600

Try it on a 49G and you'll get all the digits...

Massimo

                  
Re: 33S: nCr weirdness
Message #4 Posted by Raul Lion on 18 May 2004, 12:41 p.m.,
in response to message #3 by Massimo (Italy)

The same with the 48 with Erable...

                        
Re: 33S: nCr weirdness
Message #5 Posted by Massimo (Italy) on 18 May 2004, 1:21 p.m.,
in response to message #4 by Raul Lion

Yup!

2048151626989489714335162502980825044396424887981397033820382637671748186202083755828932994182610206201464766319998023692415481798004524792018047549769261578563012896634320647148511523952516512277685886115395462561479073786684641544445336176137700738556738145896300713065104559595144798887462063687185145518285511731662762536637730846829322553890497438594814317550307837964443708100851637248274627914170166198837648408435414308177859470377465651884755146807496946749238030331018187232980096685674585602525499101181135253534658887941966653674904511306110096311906270342502293155911108976733963991149120

:-)

                              
Show-off! (NT)
Message #6 Posted by Paul Brogger on 18 May 2004, 1:56 p.m.,
in response to message #5 by Massimo (Italy)

8~O

      
Re: 33S: nCr weirdness
Message #7 Posted by James McFadyen on 18 May 2004, 8:42 a.m.,
in response to message #1 by KC

Based on the combination formula:

nCr = n!/[(n-r)!*r!]

I wrote a 33S program based on the following: If we write it out sort of longhanded:

nCr = [(n)(n-1)(n-2)...(n-r+1)(n-r)(n-r-1)...(1)]/[(n-r)(n-r-1)...(1)*(r)(r-1)(r-2)...(1)]

There are terms on the numerator and denominator that cancel leaving us with:

nCr = [(n)(n-1)(n-2)...(n-r+1)]/[(r)(r-1)(r-2)...(1)]

If these terms are done separately, you can be dividing while multiplying individual terms thus preventing an overflow condition on relatively small values of n and r. I can write the program listing for anyone interested, but I doubt anyone is. Anyway, here are the results:

1600C800 = 8.8676E479

1650C825 = 9.8316E494

1660C830 = 1.0037E498

1662C831 = 4.0125E498

1664C832 = 1.6040E499

1666C833 = 6.4122E499

1668C834 = 1.0000E500(?)

1700C850 = OVERFLOW

The results from the built-in combination formula differ from mine starting at 1666C833 where the calculator's built-in gets 1.6021E499 as a result (which seems to be a bit low).

My 33s also had the same formula pre-loaded in the equation library. (just got it yesterday, S/N CNA4130XXXX)

Anyway, I was bored and thought this would be a good excuse to write a program for my new 33s. I'll have to compare results with my old 32SII.

James McF.

      
More 33S weirdness - polar conversions
Message #8 Posted by V. Taylor on 18 May 2004, 9:20 a.m.,
in response to message #1 by KC

Here's another 33s weirdness. You can calculate an even root of a negeative number, as discussed elsewhere in this forum, using complex operations. This leaves the real part in the x-register and the imaginary part in the y-register. I wrote a small program to do this similar to others that have been posted:

C0001 LBL C

C0002 RPN ;Just to be sure

C0003 0

C0004 X<>Y

COOO5 CMPLXy^x

C0006 RTN

Given a negative number in the y-register and a fractional exponent in the x-register, say -4 and .5 this returns the correct square root, 0 in the x-register and 2 in the y-register representing the complex number 0+2i in rectangular form. The weirdness comes when you try to convert this to polar form using the ->theta,r key. If I just type 2 <enter> 0 ->theta,r I get the expected result, magnitude 2 and angle of 90 deg. But if I perform the same operation on the result of the complex operation, seemingly the same x=0,y=2 oredered pair, I get a magnitude of 2, which is expected, but at an angle of 270 deg which is very unexepected. Normally for any ordered pair on the stack the range of theta is -180 < 0 < 180 which makes the result of 270 deg even stranger. If I run the reverse ->y,x operation on the result I get y=-2 and x=0 which would be expected from an angle of 270 deg. Performing another ->theta,r gives the expected result of r=2 and theta=-90 deg (as opposed to 270 deg as before). I'm sure this is due to the algorithm used to compute the angle and its determination of the sign of the angle, but the result seems to imply that the calculator knows that it is working on a complex number, or at least that the number in the y-register is not a normal number. I didn't think there were different data types allowed on the stack of the 33s. Is there an undocumented flag or something that indicates a complex stack? I was under the assumption that the complex key just caused the stack to be treated as a pair of complex numbers for that particular operation but the numbers in the actual stack levels are still just real numbers. In any case the angle of 270 deg outside the normal range of the function and is weird!

Virgil Taylor

      
Re: 33S: nCr weirdness
Message #9 Posted by Jordi Hidalgo on 18 May 2004, 11:52 a.m.,
in response to message #1 by KC

KC wrote:

Quote:
[...] found the following equation preinstalled at the time of buying: V=.25pi d^2 l.
Same here. And vars D, L, V and W had non-zero values :-)
            
.25 x pi x d^2 x L
Message #10 Posted by Wayne Stephens on 19 May 2004, 7:58 a.m.,
in response to message #9 by Jordi Hidalgo

Am I missing something?

Are you writing d^21 or d^2 x L? Because d^21 is certainly not going to give you the volume of anything.

Mine has the preloaded equation as written in my subject line. I believe it is there as a "training" tool for those who work through the exercises in the manual.

Take care.

Wayne

                  
Re: .25 x pi x d^2 x L
Message #11 Posted by Eddie Shore on 20 May 2004, 8:40 p.m.,
in response to message #10 by Wayne Stephens

I didn't noticed a pre-loaded equation. Maybe I erased following the steps in the "getting started" section.


[ Return to Index | Top of Index ]

Go back to the main exhibit hall