Next tournament: programmer vs. programmer

[arturo100]

I still see unfair comp-comp tournaments in which programs are using more cores, bigger hard-disks, extended opening books, more fast RAM, dedicated hardware, etc. I would propose that next time programmers play against each other, trying to derive their moves from paper calculation (a la Turing).

[Harvey Williamson]

I still see unfair comp-comp tournaments in which programs are using more cores, bigger hard-disks, extended opening books, more fast RAM, dedicated hardware, etc. I would propose that next time programmers play against each other, trying to derive their moves from paper calculation (a la Turing).

1. GM Larry Kaufman
2. FM Vincent Diepeveen

[mathmoi]

What if a team can get a better pencil than me? Shouldn't we standardize the pencil and paper used?

[govert]

What if a team can get a better pencil than me? Shouldn't we standardize the pencil and paper used?

What if someone has a better brain than me. That would be unfair too!!

[swami]

I still see unfair comp-comp tournaments in which programs are using more cores, bigger hard-disks, extended opening books, more fast RAM, dedicated hardware, etc. I would propose that next time programmers play against each other, trying to derive their moves from paper calculation (a la Turing).

1. GM Larry Kaufman
2. FM Vincent Diepeveen

Actually, #2 should be IM Vasik Rajilich.

#3 either Miguel or Vincent

[Harvey Williamson]

I still see unfair comp-comp tournaments in which programs are using more cores, bigger hard-disks, extended opening books, more fast RAM, dedicated hardware, etc. I would propose that next time programmers play against each other, trying to derive their moves from paper calculation (a la Turing).

1. GM Larry Kaufman
2. FM Vincent Diepeveen

Actually, #2 should be IM Vasik Rajilich.

#3 either Miguel or Vincent

I think the Jonny programmer has IM norms also.

[Albert Silver]

I still see unfair comp-comp tournaments in which programs are using more cores, bigger hard-disks, extended opening books, more fast RAM, dedicated hardware, etc. I would propose that next time programmers play against each other, trying to derive their moves from paper calculation (a la Turing).

1. GM Larry Kaufman
2. FM Vincent Diepeveen

Presuming they derive their moves STRICTLY from paper calculation, that list above is completely off, unless Larry and Vincent are a whizzes with paper math.

That said, let me make my own proposition:

Computer Chess Boxing!

The programmers have to manually play the moves their engines propose on a physical board, a blitz game, then they get up and put their gloves on!

[Don]

I still see unfair comp-comp tournaments in which programs are using more cores, bigger hard-disks, extended opening books, more fast RAM, dedicated hardware, etc. I would propose that next time programmers play against each other, trying to derive their moves from paper calculation (a la Turing).

1. GM Larry Kaufman
2. FM Vincent Diepeveen

Presuming they derive their moves STRICTLY from paper calculation, that list above is completely off, unless Larry and Vincent are a whizzes with paper math.

That said, let me make my own proposition:

Computer Chess Boxing!

The programmers have to manually play the moves their engines propose on a physical board, a blitz game, then they get up and put their gloves on!

Each paper player should be playing in behalf of their opponents. In other words if you and I have submitted paper programs then I operate your program and do the calculations you specify and visa versa. Each program author of course might want to verify that hist programs moves moves were being correctly executed. Any disagreement could be settle between them, but in the case where they cannot resolve the bug the author could request some additional help from a 3rd party.

Here is a simple paper program:

1. play a legal move selected in a uniformly random way.

A RNG could be constructed based on coin flips.

Probably better to have a paper program that can be unambiguously executed and that does not rely on any random selection or outside paraphernalia such as coins or dice.

I made such a program when I was a kid and before home computers existed. I vaguely remember that step 1 started with "are you in check? If yes, goto step 2, otherwise go to step 10." I specified that you should capture the checking piece if possible and I had rules to determine which piece should capture it if there was more than one.

It was kind of fun I remember but the challenge is to make it very trivial to execute. It should not be so difficult that you absolutely must have a paper and pencil and do a ton of calculation. It's also more difficult than you think not to create ambiguous rules. You cannot make assumptions about concepts without really precise definitions - for instance you cannot ask "is your queen in danger" without having a very precise definition of what "in danger" means.

[Bo Persson]

I still see unfair comp-comp tournaments in which programs are using more cores, bigger hard-disks, extended opening books, more fast RAM, dedicated hardware, etc. I would propose that next time programmers play against each other, trying to derive their moves from paper calculation (a la Turing).

1. GM Larry Kaufman
2. FM Vincent Diepeveen

And they must of course not use more than 8 moves worth of opening theory!