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:


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.
    – user53141
    Commented Aug 24, 2013 at 20:46
  • 1
    I know at least 2 languages that have a BCD type, they are COBOL and 370-Assembler. You could try them.
    – ott--
    Commented Aug 24, 2013 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.
    – user7043
    Commented Aug 24, 2013 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#) Commented Aug 24, 2013 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.
    – user7043
    Commented Aug 24, 2013 at 20:58

3 Answers 3


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
    Commented Aug 24, 2013 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. Commented Aug 24, 2013 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
    Commented Oct 23, 2014 at 1:39
  • 1
    @supercat, floating point, whatever the base, implies normalization and denormalization steps. Commented Oct 23, 2014 at 6:53
  • @AProgrammer: Yes, but division and multiplication is much more expensive than shifting.
    – supercat
    Commented Oct 23, 2014 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. Commented Aug 25, 2013 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 :-) Commented Aug 25, 2013 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.

See Also
How Lua handles both integer and float numbers?

  • .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).
    – user7043
    Commented Aug 24, 2013 at 20:30
  • @delnan: Anything is possible, given enough bits. The decimal type in .NET uses actual base 10 arithmetic. Commented Aug 24, 2013 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?
    – user7043
    Commented Aug 24, 2013 at 20:34
  • See the fourth and fifth paragraphs. Commented Aug 24, 2013 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.
    – user7043
    Commented Aug 24, 2013 at 20:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.