This repository contains all data and code used in the following paper: https://browse.arxiv.org/pdf/2308.12359.pdf Matlab is the only language used in generating data and running simulations necessary for experiments. Figures are referenced according to their names here, and their label within the aforementioned paper.
Figure 1, Figure 2, and Figure 4 may all be generated from the Matlab file labeled 'testing_L_fxn_moving_anchors.m'. Please note that Figure 1 and Figure 2 require the variable 'N' for iterations to be set to 2000, while Figure 4 requires this number to be set to 5000 to recover the images we've created. There is commented-out code within the file that allows one control over graphing both algorithm and anchor iterations, or just algorithm iterations. Using this commented-out code (or your own variants of it) you may be able replicate our images of moving anchor images, or create your own, varying starting points or whatever else you wish.
Generally, one wishes to distinguish algorithm updates (henceforth referred to as update1, update2, or update3) from one another with a system that clarifies which one is the fixed anchor, which one is the moving anchor with a positive gamma parameter, and which one is the moving anchor with a negative gamma parameter. The practice we implement is setting update1 = fixed anchor (whether in the EAG-V setting or FEG setting), update2 = positive gamma moving anchor, update3 = negative gamma moving anchor.
If, in the case of generating Figure 2, one wishes to also track the moving anchor iterations, it is suggested that users label their 'anchor' variables within the matlab code according to the update label, so that, for example, anchor2 tracks the moving anchor corresponding to the positive gamma variant. While this may seem complicated, one may simply follow a similar procedure to the one outlined below for Figure 4.
To obtain Figure 4, one should set N = 5000, ctrl+f replace all instances of update2 or update3 with update1, and then comment out the 'gamma_k' parameter and input a zero; update1 will then correspond to the fixed anchor. Then execute the code. Then, one should ctrl+f replace all instances of update1 with update2, remove the zero, and make sure the gamma has the original formula there with NO negative sign in front; update2 then corresponds to the moving anchor with positive gamma. Then execute the code. Finally, one should follow a similar procedure to make update3 the moving anchor with negative gamma parameter. After execution for all 3 variants, one may run the following code to generate Figure 4 in the Matlab command line in this order:
plot(log(1:N), 2log((epsupdate1(1,:) + update1(2,:)).^2+(epsupdate1(2,:) - update1(1,:)).^2),log(1:N), 2log((epsupdate2(1,:) + update2(2,:)).^2+(epsupdate2(2,:) - update2(1,:)).^2),log(1:N), 2log((epsupdate3(1,:) + update3(2,:)).^2+(eps*update3(2,:) - update3(1,:)).^2)) title('||G(z^{k})||^{2}, EAG-V and Moving Anchors') legend('EAG-V (fixed)','Moving (\gamma > 0)','Moving (\gamma < 0)')
In this repository, 'eagv versus moving anchor.fig' is Figure 1 in our paper. Figure 2 is a combination of 'simple L fxn positive gamma moving anchor.fig' and 'simple L fxn negative gamma moving anchor.fig'. Figure 4 is 'grad_norms_squared_eagv.fig'.
Figure 3 is generated by the code labeled 'testing_L_fxn_FEG_moving_anchor.m' in a similar manner to Figure 2; its label in this repository is 'pos_gam_vs_neg_gam_mov_feg'. Figure 5 is generated by 'complicated_function_moving_anchor.m' and is labeled 'grad norm squared of negative rho, nonconv. nonconc. function.fig' in this repository, in a similar manner to how Figure 4 is generated.
Figure 6 is generated by the code labeled 'two_player_nonlinear_game_ex.m' in a manner similar to Figures 4 and 5; in this repository, its file is labeled 'nonlinear_game_fixed_anchor_negative_gammas_v2.fig'.
Although we have uploaded all necessary files, LaTeX generally seems to prefer .png files for figures, so for your own use we recommend printing any figure files you generate as .png's or other more compatible file types.
I am not a programmer by training, so many of the coding practices and processes here are likely very inefficient and can be improved in many ways. If you have any questions, comments, suggestions, or would like to get in touch, we may be reached at [email protected] and [email protected].