Optimise convolutions

[seabbs]

Description

This PR is unlinked to an issue but applies some optimises to speed up convolutions (a key pain point of the stan code base). It also replaces the custom reverse_mf function with the new reverse built in.

Initial submission checklist

• My PR is based on a package issue and I have explicitly linked it.
• I have tested my changes locally (using devtools::test() and devtools::check()).
• I have added or updated unit tests where necessary.
• I have updated the documentation if required and rebuilt docs if yes (using devtools::document()).
• I have followed the established coding standards (and checked using lintr::lint_package()).
• I have added a news item linked to this PR.

After the initial Pull Request

• I have reviewed Checks for this PR and addressed any issues as far as I am able.

[seabbs]

Slightly surprisingly this doesn't seem to make a great deal of difference. Regardless I think it should be more stable and is definitely easier to test.

[jamesmbaazam]

Thanks for this, Sam. I'll review it today.

[seabbs]

How did you get on with this?

[jamesmbaazam]

Sorry, I missed this notification. I'll finish reviewing all your PRs by close of Thursday. I'm prioritising the GP vectorisations PR due to the speed gains.

[github-actions]

This is how benchmark results would change (along with a 95% confidence interval in relative change) if 781a930 is merged into main:

• ✔️default: 43.4s -> 45.7s [-17.64%, +28.28%]
• ✔️no_delays: 50s -> 54.8s [-15.39%, +34.66%]
• ✔️random_walk: 9.74s -> 9.88s [-7.47%, +10.45%]
• ✔️stationary: 27.6s -> 22.1s [-64.09%, +24.42%]
• ✔️uncertain: 1.14m -> 1.18m [-18.52%, +26.04%]
  Further explanation regarding interpretation and methodology can be found in the documentation.

[jamesmbaazam]

This all looks good to me. The code is more readable now.

[seabbs]

Nice and I agree. Thanks for the review. This is just waiting on our decisions in the conversations. My vote is leave as is for this PR and if we feel strongly move to a new issue to refactor? It could be a good issue for someone new to stan to tackle if we decide to go that way

[github-actions]

This is how benchmark results would change (along with a 95% confidence interval in relative change) if 500924f is merged into main:

• ✔️default: 58.8s -> 49.7s [-55.3%, +24.34%]
• ✔️no_delays: 50.3s -> 51.4s [-15.61%, +19.71%]
• ✔️random_walk: 9.74s -> 58.8s [-655.79%, +1662.54%]
• ✔️stationary: 22.7s -> 22.7s [-9.86%, +9.69%]
• ✔️uncertain: 1.09m -> 1.16m [-4.87%, +17.24%]
  Further explanation regarding interpretation and methodology can be found in the documentation.

[jamesmbaazam]

I don't feel strongly about it.