pa1409@sdcc13.ucsd.edu (Steven Haehnichen) (04/10/90)
Here's a little list that has puzzled me all night and almost made me purge my favorite object compressor. I have no idea how it happened, but when I decompressed a directory, (using PAK/XPAK) the BYTES crc was different. After some poking around, I found that one decompressed binary integer looks the same as the original, but has a different CRC, a different length (?), and is not considered "SAME" by the HP48. Here is the list of two integers, UUencoded. 29.5 bytes, CRC= #A7A9h BEGIN--cut here--CUT HERE-- begin 600 puzzled.bin F2%!(4#0X+4%T*N"D`A(`T"9I#1T_'4XJ4`$`;9+6T/'3`0`K,0#$ ` end END--cut here--CUT HERE-- I had to transfer in binary because they became "SAME" after an ascii transfer. For some reason, independent of word-size, one of the integers occupies 13 bytes [#3DC9h] and the other takes only 11.5 bytes [#5600h]. If you play with the base display, or change word-size, they still return 0 when compared with SAME. Of course, == replies "1", and NEG applied to both integers returns the SAME value. Am I missing something obvious, or is there a hidden difference between the two integers? I entered the number by hand and got the same object as the 13 byte integer. So... Is there some kind of "Integer-Light" that could save 1.5 bytes of precious memory? 8) For what it's worth, the integer was originally created by the TIMEKEEP program posted by Eric Postpischil (Thanks), specifically, the CLKDAT object. (If the answer is RTFM, I'm going to be bummed..): Steve. E-Mail: shaehnichen@ucsd.edu & shaehnic@ucsd.bitnet etc...