0

For the USACO training gateway exercise humble numbers, I have a solution that works for the first 4 test cases, but then for test case 5 which has been supplied below to circumvent the need for input files, my program gets the correct answer locally when compiled by GCC and on my phone ( not sure what compiler). If I submit the answer to USACO it does not give the correct answer. From what I read that means the program has some undefined behaviour somewhere, but I could not find anything.

#include <fstream>
#include <iostream>
#include <set>

using namespace std;

//ifstream fin("humble.in");
//ofstream fout("humble.out");

set<unsigned long> cont;

int main() {

    int K = 6;
    int N = 25000;
    unsigned long values[]= {2, 3, 5, 7, 11, 13};

    cont.insert(1);
    unsigned long r = 0;

    for (int i = 0; i <= N; i++) {
        r = *cont.begin();
        for (int j = 0; j < K; j++) 
            cont.insert(r*values[j]);
        cont.erase(r);
    }

    cout << r << endl;

    return 0;
}

The answer I get locally (and the correct answer) is 682628310. The answer I get on USACO is 67108864.

Shafik Yaghmour
  • 154,301
  • 39
  • 440
  • 740
Yadeses
  • 195
  • 1
  • 8
  • 3
    Try `long long` instead of just `long` if it's possible those numbers exceed 32-bit. Switching that gives the right answer in Visual Studio where just long does not. – Retired Ninja Oct 16 '18 at 13:27
  • 1
    Hmm, yeah seems like that works. Weird the problem states it should fit within a 32 bit unsigned long. – Yadeses Oct 16 '18 at 14:39
  • Perhaps there is another solution where you don't need to do the multiply, which is the likely cause of any overflow. – Gem Taylor Oct 16 '18 at 17:55
  • Turns out by unsigned long they meant long long. As long and int seem to be equivalent in c++. – Yadeses Oct 16 '18 at 18:05
  • The sizes of int, long, long long, vary depending on platform and implementation. – Gem Taylor Oct 16 '18 at 18:08

0 Answers0