## DM42 and accuracy

Discussion around the Swiss Micros DM42 calculator.
ijabbott
Posts: 187
Joined: Fri Dec 15, 2017 2:34 pm
Location: GB-MAN

### Re: DM42 and accuracy

michel.lample wrote:
Wed Jun 10, 2020 2:36 pm
Does the DM42 (Free42) still use the CORDIC algorithm for exponentiation calculations, as do many hp calculators?
No, that's like going back to the 1970s when saving register / memory space was far more important than saving time.

michel.lample
Posts: 19
Joined: Wed May 03, 2017 5:09 pm

### Re: DM42 and accuracy

Concerning the accuracy properties of the DM42, here is an applications I’ve done with my students.

This is the “Birthday paradox” well known in probabilities: you may know that in a set of n persons (classroom by eg.), the probability that some pair of them will have the same birthday is :

P= 1- (365! / (365^n x (365-n)! ))

where “!” is the factorial op.

we can simplify this expression : P= 1- perm(365,n) / 365^n where perm(,) is the permutation operator.

Of course, if so many students calculators are unable to calculate this expression for n greater than 40 (and absolutely not the first form because of the 365!), the DM42 can do this for big n values!

In addition, the “reverse birthday” problem is more interesting : we have to solve this equation in n, for a given value of P: find a number of people so that the probability of a common birthday is P

in literature, we can find some approximations of P but, thanks to its “solve” capability, the DM41 is perfectly able to solve the equation:

To do this, we have to use a “continuous” form of the first equation, recalling that n!=Gamma(n+1).

So we have to use the first form of this probability in a solve-able program :

Code: Select all

LBL “BIRTH”
MVAR “N”
MVAR “P”
366
GAMMA
366
RCL “N”
-
GAMMA
/
365
RCL “N”
Y^X
/
1
-
RCL “P”
+
END
We can retrieve the well-known result that a 50% probability that (at least) 2 persons have a same birthday corresponds to an assembly of 22,76 people (23) .

Furthermore and without any calculation, a 100% probability corresponds to an assembly of 365+1 people of course. But the DM42 returns a strange result of 212 people !
Close inspection reveals that this number corresponds to the smallest number of the DM42: around 1E-34

I don’t know if other portable calculator are able to obtain a so powerful result!!

All the best
Michel

Walter
Posts: 1570
Joined: Tue May 02, 2017 11:13 am
Location: Close to FRA, Germany

### Re: DM42 and accuracy

michel.lample wrote:
Fri Jun 12, 2020 11:43 am
I don’t know if other portable calculator are able to obtain a so powerful result!!
I'm confident WP34S can do this as well since 2011.
DM42 SN: 00041 Beta
WP 43S running on this device

HP-35, HP-45, ..., HP-50, WP 34S, WP 31S, DM16L

ManuMa
Posts: 6
Joined: Sun Mar 15, 2020 10:14 pm
Contact:

### Re: DM42 and accuracy

michel.lample wrote:
Fri Jun 12, 2020 11:43 am
...
I don’t know if other portable calculator are able to obtain a so powerful result!!
...
Hi Michel,
I've tried with my HP-50G, and for 23 people I've got a 50.73% without effort (exact mode).

Regards,
Manuel.

michel.lample
Posts: 19
Joined: Wed May 03, 2017 5:09 pm

### Re: DM42 and accuracy

I've tried with my HP-50G, and for 23 people I've got a 50.73% without effort (exact mode).

Thanks Manuel,
But now, regarding the reverse problem, for your 50g what is the result for a "certain-event " probability ? ie. for what n do you obtain P=1 ?

Michel

Walter
Posts: 1570
Joined: Tue May 02, 2017 11:13 am
Location: Close to FRA, Germany

### Re: DM42 and accuracy

Back home at my WP43S, I get 50.7297% for 23 students easily. For 212 students, P = 1 - 7.785e-35. Solve isn't coded yet for the 43S, so the reverse problem has to wait a bit here.

Employing my good old WP34S of 2011, 50.7297% as well as 7.785e-35 are reproduced with ease. For solving, we look for the x where PERM(365,x)/365^x = 0. My quick and dirty program:

Code: Select all

LBL A
STO 00
# a        /* 365.2425
IP
STO 01
x<->y
PERM
RCL 01
RCL 00
y^x
/
RTN

Enter 50 as a guess for x and SLV A. This stops after less than a second throwing "No root found" with 268.584 in R00.
DM42 SN: 00041 Beta
WP 43S running on this device

HP-35, HP-45, ..., HP-50, WP 34S, WP 31S, DM16L

ManuMa
Posts: 6
Joined: Sun Mar 15, 2020 10:14 pm
Contact:

### Re: DM42 and accuracy

michel.lample wrote:
Mon Jun 15, 2020 5:29 pm
I've tried with my HP-50G, and for 23 people I've got a 50.73% without effort (exact mode).

Thanks Manuel,
But now, regarding the reverse problem, for your 50g what is the result for a "certain-event " probability ? ie. for what n do you obtain P=1 ?

Michel
Hi Michel,
With the 50g, if you solve PERM(365,x)/365^x = 0, with an initial guess of 100, you get 195.0330 after some 12 seconds.

Regards,
Manuel.

michel.lample
Posts: 19
Joined: Wed May 03, 2017 5:09 pm

### Re: DM42 and accuracy

With the 50g, if you solve PERM(365,x)/365^x = 0, with an initial guess of 100, you get 195.0330 after some 12 seconds.

Regards,
Manuel.
Manuel
Difficult for me to understand how the 50g can calculate a PERM function with non integer numbers (195.033) but I have to admit that I don't know this calculator.
Furthermore, on the DM42, 375^195 is around E499 which is the largest number on the 50g, this explains the result !

Michel

michel.lample
Posts: 19
Joined: Wed May 03, 2017 5:09 pm

### Re: DM42 and accuracy

On the DM42, trying to solve the birthday inverse problem with the following program reveals (for me) unknown behavior of the SOLVE algorithm:

Code: Select all

LBL"BPERM"
MVAR "X"
365
RCL "X"
PERM
365
RCL"X"
y^x
/
.END.
With any initial INTEGER value, the algorithm succeeds (result=315 in less than a second). But for any non integer initial value, the solver fails immediately.
Of course, the PERM function can't calculate for a non integer.

Strange and interesting result: if the first guess is an integer, the solver runs on integer only ?
Can someone confirm that ?

Michel

Thomas Okken
Posts: 716
Joined: Tue May 02, 2017 5:48 pm
Location: United States
Contact:

### Re: DM42 and accuracy

There's nothing in SOLVE to keep it trying only integers if the initial guesses are integers. But it sounds like what you're observing has a different reason.

SOLVE actually uses two starting values, not one. If you provide only one, the other one will be whatever was left from the last time it ran, which in your case would have been a root, so it would finish immediately.

To provide only one starting value and ignore any previous values, enter the new starting value twice: 100 [X] 100 [X] [X].