Thread Subject:

MATLAB Central Spring Contest

Just a reminder to let everyone know that the Spring Contest
launches tomorrow, Wednesday May 30th at high noon. Be
there or be square!

See you then!
Helen

Helen Chen wrote on 29-Apr-08 14:05 :
> Just a reminder to let everyone know that the Spring Contest
> launches tomorrow, Wednesday May 30th at high noon.

perhaps it does, on -your- planet. but on /this/ one, May 30th doesn't
arrive for another 30 days.

"D. Ismay" <!@a.com> wrote in message
<cuSdnYaj8fQSI4rVnZ2dnUVZ_qqgnZ2d@earthlink.com>...
> Helen Chen wrote on 29-Apr-08 14:05 :
> > Just a reminder to let everyone know that the Spring
Contest
> > launches tomorrow, Wednesday May 30th at high noon.
>
> perhaps it does, on -your- planet. but on /this/ one,
May 30th doesn't
> arrive for another 30 days.

Sorry about that, yes, I got over excited looking at the
calendar!

But still, the time has arrived. The contest begins..

The contest home page is at
http://www.mathworks.com/contest/wiring/home.html .
This page includes important links including the blog,
rules, and the contest queue.

If you've participated in the contest before, you can get
started right now by going right to the rules page at
http://www.mathworks.com/contest/wiring/rules.html .

Good luck to everyone!

Helen

Good luck everyone. Looks to be yet another interesting
contest. I'll try to do a mid contest commented code this
weekend as usual, however I might be a little tied up in
trying to teach MATLAB to the newest contest participant, my
new daughter Katie who was born on Monday;)

"Alan Chalker" <alancNOSPAM@osc.edu> wrote in message
<fva6u4$r8i$1@fred.mathworks.com>...
> Good luck everyone. Looks to be yet another interesting
> contest. I'll try to do a mid contest commented code this
> weekend as usual, however I might be a little tied up in
> trying to teach MATLAB to the newest contest participant, my
> new daughter Katie who was born on Monday;)

Congratulations, Alan!

And good luck to everyone, of course. :)

srach

"Helen Chen" <helen.chen@mathworks.com> wrote in message
<fv82i0$nql$1@fred.mathworks.com>...
> Just a reminder to let everyone know that the Spring Contest
> launches tomorrow, Wednesday May 30th at high noon. Be
> there or be square!
>
> See you then!
> Helen

The rules state that this is based on
"the problem of wiring up printed circuit boards"

How does one "wire up"? Is it possible to "wire down" as
well? Or perhaps "wire in" or "wire out"?

I'm just being picky. Terms such as "wire up", "connect up",
etc. are not grammatically correct. The word "up" is not
needed. Just drop it:

"the problem of wiring printed circuit boards"

This is similar to the phrase "In order to...", just drop
the first two words "To..."

I've written books with both of these things in them. The
copy editors strike them out immediately. I am now working
on my 11th book, and I finally learned to avoid these before
the copy editor sees them. :-)

p.s., this looks like a great contest. I like the penalties
for poor coding!

Duane Hanselman

"Alan Chalker" <alancNOSPAM@osc.edu> wrote in message
<fva6u4$r8i$1@fred.mathworks.com>...
> Good luck everyone. Looks to be yet another interesting
> contest. I'll try to do a mid contest commented code this
> weekend as usual, however I might be a little tied up in
> trying to teach MATLAB to the newest contest participant,
my
> new daughter Katie who was born on Monday;)

Congratulations!

SY

Oops, I just posted this comment to the wrong place, so now
I'll post it here (sorry)...

Shouldn’t the last line of this part of the instructions
say [ 4 5 4 6] ?

The segments for the connector between the 8 pins could be
written like so.
w = [ 2 3 2 4 ]
[ 2 4 3 4 ]
[ 3 4 3 5 ]
[ 3 5 4 5 ]
[ 4 5 5 6 ]

Andy:

That is correct, thanks for the clarification.

Lucio
The MathWorks Constest Team

"Andy Johnson" <matman@summitsolutions.net> wrote in
message <fvaatj$bdc$1@fred.mathworks.com>...
> Oops, I just posted this comment to the wrong place, so
now
> I'll post it here (sorry)...
>
> Shouldn’t the last line of this part of the instructions
> say [ 4 5 4 6] ?
>
> The segments for the connector between the 8 pins could
be
> written like so.
> w = [ 2 3 2 4 ]
> [ 2 4 3 4 ]
> [ 3 4 3 5 ]
> [ 3 5 4 5 ]
> [ 4 5 5 6 ]
>
>

Duane Hanselman wrote:
[...]
> The rules state that this is based on
> "the problem of wiring up printed circuit boards"
>
> How does one "wire up"? Is it possible to "wire down" as
> well? Or perhaps "wire in" or "wire out"?
>
> I'm just being picky. Terms such as "wire up", "connect up",
> etc. are not grammatically correct. The word "up" is not
> needed. Just drop it:
>
> "the problem of wiring printed circuit boards"
>
> This is similar to the phrase "In order to...", just drop
> the first two words "To..."

You think that's bad? News anchor's favorite lines/words:

1. "...each and every..." (how are they different?)
2. "...first and foremost..." (can you have a 'last and foremost'?)
3. "...ramification..." (but not 'implication'?)
4. Everything has "impact", but nothing has "effect".
5. "...incredible!" (literal meaning, "not credible")
6. "...massive..." (while describing objects that
do not posses mass)
7. "There's..." (contraction of "there is", for
plural case)
8. 'behaviors', 'moneys', 'winds', 'rains', 'foods', 'fruits',
'medicines', when all
of these are group nouns and don't change spelling for plural case.

And it gets better -- those people are in a profession that, you would
expect, demands above-average understanding and proper use of
English and commonly-known rules of grammar.

Go figure.
--
D. Ismay

One question:
Bridges are expensive: they cost 25 points each. In this
diagram we've saved 22 points by connecting the two 11 pins,
but we had to buy three connectors and a bridge, for a total
cost of 28. The net score for this move is 17 ...

Should it be 25+3-(11*2) = 6 ?

Using bridge will also lose credit?

Thanks

In article <a8SdnUuVdO93WIXVnZ2dnUVZ_h-vnZ2d@earthlink.com>,
D. Ismay <noSpam@Woohoo.Woohoohoo.Woohoo.Woohoohoo.HOOHOO.hoohoo.Woohoo.Woohoohoo> wrote:

>8. 'behaviors', 'moneys', 'winds', 'rains', 'foods', 'fruits',
>'medicines', when all
>of these are group nouns and don't change spelling for plural case.

You are wrong about each of the words you list.


http://www.oed.com

Note: in the below quotations, some non-ASCII letters disappeared,
especially eth and thorn. Sorry.


behaviour, n

  1b. Also in pl.

  1538 BALE Comedy in Harl. Misc. (Malh.) I. 211 Your fastynges,
  longe prayers, with other holy behauers. 1601 SHAKES. Jul. C. I.
  ii. 42 Which giue some soyle (perhaps) to my Behauiours. 1678
  CUDWORTH Intell. Syst. I. iv. S19. 366 To observe the actions,
  manners and Behaviours of men. a1763 `GEO. PSALMANAZAR' Mem. (1764)
  186, I could see..thro' all his artifices and different behaviours.
  1959 Camb. Rev. 7 Mar. 405/1 We must surely accept that the pattern
  of associated behaviours first noticed by Weber was one of the most
  brilliantly successful suggestions in the whole history of
  intellectual endeavour.

money, n

  2e. Chiefly Horse Racing and Gambling (orig. U.S.). With
  preceding ordinal number: the prize or prize money associated
  with finishing in the placing denoted by the number in a
  competitive event; this placing itself. [...] 1894 Vermont Agric.
  Rep. 14 96 He trotted in seventeen races..; won nine first
  moneys.

  3. In pl. (now chiefly in legal and quasi-legal parlance). Sums
  or quantities of money.

  c1384 Bible (Wycliffite, E.V.) (Douce 369(2)) 2 Macc. iii. 6
  Tolde to hym the tresorie in Jerusalem for to be ful with moneys
  [L. pecuniis] vnnoumbreable. 1593 Acct. Bk. W. Morton f. 69,
  Reseuet..iii scor ane stane of tolone ane pound les, of moneyes
  is sum Ic honderis xxxiiii lib. 4s. 1600 SHAKESPEARE Merchant of
  Venice I. iii. 115 You come to me, and you say, Shylocke, we
  would haue moneyes. 1625 BACON Ess. (new ed.) 246 No Man will
  Lend his Moneyes farre off, nor put them into Vnknown Hands. 1632
  W. LITHGOW Totall Disc. Trav. IV. 140 [He] furnished him with
  great moneys, and other necessaries. 1734 tr. C. Rollin Anc.
  Hist. (1827) VIII. XIX. v. 163 To make him a present of the
  monies arising from that sale. 1794 R. CUMBERLAND Jew II. ii. 24,
  Why truly, monies is a good thing. 1819 SCOTT Ivanhoe I. x*. 208
  `O,' said the Jew, `you are come to pay monies... And from whom
  dost thou bring it?' 1822 BYRON Werner II. ii, But to steal The
  moneys of a slumbering man! 1865 Morning Star 3 Feb. 3/5 A young
  woman, was charged..with stealing from the person of Robert
  Tharston,..7s. 6d., his moneys. 1871 R. ELLIS tr. Catullus Poems
  xxix. 22 Is not all his act To swallow monies, empty purses heap
  on heap? 1927 A. H. MCNEILE Introd. New Test. 132 Schmirdel
  objects that it would have been quite irrational to convey monies
  from South Galatia to Jerusalem by way of Macedonia. 1959 Times
  Rev. Industry Mar. 4/3 There is an ambivalence in the claims on
  promotional moneys, for the furtherance of distribution on the
  one hand and for the extension of advertising on the other. 1990
  J. MCGAHERN Amongst Women 55 He..started to tot up all the monies
  he presently held against the expenses he had.


wind, n. (1)

  1. Air in motion; a state of movement in the air; a current of
  air, of any degree of force perceptible to the senses, occurring
  naturally in the atmosphere, usually parallel to the surface of
  the ground. a. In general or collective sense. [...]
  (b) pl. pl. c825 Vesp. Psalter xvii[i]. 11 [10] Volavit super
  pinnas ventorum, fle ofer firu winda. 971 Blickl. Hom. 51 as
  windas & as renas syndon ealle his. a1300 Cursor M. 22630 Windes
  on ilk side sal rise. 1390 GOWER Conf. I. 34 Right now the hyhe
  wyndes blowe. c1460 J. METHAM Wks. (1916) 157 [I]ff Crystemes day
  falle vp-on Moneday, yt schuld be a gret wyntyr, and fulle off
  wyindys. a1593 MARLOWE Ovid's Elegies II. xi, Hither the winds
  blow, here the spring-tide roar. a1614 J. MELVILL Autob. & Diary
  (Wodrow Soc.) 261 The Lord of Armies, wha ryddes upon the winges
  of the woundes. 1638-56 COWLEY Davideis I. Notes, Wks. 1710 I.
  357 The Matter of Winds is an Exhalation arising out of the
  Concavities of the Earth. 1748 GRAY Alliance 43 Command the
  Winds, and tame th' unwilling Deep. 1830 TENNYSON Ode to Memory
  14 The dew-impearled winds of dawn. 1860 TYNDALL Glac. II. viii.
  263 The lighter de'bris is scattered by the winds far and wide
  over the glacier.


rain, n. (1)

  2. pl. a. Showers of rain; rainfalls. a900 O.E. Martyrol. 20 Mar.
  40 aere lyfte ecynd is aet heo teh to a renas of aem sealtan sae.
  971 Blickl. Hom. 51 as windas & as renas syndon ealle his. 1154
  O.E. Chron. (Laud MS.) an. 1098 urh mycele renas e ealles eares
  ne ablunnon. c1200 Vices & Virtues 143 Godd..wiheld alle reines
  rie hier & six monees. a1340 HAMPOLE Psalter civ. 30 He set aire
  raynys haghil. c1400 MANDEVILLE (Roxb.) vii. 23 are es na
  trubling of e aer thurgh raynes. 1556 Chron. Gr. Friars (Camden)
  2 Thys yere felle gret raynes. 1625 N. CARPENTER Geog. Del. II.
  i. (1635) 5 The extraordinary Raines and showers which those
  places suffer. 1738 GRAY Tasso 10 Swoll'n with new force and late
  descending rains. 1878 HUXLEY Physiogr. 48 The heavy tropical
  rains are usually confined to definite periods. Prov. 1846
  DENHAM Prov. (Percy Soc.) 54 Many rains, many rowans.


food, n.

  1. e. An article of food; a kind of food.
  1393 GOWER Conf. III. 26, I you shall reherce, How that my fodes
  ben diverse. c1449 PECOCK Repr. III. v. 303 Hauyng foodis..be we
  content. 1526 Pilgr. Perf. (W. de W. 1531) 5b, God sent from
  heuen a swete fode for theyr brede called manna. 1617 MARKHAM
  Caval. I. 56 In England..we have so many choyces of good foodes.
  1674 N. COX Gentl. Recreat. IV. (1677) 45 The larger the Pike the
  courser the food. 1754 Dict. Arts & Sc. II. 1288 Foods proper for
  preserving health. 1887 Cassell's Fam. Physician 911 What are the
  proper fuels, or foods, with which to supply it [the human
  machine].


fruit, n.

  1. Vegetable products in general, that are fit to be used as food
  by men and animals. Now usually in pl. Also fruits of the earth
  or the ground.
  c1375 Lay Folks Mass Bk. (MS. B.) 392 o froytes of o erthe make
  plentuus. 1549 Bk. Com. Prayer, Litany, That it may please thee
  to give and preserve to our use the kindly fruits of the earth.
  1648 GAGE West Ind. xii. 43 The answer of our Queene
  Elizabeth..to some that presented unto her of the fruits of
  America. 1665 Ord. Mayor Lond. in De Foe Plague (1840) 46 That
  no..musty corn, or other corrupt fruits..be suffered to be sold.
  1725 WATTS Logic I. vi. S3 If the husk or seeds are eaten, they
  are called the fruits of the ground. 1791 T. NEWTE Tour Eng. &
  Scot. 196 At Aberdeen, turnips, carrots, and potatoes, pass,
  among the common people, by the name of fruit. 1859 JEPHSON
  Brittany ii. 20 The Breton peasant can turn all the fruits of the
  earth to account. c1374 CHAUCER Former Age 3 They helde hem
  paied of the fructes at ey ete. 1500-20 DUNBAR Poems xiv. 63
  Quhilk slayis the corne and fruct that growis grene. fig. c1374
  CHAUCER Boeth. I. pr. i. 3 (Camb. MS.) Thise ben tho
  that..destroyen the corn plentyuos of fruites of resone. 1559
  Mirr. Mag., Hen. VI, xxxix, See here the pleasaunt fruytes that
  many princes reape. 1707 WATTS Hymn, `Come, we that love the
  Lord' viii, Celestial Fruits on earthly Ground From Faith and
  Hope may grow.

  2. The edible product of a plant or tree, consisting of the seed
  and its envelope, esp. the latter when it is of a juicy pulpy
  nature, as in the apple, orange, plum, etc. tree of fruit =
  fruit-tree. As denoting an article of food, the word is
  popularly extended to include certain vegetable products that
  resemble `fruits' in their qualities, e.g. the stalks of
  rhubarb.
  b. with a and pl., as denoting a kind of fruit.
  1375 BARBOUR Bruce x. 191 The treis..Chargit vith froytis on
  syndri viss. c1400 Lanfranc's Cirurg. 261 ou schalt purge colre
  wi a decoccioun of fretis. c1460 J. RUSSELL Bk. Nurture 667
  Speke..For frutes a-fore mete to ete em fastyngely. 1527 R.
  THORNE in Hakluyt Voy. (1589) 252 Our fruites and graines be
  Apples, Nuts, and Corne. 1650 FULLER Pisgah I. iv. 11 Dates,
  Almonds..Nuts..Pomegranates and other severall fruits. 1795
  Gentl. Mag. 540/1 The glow of ripe fruits and declining leaves
  mark the autumn. 1842 TENNYSON Gardener's Dau. 190 Fruits and
  cream served in the weeping elm. 1858 HOMANS Cycl. Commerce 886
  This fruit [currants] is of a violet colour, and hangs in long
  loose bunches. 1475 Bk. Noblesse 70 Planted withe treis of
  verdure of divers fructis. 1585 JAS. I Ess. Poesie (Arb.) 14 To
  taste, and smell..Delicious fruictis, whilks in that tyme abound.
  1596 DALRYMPLE tr. Leslie's Hist. Scot. I. 6 Excepte spice and
  Vine, and sum fructes.


medicine, n. (1)

  1. a. A substance or preparation used in the treatment of
  illness; a drug; esp. one taken by mouth. Also: such substances
  generally. Also in extended use.
  a1398 J. TREVISA tr. Bartholomaeus Anglicus De Proprietatibus
  Rerum (BL Add.) f. 99, Skabbe is curable wi metisines at..clensi
  wiinne & wioute. 464 M. PASTON in Paston Lett. (1971) I. 291 For
  Goddys sake be war what medesyns ye take of any fysissyanys of
  London. 1513 H. BRADSHAW Lyfe St. Werburge II. 853 All phisike
  and medicyns were founde to her in vayne. 1617 J. WOODALL
  Surgions Mate 4 Haue ready your medicines to binde vp the wound
  againe. 1741-3 J. WESLEY Extract of Jrnl. (1749) 15 One of the
  mistresses lay..near death, having found no help from all the
  medicines she had taken.

{There are two additional meanings listed that take the plural,
but which I have not quoted here as both are marked as Obs.}
--
  "When we all think alike no one is thinking very much."
                                              -- Walter Lippmann

Hi,

are there any limitations to the size of the grid?

and maybe a silly question, but just to be sure, there are not periodic boundary
conditions?

thanks
Sebastian

"Helen Chen" <helen.chen@mathworks.com> wrote in message
<fv82i0$nql$1@fred.mathworks.com>...
> Just a reminder to let everyone know that the Spring
Contest
> launches tomorrow, Wednesday May 30th at high noon. Be
> there or be square!
>
> See you then!
> Helen

Hi Helen,
 Great contest. May wires branch out? (fx. can 3 pins be
connected in a 'T' formation).
I might be missing it but it is not used in the examples,
but not explicitly prohibited either it seems.
Thanks
Soren

Walter Roberson wrote:
> In article <a8SdnUuVdO93WIXVnZ2dnUVZ_h-vnZ2d@earthlink.com>,
> D. Ismay <noSpam@Woohoo.Woohoohoo.Woohoo.Woohoohoo.HOOHOO.hoohoo.Woohoo.Woohoohoo> wrote:
>
>> 8. 'behaviors', 'moneys', 'winds', 'rains', 'foods', 'fruits',
>> 'medicines', when all
>> of these are group nouns and don't change spelling for plural case.
>
> You are wrong about each of the words you list.

bad guess, Mr. Roberson.

Can bridges bridge two 90 degree angled connectors in the
same node?
something like this
      |
    --//--
       |

So North and West is connected to each other and South and
East to each other.

Laszlo

"Soren Christensen" <sorench@gmail.com> wrote in message
<fvamqc$r2m$1@fred.mathworks.com>...
> "Helen Chen" <helen.chen@mathworks.com> wrote in message
> <fv82i0$nql$1@fred.mathworks.com>...
> > Just a reminder to let everyone know that the Spring
> Contest
> > launches tomorrow, Wednesday May 30th at high noon. Be
> > there or be square!
> >
> > See you then!
> > Helen
>
> Hi Helen,
> Great contest. May wires branch out? (fx. can 3 pins be
> connected in a 'T' formation).
> I might be missing it but it is not used in the examples,
> but not explicitly prohibited either it seems.
> Thanks
> Soren

In article <L_ednRtBG9SRdYXVnZ2dnUVZ_g2dnZ2d@earthlink.com>,
D. Ismay <noSpam@Woohoo.Woohoohoo.Woohoo.Woohoohoo.HOOHOO.hoohoo.Woohoo.Woohoohoo> wrote:
>Walter Roberson wrote:
>> In article <a8SdnUuVdO93WIXVnZ2dnUVZ_h-vnZ2d@earthlink.com>,
>> D. Ismay <noSpam@Woohoo.Woohoohoo.Woohoo.Woohoohoo.HOOHOO.hoohoo.Woohoo.Woohoohoo> wrote:

>>> 8. 'behaviors', 'moneys', 'winds', 'rains', 'foods', 'fruits',
>>> 'medicines', when all
>>> of these are group nouns and don't change spelling for plural case.

>> You are wrong about each of the words you list.

>bad guess, Mr. Roberson.

No guess. I provided specific citations to a source considered by many
people to be authoratative. The quotations provided in some cases extended
back farther than 1000 years. It is now incumbant upon you to prove your
case.

http://en.wikipedia.org/wiki/Mass_noun#Multiple_senses_for_one_noun

  Many English count nouns can be used as mass nouns, and in these
  cases, they take on cumulative reference. For example, one may
  say that "there's apple in this sauce," and then apple has
  cumulative reference, and, hence, is used as a mass noun.
  Conversely, "fire" is generally a mass noun, but "a fire" refers
  to a discrete entity, and does not satisfy the criterion for
  cumulative reference. Two common situations of this process are
  when speaking of either servings/measurements of a substance
  ("Two waters please") or of several types/varieties ("waters of
  the world").[2] One may say that mass nouns that are used as
  count nouns are "countified" and that count ones that are used as
  mass nouns are "massified." Some mass nouns can't easily be
  countified, and some count nouns are hard to massify. For example
  the count noun "house" is difficult to use as mass, and the mass
  noun "cutlery" is hard to countify:
--
  "Ignorance has been our king... he sits unchallenged on the throne of
  Man. His dynasty is age-old. His right to rule is now considered
  legitimate. Past sages have affirmed it. They did nothing to unseat
  him." -- Walter M Miller, Jr

I have a question that actually pertains to the contest,
not dictionary definitions.

With bridges, are you allowed to jump then over another
pin, or just a wire connection.

Ken

Hi again,
this is my first constest, so sorry for ask but the darkness implies not answering
the questions?

just to start looking tomorrow the thread.

best
s

Answers to some of your questions:

1. Bridges can only be used for crossovers, they can't be
used to have two 90 angles a the same coordinate.
2. You can not bridge pins, if I am not wrong you'll pay
for them but they'll be ignored.
3. The example that described the cost of the bridge should
give a net score of 25+3-(11*2) = 6
4. The size of the boards (as well as other parameters in
the testsuite) are sampled from a distribution, therefore
theoretically speaking there is no limit, but in practice
you could expect that most likely the distributions of the
board sizes wil resemble those in the sample testsuite.
5. "T" connections and "+" connections are possible and you
do not pay extra but the number of wires used (3 and 4
respectively)
6. Darkness does not mean "do not answer question", I'll be
around for a while, let me know if you have questions.

Good luck,

P.S. As orginizer I get the chance to peek at some of your
entries :), we have started receiving some interesting
pieces of code.
 
Lucio
The MathWorks Contest Team

Hi,

wasn't the ranking (without scores) visible in the darkness
phase of the last contests?

Markus

Enjoying the new contest! Thank you all for organizing it.

A question: is the routine that checks for forbidden
functions available? More than once in past contests I have
had entries disqualified because I accidentally left in a
forbidden command I had been using for debugging.

P.S. Congratulations, Alan!

"Nicholas Howe" <NikHow@hotmail.com> wrote in message
<fvbv0f$b3l$1@fred.mathworks.com>...
> Enjoying the new contest! Thank you all for organizing it.
>
> A question: is the routine that checks for forbidden
> functions available? More than once in past contests I have
> had entries disqualified because I accidentally left in a
> forbidden command I had been using for debugging.
>
> P.S. Congratulations, Alan!

Yes, Congrats Alan!

On the other note, I would have benefited from having the
routine that checks for forbidden functions! All my entries
in darkness failed because I accidentally left an error()
call in helper code that I copied from a function I wrote
for another purpose. I assure you I had no nefarious
purposes, and it would have been nice to find out they were
going to fail before I submitted them. Please consider
releasing this code in the future.

Thanks,

Mike Bindschadler

The first phase of the Wiring contest has passed. At
noontime today, we finished Darkness and have now entered
Twilight.

Things were off and running as soon as the challenge was
posted. Entries were posted continually through the noon
deadline. David Jones, a MATLAB Contest veteran, is the
winner at the Darkness close. Congratulations David!

Here were the top 10 in Darkness:

1 David Jones
2 Nick Howe
3 Claus Still
4 Steve Hoelzer
5 nathan q
6 Alfonso Nieto-Castanon
7 Fabio Carnevale
8 Schwabenpower
9 Michael
10 DreadNox

Best,
Helen

Markus, no we haven't changed anything about Darkness. It's
really quite dark.

Nicholas and Michael, we'll consider making this checker
available in the next contest. I hate to see it surprise
people at the end of Darkness. Sadly, some of our security
is "security through obscurity", so we'll have to trade that
off against how much security we lose.

I don't know if it is permitted to ask for help on this, but
I am really puzzled about an error message that my last four
submissions have been generating:

Line: 1 Column: 21 Unexpected MATLAB expression.

The first line of my program was a comment, and I've tried
changing it/deleting it/etc. but still get the same error
(always Line: 1 Column: 21). The code works perfectly on my
machine on the testsuite.

While this is actually just a problem with my current
algorithm, I can make a case that you should accept the
empty set as a valid answer.

Suppose that all pin values are on the order of 1e-9. Based
on the scoring of this puzzle, I can not imagine ever
wanting to connect any pins. The cost of the connector far
out ways the benefits of eliminating the pins.

That being said, I'll go find out what is wrong with my
algorithm.

"Matt Butts" <mattbutts@gmail.com> wrote in message
<fvd6cg$of3$1@fred.mathworks.com>...
> While this is actually just a problem with my current
> algorithm, I can make a case that you should accept the
> empty set as a valid answer.
>
> Suppose that all pin values are on the order of 1e-9. Based
> on the scoring of this puzzle, I can not imagine ever
> wanting to connect any pins. The cost of the connector far
> out ways the benefits of eliminating the pins.
>
> That being said, I'll go find out what is wrong with my
> algorithm.
>

Actually, this is possible, and is exactly what the
contest-supplied solver does. You just supply a 0 x 4
matrix, for example by W = zeros(0,4).

Cheers,
Mike Bindschadler

"Matthew Simoneau" <matthew@mathworks.com> wrote in message
<fvd0u3$i9i$1@fred.mathworks.com>...
> Nicholas and Michael, we'll consider making this checker
> available in the next contest. I hate to see it surprise
> people at the end of Darkness. Sadly, some of our security
> is "security through obscurity", so we'll have to trade that
> off against how much security we lose.

Even if you left the sneakier bits off the distribution
version, it would still be helpful. Something which did a
straightforward check for common functions which happen to
be disallowed in the contest (error, eval,
debugging/benchmarking functions) would help those of us
just making honest and forgetful errors.

I don't want to whine too much about it, I know it's my
responsibility to make sure my code complies with the posted
rules; this is just a suggestion for a nice feature for
future contests.

Thanks,

Mike Bindschadler

Nicholas, it took me a while to figure this out because
there was a bug in the error reporting, but your code
contains TITLE a handle graphics command and on the
restricted list. Sorry for the confusion.

"Michael Bindschadler" <mikeREMOVETHISbind@gmail.com> wrote
in message <fvd9fr$435$1@fred.mathworks.com>...
> "Matt Butts" <mattbutts@gmail.com> wrote in message
> <fvd6cg$of3$1@fred.mathworks.com>...
> > While this is actually just a problem with my current
> > algorithm, I can make a case that you should accept the
> > empty set as a valid answer.
> >
> > Suppose that all pin values are on the order of 1e-9. Based
> > on the scoring of this puzzle, I can not imagine ever
> > wanting to connect any pins. The cost of the connector far
> > out ways the benefits of eliminating the pins.
> >
> > That being said, I'll go find out what is wrong with my
> > algorithm.
> >
>
> Actually, this is possible, and is exactly what the
> contest-supplied solver does. You just supply a 0 x 4
> matrix, for example by W = zeros(0,4).
>
> Cheers,
> Mike Bindschadler

Thanks for the clarification. I was mistakenly assuming that
[] would be treated the same as a 0x4 matrix.

Sorry all, but it appears I have the dubious honor of being
the first to crash the queue this time around. I was trying
to determine the scoring coefficients and submitted a
program with what should be a very high node count.
However, after testing it on my version of R2008a, it
appears that mtree 'wraps around' the node count as a fault
and it's returning a value of 1 for the node count.

Even though I accidentally crashed the queue, I think I have
been able to figure out the scoring formula and am posting
it here as I traditionally do. I’ve determined it’s very
similar to the recent contests:

score = k1*result + k2*e(k3*runtime) +
k4*max(complexity-10,0) + k5*nodes

Where:

k1 = 0.1
k2 = 2
k3 = 2/30 (0.06666666…)
k4 = 1
k5 = 0.001

The current leading entry has a time of 56s, result of
141891, cyc of 25, and nodes of 4196. Here’s a breakdown of
the current tradoffs:

-cyc and score are a 1:1 ratio (i.e. each point shaved off
cyc is a point shaved off the score)
-time and score are a 1:5.7 ratio
-result and score are a 1:0.1 ratio
-node and score are a 1:0.001 ratio

David Jones entries have already settled in just at the
‘knee’ of the time exponential curve, which is rather flat
until about ~50s. However, because of the new time exponent
constant, we are going to see much more payoff in this
content in focusing on reducing the execution time versus
other scoring elements, probably down to the ~10 second range.

Unfortunately that probably also means that people are going
to end up taking the lead due to ‘luck of the draw’ in the
minor variations we always see in execution times, since
they will be amplified more in the total score compared to
in the past.

Hope this helps everyone!

Yes, our code wasn't robust to when the file was too big for
M-Lint to handle and the queue was down for a bit. We're
back up and running. Sorry for the delay of game.

"Matthew Simoneau" <matthew@mathworks.com> wrote in message
<fvdebf$p7p$1@fred.mathworks.com>...
> Nicholas, it took me a while to figure this out because
> there was a bug in the error reporting, but your code
> contains TITLE a handle graphics command and on the
> restricted list. Sorry for the confusion.

Thanks for looking into this for me. I think I ended up
removing that call to title soon afterwards.

Another request, if anyone has time: does anyone have the
matrix for Lucio's example problem? I'd be interested in
trying my code on it. Thanks!

Thanks to the Matlab Contest Team for dreaming up a great wiring puzzle. It
has been fun working out incremental improvements through Darkness and
Twilight, especially with the wiringGUI and Lucio's analysis to visualize solutions.

Judging from scores during Twilight, it seems that finding good bridges
efficiently is what separated my Twilight algorithm from the rest of the pack.

But now as we enter the Daylight phase, all my coding secrets will be revealed,
... so roll up your sleeves ... and let the tweakfest begin ...

Good luck to everyone for the rest of the contest!

-- David Jones

Nick, I posted Lucio's test board to the blog:

http://blogs.mathworks.com/contest/2008/05/01/sneak-peek-leading-solvers-at-work/#comment-5149

"Helen Chen" <helen.chen@mathworks.com> wrote in message
<fv82i0$nql$1@fred.mathworks.com>...
> Just a reminder to let everyone know that the Spring Contest
> launches tomorrow, Wednesday May 30th at high noon. Be
> there or be square!
>
> See you then!
> Helen

It seems that much of the Statistics page is not being
updated properly.

"the cyclist" <thecyclist@letter.after.f.mail.com> wrote in
message <fvhptn$kgm$1@fred.mathworks.com>...

> It seems that much of the Statistics page is not being
> updated properly.

Thanks for the heads-up. We'll take a look at this.

Helen

Here I want to provide Markus's post from previous contest:

"As in all contests, some guys tend to ruin the contest by
obfuscating their code, as DrSeuss does at the moment.

In the contest rules under "Hacking" we read "we ask that
you not abuse the system." I think this should also be valid
for the annoying obfuscation of code.

In the current leading code, I still find large portions of
my twilight winning code. I insist that you at least do not
obfuscate code that others have written!! If you want
introduce a new variable, call it as you like, but leave the
others as they are!

Markus
"

SY

As I usually do, I've now posted a heavily commented version
of the leading code so that those of you who aren't in the
'thick of it' can have an opportunity to understand the
alogrithms behind the solutions to this problem.

The code is entry 47616 viewable at:
http://www.mathworks.com/contest/wiring.cgi/view_submission.html?id=47616

Hope this helps!

Hi.
Would it be possible to announce in advance if we are going
to have (and when) late twilight, best result, 1000
character, generality competition?
SY (Sergey)

When did (or will) the score-neutral switch in test suite occur??

-- David Jones

Anybody wants to play “best result” with 3 min time limit
today?
Let’s say between 6PM and 9PM ET?

SY

"Sergey " <ivssnn@yahoo.com> wrote in message
<fvnfas$cmt$1@fred.mathworks.com>...
> Anybody wants to play “best result” with 3 min time limit
> today?
> Let’s say between 6PM and 9PM ET?
>
> SY
>

Unfortunately, that's right in the middle of the night in
Europe. But have fun anyway. :)


Btw. the leading entry "does it shorten time" by Gwendolyn
Fish was just a moment ago in back in the queue? Does this
announce the swapping of the test suite?

Regards,
srach

Hi,

I follow Sergey and would like to know when the next contest
phases will end. I have this HUGE improvement and just wait
to plug it in at the right time :-)

Markus

I ran into some bumps with the test suite swap, but we
should be back in business.

We're now running a "first to break 13000", which could take
some time. I picked this target by figuring that most of
the difference in results between the old and new test
suites could be made up without major innovation, but there
is always some risk that the target is too aggressive.

The "best result" really clogged the queue last time, so
instead we're bringing back a variation on the "1000
Character Challenge". This time, however, we're be using
node count rather than character count. Since the top entry
is now around 4500 nodes, maybe 1000 node limit? Or even
more restrictive? I like this one because it gives a chance
for people to work with shorter code for a while, and now
that we're using nodes instead of characters there won't be
as much pressure to make the code illegible. We'll do this
sometime tomorrow.

Historically, we've announced the mid-contest prizes as we
go so we could react to whatever was going on. We've picked
up some traditions, like the Sunday Push. I'll float the
idea to the team of announcing at least most of them in
advance next time.

"Markus Buehren" <mb_matlab.REMOVE@gmxTHIS.de> wrote in
message <fvnh32$q3s$1@fred.mathworks.com>...

> I follow Sergey and would like to know when the next contest
> phases will end. I have this HUGE improvement and just wait
> to plug it in at the right time :-)
>

Markus -

Did you see Matt's note about the schedule on the contest
blog ( http://blogs.mathworks.com/contest/ )? The challenge
to beat 13000 will remain open until someone beats it, but
we have a concurrent second - the 1000 node challenge.

Wouldn't it be interesting if someone won both challenges
with the same submission? It would be another first for the
MATLAB Contest!

Helen

> Markus -
>
> Did you see Matt's note about the schedule on the contest
> blog ( http://blogs.mathworks.com/contest/ )?

Sure, but the note was posted later than mine :-)

Markus

"the cyclist" <thecyclist@letter.after.f.mail.com> wrote in
message <fvhptn$kgm$1@fred.mathworks.com>...
> "Helen Chen" <helen.chen@mathworks.com> wrote in message
> <fv82i0$nql$1@fred.mathworks.com>...
> > Just a reminder to let everyone know that the Spring Contest
> > launches tomorrow, Wednesday May 30th at high noon. Be
> > there or be square!
> >
> > See you then!
> > Helen
>
> It seems that much of the Statistics page is not being
> updated properly.

Stats page seems to be stuck again (Tuesday at 5:40 PM, just
before end of 1000-mode contest).

The statistics page is still down, so I parsed the results
to find out who the winner of 1000-nodes-challenge is. Here
is the (inofficial) top ten:

01. 15484.3796: Uss tc
02. 15484.4924: node speed YC
03. 15485.2384: M&M_262 MikeR
04. 15485.3887: node speed YC
05. 15485.5323: M&M_259 MikeR
06. 15485.7220: super speed 2 YC
07. 15485.8111: super speed YC
08. 15485.8763: super speed 1 YC
09. 15485.8969: aam333 Abhisek Ukil
10. 15485.9271: node speed 3 YC

It seems tc aka The Cyclist has won another contest prize.
Well done! Check out which small tweak he used:

http://www.mathworks.com/contest/wiring.cgi/diff.html?id1=48627&id2=48680

Yours
Markus

Grmpf, just posting this I notice that the Statistics page
is up again...

"the cyclist" <thecyclist@letter.after.f.mail.com> wrote in
message <fvqkq7$ae2$1@fred.mathworks.com>...
> "the cyclist" <thecyclist@letter.after.f.mail.com> wrote in
> message <fvhptn$kgm$1@fred.mathworks.com>...

> Stats page seems to be stuck again (Tuesday at 5:40 PM, just
> before end of 1000-mode contest).

I think it was quite backlogged with all the last minute
postings before the 6 pm deadline as the queue has just
cleared up.

Helen

While I haven't had much time to compete in this contest,
I've done some analysis and unfortunately believe that the
13000 mark is going to be virtually impossible to beat.
Here are some key points:

As of midnight Tuesday, the leading entry has the following
stats:
Result: 134617
Time: 40.0336
Cyc: 21
Nodes: 7289
Score: 13508.84

Because of the way the scoring formula works, the ONLY way
to beat 13000 is to lower the result. Even if the time, cyc
and nodes were reduced to 1 each, the score would only
improve by 45 points to 13464. In order to reach 13000,
the result needs to improve to ~129500, or by approximately
5117 (which is a 3.8% improvement).

That might not seem like much, but it actually is. Based
upon the null move solvers submitted at the start of the
contest, we know that there are a total of 359141 points in
the original test suite. The current result is only 37% of
the max value of the test boards.

However, keep in mind that there is a non-zero lower limit
to the score for a 'perfect solver'. While it's impossible
for us to know what that is without examining the test
suite, we can make some good guesses based upon the best
results statistics. The best result so far is 133225,
almost 1400 points better than the current leader (although
it took 148 seconds to run), but still 3700 points away from
 13000, assuming it could run in less than 1/3 the time it
currently does.

Another way of looking at it is the % improvement column on
the stats webpage. The score has only improved by ~4% since
Sunday morning until right now. Thus in order to break the
goal, in the next 12 hours entries need to outperform ~72
hours worth of steady improvements.

Examining the current leading solver against random
individual boards in the sample test suite, I found that
there might be room for slight improvement, however overall
it's doing a really good job, as one might expect.

Thus, while I'm sorry if this bursts anyone's bubbles,
hopefully this will allow some competitors to refocus on
just getting a top entry instead of trying to beat an
arbitrary score. Good luck everyone for the remainder of
the contest!

Buddy .. stop the tweak bombing .. some of us would like to
submit their solutions .. simply BRUTAL

"Alan Chalker" <alancNOSPAM@osc.edu> wrote in message
<fvre0f$j6$1@fred.mathworks.com>...
> While I haven't had much time to compete in this contest,
> I've done some analysis and unfortunately believe that the
> 13000 mark is going to be virtually impossible to beat.
> Here are some key points:
>
> As of midnight Tuesday, the leading entry has the
following
> stats:
> Result: 134617
> Time: 40.0336
> Cyc: 21
> Nodes: 7289
> Score: 13508.84
>
> Because of the way the scoring formula works, the ONLY way
> to beat 13000 is to lower the result. Even if the time,
cyc
> and nodes were reduced to 1 each, the score would only
> improve by 45 points to 13464. In order to reach 13000,
> the result needs to improve to ~129500, or by
approximately
> 5117 (which is a 3.8% improvement).
>
> That might not seem like much, but it actually is. Based
> upon the null move solvers submitted at the start of the
> contest, we know that there are a total of 359141 points
in
> the original test suite. The current result is only 37%
of
> the max value of the test boards.
>
> However, keep in mind that there is a non-zero lower limit
> to the score for a 'perfect solver'. While it's
impossible
> for us to know what that is without examining the test
> suite, we can make some good guesses based upon the best
> results statistics. The best result so far is 133225,
> almost 1400 points better than the current leader
(although
> it took 148 seconds to run), but still 3700 points away
from
> 13000, assuming it could run in less than 1/3 the time it
> currently does.
>
> Another way of looking at it is the % improvement column
on
> the stats webpage. The score has only improved by ~4%
since
> Sunday morning until right now. Thus in order to break
the
> goal, in the next 12 hours entries need to outperform ~72
> hours worth of steady improvements.
>
> Examining the current leading solver against random
> individual boards in the sample test suite, I found that
> there might be room for slight improvement, however
overall
> it's doing a really good job, as one might expect.
>
> Thus, while I'm sorry if this bursts anyone's bubbles,
> hopefully this will allow some competitors to refocus on
> just getting a top entry instead of trying to beat an
> arbitrary score. Good luck everyone for the remainder of
> the contest!
>
>

why bombing the queue?
I sugguest adding some submission limits, such as 1
entry/per min/per ip.

why bombing? when is the end?

Alans bombing as well as his analysis both speak for adding
a "captcha" to the submission site (which I think is even
better than an IP limit). This would prevent the
over-over-over-specification of the solver to the test suite
which occurs due to the many parameter variations that are
submitted.

I have found some algorithmic improvement yesterday, which
dramatically boosted the score on the test suite we are
having at home. However, as the leading code is so
over-specified to the actual test suite, my change even lead
to a worse score on it. I think the parameter tweaking by
numerous automated uploads takes away the room for
algorithmic improvements.

The most obvious sign for tweaking is the introduction of
randomness into the algorithm. Not only that parameters of
the code are varied, we even don't know which parameters
that are! In my opinion the use of random generators (rand,
randn, randperm etc.) should be forbidden.

Any other thoughts?

Markus

> I have found some algorithmic improvement yesterday, which
> dramatically boosted the score on the test suite we are
> having at home. However, as the leading code is so
> over-specified to the actual test suite, my change even lead
> to a worse score on it. I think the parameter tweaking by
> numerous automated uploads takes away the room for
> algorithmic improvements.

But sometimes such differences also come with different
matlab versions or different machines. Earlier in the
contest, I found a small change that led to an improvement
of about 10 sec on my computer. I checked that on a
different computer (with a more recent matlab version) and
there this change led to a worsening of 10 sec.

(Same was true at the end of the last contest, where the
final tweak that I saved for the last seconds of the contest
actually made the score worse, although it led to
improvements on my system.)

I second your thoughts about randomness.

Regards,
srach

> I have found some algorithmic improvement yesterday, which
> dramatically boosted the score on the test suite we are
> having at home. However, as the leading code is so
> over-specified to the actual test suite, my change even lead
> to a worse score on it. I think the parameter tweaking by
> numerous automated uploads takes away the room for
> algorithmic improvements.

But sometimes such differences also come with different
matlab versions or different machines. Earlier in the
contest, I found a small change that led to an improvement
of about 10 sec on my computer. I checked that on a
different computer (with a more recent matlab version) and
there this change led to a worsening of 10 sec.

(Same was true at the end of the last contest, where the
final tweak that I saved for the last seconds of the contest
actually made the score worse, although it led to
improvements on my system.)

I second your thoughts about randomness.

Regards,
srach

> I have found some algorithmic improvement yesterday, which
> dramatically boosted the score on the test suite we are
> having at home. However, as the leading code is so
> over-specified to the actual test suite, my change even lead
> to a worse score on it. I think the parameter tweaking by
> numerous automated uploads takes away the room for
> algorithmic improvements.

But sometimes such differences also come with different
matlab versions or different machines. Earlier in the
contest, I found a small change that led to an improvement
of about 10 sec on my computer. I checked that on a
different computer (with a more recent matlab version) and
there this change led to a worsening of 10 sec.

(Same was true at the end of the last contest, where the
final tweak that I saved for the last seconds of the contest
actually made the score worse, although it led to
improvements on my system.)

I second your thoughts about randomness.

Regards,
srach

> The most obvious sign for tweaking is the introduction of
> randomness into the algorithm. Not only that parameters of
> the code are varied, we even don't know which parameters
> that are! In my opinion the use of random generators
(rand,
> randn, randperm etc.) should be forbidden.
>
> Any other thoughts?

If randomness is forbidden, genetic algorithms, simulated
annealing or even a random walk are forbidden, too. Only
deterministic algorithms are allowed in this case, no
matter how inefficient they might be.

Tweaking can be prevented by removing or deactivating the
functionality for reading and editing existing code.
However, tweaking is allowed in this contest and it is done
by people who understand the code others wrote.

I submitted my latest entry 30 minutes ago and it has still
the stats "new". Is the server down?

My entry does not show up even after an hour. Tweak bombing
should indeed be forbidden and prevented from happening by
technical measures.

"OkinawaDolphin " <OkinawaDolphin@Hotmail.com> wrote in
message <fvrvkr$688$1@fred.mathworks.com>...
> My entry does not show up even after an hour. Tweak bombing
> should indeed be forbidden and prevented from happening by
> technical measures.

Sorry all, the queue did fall asleep, but is running now.
Things should clear out in a bit.

Helen

Contest ends at 12PM Eastern today, correct?

Hi all

In my opinion, wholesale tweak-bombing, on a scale large
enough to monopolise the queue for hours, is contrary to the
spirit of the contest. Arguably, it's a form of hacking -
"Entries that compromise the contest machinery are no longer
allowed". There is probably no technical solution that would
prevent it (and anyway it's unfair to expect the Mathworks
team to work as enforcers). However, I agree with Markus
that a captcha would be a workable and useful measure.

In principle, I would like to see random functions outlawed
- however, competitors could easily circumvent it with
handwritten random number generators (they wouldn't have to
very good ones) which would lead to less intelligible code.

In general I'm in favour of a light touch with rules and
regulations. New restrictions will act as targets to be
hacked and evaded. Fun and a social spirit should stay at
the centre of the contest.

Nathan

PS Although Alan defeated the online diff function, CSdiff
on windows (or presumably a unix diff) will reveal what he
is up to :)

"Markus Buehren" <mb_matlab.REMOVE@gmxTHIS.de> wrote in
message <fvrot9$gsi$1@fred.mathworks.com>...
> Alans bombing as well as his analysis both speak for adding
> a "captcha" to the submission site (which I think is even
> better than an IP limit). This would prevent the
> over-over-over-specification of the solver to the test suite
> which occurs due to the many parameter variations that are
> submitted.
>
> I have found some algorithmic improvement yesterday, which
> dramatically boosted the score on the test suite we are
> having at home. However, as the leading code is so
> over-specified to the actual test suite, my change even lead
> to a worse score on it. I think the parameter tweaking by
> numerous automated uploads takes away the room for
> algorithmic improvements.
>
> The most obvious sign for tweaking is the introduction of
> randomness into the algorithm. Not only that parameters of
> the code are varied, we even don't know which parameters
> that are! In my opinion the use of random generators (rand,
> randn, randperm etc.) should be forbidden.
>
> Any other thoughts?
>
> Markus
>

"Helen Chen" <helen.chen@mathworks.com> wrote in message
<fvs4ar$dl5$1@fred.mathworks.com>...
> "OkinawaDolphin " <OkinawaDolphin@Hotmail.com> wrote in
> message <fvrvkr$688$1@fred.mathworks.com>...
> > My entry does not show up even after an hour. Tweak bombing
> > should indeed be forbidden and prevented from happening by
> > technical measures.
>
> Sorry all, the queue did fall asleep, but is running now.
> Things should clear out in a bit.
>
> Helen

Is the queue sleeping again?

Best,
srach

> If randomness is forbidden, genetic algorithms, simulated
> annealing or even a random walk are forbidden, too. Only
> deterministic algorithms are allowed in this case, no
> matter how inefficient they might be.

In my view, you compare two different things here: Genetic
algorithms and such are tools for finding an optimal
parameter set. The solver algorithm itself is then used for
solving the problem, using the parameters found in a step
before.

If you look at the entries using randomness in this contest,
there is not the slightest sign that something like a
genetic algorithm is applied there.

> Tweaking can be prevented by removing or deactivating the
> functionality for reading and editing existing code.

No, there are simple ways to upload submissions
automatically. You can even do it simply from within Matlab!
I know which Matlab function one can use for it, but I won't
tell it to anyone now :-)

> However, tweaking is allowed in this contest and it is done
> by people who understand the code others wrote.

No!! For tweaking, you don't need any clue about how the
code itself works! Just play around a bit with the
parameters, let one solver run more than once and select the
best result, or combine two different solvers and choose the
better result and sometimes you will find an improvement.
You don't need to understand the algorithms themselfes for that.

Markus

Thank you Nathan, well said. I would assume the majority
of people participate in this contest out of interest and
challenge (and maybe the opportunity to work for
matlab :) ). I have limited time in the evening once I
get home from work and do my husbandly chores .. to
actually participate. There is nothing more frustrating
then waiting over 40 minutes to see how a submission
faired whilst looking at hundreds of tweak bomb entries.
Helen .. any chance we can extend the contest one more
night for us true lovers of the game :)

"Nathan " <nathoqXXX@yahooXXX.com> wrote in message
<fvs66t$8l4$1@fred.mathworks.com>...
> Hi all
>
> In my opinion, wholesale tweak-bombing, on a scale large
> enough to monopolise the queue for hours, is contrary to
the
> spirit of the contest. Arguably, it's a form of hacking -
> "Entries that compromise the contest machinery are no
longer
> allowed". There is probably no technical solution that
would
> prevent it (and anyway it's unfair to expect the
Mathworks
> team to work as enforcers). However, I agree with Markus
> that a captcha would be a workable and useful measure.
>
> In principle, I would like to see random functions
outlawed
> - however, competitors could easily circumvent it with
> handwritten random number generators (they wouldn't have
to
> very good ones) which would lead to less intelligible
code.
>
> In general I'm in favour of a light touch with rules and
> regulations. New restrictions will act as targets to be
> hacked and evaded. Fun and a social spirit should stay at
> the centre of the contest.
>
> Nathan
>
> PS Although Alan defeated the online diff function,
CSdiff
> on windows (or presumably a unix diff) will reveal what
he
> is up to :)
>
> "Markus Buehren" <mb_matlab.REMOVE@gmxTHIS.de> wrote in
> message <fvrot9$gsi$1@fred.mathworks.com>...
> > Alans bombing as well as his analysis both speak for
adding
> > a "captcha" to the submission site (which I think is
even
> > better than an IP limit). This would prevent the
> > over-over-over-specification of the solver to the test
suite
> > which occurs due to the many parameter variations that
are
> > submitted.
> >
> > I have found some algorithmic improvement yesterday,
which
> > dramatically boosted the score on the test suite we are
> > having at home. However, as the leading code is so
> > over-specified to the actual test suite, my change
even lead
> > to a worse score on it. I think the parameter tweaking
by
> > numerous automated uploads takes away the room for
> > algorithmic improvements.
> >
> > The most obvious sign for tweaking is the introduction
of
> > randomness into the algorithm. Not only that
parameters of
> > the code are varied, we even don't know which
parameters
> > that are! In my opinion the use of random generators
(rand,
> > randn, randperm etc.) should be forbidden.
> >
> > Any other thoughts?
> >
> > Markus
> >
>

"srach " <s.rach_NOSPAM_@jacobs-university.de> wrote in
message <fvsahk$jks$1@fred.mathworks.com>...
>
> Is the queue sleeping again?
>
Sorry, I was in a meeting, but yes, they are asleep again.
Matt's taking a look and we should have them back up in a bit.

Helen

Sorry, the queue was down for about two hours this morning,
but we're back up and running now.

I'd like to take a moment and respond to a couple of points.

Yes, I tweak bombed last night in an attempt to find some
optimal parameters for the various constants in the code. I
deliberately waited until the wee hours of the morning to do
this since the majority of the leading players seem to
compete during USA daylight hours. I'm sorry if this
inconvenienced some other players though.

I also only submitted enough entries to tie up the queue for
a couple hours, and during a time when there weren't any
other 'active' subprizes people were competing for, trying
to be considerate of the fact that the contest end is
nearing and people want to get feedback on their codes.
Since I used an automated script (written in MATLAB of
course;) to do this, I (or another player with less
integrity) could easily tie up the queue for the remainder
of the contest.

Please note that the rules explicitly ALLOW tweak bombing:
"Tuning the entry to the contest test suite via tweak
bombing or other techniques is still allowed, but we ask
that you not overwhelm the queue." However, how does one
define 'overwhelming' the queue? This has been a reoccuring
issue in past contests and there have been various
suggestions, such as CAPTCHAs or random seeds to the RAND
function, which I think should be strongly considered.

Generally I'm not in favor of this type of 'style of play',
however I saw what I thought was an opportunity to be
involved in a way I haven't been involved before and thought
I'd try it out. As an aside, since the queue is now at the
point where new entries aren't going to run until after the
contest closes, I intend to make one last stab at this in
the off chance I hit upon just the right parameters.

The queue is closed. Good luck to all of you!

Best,
srach

Hi Alan

I would consider the queue "overwhelmed" when it's blocked
for several hours! There are many "leading players", and
non-leading ones too, who do their work at times other than
American daylight.

ooops... while writing this I nearly forgot to post my
last-minute tweaks, erm, innovations...

Good luck

Nathan

"Alan Chalker" <alancNOSPAM@osc.edu> wrote in message
<fvshij$ipo$1@fred.mathworks.com>...
> I'd like to take a moment and respond to a couple of points.
>
> Yes, I tweak bombed last night in an attempt to find some
> optimal parameters for the various constants in the code. I
> deliberately waited until the wee hours of the morning to do
> this since the majority of the leading players seem to
> compete during USA daylight hours. I'm sorry if this
> inconvenienced some other players though.
>
> I also only submitted enough entries to tie up the queue for
> a couple hours, and during a time when there weren't any
> other 'active' subprizes people were competing for, trying
> to be considerate of the fact that the contest end is
> nearing and people want to get feedback on their codes.
> Since I used an automated script (written in MATLAB of
> course;) to do this, I (or another player with less
> integrity) could easily tie up the queue for the remainder
> of the contest.
>
> Please note that the rules explicitly ALLOW tweak bombing:
> "Tuning the entry to the contest test suite via tweak
> bombing or other techniques is still allowed, but we ask
> that you not overwhelm the queue." However, how does one
> define 'overwhelming' the queue? This has been a reoccuring
> issue in past contests and there have been various
> suggestions, such as CAPTCHAs or random seeds to the RAND
> function, which I think should be strongly considered.
>
> Generally I'm not in favor of this type of 'style of play',
> however I saw what I thought was an opportunity to be
> involved in a way I haven't been involved before and thought
> I'd try it out. As an aside, since the queue is now at the
> point where new entries aren't going to run until after the
> contest closes, I intend to make one last stab at this in
> the off chance I hit upon just the right parameters.
>
>
>

"Helen Chen" <helen.chen@mathworks.com> wrote in message
<fv82i0$nql$1@fred.mathworks.com>...
> Just a reminder to let everyone know that the Spring Contest
> launches tomorrow, Wednesday May 30th at high noon. Be
> there or be square!
>
> See you then!
> Helen

Thanks for running another fun contest. Not actually having
access to MATLAB anymore took some fun out of it. 8-/
Didn't stop me from tweaking here and there, though.

How about using an anti-spam tech, such the one used for
File Exchange review comments to prevent automatic
submissions, i.e. a user has to copy certain characters
shown on the screen before he/she can submit a code. This
has been used in File Exchange, hence should not be
difficult for TMW to implement in the contest page.

Yi

"the cyclist" <thecyclist@letter.after.f.mail.com> wrote in
message <fvsk1d$m84$1@fred.mathworks.com>...
> "Helen Chen" <helen.chen@mathworks.com> wrote in message
> <fv82i0$nql$1@fred.mathworks.com>...
> > Just a reminder to let everyone know that the Spring Contest
> > launches tomorrow, Wednesday May 30th at high noon. Be
> > there or be square!
> >
> > See you then!
> > Helen
>
> Thanks for running another fun contest. Not actually having
> access to MATLAB anymore took some fun out of it. 8-/
> Didn't stop me from tweaking here and there, though.

Congratulations to Tim for winning the 1000 node prize, ...
without actually having access to MATLAB !

-- David Jones

I strongly agree that using random function will discourage
algorithmic development because a well-tuned random code
will significantly disadvantage any new algorithm, which
has not been tuned for the specific test suite.

As Markus said, using random functions here is total
different from the use in a GA type algorithm, where the
statistical nature of a random function is used to get the
optimal solution.

However, here, the random function is used just like other
parameters to be tuned specificly for the test suite. By
doing so, when altering an algorithm, the number of random
function calls will change as well, hence the result is
completely unpredictable.
 
The main problem with random function is that it
has 'memory', so that previours use of a random function
will affect the follows. As Nathan mentioned, disallowing
random function will not solve the problem because a user
can develop his own.

However, I would like to suggest to use a random function
in runcontest function to make tuning random parameters
imposible. For example, in runcontest function, a line of
rand('state',sum(100*clock)) can make any intention to tune
a random parameter impossible because even with the same
parameters, the results could be totally different if a
random function is used in a code.

Yi

"Yi Cao" <y.cao@cranfield.ac.uk> wrote in message
<fvsl6t$5db$1@fred.mathworks.com>...
> How about using an anti-spam tech, such the one used for
> File Exchange review comments to prevent automatic
> submissions, i.e. a user has to copy certain characters
> shown on the screen before he/she can submit a code. This
> has been used in File Exchange, hence should not be
> difficult for TMW to implement in the contest page.
>
> Yi

Excellent idea! It wouldn't eliminate tweak bombing, but at
least it would make it harder.

"Yi Cao" <y.cao@cranfield.ac.uk> wrote in message
<fvsot0$gr9$1@fred.mathworks.com>...
> However, I would like to suggest to use a random function
> in runcontest function to make tuning random parameters
> imposible. For example, in runcontest function, a line of
> rand('state',sum(100*clock)) can make any intention to tune
> a random parameter impossible because even with the same
> parameters, the results could be totally different if a
> random function is used in a code.
>
> Yi

No. The same code must give the same score every time it
runs. Otherwise, a new type of random variable "tuning" is
possible: submitting the same code multiple times. I too
wish that magic number tuning was not a part of the contest,
but I don't think it can be programmatically enforced.

Steve

"Jin " <xx@xx.xx> wrote in message
<fvrj7b$kf6$1@fred.mathworks.com>...
> why bombing the queue?
> I sugguest adding some submission limits, such as 1
> entry/per min/per ip.
>

I think that would be an excellent limitation on
submissions. One per minute seems fast enough for tweak
bombers to do what they do, but the spacing should help to
keep the queue shorter (not "overwhelmed").

Steve

It would be great if the MATLAB Contest Team would let us know their plans for
the end of the contest, ... when the queue is expected to re-open, ... when the
deadline for the end of the contest will be, ... and so on.

"David " <djones.nospam@remove.mcmaster.ca> wrote in message
<fvssmq$7pp$1@fred.mathworks.com>...
> It would be great if the MATLAB Contest Team would let us
know their plans for
> the end of the contest, ... when the queue is expected to
re-open, ... when the
> deadline for the end of the contest will be, ... and so on.
>
>

The contest is over. The queue was closed at 12PM and now
the remaining entries will be processed to find a winner.

Regards,
srach

"Steve Hoelzer" <shoelzer@gmail.com> wrote in message
<fvsqp9$8gg$1@fred.mathworks.com>...
> No. The same code must give the same score every time it
> runs. Otherwise, a new type of random variable "tuning" is
> possible: submitting the same code multiple times. I too
> wish that magic number tuning was not a part of the
contest,
> but I don't think it can be programmatically enforced.
>
> Steve

However, currently, it is already possible to resubmit the
same code several time to get the best score because the
same code wont get the same result on timeing.

Yi

"Yi Cao" <y.cao@cranfield.ac.uk> wrote in message
<fvstsb$m4n$1@fred.mathworks.com>...
> "Steve Hoelzer" <shoelzer@gmail.com> wrote in message
> <fvsqp9$8gg$1@fred.mathworks.com>...
> > No. The same code must give the same score every time it
> > runs. Otherwise, a new type of random variable "tuning" is
> > possible: submitting the same code multiple times. I too
> > wish that magic number tuning was not a part of the
> contest,
> > but I don't think it can be programmatically enforced.
> >
> > Steve
>
> However, currently, it is already possible to resubmit the
> same code several time to get the best score because the
> same code wont get the same result on timeing.
>
> Yi

True, but the timing variation is small and has little
impact on score compared to varying the random number seed.

That said, I would support a change to the scoring function
such that run time is rounded to the nearest second. That
should mostly eliminate the effect of timing variation.

Steve

There are many valid uses of random numbers besides genetic
algorithms. Many quicksort implementations use randomness,
for example. But any such use will leave the temptation to
tweak the state of the random number generator so as to
improve the result.

I'd like to make another suggestion, in the spirit of
friendly competition. Currently the Mathworks folks provide
recognition to players who win various phases of the
contest. But this doesn't always capture all the wonderful
things that people have contributed to the solution. I'd
like to suggest the idea of players recognizing other
players who have achieved something notable during the
contest, but perhaps didn't win a prize for it. I can't
nominate anyone myself because I didn't follow the contest
in daylight, but perhaps someone else can.

> How about using an anti-spam tech, such the one used for
> File Exchange review comments to prevent automatic
> submissions, i.e. a user has to copy certain characters
> shown on the screen before he/she can submit a code.

Thats exactly what is called a "CAPTCHA" in internet slang :-)

Markus

"Steve Hoelzer" <shoelzer@gmail.com> wrote in message
>
> That said, I would support a change to the scoring
function
> such that run time is rounded to the nearest second. That
> should mostly eliminate the effect of timing variation.
>
> Steve
>

Good point. I would like to support this proposal. It will
discourage users to submit codes with trival or nil
contributions.

Yi

on top of all the very good suggestions to keep the contest
engaging and minimally frustrating for everyone I would
also suggest reviving some form of generality prize at the
end of the contest to keep the interest of those developing
non-overfitting solutions and alternative algorithm
strategies alive

That said it has been lots of fun, congrats to the matlab
team for their good work!

"Alfonso Nieto-Castanon" <alfnie@gmail.com> wrote in message
<fvt6t3$cpq$1@fred.mathworks.com>...
>
> on top of all the very good suggestions to keep the contest
> engaging and minimally frustrating for everyone I would
> also suggest reviving some form of generality prize at the
> end of the contest to keep the interest of those developing
> non-overfitting solutions and alternative algorithm
> strategies alive

I like the idea of a generality prize, but I don't think
it's valid to have one after daylight. There are so many
parameter tweaked entries that one of them is bound to be
overfitted to the generality test set. The darkness stage is
probably as close as you can get to a generality contest.

"Steve Hoelzer" <shoelzer@gmail.com> wrote in message
<fvt9bt$ai7$1@fred.mathworks.com>...
> I like the idea of a generality prize, but I don't think
> it's valid to have one after daylight. There are so many
> parameter tweaked entries that one of them is bound to be
> overfitted to the generality test set. The darkness stage
is
> probably as close as you can get to a generality contest.

I see your point, nevertheless I would think that the
previously used solution of limiting generality submissions
to a subset of the last day entries (renamed to indicate
that they go for the generality prize) should do the job -
together with people somehow limiting themselves as to the
number of entries anyone would send for a "generality"
prize without too much shame...

And of course, while there are no perfect solutions I know
at least for me (I like the algorithm development part more
than the tweeking) this would make an interesting challenge
to work towards (and one day of darkness is so little time
to loose with this...)

-Alfonso

"Steve Hoelzer" <shoelzer@gmail.com> wrote in message
> I like the idea of a generality prize, but I don't think
> it's valid to have one after daylight.


I have a proposal to enhance the "generality" of the leading/winning entries
in the MATLAB Contest ...

The idea is a variation on what is already done with two test suites.
Instead of switching out the test suites in SEQUENCE, ...
I think you could run them in PARALLEL,
by using one large test suite with two subsets (A and B)
that are statistically similar.
(The statistical similarity would be important, ...)

Then the RESULT when scoring an entry would be
the MAX of RESULT_A and RESULT_B.

Any tweaking that leads to a better result in subset A
would provide no benefit if there was still a poor result in subset B.

- - -

Here is a generalized version of this idea that I would actually recommend
implementing ... (it uses the majority of the large test suite to assign the final
score, so it might be more robust).

Let's say we want a test suite containing 256 boards for the Wiring puzzle.
The contest team carefully creates 4 classes of puzzles (maybe 64 of each)
... we might call them: small, medium, large, extra-large,
or they might be created on a continuum from small to extra-large.
Whether they are hand-crafted or computer-generated,
there need to be 4 "equally difficult" examples of each "class" of puzzle.
Randomly assign one of 4 colours (Red, Green, Blue, Yellow)
to the boards in each class.

A good "general" solution should get similar results
for each of the 4 colours. ... An entry with lots of silly tweaks
and overfitting may have a higher variance of results
across the different colours.

Now we create 4 overlapping subsets of our single test suite:

A = Red, Green, Blue (but not Yellow) = 48 small, 48 medium, 48 large, 48
extra-large
B = Red, Green, Yellow (but not Blue) = 48 small, 48 medium, etc.
C = Red, Blue, Yellow (but not Green) = ...
D = Green, Blue, Yellow (but not Red) = ...

RESULT_A is the sum of the results from Red, Green, and Blue boards.
... and so on.

The final RESULT used to score an entry is the MAX of RESULT_A, RESULT_B,
RESULT_C, RESULT_D

General solutions (with low variance) will get full credit for their good "result"
in each of the test subsets. Tweaky overfitting solutions (with high variance)
will get punished according to their worst result in one of the subsets.

The execution time would still be the time to process the entire test suite.

I hope this idea makes sense to the Matlab Contest Team. If not, ... I could
try to do a better job of explaining it. I think it would be pretty
straightforward to test it on some entries from the Wiring Contest.

Who knows, ... they could even use this idea to award a "Generality Prize" for
the Wiring Contest ... perhaps by scoring those entries that were leading the
competition at one time or another ...

-- David Jones

parameter tweaking is allowed, and using random is not a
bad thing as well. But using many submissions to walk
through the solution space is meaningless(because it's
trivial if we have *enough* time). I have only 2 hours/day
to watch the contest. I aslo do some my own codes,but I
have no time to finish them. However, I think to hit 13000
is very possible. But all are high on using parameter
tweaking(throgh many submissions) to get a special lucky
one in the late contest.

Congrats on your win Stefan! It looks like tweaking at the
end paid off for you. And thanks to the MATLAB contest team
again for organizing another fun and exciting event.

> Here is a generalized version of this idea that I would
actually recommend
> implementing ... (it uses the majority of the large test
suite to assign the final
> score, so it might be more robust).
>
> Let's say we want a test suite containing 256 boards for
the Wiring puzzle.
> The contest team carefully creates 4 classes of puzzles
(maybe 64 of each) ...


Hi David,

don't you think that when using your suggestion, tweak
bombing would lead to minor steps approaching the optimal
solution for the modified score computation? I think there
would also be an overfitting, in a slightly different manner.

Markus

> > That said, I would support a change to the scoring
> function
> > such that run time is rounded to the nearest second. That
> > should mostly eliminate the effect of timing variation.

I also support everything that would take the motivation out
of tweaking. But also with the changed timing, a minor time
improvement could lead to a jump from one quantization
interval to the next...

Markus

Congratulations to the grand prize, Stefan!

I am glad the grand prize is going to Germany the second
time in a row! ;-)

Markus

"Markus Buehren" <mb_matlab.REMOVE@gmxTHIS.de> wrote in
message <fvu4c8$jkj$1@fred.mathworks.com>...
> Congratulations to the grand prize, Stefan!
>
> I am glad the grand prize is going to Germany the second
> time in a row! ;-)
>
> Markus

Congratulations to Stefan! I am glad to see the final
wnning entry was based on one of my final improvements
(13th generation).

I noticed you were able to pick up my "new trial" code.
Unfortunately, I was not able to correctly estimate the
impact of the improved speed on score. If I included 4
different board manipulations, it might win the prize.

I completely missed the darkness and twilight phases. In
daylight phase, I was concentrated on improving the
bridgepath function because I found it was the bottleneck
for both complexity and speed. This has been proven
productive although myself missed the 1000 node contest to
Tim. :(

The current winning code still has many rooms to improve.
If we had time, the 13000 goal would be achievable.

Anyway, it was another great fun to join the contest.
Thanks to TMW team for organizing the contest.

See you all in six month time.

Yi

Thanks again Mathworks!

Congratulations to Stefan, Tim and David. (Nice solution,
David!)

Nathan

"Yi Cao" <y.cao@cranfield.ac.uk> wrote in message
<fvucs2$d4v$1@fred.mathworks.com>...
> "Markus Buehren" <mb_matlab.REMOVE@gmxTHIS.de> wrote in
> message <fvu4c8$jkj$1@fred.mathworks.com>...
> > Congratulations to the grand prize, Stefan!
> >
> > I am glad the grand prize is going to Germany the second
> > time in a row! ;-)
> >
> > Markus
>
> Congratulations to Stefan! I am glad to see the final
> wnning entry was based on one of my final improvements
> (13th generation).
>
> I noticed you were able to pick up my "new trial" code.
> Unfortunately, I was not able to correctly estimate the
> impact of the improved speed on score. If I included 4
> different board manipulations, it might win the prize.
>
> I completely missed the darkness and twilight phases. In
> daylight phase, I was concentrated on improving the
> bridgepath function because I found it was the bottleneck
> for both complexity and speed. This has been proven
> productive although myself missed the 1000 node contest to
> Tim. :(
>
> The current winning code still has many rooms to improve.
> If we had time, the 13000 goal would be achievable.
>
> Anyway, it was another great fun to join the contest.
> Thanks to TMW team for organizing the contest.
>
> See you all in six month time.
>
> Yi

"Yi Cao" <y.cao@cranfield.ac.uk> wrote in message
<snip>

> Congratulations to Stefan! I am glad to see the final
> wnning entry was based on one of my final improvements
> (13th generation).

Yes, the winning entry was indeed based on your 13th
generation, and I appreciate your contribution, and the
contributions of all others that improved that piece of code
during the contest.


> I noticed you were able to pick up my "new trial" code.
> Unfortunately, I was not able to correctly estimate the
> impact of the improved speed on score. If I included 4
> different board manipulations, it might win the prize.

No, did not pick up your "new trial" code. (You introduced
the board manipulations in "new trial 1" which was submitted
11:55:46; the winning entry "tweaky bird and pushy cat 21"
was already submitted 11:55:18.)

Actually I came across the idea to trade some speed for
accuracy already during the 1000 nodes contest, where
basically the same modification led to about 4000 pts.
improvement in results, while worsening the time by about 20
ms (entry "....until you can call him a man.").

For the final contest, I prepared lots of browser tabs and
picked entries by random to apply this manipulation (and
some different ones that were not quite successful). Then I
waited the deadline to approach to submit all those entries.
Unfortunately, my poker face broke to early and, thus, I
started submitting to early. I was done with submitting
already 11.56, leaving lots of time for others to pick up
entries (see Alan's win in the best results.
Congratulations, Alan!). Finally, the winning entry improved
the score of "13th generation" by about 100 pts.

Big thanks to the team at matlab central for organizing
another great contest and all the participants for an
entertaining week.

See you all in Fall...

Regards,
Stefan aka srach

"srach " <s.rach_NOSPAM_@jacobs-university.de> wrote in
message <fvuln8$m57$1@fred.mathworks.com>...
>
> No, did not pick up your "new trial" code. (You introduced
> the board manipulations in "new trial 1" which was
submitted
> 11:55:46; the winning entry "tweaky bird and pushy cat 21"
> was already submitted 11:55:18.)
>

No, I did not mean the winning entry but the entry
of "tweaky bird and pushy cat 26", which was submitted at
11:57:36. The "new trial" code combines all 4 search paths
in "bridgepath_a" into a for loop. It becomes faster with
reduced complexity to 18, but the original tuning
parameters make the results worse. To fully use the
improvement in speed, we have to inlcude more board
manipulations. Observing all results it produced, I
estimate we can have 4 board manipulations, which should
significantly reduce the results.

Yi

"Yi Cao" <y.cao@cranfield.ac.uk> wrote in message
<fvurpi$2an$1@fred.mathworks.com>...
> "srach " <s.rach_NOSPAM_@jacobs-university.de> wrote in
> message <fvuln8$m57$1@fred.mathworks.com>...
> >
> > No, did not pick up your "new trial" code. (You introduced
> > the board manipulations in "new trial 1" which was
> submitted
> > 11:55:46; the winning entry "tweaky bird and pushy cat 21"
> > was already submitted 11:55:18.)
> >
>
> No, I did not mean the winning entry but the entry
> of "tweaky bird and pushy cat 26", which was submitted at
> 11:57:36. The "new trial" code combines all 4 search paths
> in "bridgepath_a" into a for loop. It becomes faster with
> reduced complexity to 18, but the original tuning
> parameters make the results worse. To fully use the
> improvement in speed, we have to inlcude more board
> manipulations. Observing all results it produced, I
> estimate we can have 4 board manipulations, which should
> significantly reduce the results.
>
> Yi

You are, of course, correct; I did get you wrong.

Regards,
Stefan

"srach " <s.rach_NOSPAM_@jacobs-university.de> wrote in
message <fvuln8$m57$1@fred.mathworks.com>...
> For the final contest, I prepared lots of browser tabs and
> picked entries by random to apply this manipulation (and
> some different ones that were not quite successful). Then I
> waited the deadline to approach to submit all those entries.

Interesting approach, Stefan. This sounds like an overview
of your test strategy would be a very interesting YouTube
video for others to start planning their strategy for the
Fall Contest.

> Unfortunately, my poker face broke to early and, thus, I
> started submitting to early.
:-)

> Big thanks to the team at matlab central for organizing
> another great contest and all the participants for an
> entertaining week.
>

It was our pleasure! Thank you to everyone who
participated. It was your actions, both with submissions and
in discussion, that make our contests such fun.

Helen

The function runcontest displayed the overall results and
time. However, statistics such as minimum, mean, variance
and maximum are much more helpful for evaluating the
performance of the solver than a sum only. Is it possible
that the runcontest function of the next contest includes
performance statistics?

Hi all,
congratulations to the winners!
It has been my first partecipation, it has been a very
interesting experience, the problem was very interesting too
and very funny!!
I'm also glad that in the winning code there is a my
(little) improvement (and vainly I obfuscate it :-) ).

The main speedup was to avoid to put the bridgepath function
in the double nested loop in phase2. It was better to call
only once a function newBridgepath (aka d4TZerDbiG in the
winning entry) that finds a path for all the sources pins
and all the targets concurrently. Initially the global
speedup was of about 60% in time!!
Unfortunately the change produced a function with a
different behaviour and so it was impossible to apply the
speedup to an "overtuned" entry and to get the same score again.

An other speedup regards the functions phase1 and phase3: in
such functions it's useless to call the function complexpath
two times with the same value of b, so many computations
could be saved, with an improvement of about 30% in time.
Unfortunately I didn't succeed in using the saved time to
win the contest. :-(

Regarding the suggestions about the rules of the contest, I
think that:

1) As many people say, randomness is unavoidable.
2) Why don't hide the score and the code of an entry for the
last 60 (or 30) minutes before a deadline? So it won't be
necessary to submit a winning-candidate entry only 3 minutes
before the end of the contest (with many risks!).
3) To avoid the tweak bombing (I also submitted about 100
entries in the last 5 minutes of the contest) it would be
useful to use very large test suites, i.e. 2000 puzzles
instead of 200, so the effect of randomness will be
negligible. Moreover the efficiency will be crucial.
4) (stupid idea) Why don't you organize also a "short-life
contest"? It's very difficult to find the time to follow the
contest for a whole week. It would be very convenient to
partecipate to a contest only during the week-end.

A request:
I'd ask the staff what is the initialization of the random
generator. The behaviour of the random generator is very
important to succeed in overfitting the puzzles and I want
to see on my computer the score of some scripts that I
mistakenly didn't submit. :-((
Fortunately these scripts are losing versus "tweaky bird and
pushy cat 21" with many random seeds :-)

Thank you!!
Goodbye and sorry for my bad english!!!

> 4) (stupid idea) Why don't you organize also a "short-life
> contest"? It's very difficult to find the time to follow
the
> contest for a whole week. It would be very convenient to
> partecipate to a contest only during the week-end.

I suggest the opposite: The contest should last three or
for weeks. The darkness and twilight should last a week
respectively. Why?

1. When daylight begins, many participants focus on
tweaking. If you try to develop and optimize an algorithm
during this time, the results are worse than average.

2. The best programs were also the longest and most
complicated. If functions are called "sunday" or "tweak",
it is difficult to figure out what they mean. So tweaking
is mainly done by parameter tuning instead of algorithm
optimization.

3. People who can work on their entries during the weekend
only have also a chance to take part in the contest.

By the way, I think that the explanation of the rules is
misleading somehow. When pin values are one digit numbers,
connectors are expensive compared to the pins.
 
However, when the pin values are two digit numbers on a 15
* 17 board, they are actually cheap. Under this condition,
connecting isolated islands is not a waste of time and
material. The number of points saved exceeds the number of
connectors often.

By connecting distant islands, the board can get fragmented
and it gets necessary to build bridges or to leave many
pins unconnected. But this means that isolated island
themselves should be avoided, not connecting them.

"OkinawaDolphin " <OkinawaDolphin@Hotmail.com> wrote in
message <g00t34$kj5$1@fred.mathworks.com>...
>
> 2. The best programs were also the longest and most
> complicated. If functions are called "sunday" or "tweak",
> it is difficult to figure out what they mean. So tweaking
> is mainly done by parameter tuning instead of algorithm
> optimization.
>

The subday function name was given by me. I used it in my
local computer to identify different version of code
because it was developed on sunday. Basically, it is a
solver. Since it was the first entry when it was submitted,
it has been copied into allmost all entries. :)

Yi

Congratulations to Stefan and all participants.

Many thanks to organizers of great contest.

SY (Sergey)

P.S. Sadly:

Any new even mildly new code modification has to be tweaked
somehow to be competitive with previous highly tweaked
code. The author has two choices: submit numerous
modifications with “all possible” parameters or try to
adjust parameters looking on code score. Second method has
several significant disadvantages: somebody else may pick
up code and find best parameter combination faster, author
may not have enough time before deadline, queue may be
stalled.
So, here is my conclusion: I am writing my out “tweaking
machine gun” and will use it next time if captcha is not
implemented.

"Sergey " <ivssnn@yahoo.com> wrote in message
> Any new even mildly new code modification has to be tweaked
> somehow to be competitive with previous highly tweaked
> code.

Hi Sergey:

You are right. Introducing a new idea to compete with
hyper-tweaked code is very difficult. We'd like to make it
easier. Can you think of things we might do to the contest
machinery to make it easier to introduce new algorithmic
ideas? Based on all the feedback so far, we will probably
introduce some kind of rate limiter (whether by CAPTCHA or
otherwise). What are some other ideas? I've often wondered
if people might flag new ideas explicitly with a message
like "please help me tweak a new concept into first place."
We tried a late stage twilight last time, but it didn't seem
to help, and it wasn't much fun.

-Ned.
Contest Team

"Ned Gulley" <gulley@mathworks.com> wrote in message >
> Hi Sergey:
>
> You are right. Introducing a new idea to compete with
> hyper-tweaked code is very difficult. We'd like to make it
> easier. Can you think of things we might do to the contest
> machinery to make it easier to introduce new algorithmic
> ideas? Based on all the feedback so far, we will probably
> introduce some kind of rate limiter (whether by CAPTCHA or
> otherwise). What are some other ideas? I've often wondered
> if people might flag new ideas explicitly with a message
> like "please help me tweak a new concept into first
place."
> We tried a late stage twilight last time, but it didn't
seem
> to help, and it wasn't much fun.
>
> -Ned.
> Contest Team

I think to encourage new idea, we have to introduce some
generality index to be included in the overall score. When
a new algorithm is submitted, even it may not be able to
compete with current best code, but if it shows some
advantage in generality, it might be pick up by someone
else to tweak it into top. The generality index can come
from another hidden testsuit or simply an average results
by dropping different portion of cases in the testsuite
(something like cross validation).

Another suggestion, can we make the last 30 minutes or so
as the twilight phase, or disable downloading an entry from
the waiting queue? This will encourage people to submit
their final code earlier.

The node index and 1000 node contest were good. But, it
seems that the weight of the node index was too small, no
one cared about it.

Yi

> Based on all the feedback so far, we will probably
> introduce some kind of rate limiter (whether by CAPTCHA or
> otherwise).

I am really glad to hear that :-) A captcha will take most
of the fun out of the annoying tweak-bombing.

> I've often wondered
> if people might flag new ideas explicitly with a message
> like "please help me tweak a new concept into first
> place."

Hmm, but in this way the contestant who had the idea will
probably not be rewarded with a contest prize...

> else to tweak it into top. The generality index can come
> from another hidden testsuit or simply an average results
> by dropping different portion of cases in the testsuite
> (something like cross validation).

Good idea, but as every submission must be rated under the
same conditions, finally we will again have only one rating
function outputting one score value. Entries can be tweaked
against this score...

> Another suggestion, can we make the last 30 minutes or so
> as the twilight phase, or disable downloading an entry from
> the waiting queue? This will encourage people to submit
> their final code earlier.

Good idea! Code in the queue should generally be hidden, and
also all code submitted in the last hour or 30 minutes
before a phase deadline, even if it was already processed.


Further, I would still like to have some extension to the
twilight phase. However, if someone does not have the time
to develop his own code, he would not get an entry into the
contest. So this is my suggestion for a compromise:

The submissions of the ten best contestants (not ten best
submissions!) after twilight should be published after 48
hours. All other submitted code, as well as all new
submissions during the "twilight 2" phase should be hidden
until this phase ends. This way everyone can see some code
examples, optimize them or build his own best combination of
those submissions.

Only drawback of this suggestion might be that people could
submit obfuscated code to hide their ideas. However, I
personally would be very proud to see my own code survive
until the end of the contest, so I would not start
obfuscating already during the first contest hours.


Finally: Any idea about how to avoid obfuscation???


Yours
Markus

First of all, hats off to Matlab team for organizing
another exciting contest. and few ideas towards supporting
generality:

1.
> Further, I would still like to have some extension to the
> twilight phase.

I agree with Markus, (don't know if you meant like this):
but I would like to have the twilight extended at least
half a day more.

2. make the 1 Hr before the deadline time of say best
result before 6,1000 node challenge, final day etc,
TWILIGHT (no code download but score visible).
 
3. A lot of tweaking is aimed at improving the best score
by reducing computation time. In current format, a time
improvement of the order of -0.0001 is enough to have new
score improvement with same result. Same result possibly
indicates no improvement from algorithm side. This could
be changed after say Saturday push. reduce this order
sequentially, Saturday 0.0001, Sunday 0.1 ... On sunday
one can also round off the time to nearest integer. So, to
improve score one has to really work on the algorithm to
improve the "result". change the scoring coefficients
after sunday to lay more weight on result than time.

4. I like the idea of the "generality index" into the
scoring equation. And around Sunday, change focus from
just minimizing the score to somehow include the
generality condition as well. Such that for an overfitted
solution which exceeds the maximum "generality index" the
score would be penalized evenif it reduces result or
improves time on current set. Counting usage of random
functions (if possible) might help as no. of use of random
functions should be inversely related to the generality.

Anyway just a few thoughts (maybe already quite a few
lines), but open to debate and grow further ....

BR,
Abhisek

First of all, hats off to Matlab team for organizing
another exciting contest. and few ideas towards supporting
generality:

1.
> Further, I would still like to have some extension to the
> twilight phase.

I agree with Markus, (don't know if you meant like this):
but I would like to have the twilight extended at least
half a day more.

2. make the 1 Hr before the deadline time of say best
result before 6,1000 node challenge, final day etc,
TWILIGHT (no code download but score visible).
 
3. A lot of tweaking is aimed at improving the best score
by reducing computation time. In current format, a time
improvement of the order of -0.0001 is enough to have new
score improvement with same result. Same result possibly
indicates no improvement from algorithm side. This could
be changed after say Saturday push. reduce this order
sequentially, Saturday 0.0001, Sunday 0.1 ... On sunday
one can also round off the time to nearest integer. So, to
improve score one has to really work on the algorithm to
improve the "result". change the scoring coefficients
after sunday to lay more weight on result than time.

4. I like the idea of the "generality index" into the
scoring equation. And around Sunday, change focus from
just minimizing the score to somehow include the
generality condition as well. Such that for an overfitted
solution which exceeds the maximum "generality index" the
score would be penalized evenif it reduces result or
improves time on current set. Counting usage of random
functions (if possible) might help as no. of use of random
functions should be inversely related to the generality.

Anyway just a few thoughts (maybe already quite a few
lines), but open to debate and grow further ....

BR,
Abhisek

Seem to me, we are coming to some consensus. I would like
to see last one hour before all deadlines to be twilight
too. It will give some time for new code to be adjusted and
make sure that the real author of good modification will
get credit. However it does not solve completely problem of
automatic submissions because they still may clog queue and
deny everybody feedback from test, making it essentially
dark.

There were a lot of discussions about test set overfitting.
I do not think that any suggested method of using subsets
will really work; it will just change test set (or weighted
combination of sets) to fit.
Another idea is to make “generality” prize the main prize
with limited number of submission from each participant.

All this may be (?) less important with different kind of
contest problem. I would say that Blackbox contest having
its own problem (probing) was not under the danger of
overfitting and unnecessary parameter tweaking.

"Ned Gulley" <gulley@mathworks.com> wrote in message
<g036ef$i42$1@fred.mathworks.com>...

>
> Hi Sergey:
>
> You are right. Introducing a new idea to compete with
> hyper-tweaked code is very difficult. We'd like to make it
> easier. Can you think of things we might do to the contest
> machinery to make it easier to introduce new algorithmic
> ideas? Based on all the feedback so far, we will probably
> introduce some kind of rate limiter (whether by CAPTCHA or
> otherwise). What are some other ideas? I've often wondered
> if people might flag new ideas explicitly with a message
> like "please help me tweak a new concept into first place."
> We tried a late stage twilight last time, but it didn't seem
> to help, and it wasn't much fun.
>
> -Ned.
> Contest Team


Ned:

I'd like to put forth a couple comments, suggestions:

-The 'late-stage twilight' you tried previously wasn't
really what everyone has been suggesting. I believe you did
it right after the test-suite swap, whereas I believe
everyone has more interest in it occurring at the VERY END,
of the contest.

-I'm glad to hear you are seriously considering implementing
a rate-limiter on the entries submissions. The main contest
community has been asking for this for a long time and I
guess my tweak bombing was the straw that finally broke the
camel's back. I'm not sure what the reluctance has been in
the past from the organizers to implement it, but I suspect
it's just that there is a certain amount of technical effort
you don't have time to implement. Perhaps you could look at
the reCAPTCHA project
(http://recaptcha.net/whyrecaptcha.html). It's a free
implementation and general easy to utilize.

-I like the suggestion someone else made on having the queue
entries not be visible until they are run. This, combined
with a rate-limiter should significantly reduce the
'free-for alls' we see at the contest deadlines.

-Another way to potentially test for generality is to have a
 second test suite that the codes are only run against maybe
once a day. The test-suite swap doesn't seem to have
reduced the tweaking too much, albeit caused just the
opposite. I think the way to test for generality is to
reduce, but not eliminate, the feedback you give us on the
solvers against a secondary test suite. One suggestion would
be to run at midnight each night the top x
(50? 100?) solvers against an alternate test-suite and
provide a 'generality' score. This would prevent someone
from trying to 'bomb the queue' with a ton of entries, since
only a handful would be checked for generality, and would
add a new element for dedicated competitors where they have
to closely examine the leading 'generality' solvers to
understand why they are so much better. You might even mix
up the alternate test suite each night.

-I really liked the new node challenge that replaced the
character challenge. It virtually eliminated the
obscufation that always occurs around that time of the contest.

-I missed having the mid-contest analysis Lucio normally
does. I always find that a very insightful part of the
competition and while I understand it takes time, I hope you
find a way to include it in future contest again. Perhaps
you could outsource some of it to contest competitors like
myself that are interested in contributing to the
'meta-contest'?

-I like the idea of randomly seeding the rand function
within the runcontest routine for each time it runs (i.e.
rand('twister', time*100)). That would definitely reduce
the 'over-fitting' we always see occuring. It wouldn't
eliminate the 'tweak bombing', but some of these other
suggestions would help with that.

-I also would like to echo the idea of reducing the time
dependence on the score. One way to do that is to pick the
scoring coefficients more appropriately to 'de-value' minor
timing variations. Another way would be to just round the
times to the nearest tenth second.

-I also like how you have provided a nice variety on the
mid-game contests. Sometimes you announce them way in
advance and give lots of time to work on them, other times
you 'spring them on us' and only provide a few hours. The
varied end times also allow for competitors virtually
anywhere in the world to be able to participated at least once.

Thanks again for hosting another fun contest! I look
forward to the fall version.

I do also second the idea of returning to twilight for the
last hour of the contest. In addition, I would suggest to
switch to a new testsuite for this last hour. This would
give algorithmic improvements a better chance against highly
tweaked code. However, one should abandon the idea that this
last hour in twilight will leave time to optimize any code
to the new testsuite, because the queue will fill quite
quickly, I think.

Regarding the tweak bombing, it is not "them" that are
spamming, it's us. Thus, all we should need is a kind of
agreement how many entries per person are considered normal
participation, and at which number of entries spamming
starts. Thus, if we agree on only submitting only about 100,
200, or 400 entries, we don't need a CAPTCHA (still I would
welcome one). Of course, one can still use different aliases
for submissions, but we all are free not to do so.
Nevertheless, the queue will still get pretty crowded close
to deadlines.

Same is true for obfuscating, we should simply don't do it.
My impression of the current contest was, that obfuscation
was less frequent compared to earlier contests, although it
appeared to result in slightly faster run-times.


In this contest, I liked the 1000 node contest; it is much
better than the 1000 character contest, because there is no
need anymore to obfuscate in order to reach the character
limit.

Maybe it should be considered to extend the first twilight a
little bit to allow more time for the development of
different algorithms.

Regards,
Stefan aka srach

"Steve Hoelzer" <shoelzer@gmail.com> wrote in message
<fvsqp9$8gg$1@fred.mathworks.com>...
> "Yi Cao" <y.cao@cranfield.ac.uk> wrote in message
> <fvsot0$gr9$1@fred.mathworks.com>...
> > However, I would like to suggest to use a random
function
> > in runcontest function to make tuning random parameters
> > imposible. For example, in runcontest function, a line
of
> > rand('state',sum(100*clock)) can make any intention to
tune
> > a random parameter impossible because even with the
same
> > parameters, the results could be totally different if a
> > random function is used in a code.
> >
> > Yi
>
> No. The same code must give the same score every time it
> runs. Otherwise, a new type of random variable "tuning" is
> possible: submitting the same code multiple times. I too
> wish that magic number tuning was not a part of the
contest,
> but I don't think it can be programmatically enforced.
>
> Steve

If most of us agree to discourage using random functions,
then including a random seeds in runcontest is a solution.
It wont affect entries which do not use any random function
but will make results unpredictable if a random function is
used. It is against "The same code must give the same score
every time it runs". However, this is what the
user "deserved" because he/she makes some decision
randomly. OK, they can resubmit the same code several
times, but seldom one of them can get to the top because
they cannot tune parameters systematically.

I support the idea to let the final stage of contests a
twilight phase. It is also logical, a contest starting from
darkness, then twilight, then full daylight, finally
twilight again because it is going to finish. It does not
need to be a full day, but 4 hours will be enough. If
possible, I would like only those submitted during the last
4 hours to be protected from download but not old entries.
This will help us to search the complete list to find a
good code to work with during the final stage.

Yi

Hi all,

I post one idea here again in the hope for some comments.
The idea was about an extension of the twilight phase:

The submissions of the ten best contestants (not ten best
submissions!) after twilight should be published after 48
hours. All other submitted code, as well as all new
submissions during the "twilight 2" phase (like another 24
hours) should be hidden until this phase ends. This way
everyone can see some code examples, optimize them or build
his own best combination of those submissions.


And another thing: I guess many contestants have more time
for the contest in the weekend compared to weekdays.
However, in the weekend most of the times there are no
challenges ending where one could win a prize. Maybe the
contest team could announce one or two challenges also for
saturday and sunday before going into their deserved
weekend? If a rate limiter like a captcha is implemented,
hopefully there will be no queue or statistics crashes
during that time...

Markus

Contest team, I haven't said it yet, so thanks for running
another great contest! I'm already looking forward to the
next with some of the changes that have been mentioned here.

Speaking of those changes, here's my take on many of items
that have been brought up...

Ideas I like:
    1. Rate limiter.
    2. Longer twilight.
    3. 1000 nodes instead of 1000 characters. (Although
maybe 1000 is too large. Maybe a 500 node challenge?)
    4. Can't view entries until they are scored.
    5. Mid-contest and end-of-contest analyses. I know it is
a lot of work, but I always find them interesting and
sometimes helpful in developing my own code.

Ideas I'm not sure about:
    1. One hour twilight before all contest deadlines. This
may cause people to only submit code right before deadlines,
which would make the rest of daylight pretty boring. If
twilight is only added at the very end of the contest, then
the phases become darkness, dawn, daylight, and dusk.
    2. Random rand seed. Random numbers *can* have a place
in legitimate entries, and I feel pretty strongly that an
entry should give the same score every time it runs.
However, this would eliminate one type of magic number tuning.
    3. Quantize run time in the scoring equation. This
minimizes the impact of tiny speed tweaks and run time
variation, but quantization boundaries will always be a problem.

Ideas I'm against:
    1. Some other method of computing a generality score. No
matter how you do it, tweaking can optimize entries for the
new score computation.
    2. Reduce the weight of time in the score. It's more
interesting to balance time vs. performance, rather than
just go for performance.

Contest team, I haven't said it yet, so thanks for running
another great contest! I'm already looking forward to the
next with some of the changes that have been mentioned here.

Speaking of those changes, here's my take on many of items
that have been brought up...

Ideas I like:
    1. Rate limiter.
    2. Longer twilight.
    3. 1000 nodes instead of 1000 characters. (Although
maybe 1000 is too large. Maybe a 500 node challenge?)
    4. Can't view entries until they are scored.
    5. Mid-contest and end-of-contest analyses. I know it is
a lot of work, but I always find them interesting and
sometimes helpful in developing my own code.

Ideas I'm not sure about:
    1. One hour twilight before all contest deadlines. This
may cause people to only submit code right before deadlines,
which would make the rest of daylight pretty boring. If
twilight is only added at the very end of the contest, then
the phases become darkness, dawn, daylight, and dusk.
    2. Random rand seed. Random numbers *can* have a place
in legitimate entries, and I feel pretty strongly that an
entry should give the same score every time it runs.
However, this would eliminate one type of magic number tuning.
    3. Quantize run time in the scoring equation. This
minimizes the impact of tiny speed tweaks and run time
variation, but quantization boundaries will always be a problem.

Ideas I'm against:
    1. Some other method of computing a generality score. No
matter how you do it, tweaking can optimize entries for the
new score computation.
    2. Reduce the weight of time in the score. It's more
interesting to balance time vs. performance, rather than
just go for performance.

Hi all,

I want to express an idea about the weight of time in the score.
The quantization of time in the score can suffer of
boundaries problem, as Steve Hoelzer wrote. A solution can
be the following:

1) If an entry obtains the *same* result of a previous entry
and its CPU time is better than the one of the previous
entry by less than 1s (or 0.XXXs), the score "collapses" to
the one of the first entry (+ epsilon). In example, assume that:

Score = Time + Result

the following results will hold:

Result 10, Time 10.5, Score: 20.5
Result 10, Time 10.4, Score 20.5 + eps
Result 10, Time 9.501, Score 20.5 + eps
Result 10, Time 9.49, Score 19.49
Result 9.9, Time 9.4, Score 19.3
Result 10, Time 8.491, Score 19.49 + eps
Result 10, Time 8.3, Score 18.3

Thus small and accidental cpu time improvements will be ignored.

Fabio

Is it just me or is the contest page missing now?
http://www.mathworks.com/contest/wiring/home.html
redirects to a 'page not found'....

"Alan Chalker" <alancNOSPAM@osc.edu> wrote in message
news:g0ft93$plv$1@fred.mathworks.com...
> Is it just me or is the contest page missing now?
> http://www.mathworks.com/contest/wiring/home.html
> redirects to a 'page not found'....

I'm not sure what the status was last night, but it seems to be up now.

--
Steve Lord
slord@mathworks.com

I want to add a few comments to what Steve Hoelzer has
already said about the suggested changes for the Matlab
contest ...

"Steve Hoelzer" <shoelzer@gmail.com> wrote in message
<g09kgq$ldb$1@fred.mathworks.com>...

> Ideas (Steve) liked:
>
> 4. Can't view entries until they are scored.

I would suggest a variation on this idea.

During most of the Daylight phase, allow entries in the
queue to be viewed (even before they are scored). I think
this adds to the interest and excitement by allowing all
competitors to learn what various tricks people are trying,
and most of the time there is no benefit for waiting until
the entries are scored. ... and I wouldn't like to see any
incentive for people clogging the queue, just to delay
others from seeing their not-yet-scored entry further down
the queue.

During the final hour of the contest, go into a kind of
"Late Twilight" where entries can't be viewed until they are
scored. This will enable competitors to submit what they
think might be a winning improvement, without needing to
wait until the last 5 minutes, and without needing to submit
100 variations of essentially the same thing.

I also think many people have real life constraints on their
schedules (at work or home, depending on time zone) that
makes it difficult for them to be at their computer
precisely moments before the deadline to trigger some
specialized software to submit 500 entries at a rate of 10
per second, or to click submit on several dozen Firefox
browser tabs they set up in advance ...




> 5. Mid-contest and end-of-contest analyses.


I agree these are really valuable and worth the effort.
They help competitors "catch up" and understand how the key
algorithms form Darkness/Twilight are working, ... thus
increasing more effective participation in the later stages
of the contest. They also have lasting educational value
for students who want to how to use Matlab to solve problems
similar to the Contest puzzles.

>
> Ideas Steve was not sure about:
> 1. One hour twilight before all contest deadlines.

I agree we should keep the frenzy and free-for-all
atmosphere for all the mid-contest deadlines, ... but the
one hour twilight before the final deadline does makes sense.


> 2. Random rand seed.

I think the repeatability of scoring the entries is
critically important, so it would be a mistake to vary the
random seed.

Randomization does have a legitimate role in many realistic
algorithms. In the Wiring Contest, there were often several
"equivalent" choices for different wire paths. An effective
strategy was to have a very fast algorithm so you could
solve the problem two (or more) times, choosing different
"random" paths each time, and then selecting the better
solution.

We don't know the actual test suite, and we don't know the
actual random number seed. Both are part of the same
phenomenon of "over-fitting" in the leading entries.

I would like to add another suggestion to the mix ...


If people are generally happy with the idea of a "Late
Twilight" phase in the closing hours of the Matlab Contest,
it would make sense to give a prize, ... let's call it the
"Dusk prize", since the sun would be setting on Daylight.

This would reward a person who submits the leading entry "in
the clear" during Daylight.

After that, during the "Late Twilight", all entries would
remain visible once they are scored, but entries sitting in
the queue would not be visible.

-- David Jones

I have developed a post-contest solver to break the 13000
barrier. It is able to reduce results to below 130000 in
about 30 seconds. Complexity is reduced to 10 and length in
node to 2778.

The code has been submitted to Matlab File Exchange. It has
many tunable parameters for those who wish to optimize the
code to play with. Please let me know your findings.

Yi