In between the years, a PISA question (nothing essential): The last digit of 7^190

Last digit of 7^190, I thought a simple question if you have Matlab. But

fprintf('%f\n',7.0^190.0)

reports 4 as last digit, but it must be an odd number. 7^190 is fare away from realmax. Why that? It's not a big issue, only for my understanding.

[Stephen23]

"7^190 is fare away from realmax"

REALMAX is irrelevant.

The value is well above FLINTMAX (so, as the documentation states, your value is outside the range of consecutive integer values), so there is no expectation that your value will be represented accurately down to the ones:

https://www.mathworks.com/help/matlab/ref/flintmax.html

Answer 1

[Paul]

Well, if 7^190 is larger than realmax, then using double precison won't work to just try to compute it. You could try the Symbolic Math Toolbox. Or do some analysis and see the pattern in the last digit of 7^n for increments of n, and then figure out where the pattern would be for n == 190.

[Alexander]

7^190 = 3.7036e+160, realmax = 1.7977e+308. It's clear for me, when I exceed ralmax boundary, than I than there are inaccurancies. But 7^190 is fare away.

[Paul]

Ok. Perhaps try one or both of the suggestions in my answer.

[Dyuman Joshi]

@Paul, did you mean flintmax?

[Alexander]

Hi @Dyuman Joshi, no, I was dealing with double numbers. Does have flintmax an effect of my question?

[John D'Errico]

@Alexander

format long g
flintmax

ans = 
      9.00719925474099e+15

is the largest integer that is exactly, uniquely representable as a double. (There is also a flintmax for singles too.)

flintmax is the number

2^53-1

ans = 
      9.00719925474099e+15

Any number larger than that is not uniquely represented by a double. If we go any further, then we would find the least significant bits of that number are not perfectly known.

Note that flintmax is significantly less than realmax, by many orders of magnitude, so there are many numbers that double can represent, but only imperfectly. And we see that your number lies in the nether region, between the two boundaries.

7^190

ans = 
      3.7036300802816e+160

realmax

ans = 
     1.79769313486232e+308

certaainly falls into that domain, as beyond flintmax, but well below realmax. Here is the exact number, computed as a sym

sym(7)^190

ans = 

37036300802816027166397504837023132103935904664589688209993011047970173724580953468862621004041894128193388186915258951321654310122171416116357699953172946967249

And here is what the double precision version sees:

sym(7^190)

ans = 

37036300802816026017917201676324198784916119353248748160351881978039946084074545334861220526439049530753562341694871901345447895734391162141803321189399405789184

The two numbers are very different beyond about the 16th decimal digit. So it is certainly true that the double version would have mostly garbage for digits.

[Paul]

@Dyuman Joshi, I misintepreted what the OP meant by "far away" in the original question and must have had a brain cramp when I read the follow-up comment.

Anyway, one of the suggestions has already been shown by @John D'Errico. Another approach, which can actually be done with pencil and paper, is to see that that last digit of 7^n repeats in a cycle of four

n = 0:7;
7.^n

ans = 1×8

1 7 49 343 2401 16807 117649 823543

So we can get the answer by

d = [1 7 9 3];
d7tothe190 = d(mod(190,4)+1)  % account for 1-based indexing

d7tothe190 = 9

[Alexander]

Thanks @John D'Errico. I'll remember that in future. And hopefully nobody comes across with that issue in future. Is it a bug or intentionally?

[Dyuman Joshi]

Yes, that's the basic approach for getting the last digit, however, OP is asking why the output is wrong from the code used.

I'll reiterate the part from @John's response that answers that, for OP - Any number larger than that* is not uniquely represented by a double. If we go any further, then we would find the least significant bits of that number are not perfectly known.

*that means flintmax.

Incidently, my 1st question on MATLAB Answers was similar to this question as well.

"Not all numbers in the vicinity of large values can be exactly represented in double precision."

This was the statement given in the answer by @Steven Lord, which helped me understand the why.

Though, it took me awhile to understand how double precision numbers worked, as can be observed by my 3rd question here.

[Walter Roberson]

It is a known limitation.

powermod(7, 190, 10)

ans = 9

powermod() is part of the Symbolic toolbox, but see also https://www.mathworks.com/matlabcentral/fileexchange/38516-powermod

[Dyuman Joshi]

"Is it a bug or intentionally?"

That is a known limitation of double precision numbers.

"And hopefully nobody comes across with that issue in future."

It will be encountered if people try to use double precision numbers for representing numbers greater than flintmax.

What is the solution then? Use higher precision.

> Symbolic numbers via the Symbolic Math Toolbox.

> Big Integer from java.math library

> https://in.mathworks.com/matlabcentral/fileexchange/22725-variable-precision-integer-arithmetic by @John D'Errico

[Stephen23]

"What is the solution then? Use higher precision."

Considering that this is "a PISA question", the solution is to look at the final digits of powers of seven and notice the repeating pattern. @Alexander: try displaying the first ten or twelve powers of seven.

"the largest integer that is exactly, uniquely representable as a double"

is REALMAX:

https://stackoverflow.com/questions/1848700/biggest-integer-that-can-be-stored-in-a-double

[John D'Errico]

@Stephen23

NO. realmax is NOT the largest integer exactly, uniquely representable as a double. NOT. NOT.

Just because you read that on Stackoverflow does not add any credibility. That claim is flat out wrong.

realmax

ans = 1.7977e+308

realmax == realmax - 1

ans = logical
   1

Do you see that? I can subtract 1 from realmax, and as far as MATLAB is concerned, it sees the same number.

Any number beyond flintmax is not UNIQUELY represntable by a double. That is why it is called flintmax. It is the largest INTEGER that is uniquely representable as a float.

All of this stems from the fact that MATLAB (as well as a huge number of other languages) uses 52 binary bits to represent doubles. (plus a sign bit, and an exponent.)

@Alexander

It is not a bug. A feature is perhaps a better description. But even the word fature suggests something unintended. And all of this is completely understood and accepted by those who wrote MATLAB and any other language that uses floating point arithmetic.

Really, all of this is just a limitation of floating point arithmetic. A float can only encode a fixed number of binary digits. So once you go beyond the flintmax limit, there will be more than one integer that all essentially get assigned to any value encoded in that double.

For example,

x = 1e18;
x == x + (1:10:100)

ans = 1×10 logical array
   1   1   1   1   1   1   1   0   0   0

So I've chosen X as a number that explicitly exceeds flintmax. But there will be many other integers in that region, all of which implicitly get stuffed into the same bin.

[Dyuman Joshi]

"Considering that this is "a PISA question", the solution is to look at the final digits of powers of seven and notice the repeating pattern. It isn't hard."

@Stephen23 - I know it isnt hard, as I acknowledged Paul's use of the method mentioned in my comment.

And my point of using higher precision was not a response to how to get the last digit of XYZ, it was regarding how to deal with such large numbers.

[Stephen23]

@Dyuman Joshi: sorry, my comment was aimed at the OP. I modified my comment to make that clearer.

@John D'Errico: I am perfectly aware that the limited precision of binary floating point numbers necessarily means that multiple values (not just integers) map to REALMAX. That was not my point.

[Rik]

Though Steven is technically correct that realmax is the largest integer that can be represented by a double, stating this is not helpful, as people will misinterpret it. Realmax does represent an integer, but since multiple numbers will map to realmax, its uses are limited. If you want to guarantee the correct last digit, flintmax is the limit.

There have been efforts to implement the quad datatype in Matlab, though to my knowledge that didn't reach a practical state. That would push flintmax to 2^113-1 (if I understand it correctly). Still not enough for this question, but a lot better.

[Alexander]

Dear All, thank you very much for the many answeres which were helpful to understand this item. Also thank you for the link above and

Happy New Year