2
\$\begingroup\$

I've seen the following table on Wikipedia: imgur

However I couldn't find an explanation regarding what "bits precision" and "number of decimal digits" are and how they are related. What do they mean exactly? How to convert between them?

Thanks

\$\endgroup\$
1
  • \$\begingroup\$ 'number of decimal digits' - how many accurate digits you have after comma, it is calculated based on 'bit precision' which tells you how many bits are used to remember that number (the part after comma). no need to convert anything here... \$\endgroup\$
    – zoran404
    Sep 10, 2014 at 15:24

3 Answers 3

1
\$\begingroup\$

Both of the two answers (JRE and Spehro Pefhany) are okay except IEEE floating point has an extra feature.

I hope it is clear that

2.3 x 10^2 = 23 x 10^1 = 230 x 10^0

It would create more work for the hardware if all three were valid (translated into base 2). For example two different bit patterns could be the same number.

So, IEEE mandates that the top bit of the mantissa is always 1. This is a normalised representation. Each number is only ever stored as one specific bit pattern.

Then, because the first bit is always 1, it is not stored. So the mantissa is actually 1 bit longer than stored because of this implied top 1 bit.

\$\endgroup\$
5
  • \$\begingroup\$ Since the bit conveys no information, the width of the mantissa for precision calculations need not consider the implied leading '1'. \$\endgroup\$ Sep 10, 2014 at 20:16
  • \$\begingroup\$ Why do you think "the bit conveys no information"? \$\endgroup\$
    – gbulmer
    Sep 10, 2014 at 20:17
  • \$\begingroup\$ Because it's always 1! \$\endgroup\$ Sep 10, 2014 at 20:18
  • \$\begingroup\$ @SpehroPefhany - the rule about normalising the number so that it is always one, and hence that implied bit, causes the number of significant digits to be bounded. Further, if you actually try to convert between a human-readable base 10 number and an IEEE representation, that bit is needed. Hence, I don't believe it can be ignored. \$\endgroup\$
    – gbulmer
    Sep 10, 2014 at 20:30
  • \$\begingroup\$ Okay, but if there's 24 bits (+1) of mantissa, there are only 2^24 possible values, not 2^25 (ignoring sign), so precision of the mantissa can't be better than 1 part in 2^24. \$\endgroup\$ Sep 10, 2014 at 20:38
0
\$\begingroup\$

Take an example: 2.5E3 that would be 2.5 *10^3. The 2.5 is known as the mantissa, 3 is known as the exponent.

With a floating point number, you have some certain number of bits to represent both of these things together.
For single precision floating point you have 32 bits to represent the mantissa and the exponent. The 32 available bits are split into 24 for the mantissa and 8 for the exponent. The 24 bits for the mantissa represent a decimal number.
The whole floating point number will only have 24 bits that are significant (that are non-zero.) This number (24) is also the bits of precision given in the table. The exponent then says how many zeros to add to the end. The largest number you can represent with 24 bits is 16777215. You have 7 digits that can represent anything from 0 to 9, and one digit that can only represent from 0 to 1 - this is the decimal precision.

As mentioned by Spehro Pefhany, you can calculate the number of digits of precision from the bits of precision by multiplying the bits of precision by ln(2)/ln(10) - for 24 bits that gives you 7.225 digits of precision when the binary number is printed in decimal form.

\$\endgroup\$
0
\$\begingroup\$

The number of bits can be converted to decimal digits by multiplying it by ln(2)/ln(10) ~= 0.3.

This assumes that the sign is handled similarly in each case.

A number that can vary from 0 to 99.9 in increments of 0.1 has a precision of log2(100/0.1) ~=10 bits (binary digits) and a decimal precision of log10(100/0.1) = 3 decimal digits.

Similarly the precision in any given base n is logn(100/0.1). If n = 16 (hex) the precision is ~2.5 nibbles.

I used the example of 99.9 and 0.1 increment because the bits in a floating point number mantissa do not directly represent the magnitude (they have to be multiplied by two raised to the power of the exponent- or left/right shifted a number of times dependent on the exponent value.

If the mantissa is 24 bits, then it can represent 2^24 different values and it has a precision of log10(2^24) = 7.2 decimal digits. If you think of it as a fraction from 0 to 1 it could only move in increments of 1/2^24 or 0.00000005960. That's a little hard to visualize, perhaps, so I used the decimal example.

In the case of a typical pocket calculator, they actually do work in decimal internally, so you will get an 'even' number of digits precision. For example, an 8-digit calculator would have a precision of about 25.6 bits (inefficiently represented in 32 bits internally usually because calculators use binary coded decimal).

\$\endgroup\$
3
  • \$\begingroup\$ Sorry. Now I get the conversion between bits precision and decimal precision, but I don't get the thing about 0.1... Is it to say that a number that can vary from 0 to 9999 in increments of 0.1 has a decimal precision of 4 decimal digits? It actually makes sense if I think in terms of "there are four digits" in 9999. But why do we specifically use "increments of 0.1" here? Is it because "1000/0.1 = 10000" and log10(10000) = 4? Thanks! \$\endgroup\$
    – xji
    Sep 10, 2014 at 15:43
  • \$\begingroup\$ Could you provide a cite for pocket calculators using decimal numbers internally? The only thing I can find suggests that calculators use 4 bit processors (cheap pocket calculators) or ARM or or even 8 bit cPUs (Z80 and similar) - I find nothing that says that calculators use decimal numbers internally. \$\endgroup\$
    – JRE
    Sep 10, 2014 at 17:42
  • \$\begingroup\$ @JRE They use BCD numbers internally. The 4-bit processors (eg. TMS1000 derivatives) were nibble-serial BCD. Even up to the HP41, BCD is used internally. It would make little sense in the early resource-starved years to convert to and from binary. Nowadays there are some boutique calculators that are ARM based, but they are very much the exception and they're not your "four banger" type. Another reason to use BCD is that subtraction of numbers in decimal is exact so you don't have unpleasant things happening like 12.121 - 11.121 - 1 = 0.000000003. Ref: hpmuseum.org/techcpu.htm \$\endgroup\$ Sep 10, 2014 at 19:47

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.