How are ninja solutions even possible in Cody?

In a previous Q & A, Jan Simon pointed to Cody: Sum 1:2^n. The current leading solution to that problem has node-count (or more simply, "length") 10. Apparently, 10 is the minimal length (per the official length-function on File Exchange) of any function taking input & generating output:

function y = test_cody_solution(x)
    y = x;
end

Per Cody instruction examples, additional computation within a function definition increases the solution length. For example, both of the following functions have length 12:

function y = test_cody_solution(x)
    y = [x];
end

function y = test_cody_solution(x)
    y = x+1;
end

My question is: what kinds of ninja-style coding idioms even exist in MATLAB which actually perform definite computation but at the same time do not increase the node-count above 10? I'm not able to imagine what could be going on in order for someone to solve a given non-trivial Cody puzzle in length 10 or 11? IOW, without respect to any particular Cody problem, could someone please give an example of a non-trivial function which somehow comes in at or just above the absolute lower bound? Any explanation of the magic would be appreciated as well.

Thanks, Brad

Answer 1

[Doug Hull]

Not sure if I am using super-powers to see the leading solution that you pointed to but his is what was leading:

function y = sum_int(x)
  regexp '' '(?@y=sum(1:2^x);)'
end

So this is the Ninja solution to that Cody problem

I would not spend a whole lot of mental effort on figuring out this "best" solutions to these Cody problems. The scoring encourages really arcane solutions like this. I take pride in having the "worst" score on most of the problems I am involved with. I will take long, readable code every time.

[Bradley Stiritz]

Hi Doug,

Thanks for your reply & comments. The code you posted actually has to be modified slightly in order to run--

y = regexp('','(?@y=sum(1:2^x);)');

--and in fact generates a length of 1 in R2013b! I agree with you & Jan, this type of "solution" seems very artificial & non-relevant for most real-world applications. But I'm sure it will be good fodder for the upcoming e-book "500 Top-Secret MATLAB Cody Hacks" ;) I'm guessing regexp() must be one of a number of eval() - type Cody exploits (though eval('x') itself generates length 12).

Anyway, I also code in multi-step & highly verbose fashion, so I'm sure my scores will be extremely uncompetitive as well. I appreciate you posting this example & also expressing your feelings about high vs. low scores. I'm going to try to emulate your good attitude!

[Mingji Chen]

I think that the size of the leading solution should be based on the least number of characters for one's code. As for your example, compare these two codes:

function y = sum_int(x)

regexp '' '(?@y=sum(1:2^x);)'

end

function y = sum_int(x)

y=sum(1:2^x);

end

Obviously the second code uses fewer characters, this should be closer to a leading solution for that Cody problem.

[Rik]

Or better yet: runtime (either as a fraction of an example solution, or in absolute terms). That way you optimize for speed, instead of arcane hacks that have nothing to do with anything real world. At least speed has a real world application.

This is the main reason I stopped doing Cody puzzles: with nice, compact, fast code you will still be orders of magnitude above a forrest of tiny score solutions. Which you can't view if you don't have at least that score, so you can only learn from people who are worse than you.

Answer 2

[Chris Pap]

Not an answer -

This ruined the Cody challenge for me.

I guessed the "minimun parse tree" requirement would exclude invoking functions of regular expressions and related stunts. Not because it is hard to do (which is), but because this has little to do with code improvement in terms of computability.

Anyway. Back to cody.

Bye guys