Defining the new Backend API classes

[HGSilveri]

• Introduces the Results class and make Result a subclass of it in backwards compatible way
• Defines the State and Operator ABCs
• Updates BackendConfig and defines EmulationConfig
• Defines the EmulatorBackend ABC
• Defines the Callback and Observable ABCs
• Defines the default observables

[a-quelle]

c_n/r{ij}^n? There is also XY.

[a-quelle]

Pablo recently added a log_file to our BackendConfig it would cause the application to pipe all output into the log file. It seems like a thing we could generally support, though I'm also fine with keeping it an emu-mps specific config value.

[HGSilveri]

It sounds a bit EMU-MPS specific at this moment. I'd keep it there for now, we can always extend it to EmulationConfig if it makes sense in the future

[a-quelle]

We have recently had to add the following to this class

if hasattr(state, "get_correlation_matrix") and callable(
            state.get_correlation_matrix
        ):
            return state.get_correlation_matrix(

to resolve a performance bottleneck. We managed to improve the runtime of this callback a factor of 30 for the case we benchmarked. I would very much like to have some mechanism that prevents us from having to write an emu-mps specific callback to avoid a regression.

[HGSilveri]

I noticed that. I added a State.get_correlation_matrix() method that raises NotImplementedError by default but leaves it up to the State subclass to define a custom way to calculate it with a controlled signature. I believe I'm covering what you are requesting in lines 226-229, no?

[a-quelle]

I've done some thinking, and in the worst case, we can always override the Callback behaviour in the backend ourselves. This holds for all the comments I wrote in this file, so I don't consider any of it truly blocking, but some thought might deliver a more elegant solution.

[a-quelle]

I think in the end it's best if you just take implementations that work well for state-vector, and we monkeypatch them in the emulators as needed.

[HGSilveri]

So, in your MPSConfig or MPSConfig, you would basically override apply() of select observables at runtime?

[a-quelle]

Same as with the CorrelationMatrix, except it's less critical here. Maybe we can figure something out

[a-quelle]

last week I found the following implementation to be significantly faster and more memory efficient for MPS. For state vector, the opposite is probably true. Another conundrum.

h_squared = H @ H
        return h_squared.expect(state).real - H.expect(state).real ** 2

[HGSilveri]

Interesting, I thought that matrix-matrix multiplication would always be more resource intensive, so I tried to avoid it. Just goes to show how little I know about matrix product states, I guess

[a-quelle]

This is the case that really convinced me that maybe emu-mps should just patch the contents of these methods at runtime.

On a separate note though, shouldn't you replace identity.expect(hstate) with sqrt(h_state.overlap(h_state)) for performance?

[HGSilveri]

Yes, that's a good point

[a-quelle]

same here with the overlap, I guess.

[a-quelle]

Based on my monkey patching idea, we could remove this. Having it is a bit of a slipperly slope, since why not also add a get_magnetization and whatever other items you could think of.

[HGSilveri]

Sure, I'm fine with that