Must be my lucky day.



#37

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.


#38

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

Cheers.

Luiz (Brazil)

#39

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


#40

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;)


#41

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.


#42

That's exactly how these terms are commonly used.

#43

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.
#44

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

#45

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).


#46

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.


#47

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


#48

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


#49

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)


#50

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


#51

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.

#52

Á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

#53

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.


#54

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.

#55

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.


#56

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.


#57

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.


#58

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.


#59

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...


#60

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.

#61

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.


#62

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

#63

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...


#64

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

#65

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.

#66

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


#67

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)


#68

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


#69

Thanks, Didier;

It´s been downloaded at this very moment.

Cheers!

Luiz (Brazil)

#70

Hi Luiz,

Hugh also has it available on his site, here .

Regards,
Bart


#71

Thanks, Bart;

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

Cheers.

Luiz (Brazil)

#72

Guys;

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

Thank you!

Luiz (Brazil)


Possibly Related Threads...
Thread Author Replies Views Last Post
  The Lucky WP34S Cable eri 7 1,482 12-22-2013, 05:18 AM
Last Post: Walter B
  An amazing day: Giving a talk at HP about their calculators Geir Isene 9 1,830 12-16-2013, 06:14 PM
Last Post: aurelio
  OT - A lucky find - Busicom Handy-LE LE-120A Cristian Arezzini 2 652 09-26-2013, 04:43 AM
Last Post: Cristian Arezzini
  HHC 2013 Day 2 Highlights Eddie W. Shore 6 1,112 09-23-2013, 04:03 PM
Last Post: Kimberly Thompson
  HHC 2013: Day 1 Highlights Eddie W. Shore 28 3,072 09-23-2013, 03:22 PM
Last Post: Brad Barton
  Happy Mother's Day! Eddie W. Shore 1 457 05-12-2013, 11:35 AM
Last Post: Walter B
  HP lucky dip Keith Midson 6 919 05-12-2013, 06:40 AM
Last Post: aurelio
  happy fibonacci day 5/8/13 Allen 8 1,320 05-09-2013, 01:48 AM
Last Post: Gerson W. Barbosa
  Stupid idea of the day: 41-compatible watch bhtooefr 0 404 03-31-2013, 08:23 AM
Last Post: bhtooefr
  OT: Happy Pi Day! Eddie W. Shore 13 1,559 03-22-2013, 10:44 AM
Last Post: Les Koller

Forum Jump: