Python O(1):
Since the challenge has been specified to be using Big O. I concluded that the best way to do it(since the upper bound is limited by a constant) is to just to create a giant look-up array.
However, this program would be too big to post here, so I made a program that generates it:
def zeroesUpToN(n):
zeros = 0
for i in range(n):
s = str(i+1)
zeros += s.count('0')
return zeros
s = "print(["
for i in range(10^10000):
s += str(zeroesUpToN(i+1)) + ",";
s = s[:-1] + "][int(input())])"
print(s)
So, this will ALWAYS take a long time to run(I mean the resulting program, not the generating program. The generating program would take even longer). But, how long it takes to run will not depend on n. Therefore, by definition it is an O(1) solution.
Here is an actual program that works for smaller outputs(up to 200):
print([0,0,0,0,0,0,0,0,0,1,1,1,1,1,1,1,1,1,1,2,2,2,2,2,2,2,2,2,2,3,3,3,3,3,3,3,3,3,3,4,4,4,4,4,4,4,4,4,4,5,5,5,5,5,5,5,5,5,5,6,6,6,6,6,6,6,6,6,6,7,7,7,7,7,7,7,7,7,7,8,8,8,8,8,8,8,8,8,8,9,9,9,9,9,9,9,9,9,9,11,12,13,14,15,16,17,18,19,20,21,21,21,21,21,21,21,21,21,21,22,22,22,22,22,22,22,22,22,22,23,23,23,23,23,23,23,23,23,23,24,24,24,24,24,24,24,24,24,24,25,25,25,25,25,25,25,25,25,25,26,26,26,26,26,26,26,26,26,26,27,27,27,27,27,27,27,27,27,27,28,28,28,28,28,28,28,28,28,28,29,29,29,29,29,29,29,29,29,29,31][int(input())])
The real one is obviously much bigger.
P.S This is the problem with Big O problems.
EDIT: Oops, I forgot to give credit to @user2509848 whom I actually stole the code for generating each N.
7How are you going to measure the speed of the submissions? – Howard – 2014-01-09T18:42:47.477
Most efficient algorithm. – Xinbi – 2014-01-09T19:11:18.150
2@Xinbi
most efficient
isn't particularly well defined. Do you mean in Big O complexity? Benchmark? If we measure straight time, it's unfair if I have an 8 core processor and parallelise this. – Cruncher – 2014-01-09T19:26:33.973I did mean Big O complexity. I'm not interested in the CPU power of the machine it's running on. I'm interested in the algorithm that solves the problem. – Xinbi – 2014-01-09T19:57:45.533
@Xinbi In that case, you're very likely to get ties. Do you have a tie breaking condition? – Cruncher – 2014-01-09T20:21:20.217
4I got an O(1) solution. Do I win now? xD – Cruncher – 2014-01-09T21:03:48.287
4I agree with @Cruncher's approach to game a Big-O challenge with a massive lookup table. It's foolish to not freely spend a free resource if it helps your answer. RAM, code space, and setup time, in this problem specification, are all free. A pure lookup approach may be practically impossible but a hybrid solution of lookup/computation could be the best in practical implementation. – Darren Stone – 2014-01-09T22:38:26.787
You might limit program size to get the actual computation, without too much lookup. In that case, be specific about the bound. – MvG – 2014-01-09T23:13:04.863
Relevant Euler problem... I solved it years ago, my code works for all other digits except zero, so it needs some refactoring.
– swish – 2014-01-10T00:23:21.450At the moment, you have at least three different answers: 16577013436077779652, 16577013372932555467 and my own 16577013372932555466 which is off by one from that before. Can we establish that for e.g. n = 30270501, the correct answer is 20398096 as per this simple approach? Or does anyone have reason to doubt even that simple approach?
– MvG – 2014-01-10T01:01:57.587@MvG I think yours is correct. – Xinbi – 2014-01-10T01:06:51.950