0
#include <iostream>
#include <math.h>
#include <algorithm>

using namespace std;

int main() {
    int t, c1, c2, res;
    string str1, str2;

    cin >> t;

    for (int i = 0; i < t; i++) {
        c1 = c2 = res = 0;
        cin >> str1 >> str2;
        c1 = count(str1.begin(), str1.end(), '1');
        c2 = count(str2.begin(), str2.end(), '1');
        cout << (long)(((pow(10, c1) - 1) / 9) * ((pow(10, c2) - 1) / 9)) << '\n';
    }
}

For input:

1
11111 11111

Output is:

123454321

but, here is the problem,

For input:

1
10101 10100

Output is:

1220

Also, for

1
11000 11000

Output: 

120

I'm not getting why long is subtracting 1 from the final answer if the length of answer is less than 4?

Note: Here, input string is of length <= 10^5

JeJo
  • 30,635
  • 6
  • 49
  • 88
Arihant Bedagkar
  • 97
  • 1
  • 9
  • 3
    `pow` works on floating point numbers. `(long)` converts floating point numbers to a `long` by truncating them – Justin Aug 16 '18 at 05:15
  • Did you mean to cast each of the exponential terms to long before using them, e.g. in a division? – Mad Physicist Aug 16 '18 at 05:16
  • Possible duplicate of [cast variable to int vs round() function](https://stackoverflow.com/questions/11128741/cast-variable-to-int-vs-round-function) – Justin Aug 16 '18 at 05:17
  • no, just the final result... so that it wouldn't be represented in exponential form – Arihant Bedagkar Aug 16 '18 at 05:17
  • Also possible duplicate of https://stackoverflow.com/q/2044124/1896169 – Justin Aug 16 '18 at 05:18
  • what is the reason behind losing the last bit if length is <= 4? – Arihant Bedagkar Aug 16 '18 at 05:19
  • 1
    @Scheff: This is not a floating-point precision issue. The calculations the OP asks about are perfectly computable with floating-point with no error. The problem is their `pow` implementation is returning inaccurate results when exact results are representable and are returned by a good `pow` implementation. If `strcmp` failed because a bad implementation handled integers incorrectly, you would not say it was an integer arithmetic problem; you would say it is a `strcmp` bug. So if a bad `pow` implementation causes a problem, it is a `pow` bug, not a floating-point problem. – Eric Postpischil Aug 16 '18 at 06:52
  • @EricPostpischil Reading your comment, I must admit I have to agree. May be, I have the idea established to hard in my brain concerning "never trust `double` too much". ;-) (Time to re-think and learn for me.) – Scheff's Cat Aug 16 '18 at 06:59
  • 1
    @AlanBirtles: This is not a duplicate of that. – Eric Postpischil Aug 16 '18 at 07:09
  • Which compiler are you using? Which version? – Eric Postpischil Aug 16 '18 at 07:10

1 Answers1

2

Some pow implementations return inaccurate results even when exact results are representable. Microsoft’s pow implementation is notorious for this.

In (long)(((pow(10, c1) - 1) / 9) * ((pow(10, c2) - 1) / 9)), pow is returning a value slightly less than the correct value, such as returning 99999.999999999985448084771633148193359375 instead of 100000. This results in the rest of the arithmetic producing a value slightly less than 1221 instead of 1221. When that is converted to long, the fraction is truncated, producing 1220.

Ideally, enough people would complain to Microsoft about this, or other publishers of bad pow routines, that they would fix it.

Given that the problem exists, you can work around it by rounding the pow result to the nearest integer (as with the round function) or by writing your own power routine to suit your purposes.

Eric Postpischil
  • 195,579
  • 13
  • 168
  • 312
  • Tested the Microsoft implementation for all combinations of `pow(10, int <= 15)` and it is perfectly accurate. So the problem described in the question can't come from `pow()` – Michael Veksler Aug 16 '18 at 07:06
  • 1
    @MichaelVeksler: Which version did you test? Which version did the OP use? Microsoft might have finally fixed it. – Eric Postpischil Aug 16 '18 at 07:09
  • 1
    Yes, you seem to be correct. There must have been a bug in MS's `pow()` which they have fixed, since the code works flawlessly in VS 2015 (both release and debug). So they must have fixed their bug in `pow()` – Michael Veksler Aug 16 '18 at 07:20