why does realmax('single') display 8 digits?

most texts agree that IEEE-754 sinlge persision has 7 signicant digits and double percision has 15

so why does realmax('single') display 8 digits and realmax('double') display 16 digits?

[Ameer Hamza]

I guess you are talking about flintmax() instead of realmax(). My answer is based on flintmax().

[Bruno Luong]

He talk about realmax

>> format long
>> realmax('single')

ans =

  single

   3.4028235e+38
   ^
   1 2345678 : 8 digits
   
>> realmax('double')

ans =

    1.797693134862316e+308
   ^
    1 234567890123456 : 16 digits

[Walter Roberson]

But that is just the current format output. The format output does not reliably display enough digits to reproduce the input for double.

[Bruno Luong]

Exactly he asks about format output.

the question is "realmax('single')" why you guys think he asks about "flintmax()"?

[Walter Roberson]

I am too accustomed to floating point, I would not have guessed that the question was about how many digits MATLAB happened to display.

[Stephen23]

"most texts agree that IEEE-754 sinlge persision has 7 signicant digits and double percision has 15"

Such a simplistic generalization is not very meaningful, because the behavior of binary floating point numbers is much more nuanced than that. For a start, you need to define what "precision" means to you:

• the precision of decimal values that map to distinct binary values?
• round-trip values binary->decimal->binary giving the same value?
• something else?

For an excellent introduction into this topic:

https://www.exploringbinary.com/decimal-precision-of-binary-floating-point-numbers/

https://www.exploringbinary.com/17-digits-gets-you-there-once-youve-found-your-way/

[Sean Doherty]

thanks

[Sean Doherty]

Thakyou Stephen. This clarifies things. I would have accepted your answer, but not offered that option

Answer 1

[Ameer Hamza]

"most texts agree that IEEE-754 sinlge persision has 7 signicant digits and double percision has 15"

But they don't. More precisely, they have 24 and 53 significant binary digits, respectively. Both are capable of representing 2^24 and 2^53 consecutive integers without any loss of precision. MATLAB just returns these values.

Note that it is still possible to represent even bigger integers with full precision, but the only issue is that the number adjacent to them cannot be represented precisely.

Read here: https://en.wikipedia.org/wiki/IEEE_754#Basic_and_interchange_formats. They are capable of representing ~7.22 and ~15.96 decimal digits respectively.

[Sean Doherty]

Thanks. OK, however I think it is true that single precision guarantees just 7 significant digits, in which case, realmin('single') digit 8 is not guaranteed significant?

[Ameer Hamza]

I guess you meant flintmax() again here.

Yes, the precision for all 8 digits integers is not guaranteed. However, anything less than 16777216 can be represented precisely.

[Bruno Luong]

Why should you care about how many digits realmax('single') displays? Simply use the value it returns.

Beside 24 bits mantissa of single number is more than 7 digits (7.22 as Ameer has mentioned), so the 8-bits display might be not exact but still more accurate than 7-digit, and it might also might be true for 9, 10 digits...

[Sean Doherty]

Significant digits are reliable. 7.22 sig digs means digit 8 is not guaranteed significant

[Sean Doherty]

The point applies to any SP/DP calculation... why display 8/16 digits when only guaranteed 7/15 significant digits

[Bruno Luong]

"significant" in which sense exactly?

All the 8th digit are still significant in this sense:

Look at this exampe:

1/9 is 0.11111111111... with 1 repeated forever

>> fprintf('%1.7f\n', single(1/9))
0.1111111
>> fprintf('%1.8f\n', single(1/9))
0.11111111

Or look at this exampe:

1/3 is 0.333333333... with 3 repeated forever

>> fprintf('%1.7f\n', single(1/3))
0.3333333
>> fprintf('%1.8f\n', single(1/3))
0.33333334

Granted the 8th digit is "4" and not "3" as expected but:

0.33333334 is 5 times closer to 1/3 than 0.3333333.

So yeah it not correct digit but still quite significant nonetheless.

Again why you care about what is displayed??? If you don't trust the 8 bit just ignore it when look at the screen, or specify the number of digits you think as "significant" with fprintf. It doesn't matter for any calculation or usage of the value.

[Ameer Hamza]

"why display 8/16 digits when only guaranteed 7/15 significant digits"

Because that is the purpose of flintmax(), it returns the maximum consecutive integer precisely represented by a floating-point data type. It does not have any mentions anything about the number of digits.

Also, as Bruno mentioned, why do you care how the number is displayed in base10? As long as it is accurately represented in computer memory, there should be no issue.

If integer precision is the primary concern, then why not use an integer data type, uint32 or uint64.

[Bruno Luong]

One more example, not because 8th digit is not warranty that beyond that the digits have no "signification":

>> x = single(2^(-24)); % eps(single(1))/2
>> fprintf('%1.20e\n', x);
5.96046447753906250000e-08 % this is exact result in digital
^
1 2345678901234567 <= obtained only after at least 17 digits, even for single

Feel free to truncate with 7 digits "5.960464e-8". You'll lost the correct 10 digit trailer "...4775390625".

[Sean Doherty]

OK, thanks folk

[Walter Roberson]

There are some "single" numbers (that do not have trailing 0) where entering only 7 digits decimal is enough to completely reproduce the number, but there are others where 8 digits decimal is required.

[Bruno Luong]

"but there are others where 8 digits decimal is required."

Like

flintmax('single')

Other one need 17 digits in my example of 2^(-24) or even more (up to 20 digits).

Limiting about 7-8 digits is just like see only the emerging side of an ice-berg, and pretend digits after the 8th are not significant is just plain wrong, at least from my point of view.

[Walter Roberson]

Given N digits of a single precision number, is entering those N digits enough to exactly reproduce the same bit pattern?

fprintf('%1.20e\n', single(5.960464e-8))

5.96046412226769461995e-08

fprintf('%1.20e\n', single(5.9604644e-8))

5.96046447753906250000e-08

So 7 input digits is not enough to completely preproduce 2^-24 but 8 input digits is. Therefor, this particular number has 8 significant decimal digits in single precision. But there are other values that use "all" of the digits (no trailing 0 in decimal) that 7 copied digits is enough.

Answer 2

[Walter Roberson]

>> flintmax('single')
ans =
  single
    16777216

You get 7 full digits, up to 9999999 . And there is some spare room beyond that, but not enough for a full digit. It is about 7.22 digits.