Welcome to Gaia! ::

Seeing as you haven't gotten to that part yet, I'll write a bit on binary-decimal converions. (You can copy it into your main post if needed, or let me know if my input is unwanted.)

III. Conversions

In binary, each place represents a power of two. So where in base 10, we would have the 1s, 10s, 100s, 1000s, 10000s and so on places, in binary there would be the 1s, 2s, 4s, 8s, and 16s places.

Converting from binary to decimal is a simple matter of adding up each place. For instance, take the number 11010. This means that it has 0 ones, 1 two, 0 fours, 1 eight, and 1 sixteen. 2+8+16=26, so the binary number 11010 is equivalent to the decimal number 26.

The reverse process is a little trickier, but follows the same basic pattern. Suppose we wish to convert 26 back into binary. First, we find the largest place. Because 32 is larger than 26, we start with the 16s place. There is one 16 in 26, so we put a "1" in the 16s place. Now because the 16 has already been recorded, we have 10 left. Moving on to the next biggest place, there is one 8. Of the remaining 2, there are no 4s, so a zero goes in that place. There is one 2 in 2 (duh), so a 1 goes in that place. Because there is zero left, we put zeroes in the remaining places. The conversion is complete, and we have the binary number 11010.

Note: This same method can be used to convert between decimal and any other base.

---

This is my first tutorial/reference/thingy, so any feedbac and criticism is much appreciated.

I've never heard of that one, but it certaintly works. It's less intuitive but simpler to explain/use.

as there's been already some interest I'll add a little bit about computer numeric.

How to code decimal numbers in binary (on a computer)

unsigned integers
This is the most simple case, it is pretty much what you've seen above. So there is not much too add about that. Just a few remarks on different kinds of them and which size they have.
nibble - (a halfbyte) consists of 4 bits
Byte - a byte consists of 8 bits and can have 256 different values
Word - the size of a word depends on the CPU of the computer, typical values today are 32 bits though modern PC CPUs may work in 64 bit-mode too.

char /short / int / long: these are types used in C (and other programming languages) to carry integer values. While typical sizes are 8/16/32/32, the only thing guaranteed is char <= short <= int <= long.

How much bits do you need to store n different values. Actually it's the logarithm to the base of 2. So to store 10 different values (e.g. for a decimal digit) you need 3,32 bits.
Note: to calculate the logarithmus dualis on a typical calculator which got no ld key you'd do the following procedure:
ld(n) = log(n)/log(2) <== ln would work too.
So for 10, enter the 10 into the calculator, press [log], press [/], enter 2, press [log]

signed integers
As we've seen already in a previous post, substraction is possible with binary numbers, which leads of course to the demand to be able to store negative numbers. There are 2 different ways to do this. Both rely on the variable to have a fixed number of bits.

- one complement
The one complement negates a number by simply inverting all bits. So +7 (00000111) gets to -7 (11111000). Substraction is done by inverting the number to substract with and adding it. A negative number number can be detected by the MSB (most significant byte [the leftmost]) being set.

So 10 - 12 = -2 gets to 10 + (-12) = -2

In binary that would be:
00001010 <-- 10
11110011 <-- -12
11111101 <-- -2

The advantage of this system is, that it is pretty easy to understand and to convert a positive number to negative and viceversa. The disadvantages are that we got +0 as well as -0 now (which makes things more complicated, e.g. when testing on equality of numbers), that we waist one of the possible numbers and also that adding units in the CPU will get a little bit more complex when using this design (compared to the twocomplement)

- twocomplement
To get the two complement of a number simply invert all bits (as you'd do for the onecomplement) and add 1 to it.
E.g. for -12

12 = b00001100
inverted that becomes 11110011
11110011
00000001 +
11110100

Advantages:
- there's only one zero, as inverting 0 will give you 11111111, after adding 1 that becomes
100000000
As we only got 8 bits to store the value in our example, the red bit is an overflow bit which may be ignored
- an 8 bit number goes from -128 to 127, thus using all 256 possible values

binary coded decimals
BCD means generally encoding a digit into 4 bits (there are also other ways, e.g. packed-BCD which i will cover later on). The conversion is D->B is pretty straight forward, take a digit convert that to binary as mentioned above. Back (B->D) is almost the same, take 4 bits and convert them to the corresponding decimal number.
Note: there are also other encoding schemes, e.g. Grey-Code, Excess-3-Code, which i won't cover here as wikipedia does already a good job in explaining them..

The advantage of BCD is that they are pretty easy to understand and that the rounding properties for amounts smaller than 1 are the same as you have in the decimal-system (something that is welcomed very much in financial applications).
The disadvantages are that circuitry to work with them is more complicated and that you need more memory by using them.
Note: I mentioned above that the necessary bits to be able to store 10 different digits are 3.32. As we can only use a bit or not use it, but never use a fraction of a bit, this means we are "waisting" 0.68 bits for each decimal digit.

fixed Point
All numbers we covered yet where whole numbers. This is of course not accurate enough for all calculation we may want to do, so some encoding schemes were needed to be able to get fractions. The most simple was using fixedpoint numbers. This actually means we invent an imaginary comma (imaginary because it isn't realy stored in the number). So if we need a number with 3 digits before and 2 digits after the radix point, we just use a number able to store 5 digits and keep the ###.## scheme in mind. When doing arithmetics there may be the need to apply some correction after the operation (for multiplication and division).
E.g.
6.32 would be stored as 632 and 3.16 would be stored as 316.
Addition:
6.32*100+3.16*100 = (6.32+3.16)*100=9.48*100
no correction was needed as the comma-correcting factor was only applied once in the result
(6.32*100) / (3.16*100) = 2 ==> corrected 2*100
As the 100 term get annihilated in the operation we need to reapply it
(6.32*100) * (3.16*100) = 19.9712 * (100*100) ==> corrected 19.97*100
The 100 term gets twice into the result, so we need to divide by 100. As the result would then be 19.9712*100 we got 2 excess digits after the comma, so we would need to round again.

Using fixedpoints has some numerical disadvantages though. Imagine the the format ######.## (0.00 to 999,999.99). If we'd add 750,000.00 to 300,000.00 we'd get 1,050,000.00, so we couldn't store the result in the same variable type we used for the operands. So we'd have an upperbound up to which we could do calculations, every operation that would yield higher results poses a problem.

floating point
For many applications it is easier not having to deal with upperbounds, that's where floatingpoint numbers come in place. A FP consists of a bit for the sign, some bits for the mantissa and some bits for the exponent (for a float with 32 bits that would be: S: 1 M: 23 E: cool .
Note: Floatingpoints have an upper and lower bound as well, but for type float (32bit) this is 1.2E-38 to 3.4E+38, for double (64bit) it would be 2.3E-308 to 1.7E+308
So we got a type now that can cover quite a big range of numbers. If you remember what was written about the integers though, you'll notice that we can store not even 8 digits in 24 bits for any number.
Note: ahh, i can hear you crying "but you said the mantissa is 23 bits wide" wink That's true, but we got a hidden bit. As FPs are always normalized (by shifting the exponent) to a form where the leading bit is always true, we don't need to store the value of the leading bit (that's equivalent to the scientific notation of numbers where the leading number will never be 0).
As we got bits to the right hand side of the comma point, we will obviously need a way to convert decimal fractions to binary fractions. So let's get into that. For integer values we know that each bit resembles a value, e.g. the first bit 2^0, the 8th bit 2^7 and so on. For fractions it is similar, the first bit after the comma is worth 2^-1 (0.5), the second 2^-2(0.25) and so on.
e.g. 1.5 gets to 1.1 which resembles 2^0+2^-1

You remember the modulo method i mentioned some post ago for the conversion from decimal to binary? Well for the fractions we got a similar method. Let's try it with 0.47

0.47 * 2 = 0.94 => 0 <--- the number we see left of the comma after the multiplication is the bitvalue.
0.94 * 2 = 1.88 => 1
0.88 * 2 = 1.76 => 1
0.76 * 2 = 1.52 => 1
0.52 * 2 = 1.04 => 1
0.04 * 2 = 0.08 => 0
0.08 * 2 = 0.16 => 0
0.16 * 2 = 0.32 => 0
0.32 * 2 = 0.64 => 0
0.64 * 2 = 1.28 => 1
0.28 * 2 = 0.56 => 0
0.56 * 2 = 1.12 => 1 <-- *
0.12 * 2 = 0.24 => 0
0.24 * 2 = 0.48 => 0
0.48 * 2 = 0.96 => 0
0.96 * 2 = 1.92 => 1
0.92 * 2 = 1.84 => 1
0.84 * 2 = 1.78 => 1
0.78 * 2 = 1.56 => 1
0.56 * 2 = 1.12 => 1
ouch, we got that 0.56 already above (*) so we know for sure that the binary number will have an endless cycle. It would be
.01111000010 10001111 10001111 10001111
As we got only 23 bits to store we'll loose some accuracy of course. To increase the incuracy we could use e.g. double instead (to get 15 significant digits) or long double (to get 19 significant digits).

You've seen the the noncyclic decimal 0.47 get to a rather long cyclic binary number. Actually that is something that happens rather often, as there are many numbers that can not be yielded by summing fractions of 2s potences. For the other direction (binary to decimal) we are guaranteed to not get a cyclic number as the result of summing fractions will never by a cyclic number if none of the fractions had a cyclic denominator.

Another effect we need to consider is the annihilation of small numbers. Imagine adding 10,000,000.00 to 1.01. The result 10,000,001.01 could not be stored in a 32bit float (with 6 significant digits), so we'd loose the 4 mostright numbers of the decimal when we would have used floats to calculate.

So when using floating point numbers always be on the watch for eventual accuracy problems. While this may not be a problem for adding the 12 wages you get a year (at least not for me, even the 6 digits of simple floats are good enought there for me), it can get a very serious problem in scientific and engineering applications (when you plan the course for an exploration satellite a small error could mean you are far off the track).

summary
Well you got the basics now, if you got more specific questions don't hesitate to ask. smile