Discover MakerZone

MATLAB and Simulink resources for Arduino, LEGO, and Raspberry Pi

Learn more

Discover what MATLAB® can do for your career.

Opportunities for recent engineering grads.

Apply Today

Alfonso Nieto-Castanon

View profile information

Personal Profile

http://www.alfnie.com

1Rank
17Badges
16780Score

Alfonso Nieto-Castanon submitted a Comment to Solution 476047

Ha! I did not think of that, congrats! That gave me an idea for a potentially "unpeakable" .p code. I will create a new problem for that later tonight

on 21 Jul 2014 at 19:15

Alfonso Nieto-Castanon submitted a Comment to Problem 1969. Self-Description

I was going for the simple measurement (and the .p function was just to avoid publishing the actual solution) but please feel free to explore other approaches as well. While common hacks to pass this problem would work, I believe it might not be possible to hack the piechartsolve.p function to give away the solution (but I will be very interested if that proves to be wrong!)

on 21 Jul 2014 at 3:11

Alfonso Nieto-Castanon submitted a Comment to Problem 2450. Back to the Future III

That was a good hint (and sorry hacking was similarly fun)

on 20 Jul 2014 at 1:23

Alfonso Nieto-Castanon submitted a Comment to Solution 475011

you are apparently using some cool/sophisticated checks in secret_solver to avoid hacking attempts, but in my opinion it might be safer to just leave the checking of whether the solution is correct or not to your .p function itself, instead of having your .p function return the correct value (e.g. something like testsuite in http://www.mathworks.com/matlabcentral/cody/problems/1969-self-description)

on 19 Jul 2014 at 1:58

Alfonso Nieto-Castanon submitted a Comment to Solution 470839

Ha, I followed the same sequence. Third time (and third function to overload) is a charm. Just look at the first test in the testsuite again :)

on 15 Jul 2014 at 15:44

Alfonso Nieto-Castanon submitted a Comment to Solution 470839

No they did not. I believe then this did not work because @char/regexp takes precedence over your regexp function... this will work if you use instead another among the "three" (this is a hint) functions called by the testsuite before the error occurs (this happens when evaluating "tf{1}")...

on 12 Jul 2014 at 21:18

Alfonso Nieto-Castanon submitted a Comment to Solution 470839

mmm... this should have worked... perhaps cody fixed the "change the function name" vulnerability?

on 12 Jul 2014 at 20:29

Alfonso Nieto-Castanon submitted a Comment to Problem 1088. Rank of magic square (for beginners)

Yes, I have noticed that many of the "reference solutions" for my own problems seem to have been lost (they still appear when I edit the problem, they just disappeared from the list of scored solutions) -this explains the generalized drop in scores seen some time back. No idea what might have caused this, though. Some times a solution is "lost" if, during rescoring, it times out or runs into a general cody-level error (the same behavior when you create a solution that times out, which is not recorded as a failed solution at all). This might be intentional to avoid keeping solutions that may cause timeouts from being rescored, but it can have undesired consequences so it might be desirable to fix this behavior to avoid this sort of "lost solution" situations... (although I am not sure if this is related to this particular case of lost solutions). Thoughts?

on 12 Jul 2014 at 17:59

Alfonso Nieto-Castanon submitted a Comment to Solution 468023

You are right, you could use ind2sub to avoid some of the limitations of dec2base as well (e.g. for n>36)...

on 9 Jul 2014 at 19:34

Alfonso Nieto-Castanon liked Solution 462725

on 9 Jul 2014 at 8:12