The Museum of HP Calculators

HP Forum Archive 19

[ Return to Index | Top of Index ]

Must be my lucky day.
Message #1 Posted by Stuart Sprott on 17 Nov 2009, 5:44 a.m.

I have owned a HP42 since 1990. Being a surveyor it has had some heavy use. It has never failed me.

Eventually I moved onto the HP48 and then progressed right up to the HP50. In the mean time the HP42 has always been a sort of reserve calculator. Now that I have a HP50, I find that it has been ages since I have used the HP42. In fact about 18 months. That is when I found that the batteries were flat.

I made a mental note to get batteries but being slack I did not follow up. To day I did get some batteries and installed them. Much to my surprise I found that all my old programs were still there!!!

So you can get lucky sometimes.

      
Re: Must be my lucky day.
Message #2 Posted by Vieira, Luiz C. (Brazil) on 17 Nov 2009, 5:57 a.m.,
in response to message #1 by Stuart Sprott

Low power C-MOS RAM... World would be a sad place without them.

Cheers.

Luiz (Brazil)

      
HP-42S: "Glueck", dann "Unglueck/Pech".
Message #3 Posted by Karl Schneider on 18 Nov 2009, 12:13 a.m.,
in response to message #1 by Stuart Sprott

Glueck = Good Luck
Unglueck or Pech = Bad Luck (to varying degrees)

I've had the same situation twice recently, when switching on an HP-42S for the first time in many months.

The first one was a pre-1990 flat-display model showing a low-battery indicator, and retaining a fair amount of stored programming. I replaced all three cells quickly, knowing that some HP-42S have been known to lose contents of Continuous Memory during routine battery changes. All my CM was retained. It was the second successful battery replacement of that unit.

Then, one of my post-1990 recessed-display models would not even turn on after many months. It had many of the same stored programs, I believe. After quickly replacing the battery, no such luck: "Machine Reset" displayed upon power-up with the new battery, and all my CM was lost.

One can't let the battery get too discharged, or the capacitor that helps to retain CM will also get discharged.

Battery life can be extended on Pioneer-series models with time clocks (HP-17B, HP-17BII, HP-27S) by putting them into "coma" mode when not in use, shutting off the clock: Turn off by simultaneously pressing the keys in the upper and lower right corner positions along with the on/off key in the lower left corner.

The HP-42S can also be put into coma mode, but I doubt that doing so has much effect.

The HP-41 tends to preserve CM well. If the battery is low ("BAT" indicator on), the CX/Time Module clock will not operate, and trying to do so will turn the unit off. However, the CM is fairly safe. Needless to say, electronic backup is possible with the HP-41.

-- KS

Edited: 18 Nov 2009, 1:13 a.m. after one or more responses were posted

            
Re: HP-42S: erst "Glück", dann "Pech".
Message #4 Posted by Walter B on 18 Nov 2009, 12:44 a.m.,
in response to message #3 by Karl Schneider

Karl,

I wouldn't call the second case an "Unglück" - that's a too big word IMHO for such a memory loss though it may have caused you a lot of work reentering these routines. But since you had them all documented properly, ... d;)

                  
Re: HP-42S: erst "Glück", dann "Pech".
Message #5 Posted by Bart (UK) on 18 Nov 2009, 7:17 a.m.,
in response to message #4 by Walter B

From my Dutch background, I would have interpreted "Pech" as "bad luck" and "Unglück" more as "accident", i.e. something heavy fell on your 42S and destroyed it.

Edit: perhaps if one first connected a 4.5V source in parallel to the battery before removal. Terminals of Pioneers are reasonably accessible with small crocodile clips, I think.

Edited: 18 Nov 2009, 7:21 a.m.

                        
Re: HP-42S: erst "Glück", dann "Pech".
Message #6 Posted by Thomas Radtke on 18 Nov 2009, 7:22 a.m.,
in response to message #5 by Bart (UK)

That's exactly how these terms are commonly used.

                        
Re: HP-42S: erst "Glück", dann "Pech".
Message #7 Posted by Martin Pinckney on 18 Nov 2009, 10:47 a.m.,
in response to message #5 by Bart (UK)

Quote:
Terminals of Pioneers are reasonably accessible with small crocodile clips, I think.
This is amusing. Here in the US we call them "alligator clips". Stands to reason they would be "crocodiles" everywhere else.
                  
Re: HP-42S: erst "Glück", dann "Pech".
Message #8 Posted by Karl Schneider on 19 Nov 2009, 9:42 p.m.,
in response to message #4 by Walter B

Quote:
Karl,

I wouldn't call the second case an "Unglück" - that's a too big word IMHO for such a memory loss though it may have caused you a lot of work reentering these routines. But since you had them all documented properly...

Hi, Walter --

Yes, there is indeed a difference in severity indicated by the two words, but I forgot offhand which was the 'minor setback' and which was the 'major misfortune'. 'Unglück' is too strong a word in this case. It's all coming back to me now...

I ought to back up the code to a Free42 *.raw file before I lose the program on the other HP-42S.

-- KS

            
Pech brings opportunity
Message #9 Posted by Bart (UK) on 24 Nov 2009, 7:03 a.m.,
in response to message #3 by Karl Schneider

I had Pech with my car today, it did not start due to a dead battery.

However, I had the opportunity to play with my recently TAS aquired 99p Casio fx-7000GB while on the bus. Entering the m-of-n reliability formula, I discovered it did not have nCr (or nPr) - no big problem as it does have x!. Even so, it is still faster than the 35s.

The advantage of the 35s though is high values of n. The fx-7000G is limited to n<=69 (as n! < 10e99). The 35s happily calculates 285C283 (even though n>253 results in n! > 10e499).

                  
Re: Pech brings opportunity
Message #10 Posted by Gerson W. Barbosa on 24 Nov 2009, 7:46 a.m.,
in response to message #9 by Bart (UK)

Quote:
The 35s happily calculates 285C283 (even though n>253 results in n! > 10e499).

You can find RPN programs for combination and permutation in this old thread. Perhaps they can be converted to Casio fx-7000GB.

                        
Re: nCr program for fx-7000G (GA/GB) (Corrected)
Message #11 Posted by Bart (UK) on 24 Nov 2009, 5:42 p.m.,
in response to message #10 by Gerson W. Barbosa

Hi Gerson,

Thanks for that link. I took Eamonn's (well commented) 31-line HP-25 program and converted it for the fx-7000G. 

"N"?->N:"R"?->R
R<(N-R)=>R->X:(N-R)->X
1->D:1E-3->C
Lbl 1
X=0=>Goto 2
C*N->C:C/D->C
N-1->N:D+1->D
Dsz X:Goto 1
Lbl 2:C*1E3

I've tested it for a few datapoints (including C(90,7)) and it seems to give the correct answers.

EDIT:
Errata:

It seems that the comparison R<(N-R) doesn't work and (N-R) is always put to X. So I have modified it:
"N"?->N:"R"?->R
N-R->X:R<X=>R->X
1->D:1E-3->C
Lbl 1
X=0=>Goto 2
C*N->C:C/D->C
N-1->N:D+1->D
Dsz X:Goto 1
Lbl 2:C*1E3

This has also saved me 6 steps. Also I thank you all for thought provoking discussions.

Edited: 30 Nov 2009, 10:15 a.m. after one or more responses were posted

                              
Re: nCr program - MCODE
Message #12 Posted by Ángel Martin on 25 Nov 2009, 7:32 a.m.,
in response to message #11 by Bart (UK)

Reading this tread I realized the same error was present in the MCODE function I wrote to calculate nCr on the 41 - so I corrected it, here's the code below in case you're interested.

The corrected code will be added to the SandMath_6 module.

Cheers, ÁM

092	"R"	
003	"C"	        nCr = PROD{(n-k)/(r-k)} ,
00E	"N"	        k=0,1,…,(r-2),(r-1)
108	SETF 8	        Ángel Martin
02B	JNC +05	
092	"R"	
010	"P"	        nPr = PROD{n-k} ,
00E	"N"	        k=0,1,…,(r-2),(r-1)
104	CLRF 8	        Ángel Martin
04E	C=0 ALL	
35C	PT= 12	        builds "1" in C
050	LD@PT- 1	
268	WRIT 9(Q)	initial product
0B8	READ 2(Y)	n
2EE	?C#0 ALL	Carry set if NOT Zero
04B	JNC +09	
10E	A=C ALL	
0F8	READ 3(X)	r
351	?NC XQ	        (includes SETDEC)
050	->14D4	        [CHK_NO_S1]
088	SETF 5	        Take Integer part
0ED	?NC XQ	
064	->193B	        [INTFRC]
2EE	?C#0 ALL	Carry set if NOT Zero
30D	?NC GO	
062	->18C3	        [ERR0]
05E	C=0 MS	        make it positive >0
0E8	WRIT 3(X)	r (integer, >0)
10E	A=C ALL	        r
04E	C=0 ALL	
2DC	PT= 13	        Build "-1" in C
250	LD@PT- 9	-
050	LD@PT- 1	1
01D	?NC XQ	        Adds normalized A and C
060	->1807	        [AD2_10]
070	N=C ALL	        (r-k), index counter
2BE	C=-C-1 MS	-(r-k)
3C4	ST=0	        Clears Carry if set
128	WRIT 4(L)	-(r-k)
10E	A=C ALL	        -(r-k)
0B8	READ 2(Y)	n
01D	?NC XQ	        Adds normalized A and C
060	->1807	        [AD2_10]
10C	?FSET 8	        skip if nPr case
063	JNC +12d	
228	WRIT 8(P)	save [n-(r-k)] it in M
0F8	READ 3(X)	r
10E	A=C ALL	
138	READ 4(L)	-(r-k)
01D	?NC XQ	        Adds normalized A and C
060	->1807	        [AD2_10]
10E	A=C ALL	        r-(r-k)=k
238	READ 8(P)	
0AE	A<>C ALL	
261	?NC XQ	        Divides A over C
060	->1898	        [DV2_10]
10E	A=C ALL	        n-[(r-k)-1]
278	READ 9(Q)	partial product PP
135	?NC XQ	        it *uses* M !!
060	->184D	        [MP2_10]
2F6	?C#0 XS	        See if we overflow?
289	?C GO	        "Out of Range"
003	->00A2	        [ERROF]
268	WRIT 9(Q)	PP*{n-[(r-k)-1)]}
0B0	C=N ALL	        (r-k)-1
2EE	?C#0 ALL	
2D7	JC -38d	        loop back
278	READ 9(Q)	
0EE	B<>C ALL	final solution
391	?NC GO	        (REQUIRES Value in B)
002	->00E4	        [DROPST]

Edited: 26 Nov 2009, 1:29 a.m. after one or more responses were posted

                                    
Re: nCr program
Message #13 Posted by Vieira, Luiz C. (Brazil) on 25 Nov 2009, 10:26 a.m.,
in response to message #12 by Ángel Martin

Hi, Ángel;

I did not check for this, so I decided to ask first: can this code replace current SandMath-5 nCr code, I mean, enough room and compatible structure? This way, updating current SandMath-5 would be possible... or not?

Thanks.

Luiz (Brazil)

                                          
Re: nCr program
Message #14 Posted by Ángel Martin on 25 Nov 2009, 2:32 p.m.,
in response to message #13 by Vieira, Luiz C. (Brazil)

Hi Luiz,

Yep, same place, same FAT entry, and compatible with everything else in the module. In fact, this rewrite has one less word of code so we also gained some space :)

It wasn't too difficult, I guess I lucked out this time...

Best wishes, AM

                                                
Re: nCr program
Message #15 Posted by Vieira, Luiz C. (Brazil) on 25 Nov 2009, 2:46 p.m.,
in response to message #14 by Ángel Martin

OK, Thanks!

I'll update mine and save it with a different revision code (next letter in the current version)... If you have a different code for it, please, let me know.

That´s the first ROM image I update myself! <=^) (and another one to the collection)

Cheers!

Luiz (Brazil)

Edited: 25 Nov 2009, 3:05 p.m.

                                    
Re: nCr program
Message #16 Posted by Bart (UK) on 25 Nov 2009, 6:39 p.m.,
in response to message #12 by Ángel Martin

Ángel,

Thank you for sharing your code. Unfortunately I am not a 41-er or MCODE-er, but I see the Museum CD has "M-Code for beginners" book on it. Your code has both nCr and nPr with error trapping, so I may well come back to this in the future.

Regards,
Bart

                                    
Re: nCr program - MCODE
Message #17 Posted by Karl Schneider on 27 Nov 2009, 5:23 a.m.,
in response to message #12 by Ángel Martin

Hi, Angel --

I've been interested in your HP-41 Sandbox product, but never took the initiative.

Combination and permutation (nCr, nPr) are a good illustation of all that goes into a rigorous implementation of a straightforward calculation:

  1. Check that both n and r are verifiable non-negative integers
  2. Check that n >= r
  3. Design the algorithm such that any answer within the range of displayable values (inlcuding exponents) will be provided.
  4. Overflow results should be identified as quickly as possible.

I can't interpret your MCODE comments well enough to tell if the program will compute combination (nCr) by the shortest method possible -- namely, using the greater of r or (n-r) to cancel the largest number of multiplicands within n!.

Example:

10C7 =  10! / [7!(10-7)!]    7 > 10-7, so
     =  (10*9*8) / (3*2*1)   using 7! for cancellation
     =  10/3 * 9/2 * 8/1
     =  120

        Longer way, using 3! for cancellation: 

     =  (10*9*8*7*6*5*4) / (7*6*5*4*3*2*1)   
     =  10/7 * 9/6 * 8/5 * 7/4 * 6/3 * 5/2 * 4/1
     =  120

10C2 =  10! / [2!(10-2)!]    10-2 > 2, so
     =  10*9 / 2*1           using 8! for cancellation
     =  10/2 * 9/1
     =  72

The chain of multiplication should proceed right-to-left, with the largest quotients, so that overflow conditions are identified sooner.

HP calc's take this approach, I believe, because statistical combination or n and r always seems to take longest when r = n/2 -- doesn't matter whether r! or (n-r)! is used for cancellation, so more quotients are multiplied than if r is near either zero or n.

-- KS

Edited: 27 Nov 2009, 6:09 a.m.

                                          
Re: nCr program - MCODE
Message #18 Posted by Marcus von Cube, Germany on 27 Nov 2009, 10:05 a.m.,
in response to message #17 by Karl Schneider

Karl, since we know that nCr and nPr are integers, it seems like a good idea to round the result to the nearest integer at the end of the calculation. Through the divides, rounding errors might have crept in.

                                          
Re: nCr program - MCODE
Message #19 Posted by Ángel Martin on 27 Nov 2009, 10:22 a.m.,
in response to message #17 by Karl Schneider

Hi Karl, glad to see you posting on this topic.

Good points indeed about the rigor that should be used when writing this type of functions, be that MCODE or not. It's just good programming practices (GPP) but frequently get overlooked or abandoned for different reasons (not enough available space, being tricky or simply lazyness).

I have made a few improvements to the posted code that didn't get done precisely for lack of space. The SandMath is packed to its seams so I had to re-arrange some blocks to make it fit.

It now uses the minimum of {r, {n-r}} to expedite the calculation time. It also checks that n>r, and that neither one of them is zero. This last requirement is admitedly not universally accepted but I decided to do it this way to follow a more purist approach. Finally, The program would take the integer parts, and will force them to be positive.

The "Out of Range" condition is checked at every multiplication, so it's determined as soon as possible. The algorithm works within the nummeric range of the 41. (like it'll calculate 335C167 without problems). The chain of multiplication proceeds right-to-left, with the largest quotients first.

I'm not doing any rounding as I'm not completely in agreement with such an action - probably my own apprehension but I'm yet to find any result with fractional part.

Will post the listing in a new article in the corresponding section of this forum.

Best wishes, ÁM

Edited: 27 Nov 2009, 11:00 a.m.

                                                
Re: nCr program - MCODE
Message #20 Posted by Marcus von Cube, Germany on 27 Nov 2009, 11:42 a.m.,
in response to message #19 by Ángel Martin

Quote:
I'm not doing any rounding as I'm not completely in agreement with such an action - probably my own apprehension but I'm yet to find any result with fractional part.

What about C(7,3) = (7/1) * (6/2) * (5/3) ?

On my 15C, I get 35.00000001 as a result. The built-in function returns 35 as an integer.

                                                      
Re: nCr program - MCODE
Message #21 Posted by Ángel Martin on 27 Nov 2009, 4:12 p.m.,
in response to message #20 by Marcus von Cube, Germany

Heres's straight (copy - pasted) from my V41:

35,00000000

my MCODE function calculates it as:

5/1 * 6/2 * 7/3

Cheers, AM

Edited: 27 Nov 2009, 4:23 p.m.

                                                            
Re: nCr program - MCODE
Message #22 Posted by Marcus von Cube, Germany on 28 Nov 2009, 4:22 a.m.,
in response to message #21 by Ángel Martin

AM, you're lucky. :) It depends on the arrangement of the numbers. I'm pretty sure there will be combinations that lead to non integer results.

                                                                  
Re: nCr program - MCODE
Message #23 Posted by Ángel Martin on 28 Nov 2009, 8:01 a.m.,
in response to message #22 by Marcus von Cube, Germany

You're quite right Marcus... here's one that suffers from the non-integer illness:

C(33,7)=4.272.047,999

whereas the result should be of course 4.272.048,00

So I guess some rounding is in order after all?

Always fascinating this calculator world...

                                                                        
Re: nCr program - MCODE
Message #24 Posted by Marcus von Cube, Germany on 28 Nov 2009, 8:06 a.m.,
in response to message #23 by Ángel Martin

I'm asking myself what will happen for larger results? Due to the limited precision there might creep in quite reasonable errors. Have you (or anybody else) checked with a symbolic calc like the 50g? This cannot be overcome with rounding to the next integer because these errors might occur at numbers >= 10^10.

                                                                        
Re: nCr program - MCODE
Message #25 Posted by David Hayden on 28 Nov 2009, 12:33 p.m.,
in response to message #23 by Ángel Martin

Quote:
You're quite right Marcus... here's one that suffers from the non-integer illness:

C(33,7)=4.272.047,999

whereas the result should be of course 4.272.048,00

So I guess some rounding is in order after all?

Always fascinating this calculator world...

You can avoid the rounding error by doing two multiplications before you start dividing. So C(33,7) is computed as:
27*28/2*29/3*30/4*31/5*32/6*33/7

where the operations are performed from left to right. The result of each step is guaranteed to be an integer (I think!). You start by multiplying two consecutive integers k*(k+1). One of these is odd, so dividing by 2 gives an integer. Multiply again by (k+2) and you're guaranteed to now have a factor of 3 in the numerator, etc.

                                                                              
Re: nCr program - MCODE
Message #26 Posted by Marcus von Cube, Germany on 28 Nov 2009, 12:57 p.m.,
in response to message #25 by David Hayden

Looks like a perfect solution to me. What about the huge number accuracy issue? Any ideas?

                                                                              
Re: nCr program - MCODE
Message #27 Posted by Ángel Martin on 28 Nov 2009, 1:05 p.m.,
in response to message #25 by David Hayden

Good lateral thinking (actually not so lateral but very much to the point). I'm however weary of the prime numbers in the sequence, won't that throw the whole idea to the drawing board again?

Maybe my intuition isn't what it should though...

                                                                                    
Re: nCr program - MCODE
Message #28 Posted by David Hayden on 28 Nov 2009, 1:30 p.m.,
in response to message #27 by Ángel Martin

Quote:
Good lateral thinking (actually not so lateral but very much to the point). I'm however weary of the prime numbers in the sequence, won't that throw the whole idea to the drawing board again?

Maybe my intuition isn't what it should though...

I think it's still okay. Basically it computes C(28,2), then C(29,3) then C(30,4) ... to C(33,7). Each of these is an integer and since each one results from a single multiplication followed by a division, the results must be integral also.

Not exactly a PhD proof I suppose.... :)

Dave

                                                                                    
Re: nCr program - MCODE
Message #29 Posted by Egan Ford on 28 Nov 2009, 3:04 p.m.,
in response to message #27 by Ángel Martin

Quote:
Maybe my intuition isn't what it should though...
This may or may not help. But...

Take, say, 7 consecutive integers. Now take the set of all integers. Since every 7th integer is divisible by 7, and every 6th by 6, etc..., then if you have 7 consecutive integers then somewhere you overlap with the sequence of one in every 7 numbers. Same for 6, 5, etc...

E.g. take the sequence:

29, 30, 31

Two prime numbers. Based on the argument above at least one of the three must be divisible by 2. Same for the number 3. In this case its 30 for both.

As you continue to multiply the next number in the sequence you can be certain that the product will be divisible by the number of elements in your sequence, e.g.:

29, 30, 31, 32

4 must divide one of them. 32 in this case.

29, 30, 31, 32, 33

5 must divide one of them. Again 30.

It gets interesting with the 6th number:

29, 30, 31, 32, 33, 34

6 must divide one of them. Again 30, but 30 is all used up with 2*3*5. No worries. 1 divides 29, 2 divides 32, 3 divides 33, 4 divides 32, 5 divides 30, 6 divides 30. As you continue to multiply numbers you gain more factors and once multiplied you lose any memory of what number provided what factor.

Edited: 28 Nov 2009, 3:23 p.m.

                                                                        
Re: nCr program - MCODE
Message #30 Posted by Werner on 29 Nov 2009, 7:39 a.m.,
in response to message #23 by Ángel Martin

I'm totally unfamiliar with MCODE, but I think your code performs the division, then the multiplication.
If you were to calculate C(33,7) as 33/1*32/2*31/3*30/4*29/5*28/6*27/7,
all intermediate results are integers (and they would always be, except when they grow larger than 1e13)

A link somewhere above lead to an RPN program I posted for the 41,
that will return integer results if the result < 1e10 (without the need to rounding),
and will not overflow if the final result < 1e99 even if an intermediate result is larger,
as is the case with C(336,168).  That trick is probably not necessary in MCODE.

01*LBL"COMB"
02 ST- Y
03 X>Y?
04 X<>Y
05 +
06 1 E-3
07 ST* L
08 X<>Y
09 ISG L
10 X=0?
11 GTO 00
12*LBL 02
13 ST* Y
14 LASTX
15 INT
16 ST/ Z
17 RDN
18 DSE X
19 ISG L
20 GTO 02
21*LBL 00
22 RDN
23 1 E3
24 *
25 END
                              
OT: fx-7000G (was: nCr program)
Message #31 Posted by Vieira, Luiz C. (Brazil) on 25 Nov 2009, 10:22 a.m.,
in response to message #11 by Bart (UK)

Hi, Bart;

could not help noticing you mentioned the FX-7000G. I was lucky enough buying an FX-7000GA about five years ago, and I still have no complete information about it, just bits and pieces. Do you know if there is any on-line information about it (manuals, guides, any) I can download? I found a custom manual in French some years ago, but I would like to know if there is anything else.

Thanks.

Luiz (Brazil)

                                    
Re: OT: fx-7000G (was: nCr program)
Message #32 Posted by Didier Lachieze on 25 Nov 2009, 11:06 a.m.,
in response to message #31 by Vieira, Luiz C. (Brazil)

Hi Luiz, take a look here: Casio FX-7000GA user manual

                                          
Re: OT: fx-7000G (was: nCr program)
Message #33 Posted by Vieira, Luiz C. (Brazil) on 25 Nov 2009, 1:45 p.m.,
in response to message #32 by Didier Lachieze

Thanks, Didier;

It´s been downloaded at this very moment.

Cheers!

Luiz (Brazil)

                                    
Re: OT: fx-7000G (was: nCr program)
Message #34 Posted by Bart (UK) on 25 Nov 2009, 12:05 p.m.,
in response to message #31 by Vieira, Luiz C. (Brazil)

Hi Luiz,

Hugh also has it available on his site, here .

Regards,
Bart

                                          
Re: OT: fx-7000G (was: nCr program)
Message #35 Posted by Vieira, Luiz C. (Brazil) on 25 Nov 2009, 1:47 p.m.,
in response to message #34 by Bart (UK)

Thanks, Bart;

I appreciate it! I´ll keep both links as a reference.

Cheers.

Luiz (Brazil)

                                    
Didier & Bart: Thanks! (fx-7000G)
Message #36 Posted by Vieira, Luiz C. (Brazil) on 25 Nov 2009, 8:36 p.m.,
in response to message #31 by Vieira, Luiz C. (Brazil)

Guys;

that´s the manual I was searching for (although I was not aware of its existence...)

Thank you!

Luiz (Brazil)

[ Return to Index | Top of Index ]

Go back to the main exhibit hall