In between the years, a PISA question (nothing essential): The last digit of 7^190
Show older comments
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.
1 Comment
"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:
Accepted Answer
Paul
on 28 Dec 2023
0 votes
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.
16 Comments
Alexander
on 28 Dec 2023
Paul
on 28 Dec 2023
Ok. Perhaps try one or both of the suggestions in my answer.
Dyuman Joshi
on 28 Dec 2023
@Paul, did you mean flintmax?
Alexander
on 28 Dec 2023
John D'Errico
on 28 Dec 2023
Edited: John D'Errico
on 28 Dec 2023
format long g
flintmax
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
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
realmax
certaainly falls into that domain, as beyond flintmax, but well below realmax. Here is the exact number, computed as a sym
sym(7)^190
And here is what the double precision version sees:
sym(7^190)
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.
@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
So we can get the answer by
d = [1 7 9 3];
d7tothe190 = d(mod(190,4)+1) % account for 1-based indexing
Alexander
on 28 Dec 2023
Dyuman Joshi
on 28 Dec 2023
Edited: Dyuman Joshi
on 28 Dec 2023
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.
"Not all numbers in the vicinity of large values can be exactly represented in double precision."
Though, it took me awhile to understand how double precision numbers worked, as can be observed by my 3rd question here.
It is a known limitation.
powermod(7, 190, 10)
powermod() is part of the Symbolic toolbox, but see also https://www.mathworks.com/matlabcentral/fileexchange/38516-powermod
Dyuman Joshi
on 28 Dec 2023
Edited: Dyuman Joshi
on 28 Dec 2023
"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
"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:
John D'Errico
on 28 Dec 2023
Edited: John D'Errico
on 28 Dec 2023
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
realmax == realmax - 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.)
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)
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
on 29 Dec 2023
"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.
@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
on 29 Dec 2023
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
on 29 Dec 2023
More Answers (0)
Categories
Find more on Region and Image Properties in Help Center and File Exchange
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!
