Fix logic issues in predator prey model and tune parameters

[tkoskela]

I sat down with @JostMigenda in a workshop and had a go at tuning the parameters of the predator prey model to get it to oscillate between predator and prey populations. It is not quite there yet, the prey still all die, but works a bit better.

[github-actions]

🆗 Pre-flight checks passed 😃

This pull request has been checked and contains no modified workflow files or spoofing.

It should be safe to Approve and Run the workflows that need maintainer approval.

[JostMigenda]

Thanks @tkoskela for looking into this. Yep—it’s very tricky to tune the parameters to give nice results, but this is certainly a big improvement over the previous version.

A couple of notes:

• This includes the bugfix commit from fix logic issues in predprey example #17. Makes sense to keep bugfixes and tuning in one PR; we just shouldn’t get confused by this later.
• Before we merge this, I should check the episode text & exercises for consistency; some of the profiling outcomes we mention there will have changed as a result of these changes.
• Finally, very minor notes on the code itself:
  • The comments look like LLM slop: vaguely plausible, but sometimes contradicting the actual changes in the PR; and I don’t think they add much over the parameter names themselves
  • Adding extra spaces around = for alignment: I know there are different opinions around this, but the Python convention is not to add them

[Robadob]

More than happy to defer to @JostMigenda's judgement on approving this, looks reasonable at a glance. Please, remember to briefly review the instructor notes/solution incase anything subtle has changed there.

I think the original code was heavily inspired by our FLAMEGPU Python tutorial, which is probably inspired by a common simple agent-based model. Though that subtle bug looks like something FLAMEGPU would handle natively so it's almost certainly my mistake.

https://github.com/FLAMEGPU/FLAMEGPU2-tutorial-python

Thanks for supporting this project!

[tkoskela]

Finally, very minor notes on the code itself:

• The comments look like LLM slop: vaguely plausible, but sometimes contradicting the actual changes in the PR; and I don’t think they add much over the parameter names themselves
• Adding extra spaces around = for alignment: I know there are different opinions around this, but the Python convention is not to add them

Yeah, I was using Copilot for tuning the parameters. I get your point about the comments, they're not very useful and I've removed them and fixed the formatting.

[JostMigenda]

The function-level profiling results remained qualitatively fairly similar, so I made just a few small tweaks to the text but kept screenshots of profiling results unchanged. Line-level profiling results changed a bit more, so I had to update the outputs as well as the exercise text.

These commits should now cover all follow-on changes resulting from the logic fix and is ready for review.

[Robadob]

Yeah this looks so much better.

[Robadob]

Still such a dumb mistake.

[Robadob]

Changes look thorough, I added one suggested tweak (more-so to the original text). However after writing the comment (profiling-lines.md:502) I'm in two minds about it. See what you think.

[Robadob]

I've rebased to resolve the two conflicts (junk conflicts around timing.monotonic at the end of the code 🤷‍♂️).

Please squash, or atleast clean up the history before merge.

Feel free to delete my contribution tags from any commit comments, all I've done is housekeeping.

[JostMigenda]

I like the suggestion. Added that and cleaned up the history a bit; merging now.