- Joined
- Jul 10, 2007
- Messages
- 6,306
So.... originally I was using a checksum with a crc.
I'd have a big number and multiply the checksum in last. The checksum would be the checksum+version and the maximum would be checksum max + version max. The crc, first thing added in, would be the version. I'd divide the combined checksum version out at the back, get the checksum for the code, and subtract the retrieved checksum from the stored one to get the remaining version. After dividing out all of the values (left with crc), I'd compare the crc to the version that was left over from the checksum and make sure they were equal. This allowed me to store the version of the code in a much smaller space =).
I'm moving over to the Hamming Code for error detection, which is much, much better than a checksum (both smaller and 100% error detection). The only problem with this is that I now don't know how I should put in the version.
Any ideas?
For those who don't know, a the Hamming Code converts the number into binary and places a parity bit in every power of 2 position of the number. For example, a number of 8 digits would have a parity bit at 1, 2, 4, and 8 (all powers of 2). The parity bits are based on the xor of all of the digits with a 1 in the position of the parity bit's position. For example, 2 would require a 1 in position 2. Looking at 9 in binary, it's 1001. A 0 is in position 2 -> 10[0]1. However, the 9 would be used in the XOR for the first parity bit as a 1 is in position 1 -> 100[1].
For those who don't know what XOR is, XOR is true if there are an odd number of 1s and false if there are an even number of 1s.
1 != 1 -> 0
1 != 0 -> 1
1 != 1 != 1 -> 0 != 1 -> 1
So in a final example, given a 12 bit binary number -> 100110101101, which is 2477, the parities would be inserted like this
[1][2]1[4]001[8]1010110[16]1
Position 1 would XOR all bits in positions with 1 in position 1 of the position excluding the parity bit positions.
1: 1 - P
2: 10 - P
3: 11
4: 100
5: 101
6: 110
7: 111
8: 1000 - P
9: 1001
10: 1010
11: 1011
12: 1100
13: 1101
14: 1110
15: 1111
16: 10000 - P
17: 10001
So 1 would XOR positions 3, 5, 7, 9, 11, 13, 15, and 17.
[1][2]1[4]001[8]1010110[16]1
[1] = 1 XOR 0 XOR 1 XOR 0 XOR 0 XOR 1 XOR 1
There are 4 1's, making the first position 0 as 4 is even.
0[2]1[4]001[8]1010110[16]1
And you just keep going from there =). Now, when using this with save/load, the parity bits have to be tacked to the lowest placeholders because there can't be 0s in front.
100110101101[1][2][4][8][16]
Of course, when processing, the parity bits need to be moved back into their correct positions =).
So yea... back on track. Does anyone know a good way to store the version? The version doesn't have to be stored as the CRC either... I know how to do CRC checking without actually storing the CRC : ).
I'd have a big number and multiply the checksum in last. The checksum would be the checksum+version and the maximum would be checksum max + version max. The crc, first thing added in, would be the version. I'd divide the combined checksum version out at the back, get the checksum for the code, and subtract the retrieved checksum from the stored one to get the remaining version. After dividing out all of the values (left with crc), I'd compare the crc to the version that was left over from the checksum and make sure they were equal. This allowed me to store the version of the code in a much smaller space =).
I'm moving over to the Hamming Code for error detection, which is much, much better than a checksum (both smaller and 100% error detection). The only problem with this is that I now don't know how I should put in the version.
Any ideas?
For those who don't know, a the Hamming Code converts the number into binary and places a parity bit in every power of 2 position of the number. For example, a number of 8 digits would have a parity bit at 1, 2, 4, and 8 (all powers of 2). The parity bits are based on the xor of all of the digits with a 1 in the position of the parity bit's position. For example, 2 would require a 1 in position 2. Looking at 9 in binary, it's 1001. A 0 is in position 2 -> 10[0]1. However, the 9 would be used in the XOR for the first parity bit as a 1 is in position 1 -> 100[1].
For those who don't know what XOR is, XOR is true if there are an odd number of 1s and false if there are an even number of 1s.
1 != 1 -> 0
1 != 0 -> 1
1 != 1 != 1 -> 0 != 1 -> 1
So in a final example, given a 12 bit binary number -> 100110101101, which is 2477, the parities would be inserted like this
[1][2]1[4]001[8]1010110[16]1
Position 1 would XOR all bits in positions with 1 in position 1 of the position excluding the parity bit positions.
1: 1 - P
2: 10 - P
3: 11
4: 100
5: 101
6: 110
7: 111
8: 1000 - P
9: 1001
10: 1010
11: 1011
12: 1100
13: 1101
14: 1110
15: 1111
16: 10000 - P
17: 10001
So 1 would XOR positions 3, 5, 7, 9, 11, 13, 15, and 17.
[1][2]1[4]001[8]1010110[16]1
[1] = 1 XOR 0 XOR 1 XOR 0 XOR 0 XOR 1 XOR 1
There are 4 1's, making the first position 0 as 4 is even.
0[2]1[4]001[8]1010110[16]1
And you just keep going from there =). Now, when using this with save/load, the parity bits have to be tacked to the lowest placeholders because there can't be 0s in front.
100110101101[1][2][4][8][16]
Of course, when processing, the parity bits need to be moved back into their correct positions =).
So yea... back on track. Does anyone know a good way to store the version? The version doesn't have to be stored as the CRC either... I know how to do CRC checking without actually storing the CRC : ).