2004 Hsc (1 Viewer)

crammy90

Member
Joined
Mar 26, 2006
Messages
264
Gender
Male
HSC
2008
19
can some1 explain why the answer is a and not b
 

JMelouney

New Member
Joined
Sep 18, 2007
Messages
12
Location
Sydney
Gender
Male
HSC
2008
The same number of 0's and 1's swapped, so Checksum will not pick it up, as the number of 1's is still the same.

There is an odd parity being used, and the first and second bytes were corrupted.

In these two bytes there is an even number of ones, which will be picked up as an odd parity was chosen.

So, Parity will pick it up, Checksum won't
 

crammy90

Member
Joined
Mar 26, 2006
Messages
264
Gender
Male
HSC
2008
JMelouney said:
The same number of 0's and 1's swapped, so Checksum will not pick it up, as the number of 1's is still the same.

There is an odd parity being used, and the first and second bytes were corrupted.

In these two bytes there is an even number of ones, which will be picked up as an odd parity was chosen.

So, Parity will pick it up, Checksum won't
checksum finds integer values of all bytes/packets and of the data stream and adds etc...if the bits change the binary would change and thus the checksum value ?
is that how ur thinking Makro
 

Makro

Porcupine
Joined
May 16, 2006
Messages
415
Location
In between.
Gender
Male
HSC
2009
I was just thinking that checksum wouldn't change cos its still the same number of bits. and the parity stayed the same cos it was just swapped. :/
 

crammy90

Member
Joined
Mar 26, 2006
Messages
264
Gender
Male
HSC
2008
Makro said:
I was just thinking that checksum wouldn't change cos its still the same number of bits. and the parity stayed the same cos it was just swapped. :/
but checksum gets its sum by adding the unteger values of bytes and comparing it with the checmsum byte that was sent and if it doesnt match theres an error. Surely if bytes are changed then this wouldnt be the same number?
i actually think C now aha
partity check would find it. I think u think 1 byte went from 0000001 to 0000010 where 1 changed to a 0 and a 0 to a 1 in the same byte. This occured in 2 bytes so both their values have changed as so they both are incorrect. But then if these bytes have changed their positions of their 1, the integer value of them has changed and so would produce a different checmsum value :S
 

Makro

Porcupine
Joined
May 16, 2006
Messages
415
Location
In between.
Gender
Male
HSC
2009
nah, cos the parities stay the same. If they were already correct then making 1 a 0 and 0 a 1 keeps it the same.

Also, do note that a byte is a 8 bits, and you were looking at 3 bytes.
 

crammy90

Member
Joined
Mar 26, 2006
Messages
264
Gender
Male
HSC
2008
Makro said:
nah, cos the parities stay the same. If they were already correct then making 1 a 0 and 0 a 1 keeps it the same.

Also, do note that a byte is a 8 bits, and you were looking at 3 bytes.
i read the whole question wrong aha
"checksum is calculated by adding the number of 1 bits in the data bytes" did they just make that up for this q lol i didnt read that aha
silly mistakes
 

SamD

Member
Joined
Jul 21, 2002
Messages
256
Gender
Male
HSC
N/A
A very bodgy question that was the cause of much concern at the time (both teachers and students).

If you read it carefully it actually says
"The checksum is calculated by adding up the number of ‘1’ bits in the data bytes."
In this case there are 11 of these '1' bits which in binary is 1011. Therefore (A) is correct. Checksums are NEVER (apart from this strange question LOL) calculated like this.

Note that the first two bytes were corrupted and odd parity is being used.

HTH
Sam
 

Users Who Are Viewing This Thread (Users: 0, Guests: 1)

Top