▼
Posts: 735
Threads: 34
Joined: May 2007
In RPN mode I tried to calculate:
1
INPUT
0.5
nCr
The calculator then hangs with a blinking shiftindicator. The keyboard doesn't respond. Even trying to reset the calculator with the triple keys: [ON/CE] [N] [Amort] doesn't work. I had to press a paperclip through the small hole on the back, after removing the cover.
SW Version 6 24 2008 2 is used.
Is this well known?
Now you tell me I should instead use:
n!

r! (nr)!
And funny enough it works.
Edited: 31 Mar 2009, 3:41 p.m.
▼
Posts: 1,665
Threads: 142
Joined: Jan 2009
nCr is valid only for integer values, so what you were getting was an error indication. OTOH, n! is valid for fractional values in the general case of the Gamma function, so it works. However, the calculation that you did was meaningless, as there is no such thing as the combination of 1 items taken 0.5 at a time. As to why your calculator would not reset, perhaps it became very angry at an attempt to misuse its functions and decided to lock you out. ;>)
Michael
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
nCr can easily be extend to majority of the complex plane:
1
nCr = 
(n+1) beta(nr+1, r+1)
Is this sensible? Who knows :)
 Pauli
Posts: 735
Threads: 34
Joined: May 2007
Quote:
so what you were getting was an error indication.
The error indicator for the same entries for nPr is:
ER: oo Result
While for other invalid like r > n values you would get:
ER: Invalid Input
One of the above I could accept as an error indication but not blocking the whole calculator.
Quote:
However, the calculation that you did was meaningless
You are kindly requested to scroll down to "Generalization to real and complex argument" in this article about
Binomial coefficients.
Actually I was just playing around with the calculator and wondered what if I wanted to calculate "Newton's binomial series" for an exponent of 0.5? And then I got it wrong and mixed n and r. So at least for me it makes perfectly sense to calculate say nCr(0.5, 5):
It's the coefficent of x^{5} in the Taylor series expansion of (1 + x)^{1/2}.
In a way it's exactly the same as you probably would expect if n were an integer. So the interesting thing in math is to give meaning to seemingly meaningless things.
▼
Posts: 1,665
Threads: 142
Joined: Jan 2009
The intended purpose of the nCr and nPr functions are to compute combinations and permutations of discrete objects, such that the n and r values must be integers to have any meaning. The calculation of these functions is made using the integer factorial function, which is defined for only nonnegative integer values. The fact that this a special case of Gamma, which extends to real numbers or even complex numbers is irrelevant to the intent of the nCr and nPr functions. I have yet to find a calculator with these two functions that permit noninteger values.
As far as your calculator locking up, well of course I was just joking when suggesting that it should do this. Some of my older calcs blink to indicate an error message, and I don't own an HP 20b, so I'm not familiar with its error indications.
Edited: 1 Apr 2009, 10:30 a.m.
Posts: 528
Threads: 40
Joined: Dec 2008
Quote:
nCr is valid only for integer values, so what you were getting was an error indication.
An error indication could be easily cleared so the user could continue to use the calculator. In this case, the calculator froze up completely, so I'd call it a bug.
Posts: 320
Threads: 59
Joined: Dec 2006
My guess is that the factorial function actually utilizes the gamma function, and nCr has an algorithm that does not utilize gamma.
<Michael got there first>
While working on this, I decided to try it out on the HP42S. Of course the nCr button with nonintegers doesn't work. The factorial function also doesn't work because there is a built in gamma function. Here's a little program I wrote for the HP42S to do it...
01 LBL "NCR"
02 STO 01
03 Rolldown
04 STO 02
05 1
06 +
07 GAMMA
08 1
09 RCL+ 01
10 GAMMA
11 / "divide"
12 RCL 02
13 RCL 01
14 1
15 +
16 GAMMA
17 /
18 RTN
Put two numbers on the stack and execute NCR
It's most likely not the shortest such program, but works like a charm on your noninteger problem. But, now the REALLY STRANGE PART....
...in doing a problem like 5 nCr 5 or 5 nCr 0 on the 42S I get for an output
Out of Range
x: 1.0000
However, stepping through the program to trouble shoot it, there is no "Out of Range" warning. And, executing the SAME program using Free42 on my ipod I get no "Out of Range Error". Can someone explain that to me?
CHUCK
Edited: 31 Mar 2009, 4:46 p.m.
▼
Posts: 167
Threads: 13
Joined: Sep 2008
I can't explain what you have observed, but your program doesn't give those errors when I run it on my HP42S! Its serial number is 3127S03683; perhaps yours has a different ROM containing a bug?
▼
Posts: 222
Threads: 21
Joined: Oct 2006
Nor do I have the problem on my HP42s. I get "1" for each case.
Jeff
▼
Posts: 320
Threads: 59
Joined: Dec 2006
Arrrg. I'll reset my 42s and try it again. Must have a flag or mode out of kilter. Thanks.
........later.........
Nope. I did a reset; reentered the program; and ran 5 5 NCR and still got "Out of Range". Stepping through the program works fine though. Hrmph.
My serial number is: 3313S05685
Curious if this happens for anybody else. :(
CHUCK
Edited: 31 Mar 2009, 7:09 p.m.
Posts: 1,792
Threads: 62
Joined: Jan 2005
Chuck 
Your program works just fine on my HP42S models with different ROM's (1989 flat screen 2939Sxxxxx and 1990 recessedscreen 3047Sxxxxx).
One obscure point: The numbered storage registers must be dimensioned to store realvalued numbers, not complex. Taking ABS of a recalled number before GAMMA is a workaround if the recalled value is x + i0 or x / 0.
A related point: There is a minor bug of COMB and PERM in the redesigned (recessedscreen) versions of the HP42S:
http://www.hpmuseum.org/cgisys/cgiwrap/hpmuseum/archv008.cgi?read=17122#17122
 KS
▼
Posts: 320
Threads: 59
Joined: Dec 2006
I'm still baffled. When I set flag 24 to ignore "Out of Range" errors I get 0 as a result for 5 nCr 5, and 5 nCr 0. And, setting flag 25 in program (skip error) to pinpoint which step is causing the error, I discovered two different situations.
1) "Out of Range" error occurs on the LAST gamma function for the 5 nCr 5 problem
2) the SECOND gamma causes the error on the 5 nCr 0 problem
The error doesn't occur when I reprogram with the factorial function (but this defeats the noninteger usefulness).
So, clearly there is a bug with GAMMA when executed in a RUNNING program (I don't get the error when stepping through the program.) If not a bug, then I have a very unique calculator.
I'll keep exploring.
CHUCK
Posts: 1,545
Threads: 168
Joined: Jul 2005
Yes, it is a bug. Good find.
Posts: 1,792
Threads: 62
Joined: Jan 2005
I think it may have been a bug; there were a few with earlier ROM versions. My HP20b gives the correct response of "Invalid Input".
 KS
Posts: 193
Threads: 10
Joined: Mar 2008
hello,
1 0.5 nCr should return an Invalid Input error. However, I do seem to recall that early version of the SW had a bug there and were not checking on the inputs.
the calculator does not use the factorial formula because it would lead very rapidly to numbers above the calculator precision and cause lost of precision, instead it uses a loop... as a result, of course, if you have i=0.5 and loop doing i1 until i=0.... you never end and crashes the calculator :( unless you have the version that actually tests for it...
cyrille
▼
Posts: 1,665
Threads: 142
Joined: Jan 2009
Cyrille,
Finally, a logical explanation. What is the actual algorithm that is used here? I know you say it is iterative, but exactly how does it work?
Michael
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
I'd imagine the iterative algorithm used is:
n n  1 n  2 n  ( k  1 )
nCk =  .  .  . ... . 
k k  1 k  2 k  ( k  1 )
I cannot think of a better alternative.
However, I'd use:
nCk = EXP( lngamma(n+1)  lngamma(k+1)  lngamma(nk+1) )
With a round to nearest integer if the inputs are both integer.
 Pauli
▼
Posts: 193
Threads: 10
Joined: Mar 2008
hello
Quote:
I'd imagine the iterative algorithm used is:
n n  1 n  2 n  ( k  1 )
nCk =  .  .  . ... . 
k k  1 k  2 k  ( k  1 )
yep, exactly, and since it gets to maxreal realy fast for inputs that overflow, time is not critical there...
cyrille
▼
Posts: 1,665
Threads: 142
Joined: Jan 2009
So, are you saying that the loop counter is on the denominator, and that it checks for exactly = 0, rather than <= 0, so it continues looping indefinitely? By my reckoning, the second product will produce 0, so all subsequent products will be 0, such that an overflow condition will never occur, which would then halt the calculator with an overflow error indication.
Posts: 3,229
Threads: 42
Joined: Jul 2006
True so long as you also reduce things via:
nCk = nC(nk), when k>n/2
Otherwise you could be in for a long long wait...
Think 1,000,000 C 999,999
 Pauli
