Hamming Distance in Block Parity - hamming-distance

I´m sitting here and I´m not able to solve a problem related to the hamming distance.
I have a block like this:
When I use the vertical redundancy Check now I get:
||| |
because I add an 1 to each row and column, if I have an odd number of 1´s or I add an 0 to each row and column, if i have an odd number of 0´s.
Now I should have 6 words right?
w1: 1001
w2: 0000
w3: 1110
w4: 1010
w5: 0011
w6: 0011
Are the created (through VRC) bits words too? So are 1000 and 0110 words too?
If I compare the words and check the Hamming Distance, I get an minimal Hamming Distance of 2 (0 should not count, because if the Hamming Distance is 0, the words are the same). E.g. compare w1 and w2.
In our lecture, the professor said, that the Hamming Distance for this example is 3. How can it be 3?!
Were is my mistake? :-(
I hope someone can help me.
Have a great Sunday!


MATLAB binary systems [duplicate]

I'm in a computer systems course and have been struggling, in part, with Two's Complement. I want to understand it but everything I've read hasn't brought the picture together for me. I've read the wikipedia article and various other articles, including my text book.
Hence, I wanted to start this community wiki post to define what Two's Complement is, how to use it and how it can affect numbers during operations like casts (from signed to unsigned and vice versa), bit-wise operations and bit-shift operations.
What I'm hoping for is a clear and concise definition that is easily understood by a programmer.
Two's complement is a clever way of storing integers so that common math problems are very simple to implement.
To understand, you have to think of the numbers in binary.
It basically says,
for zero, use all 0's.
for positive integers, start counting up, with a maximum of 2(number of bits - 1)-1.
for negative integers, do exactly the same thing, but switch the role of 0's and 1's (so instead of starting with 0000, start with 1111 - that's the "complement" part).
Let's try it with a mini-byte of 4 bits (we'll call it a nibble - 1/2 a byte).
0000 - zero
0001 - one
0010 - two
0011 - three
0100 to 0111 - four to seven
That's as far as we can go in positives. 23-1 = 7.
For negatives:
1111 - negative one
1110 - negative two
1101 - negative three
1100 to 1000 - negative four to negative eight
Note that you get one extra value for negatives (1000 = -8) that you don't for positives. This is because 0000 is used for zero. This can be consider as Number Line of computers.
Distinguishing between positive and negative numbers
Doing this, the first bit gets the role of the "sign" bit, as it can be used to distinguish between positive and negative decimal values. If the most significant bit is 1, then the binary can be said to be negative, where as if the most significant bit (the leftmost) is 0, you can say discern the decimal value is positive.
"One's compliment" negative numbers just flips the sign bit, then counts from 0. But this approach has to deal with interpreting 1000 as "negative zero" which is confusing. You generally only have to worry about this when working close to the hardware.
I wonder if it could be explained any better than the Wikipedia article.
The basic problem that you are trying to solve with two's complement representation is the problem of storing negative integers.
First consider an unsigned integer stored in 4 bits. You can have the following
0000 = 0
0001 = 1
0010 = 2
1111 = 15
These are unsigned because there is no indication of whether they are negative or positive.
Sign Magnitude and Excess Notation
To store negative numbers you can try a number of things. First, you can use sign magnitude notation which assigns the first bit as a sign bit to represent +/- and the remaining bits to represent the magnitude. So using 4 bits again and assuming that 1 means - and 0 means + then you have
0000 = +0
0001 = +1
0010 = +2
1000 = -0
1001 = -1
1111 = -7
So, you see the problem there? We have positive and negative 0. The bigger problem is adding and subtracting binary numbers. The circuits to add and subtract using sign magnitude will be very complex.
What is
1001 +
Another system is excess notation. You can store negative numbers, you get rid of the two zeros problem but addition and subtraction remains difficult.
So along comes two's complement. Now you can store positive and negative integers and perform arithmetic with relative ease. There are a number of methods to convert a number into two's complement. Here's one.
Convert Decimal to Two's Complement
Convert the number to binary (ignore the sign for now)
e.g. 5 is 0101 and -5 is 0101
If the number is a positive number then you are done.
e.g. 5 is 0101 in binary using twos complement notation.
If the number is negative then
3.1 find the complement (invert 0's and 1's)
e.g. -5 is 0101 so finding the complement is 1010
3.2 Add 1 to the complement 1010 + 1 = 1011.
Therefore, -5 in two's complement is 1011.
So, what if you wanted to do 2 + (-3) in binary? 2 + (-3) is -1.
What would you have to do if you were using sign magnitude to add these numbers? 0010 + 1101 = ?
Using two's complement consider how easy it would be.
2 = 0010
-3 = 1101 +
-1 = 1111
Converting Two's Complement to Decimal
Converting 1111 to decimal:
The number starts with 1, so it's negative, so we find the complement of 1111, which is 0000.
Add 1 to 0000, and we obtain 0001.
Convert 0001 to decimal, which is 1.
Apply the sign = -1.
Like most explanations I've seen, the ones above are clear about how to work with 2's complement, but don't really explain what they are mathematically. I'll try to do that, for integers at least, and I'll cover some background that's probably familiar first.
Recall how it works for decimal: 2345 is a way of writing 2 × 103 + 3 × 102 + 4 × 101 + 5 × 100.
In the same way, binary is a way of writing numbers using just 0 and 1 following the same general idea, but replacing those 10s above with 2s. Then in binary, 1111is a way of writing 1 × 23 + 1 × 22 + 1 × 21 + 1 × 20and if you work it out, that turns out to equal 15 (base 10). That's because it is 8+4+2+1 = 15.
This is all well and good for positive numbers. It even works for negative numbers if you're willing to just stick a minus sign in front of them, as humans do with decimal numbers. That can even be done in computers, sort of, but I haven't seen such a computer since the early 1970's. I'll leave the reasons for a different discussion.
For computers it turns out to be more efficient to use a complement representation for negative numbers. And here's something that is often overlooked. Complement notations involve some kind of reversal of the digits of the number, even the implied zeroes that come before a normal positive number. That's awkward, because the question arises: all of them? That could be an infinite number of digits to be considered.
Fortunately, computers don't represent infinities. Numbers are constrained to a particular length (or width, if you prefer). So let's return to positive binary numbers, but with a particular size. I'll use 8 digits ("bits") for these examples. So our binary number would really be 00001111or 0 × 27 + 0 × 26 + 0 × 25 + 0 × 24 + 1 × 23 + 1 × 22 + 1 × 21 + 1 × 20
To form the 2's complement negative, we first complement all the (binary) digits to form 11110000and add 1 to form 11110001but how are we to understand that to mean -15?
The answer is that we change the meaning of the high-order bit (the leftmost one). This bit will be a 1 for all negative numbers. The change will be to change the sign of its contribution to the value of the number it appears in. So now our 11110001 is understood to represent -1 × 27 + 1 × 26 + 1 × 25 + 1 × 24 + 0 × 23 + 0 × 22 + 0 × 21 + 1 × 20Notice that "-" in front of that expression? It means that the sign bit carries the weight -27, that is -128 (base 10). All the other positions retain the same weight they had in unsigned binary numbers.
Working out our -15, it is -128 + 64 + 32 + 16 + 1 Try it on your calculator. it's -15.
Of the three main ways that I've seen negative numbers represented in computers, 2's complement wins hands down for convenience in general use. It has an oddity, though. Since it's binary, there have to be an even number of possible bit combinations. Each positive number can be paired with its negative, but there's only one zero. Negating a zero gets you zero. So there's one more combination, the number with 1 in the sign bit and 0 everywhere else. The corresponding positive number would not fit in the number of bits being used.
What's even more odd about this number is that if you try to form its positive by complementing and adding one, you get the same negative number back. It seems natural that zero would do this, but this is unexpected and not at all the behavior we're used to because computers aside, we generally think of an unlimited supply of digits, not this fixed-length arithmetic.
This is like the tip of an iceberg of oddities. There's more lying in wait below the surface, but that's enough for this discussion. You could probably find more if you research "overflow" for fixed-point arithmetic. If you really want to get into it, you might also research "modular arithmetic".
2's complement is very useful for finding the value of a binary, however I thought of a much more concise way of solving such a problem(never seen anyone else publish it):
take a binary, for example: 1101 which is [assuming that space "1" is the sign] equal to -3.
using 2's complement we would do this...flip 1101 to 0010...add 0001 + 0010 ===> gives us 0011. 0011 in positive binary = 3. therefore 1101 = -3!
What I realized:
instead of all the flipping and adding, you can just do the basic method for solving for a positive binary(lets say 0101) is (23 * 0) + (22 * 1) + (21 * 0) + (20 * 1) = 5.
Do exactly the same concept with a negative!(with a small twist)
take 1101, for example:
for the first number instead of 23 * 1 = 8 , do -(23 * 1) = -8.
then continue as usual, doing -8 + (22 * 1) + (21 * 0) + (20 * 1) = -3
Imagine that you have a finite number of bits/trits/digits/whatever. You define 0 as all digits being 0, and count upwards naturally:
Eventually you will overflow.
We have two digits and can represent all numbers from 0 to 100. All those numbers are positive! Suppose we want to represent negative numbers too?
What we really have is a cycle. The number before 2 is 1. The number before 1 is 0. The number before 0 is... 99.
So, for simplicity, let's say that any number over 50 is negative. "0" through "49" represent 0 through 49. "99" is -1, "98" is -2, ... "50" is -50.
This representation is ten's complement. Computers typically use two's complement, which is the same except using bits instead of digits.
The nice thing about ten's complement is that addition just works. You do not need to do anything special to add positive and negative numbers!
Two complement is found out by adding one to 1'st complement of the given number.
Lets say we have to find out twos complement of 10101 then find its ones complement, that is, 01010 add 1 to this result, that is, 01010+1=01011, which is the final answer.
Lets get the answer 10 – 12 in binary form using 8 bits:
What we will really do is 10 + (-12)
We need to get the compliment part of 12 to subtract it from 10.
12 in binary is 00001100.
10 in binary is 00001010.
To get the compliment part of 12 we just reverse all the bits then add 1.
12 in binary reversed is 11110011. This is also the Inverse code (one's complement).
Now we need to add one, which is now 11110100.
So 11110100 is the compliment of 12! Easy when you think of it this way.
Now you can solve the above question of 10 - 12 in binary form.
Looking at the two's complement system from a math point of view it really makes sense. In ten's complement, the idea is to essentially 'isolate' the difference.
Example: 63 - 24 = x
We add the complement of 24 which is really just (100 - 24). So really, all we are doing is adding 100 on both sides of the equation.
Now the equation is: 100 + 63 - 24 = x + 100, that is why we remove the 100 (or 10 or 1000 or whatever).
Due to the inconvenient situation of having to subtract one number from a long chain of zeroes, we use a 'diminished radix complement' system, in the decimal system, nine's complement.
When we are presented with a number subtracted from a big chain of nines, we just need to reverse the numbers.
Example: 99999 - 03275 = 96724
That is the reason, after nine's complement, we add 1. As you probably know from childhood math, 9 becomes 10 by 'stealing' 1. So basically it's just ten's complement that takes 1 from the difference.
In Binary, two's complement is equatable to ten's complement, while one's complement to nine's complement. The primary difference is that instead of trying to isolate the difference with powers of ten (adding 10, 100, etc. into the equation) we are trying to isolate the difference with powers of two.
It is for this reason that we invert the bits. Just like how our minuend is a chain of nines in decimal, our minuend is a chain of ones in binary.
Example: 111111 - 101001 = 010110
Because chains of ones are 1 below a nice power of two, they 'steal' 1 from the difference like nine's do in decimal.
When we are using negative binary number's, we are really just saying:
0000 - 0101 = x
1111 - 0101 = 1010
1111 + 0000 - 0101 = x + 1111
In order to 'isolate' x, we need to add 1 because 1111 is one away from 10000 and we remove the leading 1 because we just added it to the original difference.
1111 + 1 + 0000 - 0101 = x + 1111 + 1
10000 + 0000 - 0101 = x + 10000
Just remove 10000 from both sides to get x, it's basic algebra.
Many of the answers so far nicely explain why two's complement is used to represent negative number, but do not tell us what two's complement number is, particularly not why a '1' is added, and in fact often added in a wrong way.
The confusion comes from a poor understanding of the definition of a complement number. A complement is the missing part that would make something complete.
The radix complement of an n digit number x in radix b is, by definition, b^n-x.
In binary 4 is represent by 100, which has 3 digits (n=3) and a radix of 2 (b=2). So its radix complement is b^n-x = 2^3-4=8-4=4 (or 100 in binary).
However, in binary obtaining a radix's complement is not as easy as getting its diminished radix complement, which is defined as (b^n-1)-y, just 1 less than that of radix complement. To get a diminished radix complement, you simply flip all the digits.
100 -> 011 (diminished (one's) radix complement)
to obtain the radix (two's) complement, we simply add 1, as the definition defined.
011 +1 ->100 (two's complement).
Now with this new understanding, let's take a look of the example given by
Vincent Ramdhanie (see above second response)
/* start of Vincent
Converting 1111 to decimal:
The number starts with 1, so it's negative, so we find the complement of 1111, which is 0000.
Add 1 to 0000, and we obtain 0001.
Convert 0001 to decimal, which is 1.
Apply the sign = -1.
end of Vincent */
Should be understood as
The number starts with 1, so it's negative. So we know it is a two's complement of some value x. To find the x represented by its two's complement, we first need find its 1's complement.
two's complement of x: 1111
one's complement of x: 1111-1 ->1110;
x = 0001, (flip all digits)
apply the sign -, and the answer =-x =-1.
It is a clever means of encoding negative integers in such a way that approximately half of the combination of bits of a data type are reserved for negative integers, and the addition of most of the negative integers with their corresponding positive integers results in a carry overflow that leaves the result to be binary zero.
So, in 2's complement if one is 0x0001 then -1 is 0x1111, because that will result in a combined sum of 0x0000 (with an overflow of 1).
2’s Complements: When we add an extra one with the 1’s complements of a number we will get the 2’s complements. For example: 100101 it’s 1’s complement is 011010 and 2’s complement is 011010+1 = 011011 (By adding one with 1's complement) For more information
this article explain it graphically.
I read a fantastic explanation on Reddit by jng, using the odometer as an analogy.
It is a useful convention. The same circuits and logic operations that
add / subtract positive numbers in binary still work on both positive
and negative numbers if using the convention, that's why it's so
useful and omnipresent.
Imagine the odometer of a car, it rolls around at (say) 99999. If you
increment 00000 you get 00001. If you decrement 00000, you get 99999
(due to the roll-around). If you add one back to 99999 it goes back to
00000. So it's useful to decide that 99999 represents -1. Likewise, it is very useful to decide that 99998 represents -2, and so on. You have
to stop somewhere, and also by convention, the top half of the numbers
are deemed to be negative (50000-99999), and the bottom half positive
just stand for themselves (00000-49999). As a result, the top digit
being 5-9 means the represented number is negative, and it being 0-4
means the represented is positive - exactly the same as the top bit
representing sign in a two's complement binary number.
Understanding this was hard for me too. Once I got it and went back to
re-read the books articles and explanations (there was no internet
back then), it turned out a lot of those describing it didn't really
understand it. I did write a book teaching assembly language after
that (which did sell quite well for 10 years).
I liked lavinio's answer, but shifting bits adds some complexity. Often there's a choice of moving bits while respecting the sign bit or while not respecting the sign bit. This is the choice between treating the numbers as signed (-8 to 7 for a nibble, -128 to 127 for bytes) or full-range unsigned numbers (0 to 15 for nibbles, 0 to 255 for bytes).
I had the same problem a couple of weeks ago. I ended up reading about it on-line from various sources, trying to put the pieces together, and writing about it myself just to make sure that I understood it correctly. We use two's complement for mainly two reasons:
To avoid multiple representations of 0
To avoid keeping track of carry bit (as in one's complement) in case of an overflow.
Carrying out simple operations like addition and subtraction becomes easy.
If you want a more detailed explanation of the matter at hand, try the article written by me here. Hope it helps!
The word complement derives from completeness. In the decimal world the numerals 0 through 9 provide a complement (complete set) of numerals or numeric symbols to express all decimal numbers. In the binary world the numerals 0 and 1 provide a complement of numerals to express all binary numbers. In fact The symbols 0 and 1 must be used to represent everything (text, images, etc) as well as positive (0) and negative (1).
In our world the blank space to the left of number is considered as zero:
In a computer storage location there is no blank space. All bits (binary digits) must be either 0 or 1. To efficiently use memory numbers may be stored as 8 bit, 16 bit, 32 bit, 64 bit, 128 bit representations. When a number that is stored as an 8 bit number is transferred to a 16 bit location the sign and magnitude (absolute value) must remain the same. Both 1's complement and 2's complement representations facilitate this.
As a noun:
Both 1's complement and 2's complement are binary representations of signed quantities where the most significant bit (the one on the left) is the sign bit. 0 is for positive and 1 is for negative.
2s complement does not mean negative. It means a signed quantity. As in decimal the magnitude is represented as the positive quantity. The structure uses sign extension to preserve the quantity when promoting to a register [] with more bits:
[0101]=[00101]=[00000000000101]=5 (base 10)
[1011]=[11011]=[11111111111011]=-5(base 10)
As a verb:
2's complement means to negate. It does not mean make negative. It means if negative make positive; if positive make negative. The magnitude is the absolute value:
if a >= 0 then |a| = a
if a < 0 then |a| = -a = 2scomplement of a
This ability allows efficient binary subtraction using negate then add.
a - b = a + (-b)
The official way to take the 1's complement is for each digit subtract its value from 1.
1'scomp(0101) = 1010.
This is the same as flipping or inverting each bit individually. This results in a negative zero which is not well loved so adding one to te 1's complement gets rid of the problem.
To negate or take the 2s complement first take the 1s complement then add 1.
Example 1 Example 2
0101 --original number 1101
1's comp 1010 0010
add 1 0001 0001
2's comp 1011 --negated number 0011
In the examples the negation works as well with sign extended numbers.
1110 Carry 111110 Carry
0110 is the same as 000110
1111 111111
sum 0101 sum 000101
1110 Carry 00000 Carry
0110 is the same as 00110
-0111 +11001
---------- ----------
sum 0101 sum 11111
Notice that when working with 2's complement, blank space to the left of the number is filled with zeros for positive numbers butis filled with ones for negative numbers. The carry is always added and must be either a 1 or 0.
REFERENCE: https://www.cs.cornell.edu/~tomf/notes/cps104/twoscomp.html
I invert all the bits and add 1. Programmatically:
// in C++11
int _powers[] = {
int value=3;
int n_bits=4;
int twos_complement = (value ^ ( _powers[n_bits]-1)) + 1;
2's complement of a given number is the no. got by adding 1 with the 1's complement of the no.
suppose, we have a binary no.: 10111001101
It's 1's complement is : 01000110010
And it's 2's complement will be : 01000110011
To bitwise complement a number is to flip all the bits in it. To two’s complement it, we flip all the bits and add one.
Using 2’s complement representation for signed integers, we apply the 2’s complement operation to convert a positive number to its negative equivalent and vice versa. So using nibbles for an example, 0001 (1) becomes 1111 (-1) and applying the op again, returns to 0001.
The behaviour of the operation at zero is advantageous in giving a single representation for zero without special handling of positive and negative zeroes. 0000 complements to 1111, which when 1 is added. overflows to 0000, giving us one zero, rather than a positive and a negative one.
A key advantage of this representation is that the standard addition circuits for unsigned integers produce correct results when applied to them. For example adding 1 and -1 in nibbles: 0001 + 1111, the bits overflow out of the register, leaving behind 0000.
For a gentle introduction, the wonderful Computerphile have produced a video on the subject.
You can also use an online calculator to calculate the two's complement binary representation of a decimal number: http://www.convertforfree.com/twos-complement-calculator/
The simplest answer:
1111 + 1 = (1)0000. So 1111 must be -1. Then -1 + 1 = 0.
It's perfect to understand these all for me.

Excel - top 3 including negative

I've written a formula to find "top 3" in terms of impact, so looking at negative numbers too. The formula is this, and feels more convoluted than it should be. Does anyone know if there is something I'm missing that would make this easier?
To provide some explanation, right now I have two "large" functions that find the 3 largest and 3 lowest numbers. I then put those into a positive list and again find the top 3 but use the below formula to determine if the value should be negative or positive.
=ROUND(IF(INDEX($K$18:$K$23, MATCH(LARGE($J$18:$J$23,$J26), $J$18:$J$23,0)) = "neg", -LARGE($J$18:$J$23,$J26), LARGE($J$18:$J$23,$J26)),0)
Data Negative?
350 neg
100 neg
25 neg
Rank Top 3
1 -350
2 150
3 -100

Weka - Classification and Regression Trees

I have run Classification and Regression Trees (trees.REPTree)
on the housing.arff data (with 66% Percentage Split). This is the outcome.
RM < 6.84
| LSTAT < 14.8
| | LSTAT < 9.75 : 25.15 (88/21.02) [47/55.38]
What do values at leaves (25.15, 88/21.02 etc) mean?
I've tried to reverse-engineer an answer, and if I get more definitive information I will update this.
I ran a very small tree on a Toyota Corolla dataset (predicting price of a used car). Here is the tree:
Age_08_04 < 32.5
| Weight < 1297.5 : 18033.54 (121/6009564.12) [59/6768951.55]
| Weight >= 1297.5 : 27945.83 (3/10945416.67) [3/22217291.67]
Age_08_04 >= 32.5
| Age_08_04 < 57.5 : 11363.26 (296/2827594.01) [144/2999066.05]
| Age_08_04 >= 57.5 : 8636.94 (537/1487597.91) [273/1821232.47]
The first numbers in the leaf nodes (18033, 27945, 11363, 8636) are the predicted prices for these cars.
The second and fourth numbers add up to the number of instances:
121 + 59 + 3 + 3 ...+273 = 1436, the number of instances in the entire set.
The second numbers add up to 957 (two third of the instances) and the fourth numbers add up to 479 (one third of the instances).
Witten et al's book (Data Mining: Practical Machine Learning Tools and Techniques, 4th edition), in section 6.1 (Decision Trees: Error Estimating Error Rates) notes
"One way of coming up with an error estimate is the standard
verification technique: hold back some of the data originally given
and use it as an independent test set to estimate the error at each
node. This is called reduced-error pruning." (Kindle location 5403)
So I think it's doing that 2/3, 1/3 split on the data, even though we're also doing 10-fold cross-validation.
The third and fifth numbers (after the /) seem to be MSEs. Doing a bit of algebra, the weighted average of the fifth numbers is consistent with the Root mean squared error and Root relative squared error reported in the cross-validation summary. (not quite exact, but I don't think I'd expect it to be)
Again, if I find out more information I will update this answer -- and I'd be happy to get more definitive information from others.

good way to match two vectors when order is relevant

I have two vectors (v1,v2) containing coordinates. Theoretically, these vectors should have the same length, and matching pairs (v1(1)~v2(1), ... v1(n)~v2(n)). however, in reality, sometimes data points are missing in either of the vectors. so I could have to skip 3 lines in v1, or 1 line in v2, etc. if we have 'used' v2(20) in a match, the next possible index is greater than 20.
How can I find the correct matching of the two?
I thought about calculating distances (because the coordinates should be approximately equal) ... but I'm not sure how to determine the best match.
and this approach does not seem too elegant to me. any elegant suggestions?
I tried k-nearest neighbours, which only works in part because there is no restriction on order and I have duplicates in my vectors.
I'm using MATLAB, maybe there already exists a useful function?
v1 v2
0 100 (a) 100 -50
150 -220 (b) -10 90 (a)
-280 -200 (c) -20 100
-330 330 160 -200 (b)
300 220 (d) -240 -200 (c)
350 400 (e) 320 250 (d)
-100 -300 (f) 320 250
-150 -250 320 380 (e)
0 -250 (g) -110 -320 (f)
0 -100 0 -250 (g)
I wrote letters next to correct matches
okay, I think the following should work, will implement tomorrow. still open to suggestions.:
while not found
see if v1(i) matches v2(i+a)
if it doesn't, swap v1 and v2 and increase a, comparing from a=0 upto a=x
I hope the following help you:
It seems like you need to compute the Dynamic Time Warping (DTW) between the two sequences X and Y. DTW will find the minimum-error warping, i.e. a path that matches each point of X with one point of Y.
There are many DTW tutorials (check for pdfs, youtube videos) and matlab code that you can check.
Depending on your problem, you may need to change a few things in DTW, in order to handle the missing data in the way it suits best your application.
Check also the Edit Distance, it uses similar principles as DTW and may give you a better idea of how sequences are matched.
Good luck!

Doubleword-length 2’s complement representation of Binary number?

Doing my first assignment in Assembler and this is the question posed...
1.Find the doubleword-length 2’s complement representation of each of the following decimal numbers. (Steps of getting your results must be displayed, otherwise you get zero point.)
a -100
b -55555
I have a very foreign professor that I completely can't understand so I'm in need of some assistance. So a doubleword would be 32 bits which would make...
A) 0000|0000|0000|0000|0000|0001|0000|0000 (1 at beginning for negative|0001 for 1|0000 for 0|0000 for 0|leading 0's for filler.
b) 1000|0000|0000|0101|0101|0101|0101|0101 (1 at beginning for negative| 00000000 for filler 0's|the rest 0101 for 5's.
Given that's somehow correct, the 2's complement would be..
I don't know. I learn by examples and my professor didn't do any. If anyone could run through one for me I'd be very grateful. I know there are calculators out there that will convert decimals to their twos compliment but I want to know HOW to do it. Thanks again.
Way off track. Remember they were decimal numbers, you can't just suddenly pretend they're hexadecimal (and use nibbles), and "just putting a 1 at the beginning" is about as far removed from two's complement as you can be.
So let's begin at the start, convert 100 and 55555 to binary. Subtract the highest power of two that will go into it, set the corresponding bit to 1. So for 100:
100 - 64 = 36, set bit 1000000
36 - 32 = 4, set bit 100000
4 - 4 = 0, set bit 100
------- +
Or 0x64 in hexadecimal. 55555 is just more of the same.
You've probably learned (or should have learned) the identity -x = ~x + 1, using that it's simple to negate 100 and 55555. Take the binary representation, as wide as you want the result to be (32 bits), so
0000 0000 0000 0000 0000 0000 0110 0100
Invert all the bits:
1111 1111 1111 1111 1111 1111 1001 1011
Add 1:
1111 1111 1111 1111 1111 1111 1001 1100
Or 0xFFFFFF9C in hexadecimal.
I SO wish that someone had explained this to me in simpler terms a long time ago.
How the "Two's Complement" Thing Works...
Step One: Turn the number into a binary string of 1 and 0 bits
Step Two: Flip all those bits
Step Three: Add one to that result
Two quick examples, in 8-bit integers
Decimal Number: 37
Make it Hex: 025h
Make it Binary: 0010 0101
Flip those bits: 1101 1010
Add binary one: 0000 0001
Get this result: 1101 1011
That is the 8 bit representation of the integer, negative 37 (decimal)
Example, the other way
Decimal Number: -41 (that's negative 41)
Make it Hex: 0D7h
Make it Binary: 1101 0111
Flip those bits: 0010 1000
Add binary one: 0000 0001
Get this result: 0010 1001
That is the 8 bit representation of the integer, 41 decimal (i.e., positive 41)
Incidentally, as an exercise, you can hit the same value with two's compliment all day along and the value with just flip back and forth between the negative and positive number.
As for 16 bit, 32 bit, and 64 bit numbers, you just extend it to the higher bits.