Computing the gradient of a Squared (wrapped) operator

[waleed-sh]

I am currently working with a Hamiltonian $H = A^\dagger A$ and very conveniently, the Squared lazy wrapper helps me avoid actually computing $A^\dagger A$, especially when taking the expectation value as it has its own local estimator which is the square of the estimator of $A$ (if I understand correctly, since it calls the .get_conn_padded() of the parent here to get the arguments and the estimator here is just the absolute value squared of the estimator of $A$).

However, when trying to now minimise $H$, the VMC driver first collects a concrete instance of this lazy operator (as shown here using .collect()). This will then actually compute $A^\dagger A$ explicitly, which can be computationally expensive if $A$ has a ton of operators in it...

Lastly, when computing .expect_and_grad(), it computes it using the non-Hermitian implementation (if I understand correctly), irrespective if whether the wrapper operator (in this case $A$) is Hermitian or not.

What I'm trying to understand are two things:

1. Why cant the gradient of $H$ be computed without explicitly constructing $A^\dagger A$? Since $\langle H \rangle \sim |E_{loc}(A)|^2$, do we really need to compute $A^\dagger A$ explicitly? Is this done for the sake of being general or is it actually necessitated from the math for any given $A$? E.g. if my $A$ is non-Hermitian but real valued (as well as my network), would that still be needed?
2. Why is it necessary for the Squared operator to use the non-Hermitian gradient function, irrespective of the wrapped operator?

Sorry of these are trivial/obvious questions! Just trying to understand some things a little better.
Appreciate any help!

[PhilipVinc]

Hi.

Your intuition is right. The gradient and expectation value of Squared[A] is much cheaper than computing the expectation value or gradient of A\dagger A.
However the cheaper Squared estimator is much more noisy than the original and requires many more samples.
Moreover , it is in principle biased.
Whether this bias and higher variance is relevant or not, it’s highly problem dependent.

you’re also right that when you are using the VMC driver, at least by default, the driver will collect the square into A\dagger A, and effectively won’t be using this trick.

the reason for this is the following:

• when you want to look for the ground state, you generally don’t want to use the squared estimator.
• You lose the zero variance principle for the gradient, therefore you need to increase the number of samples the more you converge, as opposed to the normal estimator.
• while SR is still valid, it becomes highly unstable, and its hard to use it with this estimator.

Overall, we found that sometimes usrrs where using the squared estimator without realizing it, and ending with optimizations that did not convege well, and that’s why we introduced the .collect call.

uou can still circumevent this by manually setting driver._ham to the squared operator after you construct the driver

[gcarleo]

didn't we have an option to use the biased estimator if wanted?

[waleed-sh]

I see, so basically I would then replace one computational issue (e.g. in the case of my operator containing many terms and squaring it becomes expensive) with another, namely achieving convergence + stability of the numerics in the process of doing so. This was insightful though, thanks for the quick reply!

[PhilipVinc]

Why is it necessary for the Squared operator to use the non-Hermitian gradient function, irrespective of the wrapped operator?

It’s just a name, and maybe not a terribly good one.
Non hermitian refers to the fact that you are not using the hermitianity of the operator, while in the standard estimator you use the hermitianity.