hacker.org

I have inspected 5,000 test cases and here is how the maximum was distributed over the first 20 locations in memory: cell || 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 ------++-----+-----+-----+-----+-----+-----+-----+-----+-----+---- ... count || 260 | 259 | 242 | 253 | 251 | 240 | 253 | 237 | 254 | 238...

It would be nice to get some information from the five solvers, but I do not count on it. On the other hand, except for Enodo, all solvers seem to be still active. Perhaps it makes sense to send them a PM to draw their attention to the thread? I have to think about it.

Since challenge 'Surely Smallesterest Mouse' apparently can only be solved with incredible luck, I would like to discuss potential solution ideas openly. Do you agree with that? The most general solution which I have so far, returns max{cell[ r ± 1], cell[ s ]}, where 0 < r < 9 and 0 ≤ s ≤ 9:     ( ...

Oh boy! I did not see the forest for the trees. Stupid me.

Hmmm, I have a feeling the snibril constraint solution does not exist :(. I have decided to run bruteforce search for it ... looks like several years of machine time would suffice to prove the nonexistence of it ... . (I am not searching for 20 op code, but 21 without > ...) Hmmm, the estimate time...

One-liners are often the key to shorter solutions. The following program of size 21 passes all the test cases: 0@@@@@@@@=,x?$+x?s!P$ Even smaller and without restrictions: !:^1=/?@\ $P/%0s\,x/ Just felt like posting it, because using an '@' instruction within a loop is such a nice and hugely useful...

The problem can even be solved in terms of a closed-form expression:

The population size N ≥ 4 is reached after

    ⌈log(N - ½) / log(φ)⌉

days, where φ is the golden ratio and ⌈x⌉ denotes the ceiling function.

Math is your friend!

I was able to reduce the number of cycles, but not the instructions:
Does no one have any better idea?

Honestly, I think that when an answer has been rejected as wrong once, it should be rejected always. A correct solution should be a solution that always produces a correct result, not just very rarely. It depends. I agree, if it was sheer coincidence that the solution was accepted and therefore is ...

OK ... another aproach ... there are 16! permutations, your algorithm does 29 comparisons. So it distinguish at most 2^29 of 16! of them so I hope success probability is less than 2^29/16!<1/38971. If I have not miscounted, the probability of success is 49,926,400 / 20,922,789,888,000 = 2.38622e-6....

I don't think you could wait till such small probability happens. ... I am still waiting for something like 1/13000 and it takes years ;). Of course, that was just an example. The idea is to find an algorithm whose probability of success, for the applied test cases, is sufficiently large. Currently...

Since the SuperHack program is checked with only one test case, I now believe that the solution is an algorithm that does not always sort correctly. Like the one here , although its probability of success is vanishingly small at 35,357,670 / 20,922,789,888,000 = 1.68991e-6 (if the test cases are cho...

I am now down to 54 instructions:
I wish you all a Happy New Year!

Hippo wrote:Do you mean

Code: Select all

@0@@@@@@ ,x?$+p08gP1^?$p!

?

Yes, almost exactly the same source code, however, yours separates the integers mistakenly by a space:
Could it be done with fewer instructions?

It really bothers me that even for the simpler exercise of printing the integers in reverse order, I already need 25 instructions. Heck, how can you sort the sequence of numbers with only 12 additional or 37 instructions? Currently, it is only exploited that the list contains exactly 16 positive num...