How are ninja solutions even possible in Cody?
Bradley Stiritz
on 18 Nov 2013
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
5 Comments
Time Descending
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
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
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.
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.
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.
Sign in to participate
