Fix k61r.

[drvinceknight]

Closes Axelrod-Python/axelrod-fortran#62

See discussion at that issue.

[marcharper]

Let's add a comment that this was a new addition

[drvinceknight]

Yeah good call.

[marcharper]

Is this necessary? Seems like it's not...

[drvinceknight]

Woops. My mistake, was trying things!

[meatballs]

My best guess as what's going on here:

In the documentation for the orginal code , there is a line which says

a. the -SAVEALL option must be used in the Language Systems Fortran compiler to make the local variables in the rule functions static (ie remembers from one call to the next).

By default, when a Fortran function returns, all variables within that function become undefined. The -SAVEALL option would override that behaviour and cause the compiler to save the state of all variables between invocations.

However, that option doesn't exist in the compilers we use today. Instead, we have the -fno-automatic compiler flag for which the documentation says

Treat each program unit (except those marked as RECURSIVE) as if the SAVE statement were specified for every local variable and array referenced in it. Does not affect common blocks. (Some Fortran compilers provide this option under the name -static or -save.) The default, which is -fautomatic, uses the stack for local variables smaller than the value given by -fmax-stack-var-size. Use the option -frecursive to use no static memory.

Our makefile uses the -fno-automatic flag and so the value of ICOOP will definitely be retained between calls to K61R and the behaviour we observe is exactly what you would expect from the code.

Presumably, the original -SAVEALL option behaved differently.

[drvinceknight]

Awesome investigation, thanks @meatballs, some of this could end up in the paper 👍

[drvinceknight]

@meatballs are you ok for me to do a new github release for this or would you prefer to do it?

[meatballs]

Go for it

[meatballs]

On reflection, I don't think this is to do with -SAVEALL or -fno-automaticat all. Those both affect all invocations of the function and ICOOP is correctly maintaining its state within a given match.

What we are missing here, I think, is any knowledge of how the original tournament was coded.

In our Python implementation, we run all the matches for a tournament within the same session and we are seeing that the maintenance of state across those matches is causing a problem.

But what if that's not how the original tournament was run? It's perfectly possible that the matches were run completely independently of one another and this problem would never have arisen. Without the code for the tournament itself, we'll never know.

[drvinceknight]

But what if that's not how the original tournament was run? It's perfectly possible that the matches were run completely independently of one another and this problem would never have arisen. Without the code for the tournament itself, we'll never know.

Sounds sensible to me. 👍

[marcharper]

Yeah there's still a missing piece here -- we also have to assumed that ICOOP is initialized to zero on first use so it seems like its matches had to be played in separate invocations of the entire program.

Are we sure that no other functions are affected by this bug?

[drvinceknight]

Sure? No. Pretty sure? Yeah :) I ran the check I mentioned on the PRissue and that didn't flag anything. Once we've got the new results (running) we'll know more.