Thread Subject:

MATLAB Golf Contest: November 4-6, 2003

Dust off your golf clubs, the next MATLAB programming contest,
featuring MATLAB Golf, starts tomorrow! The first challenge will be
posted on the contest page tomorrow (November 4) at 10 a.m. EST.


 <http://www.mathworks.com/contest>


For those of you who are unfamiliar with MATLAB Golf, the game
involves contestants searching for the shortest possible solution to
a series of problems. The time structure of this contest is different
from previous contests since there will be multiple challenges. Each
challenge will run for two hours, starting at 10 a.m., 1 p.m. and 4
p.m. (EST) each day. For more information on how to play, refer to
the contest rules.


 <http://www.mathworks.com/contest/golf_1.cgi/rules.html>


Please use this thread to talk about the contest, strategies, or to
ask related questions. If you have an "administrative" type of
question that you feel doesn't apply to anyone else, e-mail us at
contest@mathworks.com.


We hope that you will like the format of this new contest. Be sure to
set aside some time over the next few days to watch the contestants
at work or to submit an entry. There are MATLAB jackets and toolkits
to be won. Good luck!


Min Poh
The MATLAB Central Team
The MathWorks, Inc.

"Min Poh" <mpoh@mathworks.com> wrote:

> Dust off your golf clubs, the next MATLAB programming contest,
> featuring MATLAB Golf, starts tomorrow! The first challenge will
> be posted on the contest page tomorrow (November 4) at 10
> a.m. EST.
>
> <http://www.mathworks.com/contest>

Great initiative! But...umm...

   In MALTAB golf, the objective is [...]

I think that has got to be the #1 typo in the history of
MALT^H^HTLAB. :-)

Peter

--
Why does MATLAB have a "sin" function, but no "forgive" function?

Ahh, typos. MALTAB (Uzbekistan) is now MATLAB (Bangladesh).

We are not all americans.
What is EST time? Whow does it relate to GMT (or betterm UTC) time?

"C. Esperto" <nospam@nospam.net> wrote in message
news:eec68e3.2@WebX.raydaftYaTP...
> We are not all americans.
> What is EST time? Whow does it relate to GMT (or betterm UTC) time?

EST = GMT - 5 hours
--
Bob Gilmore

Should be fun. I think the bite-size challenges will be appreciated
by many. Any whinging about commenting and variable names is well and
truly redundant!
Nathan

Copied from an e-mail:

-------------

"Are tabs of ascii = code 9 counted=20 within the characters of the
program code?"

-------------

Tabs are counted against you, so make sure you set your editor to use
spaces.

Mike
MATLAB Contest

can you please add to the queue display the number of characters in
each submission so
that we can see how close we should aim for our next shot?
   cheers,
       j
ps. how about setting up multiple servers to speed up the queue as
execution speed isn't a factor this contest?

Does somebody understand why my entry times out after 10 s while the
previous time outs were after 120 s?

The current winning entry (Pretty Good) doesn't work for easy cases!
a=[1 2];b=[2 1];


gives 2 1 1
!!!!!!!
such an easy case!!

Stijn Helsen wrote:
>
>
> The current winning entry (Pretty Good) doesn't work for easy
> cases!
> a=[1 2];b=[2 1];
>
> gives 2 1 1
> !!!!!!!
> such an easy case!!


Yes, it is a very poor ill-posed problem. Not worth our time, I am
afraid.

The current winning entry (j1) won't work if values are repeated in
a. (i.e. a = [1 1 2 3])

The next winning entry is giving totally wrong answers!!!


j1([1 2 3], [3 1 1])
is giving : 1 2 3 1


I think the run of the testsuite should be controlled better!!!!

Since none of the entries were taking more than a second to run, we
cranked the timeout down to 10 seconds to be able to process entries
faster.


I tried your entry "martijn 4" and it gets stuck in an endless loop
in our test suite.

Philip Freeman wrote:
>
>
> The current winning entry (j1) won't work if values are repeated in
> a. (i.e. a = [1 1 2 3])


Also doesn't work on such simple cases as:
a = [1 2 3 4 5]
b = [5 1 1 1 1]
which has a solution
1 2 1 3 1 4 1 5 1


but actually returns
1 2 3 4 5 1


Makes one lose confidence in the test suite.
Ken

Ken Crounse wrote:
>
>
> Philip Freeman wrote:
>>
>>
>> The current winning entry (j1) won't work if values are
repeated
> in
>> a. (i.e. a = [1 1 2 3])
>
> Also doesn't work on such simple cases as:
> a = [1 2 3 4 5]
> b = [5 1 1 1 1]
> which has a solution
> 1 2 1 3 1 4 1 5 1
>
> but actually returns
> 1 2 3 4 5 1
>
> Makes one lose confidence in the test suite.
> Ken


Oh well, da rules are da rules.


Phil

"Ken Crounse" <rumpuscat@yahoo.com> wrote:

> Makes one lose confidence in the test suite.

They have all the entries and submission times, so if some of the
solutions are flawed they will hopefully rerun the queue. :-)

Peter

--
Why does MATLAB have a "sin" function, but no "forgive" function?

pjacklam@online.no (Peter J. Acklam) writes:

> "Ken Crounse" <rumpuscat@yahoo.com> wrote:
>
>> Makes one lose confidence in the test suite.
>
> They have all the entries and submission times, so if some of the
> solutions are flawed they will hopefully rerun the queue. :-)

Would it not be simpler to release the test code (not necessarily the
full suite)? That would eliminate many of the failed entries and
solve the "ill-posed problem" issue. You guys could still surprise us
with the test cases.


--
Peter Boettcher <boettcher@ll.mit.edu>
MIT Lincoln Laboratory
MATLAB FAQ: http://www.mit.edu/~pwb/cssm/

I doubt they will.
The rules say that the test suite is final :P


Peter J. Acklam wrote:
>
>
> "Ken Crounse" <rumpuscat@yahoo.com> wrote:
>
>> Makes one lose confidence in the test suite.
>
> They have all the entries and submission times, so if some of the
> solutions are flawed they will hopefully rerun the queue. :-)
>
> Peter
>
> --
> Why does MATLAB have a "sin" function, but no "forgive" function?
>

"Christopher Cheng" <chris_cheng@bose.com> wrote:

> The rules say that the test suite is final :P

Hm. It takes the fun out of it if an entry can win while it gives
incorrect results for input which is valid according to the rules.

Peter

--
Why does MATLAB have a "sin" function, but no "forgive" function?

Philip Freeman wrote:
>
> Oh well, da rules are da rules.
>
> Phil


Phil is correct to refer to the rules here. We anticipated this kind
of situation when we included this sentence in the rules: "The test
suites represent the final word: if it passes the test suite, then
it's a legal entry, even if a more comprehensive test suite might
plausibly have failed the same entry."


Still, we admit that the test suite was too thin in this case, and
we'll bulk them up for the rest of the contest.


But keep in mind that this same situation is likely to come up again,
though perhaps in a more complex and subtle form. No test suite is
universally comprehensive.


The golf contest is a work-in-progress. Bear with us, and we'll try
to tighten up the weak spots in real time. Keep the comments coming
so we can tune it up.


In the meantime, the rules stand, and whoever has the shortest entry
that passes the test suite wins.


-Ned.

Matthew Simoneau wrote:
> I tried your entry "martijn 4" and it gets stuck in an endless loop
> in our test suite.


Thanks for your answer. But the only loop is a finite for loop.
Probably some a and b in the test suite are quite long and the
duration of the perms command explodes. But now it's length is
nowhere near that of the winning entry, so never mind.

Peter J. Acklam wrote:
>
>
> "Christopher Cheng" <chris_cheng@bose.com> wrote:
>
>> The rules say that the test suite is final :P
>
> Hm. It takes the fun out of it if an entry can win while it gives
> incorrect results for input which is valid according to the rules.
>
> Peter
>
> --
> Why does MATLAB have a "sin" function, but no "forgive" function?
>


I wonder if


c=1;


could have passed the suite?


Phil

Even more annoying than having a winning entry that doesn't really
solve the posed problem but simply 'somehow came around the test
suite' is for me that the winner (j11) simply exchanged a ',' for a
not counted blank. I recommend submitting 1 minute before the hole
closes...


BR
Stephan


Ned Gulley wrote:
>
>
> Philip Freeman wrote:
>>
>> Oh well, da rules are da rules.
>>
>> Phil
>
> Phil is correct to refer to the rules here. We anticipated this
> kind
> of situation when we included this sentence in the rules: "The test
> suites represent the final word: if it passes the test suite, then
> it's a legal entry, even if a more comprehensive test suite might
> plausibly have failed the same entry."
>
> Still, we admit that the test suite was too thin in this case, and
> we'll bulk them up for the rest of the contest.
>
> But keep in mind that this same situation is likely to come up
> again,
> though perhaps in a more complex and subtle form. No test suite is
> universally comprehensive.
>
> The golf contest is a work-in-progress. Bear with us, and we'll try
> to tighten up the weak spots in real time. Keep the comments coming
> so we can tune it up.
>
> In the meantime, the rules stand, and whoever has the shortest
> entry
> that passes the test suite wins.
>
> -Ned.

Stephan wrote:
>
>
> Even more annoying than having a winning entry that doesn't really
> solve the posed problem but simply 'somehow came around the test
> suite' is for me that the winner (j11) simply exchanged a ',' for a
> not counted blank. I recommend submitting 1 minute before the hole
> closes...


That's really what this game is about :
or making the best entry, or impoving a good one to a better one, if
necessary with an infinitesimal change....

I have to agree with Stephan. Perhaps the Matlab contest people can
write a preprocessor that automatically removes redundant punctuation
(for example, unnecessary commas and parentheses).


G

Guy Shechter wrote:
> I have to agree with Stephan. Perhaps the Matlab contest people can
> write a preprocessor that automatically removes redundant punctuation
> (for example, unnecessary commas and parentheses).

In some cases, commas and parentheses are necessary to obtain the desired
result, so any preprocessor would have to be really smart. For example,
compare -3^(1/2) and (-3)^(1/2). [And no, that's not a bug, but order of
operations. See HELP PRECEDENCE.]
Also note in the contest rules:

"Minor rule change: Spaces, newlines, and semicolons will not count against
your score."

--
Steve Lord
slord@mathworks.com

An idea for palindrome (but I can't figure out where to go with it)


if you do this:
m=sqrt(a'*fliplr(a));
m=~(m-ceil(m));


Then the longest palindrome is the the longest chain of off diagonal
1's in the resulting matrix. It seems clever, but I can't figure out
a quick way to search for the chain. Feel free to try this out.

Last contests seem to have had much much more special test cases.
This testcase (palindrome) hasn't the trivial case with one letter.


The current winning entry doesn't give the right answer for
a='a'


xxxxxxxx

Nice one Philip,
the next 2 lines would be something like


[e f]=max(sum(spdiags(m)))
diag(m,1+f-n)


to pull out the diagonal,but that already takes it over 70...


looks like ugly will beat elegant again ;)

jpreen wrote:
> [e f]=max(sum(spdiags(m)))


oops, forgot that matches can occur outside the palindrome, same
problem again. let's hope hole 3 is matrix-friendly!

jpreen wrote:
> looks like ugly will beat elegant again ;)


And short can be seen as 'elegant' too....

Stijn Helsen wrote:
> And short can be seen as 'elegant' too....


indeed, i'm continually impressed by
your tweaking skill, Stijn ;)


but for this hole the winning code is the same algorithm as we all
seemingly first thought of, at least there were several different
approaches in play for the first hole...

Stijn Helsen wrote:


> The current winning entry doesn't give the right answer for
> a='a'


My fault. After submitting the code, I corrected for it but the
corrected entry was too long after the faulty one took first place.


More special cases in the test suite, and shorter timeouts would be
nice.


/Per

Why does it take such a long time to process the queue? The typical
entry has an elapsed time of 10 sec.


Heinrich


Heinrich.Acker{at}web.de

That's a problem of this kind of games. If an error doesn't mind (or
even helps to be better), errors are not easily corrected....


Per Rutquist wrote:
>
> My fault. After submitting the code, I corrected for it but the
> corrected entry was too long after the faulty one took first place.
>
> More special cases in the test suite, and shorter timeouts would be
> nice.
>
> /Per

But it is still nice to have the first working algorithm submitted.
("""and the first one has to give room for improvement""")


j wrote:
>
>
> but for this hole the winning code is the same algorithm as we all
> seemingly first thought of, at least there were several different
> approaches in play for the first hole...

In addition to the run-time, there are about 10 seconds of overhead
in processing each entry. The big hit, however, is when an entry
times out. After the timeout, there's an additional hit of a couple
minutes. The queue throughput hasn't been too much of a problem in
"traditional" MATLAB contests, but is more noticeable here because of
the volume of entries we've been receiving and the additional
time-sensitivity. We're brainstorming some ways to speed this up,
but we're hesitant to make major untested changes while the contest
is going on. It will probably have to wait until next time.

Am I the only one who can't submit entries or even reach the contest
site?


I guess this one was too easy :)


/Christian

christian ylämäki wrote:
> Am I the only one who can't submit entries or even reach the
contest site?


i'm having the same trouble, i got through once but it said i'd
already submitted, so it looks like it is just slow loading the
confirmation page?

So, are 'they' saying that they don't dare doing (untested) changes
and then let the system crash (by some changes)?


j wrote:
>
> i'm having the same trouble, i got through once but it said i'd
> already submitted, so it looks like it is just slow loading the
> confirmation page?

Maybe we can post submissions here to get a correct timestamp? I'm
trying again for a quarter of an hour to send submissions....

And still trying.......


Stijn Helsen wrote:
>
>
> Maybe we can post submissions here to get a correct timestamp? I'm
> trying again for a quarter of an hour to send submissions....

My submissions got sent even if I didn't see the confirmation page.


Stijn Helsen wrote:
>
>
> And still trying.......
>
> Stijn Helsen wrote:
>>
>>
>> Maybe we can post submissions here to get a correct timestamp?
> I'm
>> trying again for a quarter of an hour to send submissions....

I just see that the time stamp on this page is also a bit strange
(two entries long after each other and the latest arrived before the
other?)

I don't know what's going on for the Encryption contest because most
of time I see blank page. Is Mathwork ask us to decode the blank page
too?


Anyway, I share with you my code here:


b=kron(a|1,b)
c=97+rem(a-12+b(a|1),26)
c(a==32)=32

christian ylämäki wrote:
> Am I the only one who can't submit entries or even reach the
> contest site?


I can think of three possible causes for the slowness:
1) Their server can't handle the load. Lot's of people are repeatedly
reloading a big page to monitor the queue.
2) Someone is running a denial-of-service attac.
3) Someone is using a robot to download entries, and this robot is
running haywire.


In case 1: There should be a page that only shows the submissions of
the last five minutes. That would keep a lot of people from reloading
the entire queue.


In cases 2-3 whoever is doing it should be banned from the site.


/Per

I was sending :
b=b'*(a>0);
i=a>32;
a(i)=97+rem(a(i)-12+b(i),26);
c=a;
(and some other versions)


wu vincent wrote:
> Anyway, I share with you my code here:
>
> b=kron(a|1,b)
> c=97+rem(a-12+b(a|1),26)
> c(a==32)=32

So, one thing is working there : the time-out (closed). After trying
for I think 3/4 hours, I couldn't send one entry!!!!!

This was mine - it kind of takes advantage of the subtle rule change:


b = b'*';;;;;;;;;;;;;;;;;;;;;;;;;;;;;;'+6;
i = a > 32;
a(i) = 97 + mod(a(i)+15*b(i),26);
c = a;


With the rule that semicolons don't count, this would be 46
characters... not sure how it's going to be ruled ;) I didn't
include all the semicolons from the 'official' entry.


- BK


Stijn Helsen wrote:
>
>
> I was sending :
> b=b'*(a>0);
> i=a>32;
> a(i)=97+rem(a(i)-12+b(i),26);
> c=a;
> (and some other versions)
>
> wu vincent wrote:
>> Anyway, I share with you my code here:
>>
>> b=kron(a|1,b)
>> c=97+rem(a-12+b(a|1),26)
>> c(a==32)=32

Yep, time-out is working. Fairly certain this didn't make it into
the queue due to the delays, I'll place it here. Credit to Peng for
what I was working from.


i=a>33;
b=kron(a>0,b);
c(i)=97+rem(a(i)-12+b(i),26);

Maybe I must apologize (although...). I thought no submissions were
send, because I only got "connecting to www.compuserve.com".
Therefore I thought nothing was sent. I couldn't open the "all
submission page (I still can't), so I didn't know anything came
through.
Now I tried "Find submission", and there I saw a lot of submissions
arrived.....
Sorry. (But it made me nervous..)

The queue is really slow... I submitted an entry at about 5:50pm and
around 6:05pm I finally got a response: Internal server error. I
guess my entry never made it.


-Frustrated contestant

"wu vincent" <vincent@comp.hkbu.edu.hk> wrote:

> I don't know what's going on for the Encryption contest because most
> of time I see blank page.

And the complete list of entries seems messed up too. Now the
reported leading entry is one with 68 characters.

Peter

--
Why does MATLAB have a "sin" function, but no "forgive" function?

Stijn Helsen wrote:
>
>
> Maybe I must apologize (although...). I thought no submissions
> were
> send, because I only got "connecting to www.compuserve.com".
> Therefore I thought nothing was sent. I couldn't open the "all
> submission page (I still can't), so I didn't know anything came
> through.
> Now I tried "Find submission", and there I saw a lot of submissions
> arrived.....
> Sorry. (But it made me nervous..)


Me too. the server did accept all my submissions just now I search my
entries.

Peter J. Acklam wrote:
>
> And the complete list of entries seems messed up too.


We on the Contest Team have to offer an unreserved apology for the
ugly state that the contest queue got into this afternoon.


We tried to experiment with the contest format and didn't anticipate
a number of problems that our changes caused. We are making some
changes tonight to help things run more smoothly tomorrow. Notice
that we have scaled back from three problems per day to two, so that
there will overall be only seven problems.


We will run the complete queues for holes two and three and post a
winner for each tonight. We recognize that participation in the
encryption problem suffered badly from web delays, but we will move
on to the next problem rather than re-run this one. All entries that
made it into the queue will be run.


Sorry for the confusion and frustration --- we hope at least the
problems presented today stimulated some good thinking about minimal
coding in MATLAB.


-Ned Gulley.
The MATLAB Contest Team

"Josh Landau" <josh@wcbn.org> writes:

> Yep, time-out is working. Fairly certain this didn't make it into
> the queue due to the delays, I'll place it here. Credit to Peng for
> what I was working from.

So to be honest, I didn't have this version until 20 minutes after
queue closed, but the blasted server didn't let me submit my earlier
bigger version:

x=hankel(rem(16:1e3,26)+97);
x(32,:)=32;
c=diag(x(a,repmat(b,9)'))'



--
Peter Boettcher <boettcher@ll.mit.edu>
MIT Lincoln Laboratory
MATLAB FAQ: http://www.mit.edu/~pwb/cssm/

No need for the space exclusion line; this seems to work and is
shorter than Per's current winner:


b=b'*~~a;
c=97+rem(a-12+b(1,:),26);
c(a==' ')=' ';


Can you please have more servers for tomorrow?

Stijn Helsen wrote:
>
>
> So, one thing is working there : the time-out (closed). After
> trying
> for I think 3/4 hours, I couldn't send one entry!!!!!


Yep. I think we are all in the same boat. Pity, since I suspect many
of us managed to beat peng's 16:56 entry.


Roger

Alex Backer wrote:
>
>
> No need for the space exclusion line; this seems to work and is
> shorter than Per's current winner:
>
> b=b'*~~a;
> c=97+rem(a-12+b(1,:),26);
> c(a==' ')=' ';


& it's possible to eliminate the 1st line (& the 1,: in the 2nd) too
if you use an additional REM in the 2nd to loop through b, but it's
not clear that the total ends up shorter.

And can you have entries with repeated names not bounce? You could
accept them or modify them automatically. It's frustrating after a
long delay to get a message saying Error: Name repeated.

Let me ask the general question: if you have a good problem, a good
test suite, and a responsive server (a challenge for us today), do
you prefer the short golf puzzles to the long contests?


Short puzzles converge more quickly and can run out of gas after only
an hour or so, but the long puzzles can result in impenetrable
jungles of code. Which do you prefer?


Naturally, we will keep working on the obvious problems, but we're
curious to know what format to focus on in the future.


-Ned Gulley.
The MATLAB Contest Team

> Let me ask the general question: if you have a good problem, a good
> test suite, and a responsive server (a challenge for us today), do
> you prefer the short golf puzzles to the long contests?
>


How about calculating the score using some combination of code length
and number of flops? This might encourage some creative thinking,
instead of simply comma removal (guilty as charged).

I think it is good to have this kind of challenge. However, my
personal opinion is that it would be better to have more challenging
problems, with optimal solutions with 100-150 characters. This would
make it more interesting and would give rise to more creativity.


Imre Polik


> Naturally, we will keep working on the obvious problems, but we're
> curious to know what format to focus on in the future.

I prefer the longer contests. This contest just isn't very
interesting. Maybe if the problems were more difficult. Also, I
would prefer to think about the problems out of the office. The
current format gives me little time to participate. JMO, of course.
I agree with someone who stated that 150 characters should be the
minimum problem size. This may not be possible in a 2 hour contest
in the middle of the day though.


Ned Gulley wrote:
>
>
> Let me ask the general question: if you have a good problem, a good
> test suite, and a responsive server (a challenge for us today), do
> you prefer the short golf puzzles to the long contests?

I agree that these problems were not interesting. Given interesting
problems, though, I prefer one time-limited to 2-4 hours than one
lasting a week, since I don't have that much time to give to it.
Perhaps one or two good 4-hour ones, preferrably timed so that most
participants get it in the evening, would be better than 7 2-hour
ones in the middle of the day over 3 days.


Also, I maintain the position I gave in a previous contest that it
would be much more fair and motivating if points were awarded to
players based on an integral/product of the score improvement their
program achieved over the previous top score and the time the program
remained on top (with some constant time assumed after the end of the
contest to reward last-minute improvements). Thus, a program that
makes a substantial improvement can win even if someone removes a
comma at the end, but the incentive to improve on previous winners
remains, and importantly, an incentive is created to submit a
revolutionary contribution early rather than at the last minute. You
could have awards to the player with the top score added over all his
contributions and/or to the top program.


Alex


>
> Ned Gulley wrote:
>>
>>
>> Let me ask the general question: if you have a good problem, a
> good
>> test suite, and a responsive server (a challenge for us today),
> do
>> you prefer the short golf puzzles to the long contests?

I agree with some others. Short, but a little bit more complex
problems. On the other hand, I also like optimization problems like
earlier contests, but then not for such a long time (also three
days).


In other words, I don't know myself. For the rest of the family,
this contest is the best. (And the fact that the middle hole of the
day is removed (1 PM) is also good, since, here in Belgium, it is
between 7 and 9 PM, which is around eating time, and
"children-bedtime".)


Stijn


Ned Gulley wrote:
>
>
> Let me ask the general question: if you have a good problem, a good
> test suite, and a responsive server (a challenge for us today), do
> you prefer the short golf puzzles to the long contests?

Note that Stijn Helsen's code "Test 14" of 14:21:17 in the second
hole is identical to the winning entry of 14:50:19 (except for a few
semicolons that don't affect the code at all.) Stijn's entry timed
out.


Since the code is deterministic this seems very unfair. Almost all
entries enumerated all cases, and if this sometimes times out, then
the time-out is too short. Stijn should have first place! (Unless
someone else submitted code that short even sooner. I haven read all
entries...)


Sadly, this also means that I should not have second place. My entry
of 14:40:17 was based on Stijn's code, but I was guessing (wrongly)
from the long runtimes that the longest entry in the test suite had
more than 99 characters.


/Per

Ned Gulley wrote:
> Let me ask the general question: if you have a good problem, a good
> test suite, and a responsive server (a challenge for us today), do
> you prefer the short golf puzzles to the long contests?


I have to say I had low expectations on this "golf puzzle" format but
I was pleasantly surprised. All holes very pretty exiting (not
considering the server problems).


One problem was the the tasks were "solved" in about 20 min then it
was just a matter of decreasing the length of the code. This could be
solved by using a score combined of codelength, excecution time,
and/or some other measurable criteria.


I like the King of the hill scoring system.


I think that hiding the entries in the queue might be a good idea.


2 hours a problem is a little short, perhaps two 3 hour problems a
day for 3 days would be better. That way the problems could be made
tougher.
The best thing about the "golf format" is the leaderboard. Imagine
the excitement of starting the final day in the lead. The hole-winner
prize is good for people who don't have the time to compete all 3
days but I think the real competition should be about the final day
standings. I think it's more prestigiuos to be third place overall
winner than to win one hole therefore I would like to see gold,silver
and bronze prices in the overall competition.


Obviously giving away to many prices is not good either.

Thanks for spotting that!! It is also a strange error (next to the
timed out) :


connect: Connection refused at
/rel/www/external/perl5/MathWorks/MLSClient.pm line 82.


It seems that that says something else is going on then just "time
out"(??).


Do they need some extra programmers at the Mathworks??


Stijn


Per Rutquist wrote:
>
> Note that Stijn Helsen's code "Test 14" of 14:21:17 in the second
> hole is identical to the winning entry of 14:50:19 (except for a
> few
> semicolons that don't affect the code at all.) Stijn's entry timed
> out.

"Ned Gulley" <gulley@mathworks.com> wrote:

> Let me ask the general question: if you have a good problem, a
> good test suite, and a responsive server (a challenge for us
> today), do you prefer the short golf puzzles to the long
> contests?

I no longer have time participate in the long contests, so the
golf puzzles are my only chance. On the other hand, if I had the
time, the I'd prefer the long ones.

Perhaps alternating between the two is an idea. Anyway, it was
fun, so I'd like to thank the folks at MathWorks.

Peter

--
Why does MATLAB have a "sin" function, but no "forgive" function?

Sorry, I misposted the first one.


So about semicolons. In my understanding semicolons don't count at
all. Is it really the case, or it refers to line-ending semicolons
only. The same about spaces: only at the begining and the end of a
line or anywhere?

"Ned Gulley" <gulley@mathworks.com> writes:

> Let me ask the general question: if you have a good problem, a good
> test suite, and a responsive server (a challenge for us today), do
> you prefer the short golf puzzles to the long contests?
>
>
> Short puzzles converge more quickly and can run out of gas after only
> an hour or so, but the long puzzles can result in impenetrable
> jungles of code. Which do you prefer?
>
>
> Naturally, we will keep working on the obvious problems, but we're
> curious to know what format to focus on in the future.

I'll make the same suggestion for this format that I've made for the
longer ones:

It would be interesting to have 2 phases. In the first phase, NO
viewing of submissions would be allowed. Everyone would have to come
up with their own method. I think that would encourage variety of
approach. Pick a winner based on best score after this phase.

Then, in phase 2, open ALL the submissions, and compete again for the
best tweaks and combinations of approaches. Pick another winner at
this point.



--
Peter Boettcher <boettcher@ll.mit.edu>
MIT Lincoln Laboratory
MATLAB FAQ: http://www.mit.edu/~pwb/cssm/

Semicolons don't count anywhere.

It's a pitty that the codes are not included anymore. I suppose it
is to reduce the size of the page, but maybe it could be done for the
"numbered" submissions?


Stijn

Yes, we pulled the inline code from the "All Entries" page to reduce
the load on the server. We also made some optimizations to our
database backend. We're hoping that, with these changes, we won't
see the page loading issues that we saw at the end of yesterday's
last hole.

In hole #2, Stijn Helsen's entry "Test_14" failed when it should have
passed because of a server error. Since this is our mistake, we'll
also award him points for first place. The standings for this hole
are now:


1) Imre Polik and Stijn Helsen
2) Per Rutquist
3) shameless_1


Thanks to Per Rutquist for pointing this out.

With a correct working server the top 3 would have been very
different.....


Matthew Simoneau wrote:
>
>
> In hole #2, Stijn Helsen's entry "Test_14" failed when it should
> have
> passed because of a server error. Since this is our mistake, we'll
> also award him points for first place. The standings for this hole
> are now:
>
> 1) Imre Polik and Stijn Helsen
> 2) Per Rutquist
> 3) shameless_1
>
> Thanks to Per Rutquist for pointing this out.

Can someone explain to me what this line in FSec4 does?
d([a{b} 91])=1;


thanks
/Christian

I've submitted my Matrix Lab too late because of I've mistakenly
counted the number of its characters. I considered it takes 61 chars
when it really takes 60 chars because of space after 'for'


It was ready before Claus Still's FSec4 but after Niilo Sirola's
"take this".


It's very pity.

In fact, 'Matrix Lab' could be further optimized !!!, many of us
though there was no better solution that 60 !


Lucio


Alexey Skvortsov wrote:
>
>
> I've submitted my Matrix Lab too late because of I've mistakenly
> counted the number of its characters. I considered it takes 61
> chars
> when it really takes 60 chars because of space after 'for'
>
> It was ready before Claus Still's FSec4 but after Niilo Sirola's
> "take this".
>
> It's very pity.

Never mind, I figured it out. But it does not seem to work in Matlab
6.1

??? Unable to find subsindex function for class char.


christian ylämäki wrote:
> Can someone explain to me what this line in FSec4 does?
> d([a{b} 91])=1;

Strange... The minute counter of these message boxes is stuck to 03.
Any explanations?
Imre

We can reduce 91 to 9 in FSec4 and it seems


a=upper(a)
for i=';;;'
  d([a{b} 9])=1
  b=any(d(char(a)'))
end
c=find(b)


would be the solution having 59 characters.
Unfortunately I have no Matlab at home to verify it. Why do not allow
to test new submissions after the hole is closed (not including it in
the final score of course)?


I have no ideas how to improve 'Matrix lab'.
Do you?


Lucio wrote:
>
>
> In fact, 'Matrix Lab' could be further optimized !!!, many of us
> though there was no better solution that 60 !
>
> Lucio
>
> Alexey Skvortsov wrote:
>>
>>
>> I've submitted my Matrix Lab too late because of I've
mistakenly
>> counted the number of its characters. I considered it takes 61
>> chars
>> when it really takes 60 chars because of space after 'for'
>>
>> It was ready before Claus Still's FSec4 but after Niilo
Sirola's
>> "take this".
>>
>> It's very pity.

I tried it (Try 12) but it failed with
Error using ==> runcontest Index exceeds matrix dimensions.
The guys at Mathworks seem to have come up with a more thorough test
set for today.
Imre


Alexey Skvortsov wrote:
>
>
> We can reduce 91 to 9 in FSec4 and it seems
>
> a=upper(a)
> for i=';;;'
> d([a{b} 9])=1
> b=any(d(char(a)'))
> end
> c=find(b)

Imre Polik wrote:
>
>
> I tried it (Try 12) but it failed with
> Error using ==> runcontest Index exceeds matrix dimensions.
>>
>>
>> We can reduce 91 to 9 in FSec4 and it seems
>>
>> a=upper(a)
>> for i=';;;'
>> d([a{b} 9])=1
>> b=any(d(char(a)'))
>> end
>> c=find(b)


'Z'=90, so 91 is the character after. It's needed so that d is large
enough to allow the indexing that happens on the b=any... line won't
index off of the array.


Phil

Hi,


If 'd' exist, it sets all positions in d of the ASCII-codes of all
the characters of a{b} (so the current infected people) to one. If
'd' does not exist, it makes an array of 91 (therefore 91, which is
the ASCII-code behind 'Z') elements, with ones in the
character-positions of a{b}, and zeros elsewhere.
You understand?


Stijn


christian ylämäki wrote:
>
>
> Can someone explain to me what this line in FSec4 does?
> d([a{b} 91])=1;
>
> thanks
> /Christian

On previous holes, I made it onto the leader board, and never dropped
off. This time I made it, but then dropped off. Why?

It's clear that


s = sum(c(:))


in Mohsen Nosratinia's '5th try!' may be replaced by


s = c(1)*j*j


It saves one character so the result is 95 characters. Someone did
it? I was too late...

Are you sure? I think it is c(1)*(j+1)^2 (or any other form), and
that is not shorter....


Alexey Skvortsov wrote:
>
>
> It's clear that
>
> s = sum(c(:))
>
> in Mohsen Nosratinia's '5th try!' may be replaced by
>
> s = c(1)*j*j
>
> It saves one character so the result is 95 characters. Someone did
> it? I was too late...

I've seen that too now. When I saw later that I wasn't there anymore
(except the bottom one), I thought "Am I getting nuts?". So, thank
you cyclist, for telling me that I wasn't getting mad.....
But that doesn't say why? I'm curious too....
(It wouldn't be the first time that the server is not always working
as expected.)


Stijn


cyclist wrote:
> On previous holes, I made it onto the leader board, and never
> dropped
> off. This time I made it, but then dropped off. Why?

I can't wait for the result, but if "Whatever $\pi$" will win, it's a
pitty that that didn't show up earlier (for the tweakers of us).
That can be made much smaller. (I made a mistake tweaking it once,
and a later trial was too late.)

I have a suggestion to speed up the determination of the winner. If
the server preprocesses each entry just to determine its size and
then selectively executes the entries that are smaller than the
current winner first, and then the rest, we then would probably know
who won the hole a few minutes after it closes.


Also if Mathworks posts a program that determines the size of an
entry, we would probably have less entries in the queue.


-Paulo

Can anyone explain me what's the problem with this code?


for i=a(:)'
    h(i)=fix(sqrt(nnz(a==i)))^2*i;
end
b=max(h)


I mean systactically. It produced an error


Error using ==> runcontest Subscript indices must either be real
positive integers or logicals.


but it works fine on my machine. I use Matlab 6.5 R13.
It is an other question whether it can pass the test set.


Imre

Maybe as a first hole? (Because the problem will not be so complex,
maybe even less complex than the small programs winning here....)
Paulo wrote:
> Also if Mathworks posts a program that determines the size of an
> entry, we would probably have less entries in the queue.

Paulo wrote:
> Also if Mathworks posts a program that determines the size of an
> entry, we would probably have less entries in the queue.


%Put your code in contest.m between %START and %STOP
fid = fopen('contest.m')
A = fscanf(fid,'%s')
fclose(fid);
start = strfind(A,'%START');
stop = strfind(A,'%STOP');
A=A(start+6:stop-1)
length(A)-length(strfind(A,';'))

One cause can be if a has zeros, then it can't work. (Here on older
Mablab version it doesn't work at all.) The answer is not correct, I
think, because it doesn't look for squares.
Imre Polik wrote:
>
>
> Can anyone explain me what's the problem with this code?
>
> for i=a(:)'
> h(i)=fix(sqrt(nnz(a==i)))^2*i;
> end
> b=max(h)

I wanted to give this suggestion in the beginning of the contest, but
I think it also has disadvantages. If in the whole list the best
entries are done first, they can be tweaked first. For the maker of
the "first best code", this is not so nice. Let the tweakers work on
selecting the best "tweakable code".....
Paulo wrote:
> I have a suggestion to speed up the determination of the winner.

Thanks, I missed that one.


> One cause can be if a has zeros, then it can't work.

Stijn Helsen wrote:
>
>
> I can't wait for the result, but if "Whatever $\pi$" will win, it's
> a
> pitty that that didn't show up earlier (for the tweakers of us).
> That can be made much smaller. (I made a mistake tweaking it once,
> and a later trial was too late.)


"Whatever $\pi$" is damn clever, but it's not bullet proof, so it
might not pass (depending on the suite). For example, it fails for
some inputs. Try out:
a=[9 9 0 0 0;
9 9 0 9 9;
0 0 0 9 9];


The answer should be 36, but it comes back as 54.


Regardless, I liked that it used matrix math, which is what Matlab is
all about anyway. I've been rather dissapointed that the best
solutions so far have not really done many matrix operations.
They've mostly looked like how you would code them up in an ordinary
language using arrays except for some of the clever indexing that
Matlab lets you use. I'd prefer to see some problems were stuff like
'conv2', 'eig', '\', etc. are useful in the solution.


Phil

An example of this is some of the current entries with just the same
length as the winning entry (Bob8 and Bob9), but they could be
improved. If they were processed shortly after submission, they
would have been tweaked, with advantages and disadvantages.....
Stijn Helsen wrote:
>
>
> I wanted to give this suggestion in the beginning of the contest,
> but...

Tristram Scott's 'Bob8' & 'Bob9' was passed but they can be shortened
down to 92 characters by removing unnecessary variable 'm'


m=30; x=1:m; =====> x=1:30


because it is not used anywhere else.


I have posted such submission 'test97' but unfortunately it timed out.

I prefer the longer contests.


During the previous contests, some people quit because they found it
too difficult to follow. Reason: The code became too long very soon.
Now we have unreadable code and not-so-interesting problems.


I also think that the replacement of readable expressions by
unreadable expressions which are one character shorter is a rather
old-fashioned programming discipline.


Another problem with the short contests is that they cannot take
place at a convenient time in any time zone.


Conclusion: Run a long contest with a scoring formula that includes
code length, together with problem score. Find a good measure for
code length, one that doesn't make those programming tricks too
attractive. I think of counting something like 'language elements', a
score which counts a variable or a function call as one element,
regardless of the number of characters used. Of course, comments have
to be stripped before counting.


Heinrich.Acker<at>web.de


Ned Gulley wrote:
>
>
> Let me ask the general question: if you have a good problem, a good
> test suite, and a responsive server (a challenge for us today), do
> you prefer the short golf puzzles to the long contests?

Alexey Skvortsov wrote:
>
> Tristram Scott's 'Bob8' & 'Bob9' was passed but they can be shortened
> down to 92 characters by removing unnecessary variable 'm'
>
> m=30; x=1:m; =====> x=1:30
>
> because it is not used anywhere else.
>
> I have posted such submission 'test97' but unfortunately it timed out.

Indeed, that was left over from an earlier version where I had:

m = 30;
x = 1:m;
a(2*m,2*m) = 0;

I should have spotted that, but it was getting late in England...

Still, Francois Glineur did an excellent trick using the std() as a
check for uniformity, and managed to sneak it through in the nick of
time. Well done Francois!

On the topic of which types of competition are preferred, I favour a
series of short problems, such as we have now. If I have a few spare
minutes I can code up an entry, with very fast feedback. It is true
that the compressed code we are creating is not always the most
readable, and likley not the most rapid, but as a mind exercise with
MATLAB, it is good, and I am enjoying it. The target here is not what I
usually aim for in my own code, where I look for clarity, speed, and
memory efficiency, but I don't think that matters. We just need a goal,
and a metric which is simple. Length of code is a very simple metric
indeed.

The issue with time zones is relavant, and while those of us outside the
EST zone might like to see it running earlier (me) or later (my friends
in New Zealand) it does require some human supervision from TMW, and we
shouldn't expect them to work unsociable hours so we may enjoy
ourselves.

Thank you to the team at The MathWorks, the game is a good one!

Philip Freeman wrote:


> I'd prefer to see some problems were stuff
> like 'conv2', 'eig', '\', etc. are useful > in the solution.


Talking about that - here's one with 90 chars, using 'conv2':


[m n b]=size(a);
for i=2:n
    for j=1:9
        c=a;
        c(a~=j)=-Inf;
        t=conv2(c,ones(i),'valid');
        b=max([b;t(:)]);
    end;
end;


I was waiting for earlier submissions to complete test (I wasn't sure
they would pass at all) and never submitted this one. Silly me...
Cheers,
Sh_Kilnao

I missed the contest, but here is a suggestion based on conv2, using
86 characters:


b = 0
for v = a(:)'
 for i = 2 : min(size(a))
  b = max(b,v*i*i*ismember(i*i,conv2(a==v,ones(i))))
 end
end


Best,
Magnus Eriksson
Mid Sweden University

Stijn Helsen and cyclist have noticed their entry drop off the
leaderboard. Because of our "king of the hill" scoring, this is
surprising. The only time you should see this is when occasionally
entries are processed out of order. That is, they go through the
queue in a slightly different order as their submission time. If you
notice something else going on, please let us know.

Here is a 81-char entry for the "Heaviest" hole :


x=0:19;
b=0;
for i=x
   for j=x+2
      for k=x
         r=1:j;
         try
            b = max([b j^2*unique(a(i+r,k+r))]);
         end
      end
   end
end


It is based on the "try/end" and "unique" ideas of AJ Johnson.


Francois

Hi guys,
Do we need Euclidian or Manhattan distance in "Pathfinder". I am a
little confused. Seems to be the former.


Peng

Peng wrote:
>
>
> Hi guys,
> Do we need Euclidian or Manhattan distance in "Pathfinder". I am a
> little confused. Seems to be the former.
>
> Peng


I was wrong. It's Manhattan distance.

Actually, it's Euclidean distance between each set of points as
restricted by the network topology. Take a look at the picture at
the bottom of the problem description:


 <http://www.mathworks.com/contest/golf_1_pathfinder.cgi/home.html>


The point that is farthest away from point 1, by this metric, is
point 5. From 1 to 3, 3 to 4, and 4 to 5, the distance between each
of these pairs is measured by a Euclidean distance.


Notice also that from point 1, point 6 is farther away than point 5
in absolute distance, but point 5 is farther when the path is
restrected by the network topology.


I hope this helps.

Server "almost down" again??? I "almost can't" get in...

Are the servers in trouble again? All I have got the last minutes
is a "The operation timed out when attempting to contact
www.mathworks.com". :-/

Peter

--
Why does MATLAB have a "sin" function, but no "forgive" function?

Same problem. However, the message board link works fast, but my
submission has been trying for 5 minutes. There are very few
submissions, though...
Imre

There's nowhere in the rules that says that the submission has to be
a script and not a function. I wrote a recursive algorithm to solve
the current hole, but I got an error saying "Functions cannot be
defined in scripts", and yet I cannot make it a function myself
without knowing that you'll feed it a & b in that order as
parameters(which is what I assumed in my entry "Functional form of
Rec tweak").


Please let us know ASAP whether you will correct your evaluation
program to follow the rules, or what the form to put custom-defined
functions for recursivity in our submissions is.


Thanks!

I think you should just write a script, which means no recursive
programs are allowed in this contest. That means that you can say
that what you want to solve has to be done (or able to do) in the
command window....


Alex Backer wrote:
>
>
> There's nowhere in the rules that says that the submission has to
> be
> a script and not a function. I wrote a recursive algorithm to
solve...

It's actually possible to write a script with recursive function,
using EVAL... I got something, just need more time.
What about an hour more... PLEASE !


Stijn Helsen wrote:
>
>
> I think you should just write a script, which means no recursive
> programs are allowed in this contest. That means that you can say
> that what you want to solve has to be done (or able to do) in the
> command window....
>
> Alex Backer wrote:
>>
>>
>> There's nowhere in the rules that says that the submission has
to
>> be
>> a script and not a function. I wrote a recursive algorithm to
> solve...

I don't think eval is allowed.


JeanPhi wrote:
>
>
> It's actually possible to write a script with recursive function,
> using EVAL... I got something, just need more time.

[having trouble submitting even messages now :) sorry if this is
duplicated.]


I submitted the 174-char "need more coffee" and found out that the
hole was closed when I returned. (stupid time differences...) Seems
that my entry failed on small sets (stupid nchoosek).


Check out the corrected version at 177 chars. And it isn't even
correctly tweaked yet :)


n=size(a,1);
s=0;
for i=2:n
  l=inf;
  for r=2:n
    for d=nchoosek([2 2 2:i-1 i+1:n],r-2)'
      d = [1 d' i];
      u = d(1:r-1);
      v = d(2:r);
      if diag(a(u,v))
        m=norm(b(u,:)-b(v,:),'fro');
        if m<l
          e = d;
          l = m;
        end
      end
    end
  end
  if l>=s
    c = e;
    s = l;
  end
end

Not that this affects the positions at all, but there seem to have
been server errors again, since this entry was identical to the
winner when it was submitted other than changing an Inf for a 99:


2003-11-06 11:45:01 99 Alex Backer Failed (execution) 0.0000 0.0000
0.00 Error using ==> runcontest "c" does not contain the correct
path

I also missed most of contest because I got an important phone
call...


So, hereby my own home-grown home-tweaked solution of 133 characters:


l=b*[1;i];
w=l'~=NaN;
d=w*inf;
d(1)=0;
D=abs(l*w-w'*l.')*1./a;
for p=w
  d=min(D+d'*w);
end
a=1./a;
[k,j]=max(d);
c=j;
while j~=1
  [k,j]=min(d .* a(j,:));
  c=[j c];
end


Bert


bert.jagers at wldelft.nl

Now that I look at it, that probably wasn't the best choice for an
error message. The path that the error message is referring to is
the path in the puzzle, not the computer path.


In other words, there was no server error...the entry failed because
the code returned the wrong answer.


Alex Backer wrote:
>
>
> Not that this affects the positions at all, but there seem to have
> been server errors again, since this entry was identical to the
> winner when it was submitted other than changing an Inf for a 99:
>
> 2003-11-06 11:45:01 99 Alex Backer Failed (execution) 0.0000 0.0000
> 0.00 Error using ==> runcontest "c" does not contain the correct
> path

Nice!
Here's 2 tweaks reducing it a bit further:


Niilo Sirola wrote:


> n=trace(a);
> s=0;
> for i=2:n
> l=99;
> for r=2:n
> for d=nchoosek([2 2 2:i-1 i+1:n],r-2)'
> d = [1 d' i];
> u = d(1:r-1);
> v = d(2:r);
> if diag(a(u,v))
> m=norm(b(u,:)-b(v,:),'fro');
> if m<l
> e = d;
> l = m;
> end
> end
> end
> end
> if l>=s
> c = e;
> s = l;
> end
> end

And it can be made shorter!! This version based on yours is only 121.
If 99 is enough instead of 9e9 in the second linethen 120.


 l=b*[1;i];
 w=l'<9e9;
 d=w*inf;
 d(1)=0;
 D=abs(l*w-w'*l.')./a;
 for p=w
 d=min(D+d'*w);
end
  [k j]=max(d);
 c=j;
 while j>1
 [k j]=min(d ./ a(j,:));
 c=[j c]
end


Imre

Sorry, but I just ran it against the test suite, and it does not
return the correct 'path' for all of the test cases.


Mike


Bert Jagers wrote:
>
>
> I also missed most of contest because I got an important phone
> call...
>
> So, hereby my own home-grown home-tweaked solution of 133
> characters:
>
> l=b*[1;i];
> w=l'~=NaN;
> d=w*inf;
> d(1)=0;
> D=abs(l*w-w'*l.')*1./a;
> for p=w
> d=min(D+d'*w);
> end
> a=1./a;
> [k,j]=max(d);
> c=j;
> while j~=1
> [k,j]=min(d .* a(j,:));
> c=[j c];
> end
>
> Bert
>
> bert.jagers at wldelft.nl

Same as its parent...fails the test suite.


Mike


Imre Polik wrote:
>
>
> And it can be made shorter!! This version based on yours is only
> 121.
> If 99 is enough instead of 9e9 in the second linethen 120.
>
> l=b*[1;i];
> w=l'<9e9;
> d=w*inf;
> d(1)=0;
> D=abs(l*w-w'*l.')./a;
> for p=w
> d=min(D+d'*w);
> end
> [k j]=max(d);
> c=j;
> while j>1
> [k j]=min(d ./ a(j,:));
> c=[j c]
> end
>
> Imre

Here is a 132-char entry based on my "FG" entry (which does not work
because x' is not the same as x.')


x=b*[1;i];
n=1:numel(x);
d=n/0;
d(1)=0;
for y=n
   for j=n
       w = d(j)+abs(x.'-x(j));
       t = (w < d) & a(j,:);
       p(t) = j;
       d(t) = w(t);
   end
end
[y m]=max(d);
c=m;
while c>1
    c = [p(c) m];
end


Mike, does it pass the test suite ?


Francois

I think Bert just made a tiny mistake. Try this:


l=b*[1;1];
 w=l'<Inf;
 d=w*inf;
 d(1)=0;
 D=abs(l*w-w'*l.')./a;
 for p=w
 d=min(D+d'*w);
end
  [k j]=max(d);
 c=j;
 while j>1
 [k j]=min(d ./ a(j,:));
 c=[j c]
end

That works...at the risk of being a killjoy, I am going to have to
decline any more requests to run entries that didn't make it by the
deadline. We still have one more hole to go.


Never fear, the full test suites will be posted to the File Exchange
tomorrow.


Mike


Francois Glineur wrote:
>
>
> Here is a 132-char entry based on my "FG" entry (which does not
> work
> because x' is not the same as x.')
>
> x=b*[1;i];
> n=1:numel(x);
> d=n/0;
> d(1)=0;
> for y=n
> for j=n
> w = d(j)+abs(x.'-x(j));
> t = (w < d) & a(j,:);
> p(t) = j;
> d(t) = w(t);
> end
> end
> [y m]=max(d);
> c=m;
> while c>1
> c = [p(c) m];
> end
>
> Mike, does it pass the test suite ?
>
> Francois

I meant this. But I haven't fully analyzed Bert's code, it's just
based on a couple of test examples.


> l=b*[1;6];
> w=l'<Inf;
> d=w*inf;
> d(1)=0;
> D=abs(l*w-w'*l.')./a;
> for p=w
> d=min(D+d'*w);
> end
> [k j]=max(d);
> c=j;
> while j>1
> [k j]=min(d ./ a(j,:));
> c=[j c]
> end

Alex wrote:
> I meant this. But I haven't fully analyzed Bert's code, it's just
> based on a couple of test examples.
>
>> l=b*[1;6];


No, I don't think this will work. At least conceptually you need to
go to complex space. To get the distances right.


I willy surely use the full test suite when it posted tomorrow to
find out what went wrong in my code.


Bert

Alex Backer wrote:
>
>
> I think Bert just made a tiny mistake.


As Mike said, we'll post the complete tets suite tomorrow, but here
is an example from the test suite that shows where this code fails.


a = [ ...
1 1 0 0 0 0 0 1 0 0 1
1 1 0 1 0 0 0 0 0 0 0
0 0 1 1 0 0 0 0 0 0 0
0 1 1 1 1 0 1 0 0 0 0
0 0 0 1 1 1 0 0 0 0 0
0 0 0 0 1 1 1 0 0 0 0
0 0 0 1 0 1 1 1 0 1 0
1 0 0 0 0 0 1 1 1 0 1
0 0 0 0 0 0 0 1 1 1 0
0 0 0 0 0 0 1 0 1 1 0
1 0 0 0 0 0 0 1 0 0 1 ];


b = [ ...
10 2
13 2
17 1
17 3
19 4
18 7
14 6
12 4
12 7
14 8
1 6 ];


The most distant point from p1 (10,2) is p11 (1,6). Unfortunately the
code here is saying it is p6 (18,7).


-Ned.

> And it can be made shorter!! This version based on yours is only
> 121.


That's indeed much shorter still. Pitty of the fact that both codes
don't run correctly.
I will surely use the full test suite when it posted tomorrow to find
out what went wrong.


Bert

Ned Gulley wrote:
>
>
> As Mike said, we'll post the complete tets suite tomorrow, but here
> is an example from the test suite that shows where this code fails.
>
> a = [ ...
>
> b = [ ...
>
> The most distant point from p1 (10,2) is p11 (1,6). Unfortunately
> the
> code here is saying it is p6 (18,7).
>
> -Ned.


The only way that I can make my code give that answer is to set
i=1,2,3 or 4. That suggests that i is used as a variable somewhere
else and I should have used 1i. But why should Francois Glineur's
code then work fine? ... still puzzling ...


Oh, wait the new hole is open ...


Bert

"snake" doesn't seem to require you keep track of bifurcations... at
least the current leader doesn't give (what i consider to be) the
right answer for this.


a = [ 1 2 3
       4 3 4
       5 6 2]

Great Rumpuscat wrote:
> the current leader doesn't give (what i consider to be) the
> right answer for this.
>
> a = [ 1 2 3
> 4 3 4
> 5 6 2]


agreed, and even more annoyingly, my entry gives the correct answer
for this and the other 2 example problems, but still fails somehow as
i skipped the braching bit ;)

I agree, the basic greedy approach (try right then left, down, up)
seems to work on the whole test suite, which I think is a pity, since
it makes the problem a lot simpler !


Small counterexample for cyclist :
a=[1 2
   2 2
   3 1]


Let's go for an hour of tweaking ...

Forgive me, father, for I have tweaked.


I have tweaked more than 40 times since my last confession.


I am so ashamed.


At one point in my life, I had an original entry. (I even made the
"palindrome" leader board!)


I resolve to tweak no more, but I am not sure I can stop myself.


====


This is a serious sin, my son, but I absolve you. Say three Hail
Molers.

I had an interesting idea yesterday. Try to reverse engineer these
codes.


If a is a matrix input, what will be in b?


I think the winning codes would give a bit of a headache without
knowing the problem...


Not taking into account if the code doesn't really do what is
expected but still passes the test set.


Imre

To the Mathworks : will we get again the used testsuites (long) after
the contest? Some "nicer" working programs (in development) were not
worth for further development, because the code became to big. But
to know if those codes passed the test, I will be interested (again)
in the testsuites (to see what passes (wrongly) and what doesn't
pass)..

Just missed my last attempt at 115 chars:


[h w b]=size(a);
for i=1:h*w
   c=[];
   while i
      i=i(1);
      c =[c; i];
      t = i+[-h h -1 1];
      i = t(a(t(t>0&t<=h*w))==(a(i)+1));
   end
   if nnz(c)>nnz(b)
      b=c;
   end
end


Oh well, till next time...

Whoa! It's over. A bit frustrating with the queue over an hour
behind, still don't know if I'm doing fine or not. At last I started
seeing my original code in other people's entries too :) However,
looks like Nicke will take the jackpot with his well-timed Revolution
IV. Well done.

With the long queue we can start a sideshow betting who will win. I
believe it will be 'x12 tweak tweak' by Guy Shechter.


This contest format was fun. Although I prefer a contest were time,
accuracy and yes, code size, play a role in the final score. Maybe
an exponential function for the code size score such that going from
35 to 36 characters will not affect the score but going from 1000 to
1001 will be fatal.


Paulo


Niilo Sirola wrote:
>
>
> Whoa! It's over. A bit frustrating with the queue over an hour
> behind, still don't know if I'm doing fine or not. At last I
> started
> seeing my original code in other people's entries too :) However,
> looks like Nicke will take the jackpot with his well-timed
> Revolution
> IV. Well done.

Paulo wrote:
> I
> believe it will be 'x12 tweak tweak' by Guy Shechter.


As the person behind the first tweak I have to say I'm not all that
happy how it turned out.I don't work well under time pressure so it
got worse, but perhaps I was on to something.

Paulo wrote:

> With the long queue we can start a sideshow betting who will win.
> I
> believe it will be 'x12 tweak tweak' by Guy Shechter.


According to my calculations x12 = 118chars and 'x12 tweak tweak' =
121chars

Another idea for the snake hole (using matrices) :


[m n i]=size(a);
l = diff(a')';l=l(:);
e=diff(a);e(m,n)=0;u=e(:);
r=find(l == 1);
s=find(l == -1);
t=find(u == 1);
u=find(u == -1);
F=sparse([r;s+m;t;u+1],[r+m;s;t+1;u],1,m*n,m*n);
G{i}=F;
while any(G{i}(:))
   i=i+1;
   G{i} = G{i-1}*F;
end
[b e] = find(G{i-1});
b(i,1)=e;
for j = 2:i-1
   b(j) = find(F(b(j-1),:) & G{i-j}(:, e)');
end


Very fast but hopelessly too long ...


Francois

This code seems too long. Unfortunately, most top codes are not
considered with bifurcation. Here is a code of 191 length twisted
from my submission "Bellman", which for some reason was failed by the
server.


[n m]=size(a);
[s t]=sort(a(:));
q=t./t;
p=num2cell(1:n);
for k=t'
    [i,j]=ind2sub(n,k);
    I=k+[n*[j<m -(j>1)] i<n -(i>1)];
    K=(a(I)+1)==a(k);
    if sum(K)
        J=I(K);
        [v u]=max(q(J));
        q(k)=v+1;
        p{k}=[p{J(u)};k];
    end
end
[g h]=max(q);
b=p{h};


Francois Glineur wrote:
>
>
> Another idea for the snake hole (using matrices) :
>
> [m n i]=size(a);
> l = diff(a')';l=l(:);
> e=diff(a);e(m,n)=0;u=e(:);
> r=find(l == 1);
> s=find(l == -1);
> t=find(u == 1);
> u=find(u == -1);
> F=sparse([r;s+m;t;u+1],[r+m;s;t+1;u],1,m*n,m*n);
> G{i}=F;
> while any(G{i}(:))
> i=i+1;
> G{i} = G{i-1}*F;
> end
> [b e] = find(G{i-1});
> b(i,1)=e;
> for j = 2:i-1
> b(j) = find(F(b(j-1),:) & G{i-j}(:, e)');
> end
>
> Very fast but hopelessly too long ...
>
> Francois

2-3 hour seems too short to develop a good algorithm. Once a hole
opens, you will be pushed to twist other's code. How about to publish
the question one or two hours ahead of the official hole opening
time? In this way, authors can twist their own code before submit it.


-Yi


Ned Gulley wrote:
>
>
> Let me ask the general question: if you have a good problem, a good
> test suite, and a responsive server (a challenge for us today), do
> you prefer the short golf puzzles to the long contests?
>
> Short puzzles converge more quickly and can run out of gas after
> only
> an hour or so, but the long puzzles can result in impenetrable
> jungles of code. Which do you prefer?
>
> Naturally, we will keep working on the obvious problems, but we're
> curious to know what format to focus on in the future.
>
> -Ned Gulley.
> The MATLAB Contest Team

Stijn Helsen wrote:
>
>
> I can't wait for the result, but if "Whatever $\pi$" will win, it's
> a
> pitty that that didn't show up earlier (for the tweakers of us).


I'll just mention here that "Whatever $\pi$"
was in itself a tweak. Due to the long
queue it was hard to tell if entries in
the queue were good candidates, so I just
picked a shortish one and trimmed off a
few characters, without realling putting
that much effort into understanding it.


Nicke

I think this is an interesting idea. I would prefer 1 or 2 days (or
even longer) though. 2-3 hours is too short for me, but apparently
not for Per and others. A deeply humbling contest!


Yi Cao wrote:
>
>
> 2-3 hour seems too short to develop a good algorithm. Once a hole
> opens, you will be pushed to twist other's code. How about to
> publish
> the question one or two hours ahead of the official hole opening
> time? In this way, authors can twist their own code before submit
> it.

As promised, the code to generate the full testsuites for each of the
holes is now available from the File Exchange.

<http://www.mathworks.com/matlabcentral/fileexchange/loadFile.do?objectId=4125&objectType=FILE>

Enjoy,
Mike

If you have to start twisting other's code from the beginning, how
can others have made their code then?
For the (low) complexity of the problems, 2-3 hours should be enough.
 That can also be seen on the final codes. Maybe some final
optimisations can be done, but it won't be much.
Fast working is one of the good things in such contests.


Yi Cao wrote:
> 2-3 hour seems too short to develop a good algorithm. Once a hole
> opens, you will be pushed to twist other's code.

I agree with Stijn, 2-3 hours seems like a good length, and the
graph-constrained network diameter problem in the Thu AM problem was
nice.


I developed original code for it, but after it was found to be
invalid for the contest due to the ban on recursion, the tentation
not to develop something new from scratch when a working entry is
there already to tweak is too great. If the scoring system had prized
more efficient algorithms or the test suite had disallowed short
entries that cut corners, there might have been an incentive to keep
developing original code, but as it was, the length limitation was
too great to start developing from scratch.


Stijn Helsen wrote:
>
>
> If you have to start twisting other's code from the beginning, how
> can others have made their code then?
> For the (low) complexity of the problems, 2-3 hours should be
> enough.
> That can also be seen on the final codes. Maybe some final
> optimisations can be done, but it won't be much.
> Fast working is one of the good things in such contests.
>
> Yi Cao wrote:
>> 2-3 hour seems too short to develop a good algorithm. Once a
hole
>> opens, you will be pushed to twist other's code.

Rereading a post by Ned during the April contest, I can see the
struggle by our kind Mathworks hosts to find a fair and fun scoring
system. Since CPU time could be iffy at short time scales, you
introduced the unambiguous entry length system. And yet I don't think
that is the ideal solution, because although it is fun during the
moment to try to find a way to eliminate a few characters, I don't
think it's the kind of rewarding fun of writing good algorithms, and
I don't think the incentive to write unreadable short code is what
you're looking for, either. Perhaps problems where it's really hard
to get it right for all test cases, so people can continue to
innovate right to the end and scoring can be made by how many test
cases a program gets right, would be nice to try. Someone's previous
suggestion of changing test suites would be nice too to prevent
overfitting. That way we'd keep looking for a solution to the stated
problem, not a way to work around the things that the Mathworks
people forgot to think about. I would still keep the contest length
about 3 hours. So perhaps the right balance for my taste is a mix
between some of the features of the old contests and the new one.


Thanks for the fun!

"Stijn Helsen" <SHelsenaaa___aaa@abc__compuserve.com> writes:

> If you have to start twisting other's code from the beginning, how
> can others have made their code then?
> For the (low) complexity of the problems, 2-3 hours should be enough.
> That can also be seen on the final codes. Maybe some final
> optimisations can be done, but it won't be much.
> Fast working is one of the good things in such contests.
>
>
> Yi Cao wrote:
>> 2-3 hour seems too short to develop a good algorithm. Once a hole
>> opens, you will be pushed to twist other's code.


So the problem is, a good solid original solution might take 2 hours
to develop. Then if it takes another two hours to make it through the
queue, that's your only shot at seeing if it works. So it's much
safer to hack on someone's quick and working entry.

A faster queue or a more complete published test set or a longer run
length would help this. So would a separate "write-only" phase where
EVERYONE tries their own original solution.


--
Peter Boettcher <boettcher@ll.mit.edu>
MIT Lincoln Laboratory
MATLAB FAQ: http://www.mit.edu/~pwb/cssm/

"Stijn Helsen" <SHelsenaaa___aaa@abc__compuserve.com> wrote:

> If you have to start twisting other's code from the beginning,
> how can others have made their code then? For the (low)
> complexity of the problems, 2-3 hours should be enough.

I agree. 2 hours for the smaller and 3 hours for the other
problems was just fine.

Peter

--
Why does MATLAB have a "sin" function, but no "forgive" function?

Alex <alex@caltech.edu> wrote:

> [...] although it is fun during the moment to try to find a way
> to eliminate a few characters, I don't think it's the kind of
> rewarding fun of writing good algorithms, and I don't think the
> incentive to write unreadable short code is what you're looking
> for, either.

Developing good algorithms is what you do all the rest of the
time, isn't it? I think it was great that the objective of the
contest was minimizing character count. Sure it's silly, but I
think it was fun, and juding from the number of participants, so
did many others.

There are other contests that focus on algorithm speed and
quality, but *all* contests don't have to be like that.

Peter

--
Why does MATLAB have a "sin" function, but no "forgive" function?

Peter Boettcher <boettcher@ll.mit.edu> wrote:

> A faster queue or a more complete published test set or a longer
> run length would help this.

Personally, I'd prefer a faster queue. The race against the clock
was stressful, but to me it was a part of the fun. The one hour
lag in the server was just frustrating.

Peter

--
Why does MATLAB have a "sin" function, but no "forgive" function?

Peter J. Acklam wrote:


> There are other contests that focus on algorithm speed and
> quality, but *all* contests don't have to be like that.
None of them are in MATLAB, or are they? And you can't beat MATLAB
for sheer fun and fast programming.


> Why does MATLAB have a "sin" function, but no "forgive" function?
It's called undo.


Cheers.

Peter J. Acklam wrote:

>> A faster queue or a more complete published test set or a
longer
>> run length would help this.
>
> Personally, I'd prefer a faster queue. The race against the clock
> was stressful, but to me it was a part of the fun. The one hour
> lag in the server was just frustrating.
>
> Peter


I agree w/Peter.

Peter J. Acklam wrote:
> Developing good algorithms is what you do all the rest of the
> time, isn't it? I think it was great that


Sometimes. Is it bad to love what I do?

Alex <alex@caltech.edu> wrote:

> Peter J. Acklam wrote:
>
> > Developing good algorithms is what you do all the rest of the
> > time, isn't it? I think it was great that
>
> Sometimes. Is it bad to love what I do?

Yes, that is bad. Very bad. It should be nothing but blood,
toil, tears, and sweat.

Ok, maybe not. I enjoy writing clever algorithms too, but I also
like doing other things for a change. Other MATLAB contests have
focused on speed, where clever algorithms play a cruicial part.

Peter

--
Why does MATLAB have a "sin" function, but no "forgive" function?

Alex <alex@caltech.edu> wrote:

> Peter J. Acklam wrote:
>
> > There are other contests that focus on algorithm speed and
> > quality, but *all* contests don't have to be like that.
>
> None of them are in MATLAB, or are they? And you can't beat
> MATLAB for sheer fun and fast programming.

At least there have been contests where the score was a weighted
sum of the quality of the solution and the execution time.

> > Why does MATLAB have a "sin" function, but no "forgive" function?
>
> It's called undo.

   » which undo
   undo not found.

:-)

Peter

--
Why does MATLAB have a "sin" function, but no "forgive" function?

Peter J. Acklam wrote:
>> > Why does MATLAB have a "sin" function, but no "forgive"
> function?
>>
>> It's called undo.
>
> » which undo
> undo not found.
>
> :-)
>
> Peter


File "undo":
   <http://www.mathworks.com/matlabcentral/fileexchange/loadFile.do?objectId=4084>


Alex ;-)