I've been looking at your QSP angle generation code and run into an issue due to my lack of understanding of how you are enforcing conventions. Here is my attempt, generated from this script.
Briefly put, the above image shows that the QSP phase angles being calculated by calling the generate method of Angler_opt are not consistent with the QSP polynomial reconstructed from those angles via _qsp_unitary_symmetric.
I have had an extremely difficult time working out what might be going on, but the existence of the function phases_Wx_to_R in src/pyLIQTR/conversions.py finally got me there. It is a reference to Equation (15) of Dong, Meng, Whaley, and Lin [arXiv2002.11649---DMWL], which explains how to convert from the 'W' convention used in Theorem 3 of Gilyén, Su, Low, and Wiebe [arXiv:1806.01838---GSLW] to what I suppose is being called the 'R' convention of DMWL, though the name suggests a mistaken equivalence with Equation (3) of Tang and Tian [arXiv:2302.14324--TT]. DMWL refer to the operator U_A, which is always paired with a Pauli Z operator, and the resulting product is not actually the same as TT's operator R.
What I believe is going on is that the _phases_lbfgs method of the Angler_opt class (src/pyLIQTR/phase_factors/optimization/angler_optimization.py) is a direct implementation of the DMWL algorithm. But the DMWL algorithm does not use the 'W' convention, and an appropriate modification must take place, perhaps an execution of phases_Wx_to_R in the gradient_optimization method before returning. Though I have not had the time (nor do I expect to have the time) to trace the complex logic of how _qsp_unitary_symmetric ought to be called in a Hamiltonian simulation circuit builder, I think I have seen enough to reach the conclusion that my script demonstrates a bug in pyLIQTR.
I've been looking at your QSP angle generation code and run into an issue due to my lack of understanding of how you are enforcing conventions. Here is my attempt, generated from this script.
Briefly put, the above image shows that the QSP phase angles being calculated by calling the
generatemethod ofAngler_optare not consistent with the QSP polynomial reconstructed from those angles via_qsp_unitary_symmetric.I have had an extremely difficult time working out what might be going on, but the existence of the function
phases_Wx_to_Rinsrc/pyLIQTR/conversions.pyfinally got me there. It is a reference to Equation (15) of Dong, Meng, Whaley, and Lin [arXiv2002.11649---DMWL], which explains how to convert from the 'W' convention used in Theorem 3 of Gilyén, Su, Low, and Wiebe [arXiv:1806.01838---GSLW] to what I suppose is being called the 'R' convention of DMWL, though the name suggests a mistaken equivalence with Equation (3) of Tang and Tian [arXiv:2302.14324--TT]. DMWL refer to the operator U_A, which is always paired with a Pauli Z operator, and the resulting product is not actually the same as TT's operator R.What I believe is going on is that the
_phases_lbfgsmethod of theAngler_optclass (src/pyLIQTR/phase_factors/optimization/angler_optimization.py) is a direct implementation of the DMWL algorithm. But the DMWL algorithm does not use the 'W' convention, and an appropriate modification must take place, perhaps an execution ofphases_Wx_to_Rin thegradient_optimizationmethod before returning. Though I have not had the time (nor do I expect to have the time) to trace the complex logic of how_qsp_unitary_symmetricought to be called in a Hamiltonian simulation circuit builder, I think I have seen enough to reach the conclusion that my script demonstrates a bug in pyLIQTR.