▼
Posts: 36
Threads: 7
Joined: Sep 2007
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.
▼
Posts: 4,027
Threads: 172
Joined: Aug 2005
Low power CMOS RAM... World would be a sad place without them.
Cheers.
Luiz (Brazil)
Posts: 1,792
Threads: 62
Joined: Jan 2005
Glueck = Good Luck
Unglueck or Pech = Bad Luck (to varying degrees)
I've had the same situation twice recently, when switching on an HP42S for the first time in many months.
The first one was a pre1990 flatdisplay model showing a lowbattery indicator, and retaining a fair amount of stored programming. I replaced all three cells quickly, knowing that some HP42S 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 post1990 recesseddisplay 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 powerup 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 Pioneerseries models with time clocks (HP17B, HP17BII, HP27S) 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 HP42S can also be put into coma mode, but I doubt that doing so has much effect.
The HP41 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 HP41.
 KS
Edited: 18 Nov 2009, 1:13 a.m. after one or more responses were posted
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
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;)
▼
Posts: 850
Threads: 10
Joined: Mar 2009
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.
▼
Posts: 1,089
Threads: 32
Joined: Dec 2005
That's exactly how these terms are commonly used.
Posts: 1,248
Threads: 33
Joined: Aug 2007
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.
Posts: 1,792
Threads: 62
Joined: Jan 2005
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 HP42S.
 KS
Posts: 850
Threads: 10
Joined: Mar 2009
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 fx7000GB while on the bus. Entering the mofn 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 fx7000G is limited to n<=69 (as n! < 10e99). The 35s happily calculates _{285}C_{283} (even though n>253 results in n! > 10e499).
▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
Quote:
The 35s happily calculates _{285}C_{283} (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 fx7000GB.
▼
Posts: 850
Threads: 10
Joined: Mar 2009
Hi Gerson,
Thanks for that link. I took Eamonn's (well commented) 31line HP25 program and converted it for the fx7000G.
"N"?>N:"R"?>R
R<(NR)=>R>X:(NR)>X
1>D:1E3>C
Lbl 1
X=0=>Goto 2
C*N>C:C/D>C
N1>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<(NR) doesn't work and (NR) is always put to X. So I have modified it:
"N"?>N:"R"?>R
NR>X:R<X=>R>X
1>D:1E3>C
Lbl 1
X=0=>Goto 2
C*N>C:C/D>C
N1>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
▼
Posts: 1,253
Threads: 117
Joined: Nov 2005
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{(nk)/(rk)} ,
00E "N" k=0,1,…,(r2),(r1)
108 SETF 8 Ángel Martin
02B JNC +05
092 "R"
010 "P" nPr = PROD{nk} ,
00E "N" k=0,1,…,(r2),(r1)
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 (rk), index counter
2BE C=C1 MS (rk)
3C4 ST=0 Clears Carry if set
128 WRIT 4(L) (rk)
10E A=C ALL (rk)
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(rk)] it in M
0F8 READ 3(X) r
10E A=C ALL
138 READ 4(L) (rk)
01D ?NC XQ Adds normalized A and C
060 >1807 [AD2_10]
10E A=C ALL r(rk)=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[(rk)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[(rk)1)]}
0B0 C=N ALL (rk)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
▼
Posts: 4,027
Threads: 172
Joined: Aug 2005
Hi, Ángel;
I did not check for this, so I decided to ask first: can this code replace current SandMath5 nCr code, I mean, enough room and compatible structure? This way, updating current SandMath5 would be possible... or not?
Thanks.
Luiz (Brazil)
▼
Posts: 1,253
Threads: 117
Joined: Nov 2005
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
▼
Posts: 4,027
Threads: 172
Joined: Aug 2005
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.
Posts: 850
Threads: 10
Joined: Mar 2009
Ángel,
Thank you for sharing your code. Unfortunately I am not a 41er or MCODEer, but I see the Museum CD has "MCode 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
Posts: 1,792
Threads: 62
Joined: Jan 2005
Hi, Angel 
I've been interested in your HP41 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:
 Check that both n and r are verifiable nonnegative integers
 Check that n >= r
 Design the algorithm such that any answer within the range of displayable values (inlcuding exponents) will be provided.
 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 (nr) to cancel the largest number of multiplicands within n!.
Example:
10C7 = 10! / [7!(107)!] 7 > 107, 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!(102)!] 102 > 2, so
= 10*9 / 2*1 using 8! for cancellation
= 10/2 * 9/1
= 72
The chain of multiplication should proceed righttoleft, 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 (nr)! 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.
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
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.
Posts: 1,253
Threads: 117
Joined: Nov 2005
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 rearrange some blocks to make it fit.
It now uses the minimum of {r, {nr}} 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 righttoleft, 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.
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
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 builtin function returns 35 as an integer.
▼
Posts: 1,253
Threads: 117
Joined: Nov 2005
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.
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
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.
▼
Posts: 1,253
Threads: 117
Joined: Nov 2005
You're quite right Marcus... here's one that suffers from the noninteger 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...
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
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.
Posts: 528
Threads: 40
Joined: Dec 2008
Quote:
You're quite right Marcus... here's one that suffers from the noninteger 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.
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
Looks like a perfect solution to me. What about the huge number accuracy issue? Any ideas?
Posts: 1,253
Threads: 117
Joined: Nov 2005
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...
▼
Posts: 528
Threads: 40
Joined: Dec 2008
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
Posts: 1,619
Threads: 147
Joined: May 2006
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.
Posts: 163
Threads: 7
Joined: Jul 2007
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 E3
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
Posts: 4,027
Threads: 172
Joined: Aug 2005
Hi, Bart;
could not help noticing you mentioned the FX7000G. I was lucky enough buying an FX7000GA about five years ago, and I still have no complete information about it, just bits and pieces. Do you know if there is any online 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)
▼
Posts: 248
Threads: 5
Joined: Feb 2008
Hi Luiz, take a look here: Casio FX7000GA user manual
▼
Posts: 4,027
Threads: 172
Joined: Aug 2005
Thanks, Didier;
It´s been downloaded at this very moment.
Cheers!
Luiz (Brazil)
Posts: 850
Threads: 10
Joined: Mar 2009
Hi Luiz,
Hugh also has it available on his site, here .
Regards, Bart
▼
Posts: 4,027
Threads: 172
Joined: Aug 2005
Thanks, Bart;
I appreciate it! I´ll keep both links as a reference.
Cheers.
Luiz (Brazil)
Posts: 4,027
Threads: 172
Joined: Aug 2005
Guys;
that´s the manual I was searching for (although I was not aware of its existence...)
Thank you!
Luiz (Brazil)
