Hey @Kuma-quant ,
A great question indeed! We have not explored an exact classification of objective functions beyond expectation values that are accessible for Rotosolve yet.
Maria is right with her answer, and as long as you know the correct frequencies of your objective function, you should be good to go!
However, as so often, there are details!
For classical post-processing of circuit outputs there are multiple ways of reconstructing: Reconstruct the circuits and combine them classically via the post-processing that already is classsical, or reconstruct the full objective function right away. It is not obvious which approach is better!
Let me give an example:
Consider the QNode and objective function
dev = qml.device("default.qubit", wires=1)
@qml.qnode(dev)
def circuit(weight, inp):
qml.RX(weight*inp, wires=0)
return qml.expval(qml.Projector([0], wires=dev.wires))
def objective_fun(weight, inputs=None, targets=None):
cost = 0.
for inp, targ in inputs, targets:
cost += (circuit(weight, inp) - targ) ** 2
return cost
Then we see that circuit
will produce a finite Fourier series with a single (non-zero) frequency, namely freqs=[weight]
. (Call the number of frequencies R, so that we get R=1 here).
This means that we can reconstruct this Fourier series with 2R+1=3 evaluations of circuit
per input inp
, leading to (2R+1)n = 3n evaluations for n inputs.
Once we have reconstructed these Fourier series, we can combine them into the classical objective function by plugging the reconstructions into objective_fun
.
This does not require additional quantum computer calls.
If we would want to call Rotosolve on the objective_fun
directly, we would need to reconstruct a Fourier series with frequencies freqs=[weight, 2*weight]
, i.e. a series with R'=2. This costs 2R'+1=5 evaluations and thus is much cheaper - it does not even depend on . Yay!
But careful: If we instead would have multiple frequencies in the circuit
, i.e. R>1, and they would not be equidistant (i.e. the second frequency is not just the doubled first frequency and so on), we would get (2R+1)n evaluations in the first approach and up to 2R^2+1 evaluations for the second approach (Let me know if you want details on this - admittedly rough - estimate; The general parameter shift rules demo could be a good place to start reading if I may shamelessly advertise it as its author). So now we need to know R an n and compare the number of evaluations to decide which approach we want to go for.
If you want to modify the cost function to use ** 4
instead of ** 2
, the estimate for the second approach is completely different, so the classical processing really matters as well.
I hope this helps to stress that there is no generic answer to “Should I use Rotosolve on the objective function or on the circuits?”.
Implementation-wise, you might be happy to hear that a reconstruction functionality is on its way into PennyLane. It might be helpful in implementing your ideas