I would suggest @MichaelBroughton as a first-pass reviewer but happy to get advice from anyone.

@MichaelBroughton
Thanks for the quick turn-around on the review and its detailed explanation. I updated the code and I think it follows the rough idea. A few remarks:

• The ProjectorSum object looks a lot like PauliSum but since you had suggested a separate object, IIUC. I'm happy to try to use PauliSum instead or leave as is (though I am not sure using PauliSum would be easy). Alternatively, we could ask for advice at the next group meeting.

• I could split the PR in smaller bits, if you want. For example, a first one could be only for ProjectorString and a second one for ProjectorSum.

• I realize that your comment suggested to use sparse matrices, but for simplicity, I only use dense ones. I do plan to address this (and left a TODO in my name). Note that the serialization of the object is already small in memory, as there's only one integer; It's only the simulation that is a little sub-optimal.

Note I don't feel very strongly about the decisions I've made. It's mostly decisions I had to make to make progress. Thanks again for the review. PTAL.

The ProjectorSum object looks a lot like PauliSum but since you had suggested a separate object, IIUC. I'm happy to try to use PauliSum instead or leave as is (though I am not sure using PauliSum would be easy). Alternatively, we could ask for advice at the next group meeting.

The point is that it look and feel very similar, but give the clear indication that you are dealing with Projectors and not Paulis. We could also surface this for more discussion, but I think this is a pretty uncontroversial approach.

I could split the PR in smaller bits, if you want. For example, a first one could be only for ProjectorString and a second one for ProjectorSum.

That sounds like a good idea. Let's start with just ProjectorStrings.

I realize that your comment suggested to use sparse matrices, but for simplicity, I only use dense ones. I do plan to address this (and left a TODO in my name). Note that the serialization of the object is already small in memory, as there's only one integer; It's only the simulation that is a little sub-optimal.

This certainly is an important piece . If we go one PR at a time, it shouldn't be that much more work to make sure that when we merge things, the performance is closer to optimal. As an example the expectation_from_*** functions can certainly be trimmed down a lot. Probably to something like:

def expectation_from_state_vector(
        self,
        state_vector: np.ndarray,
        qid_map: Mapping[raw_types.Qid, int],
        *,
        atol: float = 1e-7,
        check_preconditions: bool = True,
    ) -> float:
return np.abs(state_vector[<projector_bitstring>]) ** 2

would work

Thanks, @MichaelBroughton , PTAL when you have some time?

Thanks, @MichaelBroughton PTAL when you can.

Thanks @MichaelBroughton! I copied over your suggestion, merged from the main branch, and re-ran the tests.