# Why is float the default in the majority of languages?

In programming languages, for represent numbers you have (mainly) two types: `Int(s)` and `floats`.

The us of `Int` is very easy. However floats cause a lot of unexpected surprises:

http://anh.cs.luc.edu/python/hands-on/3.1/handsonHtml/float.html

I wonder why is not used a decimal-based type make more sense as the default for literals and normal math?

Where normal math is more precise?

-
One reason is that you can easily fake a decimal type at the application level using `int`. Faking `float` is much more difficult. – Steven Burnap Aug 24 '13 at 20:46
I know at least 2 languages that have a BCD type, they are COBOL and 370-Assembler. You could try them. – ott-- Aug 24 '13 at 20:47
@StevenBurnap Faking a fixed-point decimal number if easy with an `int`. But so is a fixed-point binary number, I'd wager. A decimal floating-point number (yes, that's a thing) is hard too. And in any case, this is only an argument for having a built-in implementation, not for making said implementation the default. – delnan Aug 24 '13 at 20:51
@delnan - that is just plain wrong. A decimal floating point number is not too hard. For example, look at .Net's System.Decimal (just decimal in C#) – Dave Hillier Aug 24 '13 at 20:54
@DaveHillier I didn't say "too hard", I said "hard". I can't judge whether it's exactly as hard to implement as a binary float (the naive, slow, inaccurate algorithms are probably more familiar as we're used to base 10), but it's nowhere as simple as a fixed-point format. – delnan Aug 24 '13 at 20:58

Languages which are using a single representation of numbers are relatively rare. As statically typed I can think only of some basic variants, and even in the dynamically typed realm I know more which are using at least integers and float than a unique format. Those who are came relatively late in the game and the choice of binary floating point is probably the result of the fact that binary floating point was already available in hardware and as type in the implementation language of their interpreter.

Now, why binary floating point has become the method of choice for type modelling real numbers?

If you want a type to modelize real numbers while using a constant size of a few words, you have the choice between fixed point and floating point numbers. Other kind of representation for rational numbers (fixed point and floating point are able to represent only rational number and a few other value like infinities -- which aren't real numbers BTW) exist but they are less widely useful.

Fixed point representations have some advantages, but they have one big issue: there is no good default for the number of digits after the point, so all languages and libraries which provide them ask the programmer to choose in the context of their application.

Floating point representations don't have that problem: once the size is fixed, you can come up with a repartition between the significand (often improperly called the mantissa) and the exponent good enough that allowing to customize it brings more problems than it would solve.

You may wonder why one has chosen a binary floating point format (BFP in the following of the discussion) instead of a decimal one. Decimal floating point (DFP) has one (and none more) advantage over binary: it can represent exactly real constant as we usually write them, in decimal. All other problems of BFP are also problems of DFP, but they may be hidden for simple enough computations by the advantage above (you get the exact result because the computation is so simple that all results -- final and intermediary -- are exactly representable).

DFP has some disadvantages of his own. Some properties of real numbers are also properties of BFP, but not of DFP (the most obvious is that (a+b)/2 may be outside the closed interval [a, b] with DFP) and because of that and for some other reasons, analysis of numerical properties of algorithms is more difficult for DFP than for BFP. Worse, error bound achievable with DFP are worse than one achievable with BFP for a given representation size. Implementing DFP is more difficult than implementing BFP (not so much that it has any importance nowadays, but it was a factor -- both of complexity and achievable performance -- when the trend was set). Finally for scientific computing -- historically the major consumer of FP -- the advantage of DFP is not pertinent, while all its disadvantages are.

So you got BFP in the hardware because it was what people needing FP wanted, and although some language definitions allow for DFP, implementations rarely use the possibility and prefer to use what the hardware provides.

-
IMHO, I think the majority of the times a number is used for counting (for i=1 to 10), specify a value (age = 10) and basic arithmetic (+-*/). But look like is expected something more complex than that? – mamcx Aug 24 '13 at 21:02
For the few languages which are using a unique number type, the direct availability of binary FP in hardware and in C probably explain it. – AProgrammer Aug 24 '13 at 21:23
Decimal floating point formats are pretty nasty in a lot of ways, since they require frequent expensive normalization and denormalization steps. The simple act of subtracting two numbers will frequently require that one be divided by a power of ten prior to the subtraction, and may then require that the result be multiplied by a power of ten. Such division and multiplication is much more expensive than shifting. – supercat Oct 23 '14 at 1:39
@supercat, floating point, whatever the base, implies normalization and denormalization steps. – AProgrammer Oct 23 '14 at 6:53
@AProgrammer: Yes, but division and multiplication is much more expensive than shifting. – supercat Oct 23 '14 at 14:47

Languages use binary floating point numbers because that's what the hardware usually provides. Very few CPUs have instructions for handling decimal floating point numbers, and the adoption of the IEEE 754 appears to have fixed the decision for the future.

-
+1 for mentioning the hardware; often a very significant factor in any decision. – Le Comte du Merde-fou Aug 25 '13 at 14:19
I started on IBM S/370 machines, which had hex-point floats, not binary-point. That and EBCDIC sensitized you to per-machine differences :-) – Ross Patterson Aug 25 '13 at 19:09

Floating point numbers are a tradeoff between precision and accuracy. They are notable for their ability to handle very wide numeric ranges, with reasonable accuracy. They are therefore considered a "one size fits all" type.

If you take a floating point number, and constrain its range to those numbers that can be represented by the mantissa only, you can treat it like an integer for accuracy purposes (in other words, you won't get the weirdness you would normally get from floats; you can compare them exactly in an `if` statement, for example).

This is why Lua chose a floating point as its default data type; in a sense, you can get the best of both worlds.

-
.NET's `decimal` is only one possible decimal type. I haven't implemented one myself but I really doubt this is inherent to base 10 - in other words, I think one could have a decimal floating point type with a range comparable to IEEE 754 (but the same issues at that magnitude, of course). – delnan Aug 24 '13 at 20:30
@delnan: Anything is possible, given enough bits. The `decimal` type in .NET uses actual base 10 arithmetic. – Robert Harvey Aug 24 '13 at 20:33
So how does your answer address the question, as none of the facts you present disqualify base 10 floating point numbers as default data type? – delnan Aug 24 '13 at 20:34
See the fourth and fifth paragraphs. – Robert Harvey Aug 24 '13 at 20:35
Those paragraphs explain why some languages get away without a separate integer type, not why both those languages and those with a separate int type default to binary floating point. – delnan Aug 24 '13 at 20:36