Add simulate method to Circuit

[Strilanc]

Currently implemented by delegating to the XmonSimulator, but this is a hidden implementation detail.

[dabacon]

This really seems to make cohesion in Circuit much worse (Circuit methods are about building and accessing circuits). I think we should make classes cohesive. Along these lines I actually think we maybe made a mistake in having to_unitary_matrix on the Circuit class. I also think that this will not scale well as we add more simulators or simulators with different features, and by keeping the soup of simulators separate it won't leak over into circuit

[Strilanc]

I think we have two types of circuit methods: manipulation methods, and inspection methods. Manipulation methods include insert, clear, and append. A natural addition to this group might be "apply optimization". Inspection methods include gate querying, slicing, and printing. "Tell me about the behavior of this circuit" seems like a natural fit here, to me.

I also think there is great value in not having to make a bunch of objects to do common tasks. The fact that I have to make an XmonSimulator object (giving it no arguments) then call simulate on it seems superfluous compared to just having a raw simulate method, and if we're going to have a raw simulate method it might as well be a member of Circuit.

Having the method be a member is also an example of what I'm going to call "autocomplete-based design". It makes it easier for the user to answer the question "how do I simulate a circuit?", because the natural instinct when you have a "how do Y to X" is to dot off of X and see what your IDE says is available to call.

So I would say I'm not worried about the cohesion. What I do worry about with this change is the effects on coupling. This is the first instance of a circular dependency workaround.

[dabacon]

I think as we have more and more simulators or backends this will never end and we will have "simulate_with_my_blah" or "run_on_my_engine". Classes that aren't cohesive become very had for people to understand.

…

On Wed, Jun 13, 2018 at 10:59 AM, Craig Gidney ***@***.***> wrote: I think we have two types of circuit methods: manipulation methods, and inspection methods. Manipulation methods include insert, clear, and append. A natural addition to this group might be "apply optimization". Inspection methods include gate querying, slicing, and printing. "Tell me about the behavior of this circuit" seems like a natural fit here, to me. I also think there is great value in not having to make a bunch of objects to do common tasks. The fact that I have to make an XmonSimulator object (giving it no arguments) then call simulate on it seems superfluous compared to just having a raw simulate method, and if we're going to have a raw simulate method it might as well be a member of Circuit. Having the method be a member is also an example of what I'm going to call "autocomplete-based design". It makes it easier for the user to answer the question "how do I simulate a circuit?", because the natural instinct when you have a "how do Y to X" is to dot off of X and see what your IDE says is available to call. So I would say I'm not worried about the cohesion. What I *do* worry about with this change is the effects on coupling. This is the first instance of a circular dependency workaround. — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#456 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAFXpgf-R5prAJVlGeN3Ghz-1G7CJUEHks5t8VMLgaJpZM4UlQ0a> .

[Strilanc]

Based on the group discussion, we're going to do something different.