The Museum of HP Calculators

HP Forum Archive 17

[ Return to Index | Top of Index ]

More about Checksum
Message #1 Posted by Miguel Toro on 15 Aug 2007, 9:16 p.m.

Hello,

I entered the insertion sorting routine as written by Gene Wright in Datafile V26 N4, in both HP 35s (CNA 72102361 and 72102362) to verify if I got the same checksums. They were different compared between them and compared to Gene's. I deleted one instruction at a time backwards until line I015: there, the checksums were exactly the same! The culprit in this case: line I016, putting ‘1’ in the stack. Beginning with this instruction the checksums of both calculators disagreed. You could try and see if you obtain the same behavior:

I001 LBL I    ---> CK = 4254
I002 STO K
I003 IP
I004 STO B
I005 ISG K
I006 RCL K
I007 STO I
I008 RCL (I)  ---> CK = D522
I009 RCL I
I010 IP
I011 STO J
I012 RCL B
I013 x=y?
I014 GTO I026
I015 RDN      ---> CK = 5E0A
I016 1        ---> CK = 0B9E ('61) CK = 8136 ('62)
I017 -
I018 STO I
I019 x<>y
I020 RCL (I)
I021 x<=y?
I022 GTO I027
I023 STO (J)
I024 x<>I
I025 GTO I011
I026 RDN
I027 x<>y
I028 STO (J)
I029 ISG K
I030 GTO I006
I031 RTN

1.- The calculators have different content 2.- I made GTO .. in both before entering the program.

Regards,

Miguel

      
Re: More about Checksum
Message #2 Posted by Paul Dale on 15 Aug 2007, 9:25 p.m.,
in response to message #1 by Miguel Toro

Does a replacement of steps 15 and 16:

I015 RDN      ---> CK = 5E0A
I016 1        ---> CK = 0B9E ('61) CK = 8136 ('62)

with

I015 CLx
I016 e^x

cause the checksums to match again?

I'm pretty confident that it is numbers that are causing the problems with the checksums and size calculations. This alternative code avoids the number. It should also be smaller and slower.

- Pauli

      
Re: More about Checksum
Message #3 Posted by Bruce Bergman on 16 Aug 2007, 12:11 a.m.,
in response to message #1 by Miguel Toro

One (1) is a rather mathematically "boring" number. I wonder if you substituted, say, nine (9) or 67 for that one line, would the checksums still diverge?

I'd try this myself, but I carelessly left my 35s at work... ;-o

thanks, bruce

            
Re: More about Checksum
Message #4 Posted by Ed Look on 16 Aug 2007, 12:56 a.m.,
in response to message #3 by Bruce Bergman

1 isn't SO boring!

It has four roots, for well, 1, thing... ;)

Hmmmmm... how would I do that on a 35s?!

                  
Re: More about Checksum
Message #5 Posted by Eric Smith on 16 Aug 2007, 10:36 a.m.,
in response to message #4 by Ed Look

Quote:
1 isn't SO boring! It has four roots

I don't understand your point. If memory serves, every positive real number has two real roots of any even positive integer order, and n complex roots of any integer order n.

            
Re: More about Checksum
Message #6 Posted by Paul Brogger on 16 Aug 2007, 10:00 a.m.,
in response to message #3 by Bruce Bergman

Maybe if someone knows something about 35s internals, (s)he could offer a more informed opinion. In my ignorance, I can only speculate whether the 35s' new capacity for vectors and complex numbers might be related. If uninitialized (and unused) vector storage is incorporated in the checksum calculation for programs when simple numbers are being entered, that might explain how differing checksums result.

-- <appended> --------------------------------

FWIW (and in case it hasn't been made clear yet), the User Manual's example programs are not immune. The first three suspect programs from the manual that I entered (chosen because each includes at least one number entered on the stack) all came up with checksums that differ from those listed in the manual:

LBL S -- page 16-13 -- CK=DDC4
LBL F -- page 16-14 -- CK=8C04
LBL I -- page 16-19 -- CK=2159

Edited: 18 Aug 2007, 11:05 a.m.

            
Re: More about Checksum
Message #7 Posted by Bill (Smithville, NJ) on 16 Aug 2007, 11:32 a.m.,
in response to message #3 by Bruce Bergman

Hi Bruce,

Quote:
One (1) is a rather mathematically "boring" number

Sound like you have listened to the BBC series on numbers.

A FURTHER FIVE NUMBERS

If you haven't heard the series, then I highly recommend it. There are three series on numbers:

Five Numbers, Another Five Numbers and A Further Five numbers.

While you are there, also check out the series on Electronic Brains.

Electronic Brains

Bill

            
Re: More about Checksum
Message #8 Posted by Paul Dale on 19 Aug 2007, 4:54 p.m.,
in response to message #3 by Bruce Bergman

1 isn't boring!

- Pauli

                  
Re: More about Checksum
Message #9 Posted by Vincze on 19 Aug 2007, 7:27 p.m.,
in response to message #8 by Paul Dale

1 is not boring, but it is the loneliest number. ;)

Why would number throw checksum off though? That I not understand. Every didgit and keystroke I would assume have an ascii code in the system, or something similar that it would be assigned. Why would a number on one person machine be different than another persons? I wonder though, if program typed in on one mode, and then typed in on different mode yield different checksum? Meaning, if you type in on one calculator in degree mode, and on different calculator in radian mode, I wonder if that be different. Or maybe with different base, although I not sure it would let you do the later. Hmm, maybe on some calculator, 1 is larger than on others. You know, 1 + 1 = 3 for very large value of 1.


[ Return to Index | Top of Index ]

Go back to the main exhibit hall