float (the C# alias for System.Single) and double (the C# alias for System.Double) are floating binary point types. float is 32-bit; double is 64-bit. In other words, they represent a number like this:

10001.10010110011

The binary number and the location of the binary point are both encoded within the value.

decimal (the C# alias for System.Decimal) is a floating decimal point type. In other words, they represent a number like this:

12345.65789

Again, the number and the location of the decimal point are both encoded within the value – that's what makes decimal still a floating point type instead of a fixed point type.

The important thing to note is that humans are used to representing non-integers in a decimal form, and expect exact results in decimal representations; not all decimal numbers are exactly representable in binary floating point – 0.1, for example – so if you use a binary floating point value you'll actually get an approximation to 0.1. You'll still get approximations when using a floating decimal point as well – the result of dividing 1 by 3 can't be exactly represented, for example.

As for what to use when:

• For values which are "naturally exact decimals" it's good to use decimal. This is usually suitable for any concepts invented by humans: financial values are the most obvious example, but there are others too. Consider the score given to divers or ice skaters, for example.

• For values which are more artefacts of nature which can't really be measured exactly anyway, float/double are more appropriate. For example, scientific data would usually be represented in this form. Here, the original values won't be "decimally accurate" to start with, so it's not important for the expected results to maintain the "decimal accuracy". Floating binary point types are much faster to work with than decimals.

Regarding to the official documentation, we have the next diferences:

• FLOAT - Floating-Point Types (Approximate Value), uses four bytes
• DOUBLE - Floating-Point Types (Approximate Value), uses eight bytes
• DECIMAL - Fixed-Point Types (Exact Value)

You can ask about differences between floating and fixed datatypes, but this is not so easy to describe, try to read the same official documentation, or this article, for example.

Biggest difference is the Double is a 64-bit and Decimal is not..... In addition:

Scientific notation (e) for Doubles is not supported.

Also, currency fields in salesforce are Decimals. The scale (number of digits to the right of decimal point) can be set for a Decimal, but cannot for a Double. This is important for currency and other calculations (division). Doubles do not have this option. You'll find that Doubles have a limited number of methods available to them compared to Decimals. Unless you know that you're dealing with very large numbers requiring a high degree of precision, Decimals will generally be a better choice.

Here is a good discussion on the issue from people way more experienced in the ins and outs than me:

From Peter Knoll:

According to the primitive data type docs currency fields are automatically assigned the type Decimal. Double is 64-bit. I'm not sure what Decimal is behind the scenes. It might be BigDecimal like or something else

From Rich Unger (Regarding the type of Decimal a decimal is:

For example, with Java you should never use floating point representations to handle monetary calculations, but instead use BigDecimal, and, as you stated you need to be careful with the comparisons. The same goes for Apex with respect to Double

SF Decimal is a BigDecimal

Run the following in Exec Anon and you'll see what I mean.

Double zeroPointZeroOne = 0.01;

Double sum = 0.0;
for (Integer i = 0; i < 10; i++) {
    sum += zeroPointZeroOne;
}

// 0.09999999999999999
System.debug('Double sum=' + sum); 

Decimal zeroPointZeroOneD = 0.01;
Decimal sumD = 0.0;
for (Integer i = 0; i < 10; i++) {
    sumD += zeroPointZeroOneD;
}

// 0.1
System.debug('Decimal sumD=' + sumD);

Comparing floating-point values

Its important to note that in the above Decimal example, in declaring Decimal sumD = 0.0;, the scale was set to 1, meaning 0.099 would be rounded up to 0.1 and 0.01 would be rounded down to 0.0. The default rounding would round 0.05 down to 0.0.

This is what I found when I had this doubt.

Use with AImysql> create table numbers (a decimal(10,2), b float);
mysql> insert into numbers values (100, 100);
mysql> select @a := (a/3), @b := (b/3), @a * 3, @b * 3 from numbers \G
*************************** 1. row ***************************
  @a := (a/3): 33.333333333
  @b := (b/3): 33.333333333333
@a + @a + @a: 99.999999999000000000000000000000
@b + @b + @b: 100

The decimal did exactly what's supposed to do on this cases, it truncated the rest, thus losing the 1/3 part.

So for sums the decimal is better, but for divisions the float is better, up to some point, of course. I mean, using DECIMAL will not give you a "fail proof arithmetic" in any means.