Though power of 2 word sizes look in hindsight like a natural consensus, historical computers used quite a wide variety, including but not limited to 9, 18, 36, 12, 24 and 60 bits.

Power-of-2 computers have tended to end up (leaving aside 8087's 80-bit extended precision) with a choice between 32 and 64-bit floating point formats.

A 12/24 bit computer, when implementing floating point, would naturally tend to 48 bits. Indeed, this precision was actually used in some cases even on power-of-2 computers: https://stackoverflow.com/questions/31928449/what-type-is-this-6-byte-48-bit-number-floating-point-integer

Would 48 bits be enough for most scientific and engineering applications (in a way that 32 is not), or would such a computer need to incur the cost of supporting a higher precision such as 96 bits?

  • 3
    For a float of a given width we can say both "It's enough" and "it's not enough". But 48 bit floats were common IIRC on Galaksija, C64, Apple II etc etc. so you may need to say more specifically what you're expecting of your float. Mar 12, 2018 at 13:20
  • 1
    The Roman numeral system didn't even know floating point. The Romans, however, tended to ignore that and did very "serious design and engineering work" with it.
    – tofro
    Mar 12, 2018 at 14:13
  • 1
    Again. Each of those would be done to whichever precision was appropriate for the task. On one day you may use low precision, on another high precision.
    – Chenmunka
    Mar 12, 2018 at 14:30
  • 2
    We can indeed say more. In my experience, occasionally, 64-bit FP is inadequate and you use arbitrary precision. Other times, you use integer arithmetic and scale everything. Is 48-bit adequate? Yes and no, it depends.
    – Chenmunka
    Mar 12, 2018 at 14:38
  • 3
    Turbo Pascal used a 48-bit floating-point type [1+15+32], and IMHO that would be the "right" type to use for most applications on processors without an FPU. On many such processors, computations with such types would be slightly more efficient than with IEEE single, and much more efficient than IEEE double. Too bad C doesn't allow implementations to define "double" in such fashion [it requires just a smidgen more precision than can be supported efficiently without an FPU].
    – supercat
    Mar 12, 2018 at 17:46

1 Answer 1


Just making a rough estimation, using:

  • 1 bit for the sign,

  • 8 bit for the exponent (range 10^-127 to 10^128)

would leave 39 bits for the mantissa. You need about 10 bits for 3 digits (2^10 is 1024), so you would have 12 digits precision in a range of 1x10-127 to 1x10128.

Seems enough for most things, I can imagine.

  • 4
    A more useful 48-bit type would be sign+exp15+mant32, using an explicit leading "1". On many FPU-less platforms, operations with a 32-bit mantissa which is stored in a word by itself will be much more efficient than operations on anything bigger.
    – supercat
    Mar 12, 2018 at 17:53
  • 3
    Incidentally, Turbo Pascal used a 48-bit floating-point type, and if C had included a long float type to which float values promote, and which whose precision could be anything between float and long double, implementations without FPUs could have processed such a type more efficiently than a 32-bit float.
    – supercat
    Nov 23, 2018 at 20:27

Not the answer you're looking for? Browse other questions tagged .