Add parameterized frugal resolvent splitting example

[peterbarkley]

This adds an example which builds a parameterized frugal resolvent splitting for a monotone inclusion problem. The Malitsky-Tam n operator splitting, Ryu's 3 operator splitting, Douglas-Rachford, and a new block splitting algorithm can be written in this parameterized form. It also adds a PEPit use case comparing these algorithms with fixed step size and with optimized step sizes and optimized matrices built using the dual of the PEP as in Ryu, Taylor, Bergeling, et al (2020) Operator splitting performance estimation: Tight contraction factors and optimal parameter selection.

[bgoujaud]

@peterbarkley Thank you for this nice PR.
I suggested a couple of minor modifications to clear things.

In addition, it would be awesome if you could add a test per algorithm in the file test_examples.
Those tests should typically compare the results provided by PEPit with some known bounds.
Since the methods you implemented here extend known algorithms, we can compare PEPit guarantees and theoretical ones for some non-trivial instances of this method.

[peterbarkley]

Thank you for the review and inputs! I will take a look at the test_examples and work on building out per-algorithm tests with theoretical references for a future PR. For the tests, it might make sense for me to generalize the FRS arguments a bit to allow a list of arbitrary operators in order to cover a wider range of theoretical results.

[bgoujaud]

Thank you for the review and input! I will take a look at the test_examples and work on building out per-algorithm tests with theoretical references for a future PR. For the tests, it might make sense for me to generalize the FRS arguments a bit to allow a list of arbitrary operators in order to cover a wider range of theoretical results.

Thank you for your contribution to PEPit!
If you think it would be better to consider more general operators than gradients, please feel free to modify the example files with Operators instead of Functions.

The tests must be simple sanity checks to ensure we did not miss a mistake in the implementation of the examples. That is why there should be one test per example file (i.e. 2 tests), consisting of running your example with a configuration for which we know the guarantee or an upper bound of it. For instance, setting the right matrices to encode the Douglas-Rachford splitting method would allow us to compare PEPit's output with its theoretical guarantee.

[peterbarkley]

Added the operator examples in the docstring and the two tests using the Douglas-Rachford matrices and the same operators and alpha/gamma settings as the existing Douglas-Rachford example.