*I mean that as we know an int is stored as 4 octets, that means if we want to convert for example 18 to binary, it must contain 32 bits not just 5 bits (18 = 10010 bits)
This works to with any other type, string, float, double etc.... we don't have the number of bits that normally we must have, the majority of type is less. So please can you explain to me, I'm sure I miss something.
*
Imagine you have a device with a long set of wheels, each showing a digit from 0 to 9. You can set each digit to one of those 10 digits, and nothing else. Your task is to agree with your friend a way to pass across a list of numbers.
Your first idea is to simply set the numbers directly, and leave any spare wheels at 0. I give you the numbers 5, 7, and 3, so you set your wheels like this:
5 7 3 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
You pass it to your friend, and they read off "5", "7", "3".
But now I give you the numbers 18, 2006, and 0. So you set the wheels like this:
1 8 2 0 0 6 0 0 0 0 0 0 0 0 0 0 0 0 0 0
You pass it to your friend, and they're confused. Is that "1", "8", "2006"? Or perhaps it's "18", "200", "6"? They don't know where one number ends and the next begins.
So, you have an idea: if all numbers were the same length, you'd know where they began and ended. Fortunately, in our number system, "1", "01", "001", and "0001" all mean the same thing, so you can agree that all numbers will be 4 digits long. 18, 2006, 0 now looks like this:
0 0 1 8 2 0 0 6 0 0 0 0 0 0 0 0 0 0 0 0
You pass it over, and your friend reads off "0018, that's eighteen; 2006; 0000, that's zero". Success!
Our only problem is that we can't represent a number higher than 9999; so when we choose our fixed width, we need to decide on the highest number we want to be able to represent. More width, higher numbers; but more wasted space when we're working with smaller numbers.
When we talk about "32-bit integers" or "64-bit integers", we're talking about essentially the same idea, but instead of wheels that can be 0 to 9, we have some representation of bits that can be either 0 or 1.
So, to store the number 18, we work out the binary, 10010, and then somewhere in memory we write down a sequence of 32 bits:
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1 0
If we don't need very high numbers, and want to save space, we might make do with 16 bits, or even 8; if memory is cheap enough, we might use 64 bits to be able to have much higher numbers. But everyone reading and writing a particular set of numbers has to agree in advance what width to use.
Things get a bit more complicated if we want negative numbers, or fractions, but the aim is the same: by agreeing in advance how much space each number will take up, we know where one number begins and the next one ends.
Now let's think about strings.
Imagine we extend the earlier task to pass a word to your friend, using the same device. One way to do this is to devise a code where each letter is given a number: 1 for A, 2 for B, and so on. Then a string is just a sequence of numbers, using our earlier fixed length idea; we only need to go up to 26, so we'll choose a fixed width of 2 digits.
So given the word "HELLO", you would pass over 8, 5, 12, 12, 15 like this:
0 8 0 5 1 2 1 2 1 5 0 0 0 0 0 0 0 0 0 0
Your friend reads off the numbers, converts them to letters, and gets the word.
Let's make it more challenging: a word, followed by a number, for instance: "YEAR", 2006; or "AGE", 18.
2 5 0 5 0 1 1 8 2 0 0 6 0 0 0 0 0 0 0 0
0 1 0 7 0 5 0 0 1 8 0 0 0 0 0 0 0 0 0 0
Wait, is that "YEART" and then 600? Or maybe "YEARTF" and a zero? We're back to our original problem of knowing when things begin and end.
One solution is to use our fixed length trick again: let's say every word is five letters long, but if the letter value if "00", ignore it. Because we're not used to putting "zeroes" on the beginning of words, we decide to pad at the end instead of the beginning, but it doesn't really matter.
2 5 0 5 0 1 1 8 0 0 2 0 0 6 0 0 0 0 0 0
0 1 0 7 0 5 0 0 0 0 0 0 1 8 0 0 0 0 0 0
The problem is, words vary in length a lot more than numbers, so we'll often have to have quite a large width, and so waste a lot of space on smaller words.
But there's something interesting about our "00", it's essentially like a space in English writing. When we read, we know that as soon as we get to a space, that's the end of the word, so we can use the same trick with our 00.
2 5 0 5 0 1 1 8 0 0 2 0 0 6 0 0 0 0 0 0
0 1 0 7 0 5 0 0 0 0 1 8 0 0 0 0 0 0 0 0
That means we can write as much text as fits in our total number of spaces; for instance, to write "A", 99; "AA", 99; and "AAAAAAAA", 99:
0 1 0 0 9 9 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 1 0 1 0 0 9 9 0 0 0 0 0 0 0 0 0 0 0 0
0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 0 9 9
This is one of the common ways strings are stored in computers - in practice, it's not words we want to separate, but whole strings, so the "terminator" (normally all zero bits) is separate from a space (which in ASCII-compatible 8-bit encodings is 00100000),
One problem is that you have to "reserve" that special terminating character - you can't represent a string that has that sequence of bits in it. To get around that, there's a different trick we can use: instead of signalling the end of the string, we can send a separate marker for the length of the string.
For instance, our "YEAR" and "AGE" example becomes:
0 4 2 5 0 5 0 1 1 8 2 0 0 6 0 0 0 0 0 0
0 3 0 1 0 7 0 5 0 0 1 8 0 0 0 0 0 0 0 0
And our As and 9s:
0 1 0 1 9 9 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 2 0 1 0 1 9 9 0 0 0 0 0 0 0 0 0 0 0 0
0 8 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 9 9
The maximum length of a string is now determined by how wide we made the number representing the length - in this case, we have a two-digit length, so can represent string from 0 to 99 letters long.
I'm currently trying to convert 44/7 to half-precision floating point format.
I'm not sure if I've done it correctly so far, so I'd really appreciate it if someone could have a look at it.
44/7 = 6,285714285714...
6 in dual -> 110;
0.285714 * 2 = 0,571428 -> 0
0.571428 * 2 = 1.142856 -> 1
0.142856 * 2 = 0.285714 -> 0
... -> 0 1 0 0 1 0 0 1 0 0 1 0 0 1 0 0 1...
-> 110, 01001001001001
-> 1,1001001001001001 -> exponent: 2;
Bias + Exponent : 2+15 = 17 => 1 0 0 0 1
All stitched together: 0 1 0 0 0 1 1 0 0 1 0 0 1 0 0 1
I've never converted decimal to 16bit IEEE754, is this the correct way of converting it?
Thanks a lot!
Correct. As you might expect, it is quantized to 6.28515625.
0100011001001001(base 2) = 4649(base 16)
6.2857142857139996
= H(4649)
= F(40C92492)
= D(40192492 49249107)
= A(0X1.92492492491070P+2)
6.28515625
= H(4649)
= F(40C92000)
= D(40192400 00000000)
= A(0X1.92400000000000P+2)
Other data points:
+0. 0000
-0. 8000
-1. BC00
+1. 3C00
+2. 4000
+4. 4400
+8. 4800
+16. 4C00
+32768. 7800
+Max 7BFF 65504
+.5f 3800
+.25f 3400
+.125f 3000
+.0625f 2C00
+MinNorm 0400 +6.103515625e-05
-MinNorm 8400 -6.103515625e-05
+MinDenorm 0001 +5.9604644775390625e-08
-MinDenorm 8001 -5.9604644775390625e-08
+Infinity 7C00
-Infinity FC00
+NaN(0) 7E00
-NaN(0) FE00
I know that I can say convert a 2-input AND gate into a NOR gate by simply inverting the two inputs because of DeMorgan's Theorem.
But how would you do the equivalent on a 3-input AND gate?
Say...
____
A___| \
B___| )___
C___|____ /
I'm trying to understand this because my homework asks me to take a circuit and convert it using NOR synthesis to only use nor gates, and I know how to do it with 2 input gates, but the gate with 3 inputs is throwing me for a spin.
DeMorgan's theorem for 2-input AND would produce:
AB
(AB)''
(A' + B')'
So, yes, the inputs are inverted and fed into a NOR gate.
DeMorgan's theorem for 3-input AND would similarly produce:
ABC
(ABC)''
(A' + B' + C')'
Which is, again, inputs inverted and fed into a (3-input) NOR gate:
___
A--O\ \
B--O ) )O---
C--O/___ /
#SailorChibi has truth tables that show equivalence.
If i haven't made any mistakes it is pretty much the same, invert all 3 of the inputs and you get a NOR
Table:
AND with inverted in is exact the same as
1 1 1 = 1
1 1 1 = 0
1 0 1 = 0
0 1 0 = 0
0 1 1 = 0
0 1 0 = 0
0 0 1 = 0
0 0 0 = 0
NOR with original input
0 0 0 = 1
0 0 1 = 0
0 1 0 = 0
1 0 1 = 0
1 0 0 = 0
1 0 1 = 0
1 1 0 = 0
1 1 1 = 0
I have a fairly simple question that i cannot find an example of online. I understand that this can simplify to A^B but I have not yet covered that section. What is the correct value of the boolean expression (A'B + AB')?
Lets look at the truth table
A B A'B AB' A'B + AB'
-----------------------------
0 0 0 0 0
0 1 1 0 1
1 0 0 1 1
1 1 0 0 0
This simply computes the xor of A and B.
and hence this is our answer.
The definition of the symbol XOR (^) is a^b = a'b + ab', i.e. one or the other but not both must be true for the expression to be true. Therefore there are no intermediate steps to convert between the two expressions. This is because a'b and ab' are prime implicants of the boolean function.
Another (not necessarily more simplified) way to define XOR is (A+B).(A'+B')
A B A+B A' B' A'+B' (A+B).(A'+B')
----------------------------------------
0 0 0 1 1 1 0
0 1 1 1 0 1 1
1 0 1 0 1 1 1
1 1 1 0 0 0 0
is it possible to simply this Boolean function
(!A*!B*!C) + (!A*!B*C*!D) + (A*!B*!C*D) + (A*!B*C*!D) + (A*B*!C*!D)
I came up with this:
(!B*(!A*(!C+!D))+A*(C XOR D)) + (A*B*!C*!D)
Messy to look at, but there are fewer terms.
Look at the truth table:
A B C D X
0 0 0 0 1
0 0 0 1 1
0 0 1 0 1
0 0 1 1 0
0 1 0 0 0
0 1 0 1 0
0 1 1 0 0
0 1 1 1 0
1 0 0 0 0
1 0 0 1 1
1 0 1 0 1
1 0 1 1 0
1 1 0 0 1
1 1 0 1 0
1 1 1 0 0
1 1 1 1 0
It looks like you can take the three parts of the table where X = 1 and simplify this to the sum of three terms:
!A*!B*!(C*D) + A*!B*(C^D) + A*B*!C*!D
Note that I've use XOR (^) in the second term. If you can't use XOR then you'll need to expand the second term a little.
You can reduce the number of terms further by factoring out either !B or A for two of the terms, e.g.
!B*(!A*!(C*D) + A*(C^D)) + A*B*!C*!D
or:
!A*!B*!(C*D) + A*(!B*(C^D) + B*!C*!D)