[SOLVED] Is there possibly an inconsistency in pow function? | Sololearn: Learn to code for FREE!
+ 14

[SOLVED] Is there possibly an inconsistency in pow function?

I was trying to enumerate powers of a certain number <N>. I am doing this by multiplying <N> by itself using a loop, so far it's fine. To verify the result, I generate what was supposedly the very same number by using pow(<N>, <counter> - 1). Everything looks fine in the beginning of the code output, but the few last numbers given by pow() function are different. I have tested this problem with a few (one-digit) numbers, but so far, the symptom showed in all the numbers I tested (except when <N> = 2) Am I doing something wrong in calling pow() or is it something inside? Here's the code, Thank you in advance 🙏 https://code.sololearn.com/c0ptmo2qCwxW/?ref=app

3rd Dec 2020, 4:45 AM
Ipang
16 ответов
+ 21
[3 of 3] So what has happend is the in the pow() function, it is only accurate to 16 significant digits, but if you use long long you can get more..... I think it makes a bit sense.. I know you have already got your answer but might this will help a bit more/less .. Hope helps a bit✌️
3rd Dec 2020, 5:38 AM
Piyush
Piyush - avatar
+ 19
[2 of 3] So what is the difference between "long long" and "int" that makes "long long" better to deal with big integers? Coz The long long takes twice as much memory as long...is this what you thought? Now see that a "double" takes as much memory as a "long long" - But some of that memory is used to hold the "matissa" and some the "exponent". The mantissa is 53 bits.So with 53 bits, you can only hold 15 or 16 decimal digits of precission. The 64 bits of the "long long" can hold 24 decimal digits of a number....
3rd Dec 2020, 5:37 AM
Piyush
Piyush - avatar
+ 18
Hii Ipang [1 of 3] Here's the output - $ ./main 1. 1 1 2. 5 5 3. 25 25 4. 125 125 5. 625 625 6. 3125 3125 7. 15625 15625 8. 78125 78125 9. 390625 390625 10. 1953125 1953125 11. 9765625 9765625 12. 48828125 48828125 13. 244140625 244140625 14. 1220703125 1220703125 15. 1808548329 -2147483648 Ok so the right hand column (the one with integer math) is wrong. and it is wrong after 15 counts!
3rd Dec 2020, 5:36 AM
Piyush
Piyush - avatar
+ 7
Seems interesting though. May be this is because the way pow() handles large numbers is different, and because of that, long long int are shown differently. When you are brute-forcing, its clear to you what you are doing, so you handle it correctly, but may be in pow() large numbers cause overflow sort of thing. [edit] As far my observation, as the numbers increase, the error increases by a larger factor.
3rd Dec 2020, 4:55 AM
Charitra
Charitra - avatar
+ 7
Ipang I'm saying, when you calculated answer using ur own method(bruteforce), then u got correct answer.
3rd Dec 2020, 5:06 AM
Charitra
Charitra - avatar
+ 7
Chiku Thanks to Coder Kitten rather me buddy! And I'm marking this thread solved now. I have come to a conclusion, that in C or C++, pow() function is the way for floating point numbers, but not so for integrals. We are better off with our own implementation 😁 Thanks to everyone who contributed 🙏
3rd Dec 2020, 5:25 AM
Ipang
+ 6
Thank you Coder Kitten for your answer. Really helpful ❤
3rd Dec 2020, 5:22 AM
Charitra
Charitra - avatar
+ 3
Chiku I'm raising this question because this problem makes me feel a bit insecure in using built-in function, while we are encouraged to avoid reinventing what was already available. Are you saying pow() function uses brute-forcing algorithm? I didn't get the second paragraph ...
3rd Dec 2020, 5:01 AM
Ipang
+ 3
Chiku If you mean the multiplication then yes, you are right! I checked the different numbers in Python and the result by multiplication was right, but the one by pow() was not. Thanks a bunch buddy! 🙏
3rd Dec 2020, 5:15 AM
Ipang
+ 3
Ipang thanks to u too for asking this cool question. It was really helpful.
3rd Dec 2020, 5:21 AM
Charitra
Charitra - avatar
+ 3
Ipang yup 🤘
3rd Dec 2020, 5:31 AM
Charitra
Charitra - avatar
+ 2
Piyush[21 Dec❤️] In Code Playground the first different output is obvious starting at 24th result (when using `long long` and <N> value 5). If we use `int` then different output starts earlier at 14th result (as you have shown). Did anyone notice how the powers of 5 (starting from 5**2) end with 25? is that a pattern or what? looks like powers of different <N> ends with different digits though 😁
3rd Dec 2020, 5:53 AM
Ipang
+ 2
Piyush[21 Dec❤️] I just saw your message FYI DMs don't work for me I can't reply 😁
3rd Dec 2020, 5:59 AM
Ipang
+ 2
Coder Kitten // 1 ends with <time limit warning> // 2 ends with sequence 2, 4, 8, 6 // 3 ends with sequence 3, 9, 7, 1 // 4 ends with sequence 4, 6 // 5 ends with 25 // 6 ends with sequence 6, 36, 16, 96, 76 // 7 ends with sequence 7, 9, 3, 1 // 8 ends with sequence 8, 4, 2, 6 // 9 ends with sequence 9, 1 5 and 10 are the ones with constants last digit(s). It's just looking different amongst other one-digit numbers tested, that's why it stands out 😁
3rd Dec 2020, 9:13 AM
Ipang
+ 2
Coder Kitten I also believed it is mathy under the hood, can't imagine myself digging that far knowing my limits 😂 Got a bad result at end for 11, didn't go higher than 11 because of it anyways. You tested 76?
3rd Dec 2020, 9:24 AM
Ipang
0
i cant find html code too
4th Dec 2020, 5:23 PM
Maruf