On the parameterization issue during EP Minimization

[aaanby]

Thank you for sharing this insightful implementation of the Entropy Pooling in Python. However, while reviewing the source code, I raise some questions regarding the minimization details. I would be pleased if you could clarify the confusion.

In entropy_pooling/entropy_pooling.py, the function _dual_objective ends withreturn -1000 * objective, 1000 * gradient. How is the multiplier 1000 chosen in this scenario? Is it related to the optimization method 'TNC' or other imperative parameters including options={'maxfun': 100000}) or input data range?

During my experiments, I found the change over this multiplier(and 'maxfun') greatly influences experimental outcome. Therefore, I am looking for the optimal parameterization that could maximize the reliability of EP. It would be of great help if you could release more details on parameter tuning during your experiments. Thanks for your assistance.

[antonvorobets]

Thanks for your question, @aaanby .

The scaling is simply what we found to work well during experimentation with relative P&L simulations.

We tried to be conservative in the optimization hyper parameters to make sure that the solutions are precise.

In a production system, one would have these hyper parameters as input to the class that performs the Entropy Pooling update.

Can you share the insights on your evaluation of hyper parameters? Do you find some combination that seems to perform significantly better than the current default values?

[aaanby]

Thanks for your prompt response. I discovered that the root cause of the issue actually stems from numerical stability problems arising from variations in data range within R_df. When I replaced R_df with a hybrid dataset comprising daily return data from the S&P 500 and VIX data in my experiments, the optimization exhibited significant anomalies. Specifically, in the posterior distribution, the regularization condition: A=(np.ones((1, S)), b=np.array([[1]]) were ignored, meaning the posterior probability sum failed to equal 1.

In this scenario, the multiplier requires precise adjustment to meet the regularization demand, whilst the statistical moments exhibit significant fluctuation. A cleverer solution involves directly scaling the original data to similar value ranges. Following this pre-processing, the multiplier exerts minimal influence on the statistical moments of the optimization results, yielding highly stable outcomes.

[antonvorobets]

I see. There might be issues if the magnitude of your constraints is very different.

Note also that your installation might be suboptimal for the CPU that you have. This is not something that I can go into detail with, but it is worth considering if you have the right flavor of numerical packages.

The default parameters have been tested with relative P&L / return distributions and should work well in that case.