'detslice' and 'detslice-with-ops' disagree on tick convention

[ghost]

Circuit.diagram('detslice') and Circuit.diagram('detslice-with-ops') should agree on which tick is which tick number, adn plot the same number of frames for a given circuit

Circuit.diagram('detslice') shows a frame at the start for the very start of the circuit, before any gates have been executed. This slice isn't always a trivial detslice, as the circuit is can have/expect incoming pauli flows, but these are not shown correctly anyways:

c = stim.Circuit("""
TICK
H 0
TICK
M 0
DETECTOR rec[-1]
TICK
""")
c.diagram('detslice')

(Notice that the first frame (start of circuit) and the next frame (first TICK, right at the start of the circuit) aren't the same; both should have red X-type detecting, but only the second one does. This method always plots the number of frames equal to the number of TICK instructions plus 1, effectively treating the start of the circuit as an implicit TICK.

Meanwhile, 'detslice-with-ops' does not include a frame at the start of the circuit. It does include the end of the circuit if it hasn't already been included: if the end of the cirucit does not have a TICK, it will plot the end of the circuit, but if it does end in a TICK, it won't plot the circuit end state twice.

c2 = stim.Circuit("""
H 0
TICK
M 0
DETECTOR rec[-1]
TICK
""")
c2.diagram('detslice-with-ops')

c3 = stim.Circuit("""
H 0
TICK
M 0
DETECTOR rec[-1]
""")
c3.diagram('detslice-with-ops')

These give identical diagrams:

This means it almost always draws a number of frames equal to the number of TICKs +1; it drops a frame if there is a TICK at the end of the circuit.

The different conventions about whether to add an implicit TICK at the start or end of the circuit lead to annoying results; like needing to add or subtract 1 to a tick range when switching from 'detslice' to 'detslice-with-ops'

IMO, these methods should agree on tick indices.
I think they should not add any implicit ticks, with tick=0 unambiguously referring to the first TICK in the circuit.
I think frames should be plot at each TICK, with with-ops indicating an additional drawing of gates back to the previous TICK (or start of circuit)
If users want a frame at the very start of the circuit, or the very end, they can add a TICK.

[Strilanc]

Urgh.... this is gonna suck to fix because it's going to mess up people's existing code. Is there any way t omaintain backwards compat while doing it?

[ghost]

i_would_like_the_correct_behaviour:bool = False ?

More seriously, at least for the tick convention thing, adding draw, plot or some other synonym_of_diagram, having diagram point at it internally with some wrapping to maintain diagram's current behaviour (and maybe a future deprecation warning?), then deprecating the old behaviour entirely on the next breaking release?

For the detslice not actually plotting the right thing in frame 0, i think that's a bug and should just get fixed, ppls current code is producing a wrong result (if they've run into this edge case at all lol)

[Strilanc]

Yeah you could argue it falls under the "trap" criteria I defined for breaking backwards compatibility.

An example of how it could be done without breaking backwards compat would be to deprecate tick and replace it by ticks. I also think adding tick= to the diagram would be quite helpful. Like, in timeslice diagrams it could show tick=4.5 to show this is the operations between ticks 4 and 5.

[Strilanc]

One possible issue with defining tick=0 to be the first tick is that it makes it impossible to see anticommutations in the implicit initialization at the start of time.

[ghost]

I type ticks and then get an arg fail a lot actually, so I'd be fine with ticks and keeping tick with the wrong behaviour for a while.

re possible anticomutations at the start of time: I would probably start adding TICK as the starting instructions of all my circuits if we made this change, bc I generally do want to be able to see things there, but i'd like to see that for both detslice and detslice-with-ops regardless.

I thought about tick=0 being unambiguously the start of the circuit, but figured it was better for the user to specify (and be able to count the ticks themselves) rather than force an implicit tick that someone might have to carve off the diagram. Also would make circuit.num_ticks always equal the number of frames in the diagram, which I like from a consistency standpoint.