Dividing factorials on 15C CE

[philiph]

Hello,
I have a question concerning my new 15C Collector's Edition.
When I tried to calculate combinations this morning, I discovered that if I type
50! divided by 45! I get the result:
254,251,199.9 instead of 254,251,200
When I type
49! divided by 45! I get the result
5,085,023.998 instead of 5,085,024
When I type
35! divided by 30! I get the result:
38,955,840.02 instead of 38,955,840
and so on.
Does anyone know the reason for this bug?
Thanks for your help!
Phil

[J-F Garnier]

(01-06-2024 10:38 AM)philiph Wrote:  When I tried to calculate combinations this morning, I discovered that if I type
50! divided by 45! I get the result:
254,251,199.9 instead of 254,251,200
...
Does anyone know the reason for this bug?

No bug.
You are not dividing 50! by 45! but 3.041409320e64 by 1.196222209e56 .
Just checked on the 34-digit Free42 application, the result of that operation is indeed:
254251199.9[123...]

J-F

[Werner]

To divide y! by x!, do:
y
Enter
Enter
x
-
Py,x

Eg. divide 50! By 45! :

50
Enter
5
Py,x

Gives 254251200 exactly.

Cheers, Werner

[Valentin Albillo]

(01-06-2024 02:13 PM)Werner Wrote:  To divide y! by x!, do:
y
Enter
Enter
x
-
Py,x

Eg. divide 50! By 45! :

50
Enter
5
Py,x

Gives 254251200 exactly.

Cheers, Werner

Werner, you're telling him to execute a series of keystrokes but then you execute a different one.

Regards.
V.

[Johnh]

I get the same results on my 15C CE.

For a basically 40-year-old design, 15C's have plenty of calculation digits for any normal calculation, then or now. But these interesting cases are pushing the limits of the accuracy to which the final result can be delivered. We only notice this because we know that the true result of dividing two such factorials has to be a whole number, eg 50! / 45! = 46 x 47 x 48 x 49 x 50 = 254,251,200

I tried 50! / 45! with TouchRPN on my Samsung S22 using the HP15C mode and it did indeed deliver 254,251,200.0. But I'm assuming that although this App is generally a great emulation of the real thing it's not an exact digit for digit copy and it uses greater internal accuracy.

[Steve Simpkin]

(01-06-2024 07:23 PM)Johnh Wrote:  I get the same results on my 15C CE.

For a basically 40-year-old design, 15C's have plenty of calculation digits for any normal calculation, then or now. But these interesting cases are pushing the limits of the accuracy to which the final result can be delivered. We only notice this because we know that the true result of dividing two such factorials has to be a whole number, eg 50! / 45! = 46 x 47 x 48 x 49 x 50 = 254,251,200

I tried 50! / 45! with TouchRPN on my Samsung S22 using the HP15C mode and it did indeed deliver 254,251,200.0. But I'm assuming that although this App is generally a great emulation of the real thing it's not an exact digit for digit copy and it uses greater internal accuracy.

I think this also goes with the HP traditional philosophy of showing you the computed answer based on the number of significant digits stored by the hardware without using invisible "guard-digits" to round off the answer as TI and other calculator manufactures typically do.

There is some interesting history behind the decision on what to show the calculator user when the true result using fixed digit math is not what they expect to see. William Kahan had the following to say about the apparent "increased accuracy" of TI models when he worked as a consultant for HP.
This is discussed starting around page 144 on the following interview with Dr. William Kahan - August 2005
https://drive.google.com/file/d/1Jlg9EWQ...zwcol/edit

[Werner]

(01-06-2024 03:17 PM)Valentin Albillo Wrote:  Werner, you're telling him to execute a series of keystrokes but then you execute a different one.

I blame age, and mileage ;-)

Werner

[jthole]

Anyway, it's not a bug, in my opinion ... the original HP-11C and 12C (I do not have a 15C) behave the same (due to their limited precision).

So given that the 15C CE is a faithful replication of the original Voyagers, I would say it works as designed.

[philiph]

Thank you folks!
Meanwhile, I came to the same concluison (too many digits) and I know the features Cy,x and Py,x.
I wonder however how the Cy,x and the Py,x formula avoid the problem. Does the programming just include the command "round to the next integer"?
Greetings Phil

[Chumango]

I get 254,251,200.001 with a 35S, and 254,251,200.0000.....1 with the 1 being 1E-25 with Free42.

[Thomas Klemm]

(01-07-2024 02:15 PM)philiph Wrote:  I wonder however how the Cy,x and the Py,x formula avoid the problem.

This avoids rounding errors:

P(50, 45) = 1 * 50 * 49 * 48 * 47 * 46
C(50, 45) = 1 * 50/1 * 49/2 * 48/3 * 47/4 * 46/5

These are corresponding Python programs:

Code:

def perm(n, k):
    p = 1
    while n > k:
        p *= n
        n -= 1
    return p

def comb(n, k):
    p = 1
    m = 1
    while n > k:
        p *= n
        p //= m
        n -= 1
        m += 1
    return p

[J-F Garnier]

(01-09-2024 01:23 AM)Thomas Klemm Wrote:  
P(50, 45) = 1 * 50 * 49 * 48 * 47 * 46

These are corresponding Python programs:

Code:

def perm(n, k):
    p = 1
    while n > k:
        p *= n
        n -= 1
    return p

It seems to me a singular way to compute permutations...

J-F

[Johnh]

Quote:I think this also goes with the HP traditional philosophy of showing you the computed answer based on the number of significant digits stored by the hardware without using invisible "guard-digits" to round off the answer as TI and other calculator manufactures typically do.

There is some interesting history behind the decision on what to show the calculator user when the true result using fixed digit math is not what they expect to see. William Kahan had the following to say about the apparent "increased accuracy" of TI models when he worked as a consultant for HP.
This is discussed starting around page 144 on the following interview with Dr. William Kahan - August 2005
https://drive.google.com/file/d/1Jlg9EWQ...zwcol/edit

Thanks, that's an interesting read. Kahan talks engagingly about his work, which he was rightly proud of.

But I'm curious about the points about rounding and guard digits. Seems to suggest that HP round every result step to 10 sig figs, rather than carrying the guard digits over to the next step. (screen shot from page 146 attached. )

I can see how this would address the TI example of doing multiple repeats of e^(ln(telephone number)). But I'm not following why it's a better idea for real-world calcs where results need to be carried over? It seems to me that over several different calc steps you would probably loose accuracy in the 10th and maybe 9th digit, instead of probably keeping them accurate if 13 digits are maintained internally?
   

[Steve Simpkin]

(01-10-2024 09:22 AM)Johnh Wrote:  

Quote:I think this also goes with the HP traditional philosophy of showing you the computed answer based on the number of significant digits stored by the hardware without using invisible "guard-digits" to round off the answer as TI and other calculator manufactures typically do.

There is some interesting history behind the decision on what to show the calculator user when the true result using fixed digit math is not what they expect to see. William Kahan had the following to say about the apparent "increased accuracy" of TI models when he worked as a consultant for HP.
This is discussed starting around page 144 on the following interview with Dr. William Kahan - August 2005
https://drive.google.com/file/d/1Jlg9EWQ...zwcol/edit

Thanks, that's an interesting read. Kahan talks engagingly about his work, which he was rightly proud of.

But I'm curious about the points about rounding and guard digits. Seems to suggest that HP round every result step to 10 sig figs, rather than carrying the guard digits over to the next step. (screen shot from page 146 attached. )

I can see how this would address the TI example of doing multiple repeats of e^(ln(telephone number)). But I'm not following why it's a better idea for real-world calcs where results need to be carried over? It seems to me that over several different calc steps you would probably loose accuracy in the 10th and maybe 9th digit, instead of probably keeping them accurate if 13 digits are maintained internally?

HP calculators did not really use guard digits. The memory and registers on the pre-Saturn CPUs were 56-bits in size which stored a 10 digit mantissa, a 2 digit exponent and signs for the mantissa and exponent. This is also what was displayed. It may have been possible to internally calculate more than 10-digits since the algorithms are working serially on 4-bit BCD digits at a time but it could only store 10-digits of the result.

The TI models used 64-bit registers and could typically store a 12 or 13 digit mantissa while displaying only 10 digits (2-3 guard digits).

There is an article by Dennis Harms ("The New Accuracy: Making 2 to the third = 8") in the Nov 1976 issue of HP Journal magazine that discusses how HP implemented the improved accuracy William Kahan suggested. A PDF of this issue is available here:
https://www.hpl.hp.com/hpjournal/pdfs/Is...976-11.pdf

[David Hayden]

(01-09-2024 01:23 AM)Thomas Klemm Wrote:  This avoids rounding errors:

P(50, 45) = 1 * 50 * 49 * 48 * 47 * 46
C(50, 45) = 1 * 50/1 * 49/2 * 48/3 * 47/4 * 46/5

Th really cool think about computing combinations this way is that the divisions always result in an integer.

Computing combinations was discussed in great detail in PPC journal. I don't have a reference handy, but I recall one final trick to prevent overflow in the multiplication: you start with 1E-99 (or whatever the smallest exponent is) as your result, run the algorithm, and then multiply the result by 1E99.

[Valentin Albillo]

(01-10-2024 03:12 PM)David Hayden Wrote:  

(01-09-2024 01:23 AM)Thomas Klemm Wrote:  C(50, 45) = 1 * 50/1 * 49/2 * 48/3 * 47/4 * 46/5

Th really cool think about computing combinations this way is that the divisions always result in an integer.

ORLY ? The divisions I've highlighted in bold red do not result in an integer. Or are you quoting some other expression/program ?

V.

[Thomas Klemm]

(01-09-2024 04:38 PM)J-F Garnier Wrote:  It seems to me a singular way to compute permutations...

Thanks, for pointing that out.
Not to be confused with:

Code:

from math import perm
perm(50, 5)

254251200

[Thomas Klemm]

(01-10-2024 05:36 PM)Valentin Albillo Wrote:  Or are you quoting some other expression/program ?

I must admit that I was concerned grouping the terms like that.
But while we had the discussion about implied multiplication and order of precedence I'm not aware of any programming language that changes the order based on whitespace.

The reason I've added the Python code is that:

Code:

p *= n
p //= m

… and:

Code:

p *= n // m

… are not the same.

The expression is to be calculated strictly from left to right.
Yes, I know that division is not associative.
But in general it is considered left associative.

The same with subtraction.
I assume that \(a - b + c\) is interpreted as \((a - b) + c\) and not as \(a - (b + c)\).
Otherwise writing polynomials becomes clumsy.

I'm a bit surprised that this confused you.

[Valentin Albillo]

(01-10-2024 07:17 PM)Thomas Klemm Wrote:  

(01-10-2024 05:36 PM)Valentin Albillo Wrote:  Or are you quoting some other expression/program ?

I'm a bit surprised that this confused you.

I quoted David Hayden, not you. I'm a bit surprised you didn't notice.

V.

[Thomas Klemm]

(01-10-2024 07:29 PM)Valentin Albillo Wrote:  I quoted David Hayden, not you. I'm a bit surprised you didn't notice.

Well, his quote included one of mine and you colored some of the terms therin red.
And yes, I've noticed that.

I just hope we clarified that David was not talking about the division 49/2 but about (1 * 50/1 * 49)/2.
Which is indeed an integer.