SPOJ Problem Set (classical)

1030. Triple Fat Ladies

Problem code: EIGHTS

Pattern Matchers have been designed for various sorts of patterns. Mr. HKP likes to observe patterns in numbers. After completing his extensive research on the squares of numbers, he has moved on to cubes. Now he wants to know all numbers whose cube ends in 888.

Given a number k, help Mr. HKP find the 1st number larger than k whose cube ends in 888.

Input

The first line of the input contains an integer t, the number of test cases. t test cases follow.

Each test case consists of a single line containing a single integer k (1 ≤ k ≤ 20000).

Output

For each test case, output a single integer which denotes the 1st number larger than k whose cube ends in 888. The result will be less than 263.

I created the algorithm, and when I test it, it seems to work well. However, when I put it into the submissions, I got a 45.45/100. I created a program which showed what the tester input. Heres what I got:
11 --> This is t the rest is k.
1
200
500
753
102
Only 5/11 were output (explains the score). However, when I ran this, there were no issues, even when I put in numbers which might trip it up (20001, -19). Is the problem with my program, or the tester?

I created the algorithm, and when I test it, it seems to work well. However, when I put it into the submissions, I got a 45.45/100. I created a program which showed what the tester input. Heres what I got:

11 --> This is t the rest is k. 1 200 500 753 102

Only 5/11 were output (explains the score). However, when I ran this, there were no issues, even when I put in numbers which might trip it up (20001, -19). Is the problem with my program, or the tester?

We cut off output, partially to avoid situations such as the one you observed, where you attempt to print out the entire input file.
Generally speaking, if nearly 300 other people have solved the problem, and you have not, it's [i]probably[/i] (but not always!) not an issue with the grader.
I've personally verified that your solution is incorrect.
Incidentally, there is no need to enter impossible input. The problem states that the bounds are 1 <= k <= 20000, and so you need not test anything outside that range.

We cut off output, partially to avoid situations such as the one you observed, where you attempt to print out the entire input file.

Generally speaking, if nearly 300 other people have solved the problem, and you have not, it's probably (but not always!) not an issue with the grader.

I've personally verified that your solution is incorrect.

Incidentally, there is no need to enter impossible input. The problem states that the bounds are 1 <= k <= 20000, and so you need not test anything outside that range.

Premature optimisation is the root of all evil. Your approach is simply wrong -- you're reporting numbers that are cube roots of things ending in 888, but not necessarily the smallest ones greater than [i]k[/i].

Premature optimisation is the root of all evil. Your approach is simply wrong -- you're reporting numbers that are cube roots of things ending in 888, but not necessarily the smallest ones greater than k.