João P. Moutinho
João P. Moutinho
Add support for custom interactions based on Projectors to the `hamiltonian_factory` function. Currently the function forces the custom interaction to return a Pauli Hamiltonian.
Moving the original issue from Qadence: https://github.com/pasqal-io/qadence/issues/346 With the reorganization of HamEvo, this would make sense to implement in PyQTorch instead. This is essentially equivalent to doing exact Trotterization automatically...
Below is the previous code calculating `HamEvo` based on a 4th order Runge Kutta method. It could be useful in the future for a simple implementation for time-dependent Hamiltonians. To...
With the refactoring of `pyqtorch` we are for now prioritizing `HamEvo` based on `torch.matrix_exp` since it has proven to be the best compromise between efficiency and support with torch autograd....
Instead of doing block to tensor -> dense matrix -> diagonal -> we should just use block to diagonal. Replicating the original issue in Qadence: https://github.com/pasqal-io/qadence/issues/368 Keeping it open there...
Original text from @dominikandreasseitz : _Right now, we call block_to_tensor in every forward pass to get the hamiltonian, which is then exponentiated in native pyq. lets find a way to...
Certain numerical operations like the Hamiltonian Evolution with RK4 method do not conserve the wavefunction normalization. We should either: - Add a normalization check at certain steps in the computation...
Currently different size operators in the `apply_operator` product are handled by padding the smaller one with identities. Another option is to do it by manipulating the qubit indices without padding,...
https://github.com/quantumlib/qsim _To speed up the simulator, we use gate fusion [[2]](https://arxiv.org/abs/1601.07195) [[3]](https://arxiv.org/abs/1704.01127), single precision arithmetic, AVX/FMA instructions for vectorization and OpenMP for multi-threading._ I suspect this gate fusion is similar...
As mentioned by @vytautas-a: _I made some calculations and experiments related to this problem (in context of GPSR) and it seems that it is two-fold: one related to numerical stability...