Add optional argument to pass gflow in `generate_from_graph()`

[pafloxy]

Is your feature request related to a problem? Please describe. NA

Describe the feature you'd like Currently the facility to generate a Pattern from a graph is provided by the function generator.generate_from_graph() which takes as arguments the following generate_from_graph(graph, angles, inputs, outputs, meas_planes=None) . I think it would be good if we can have an option to pass a gflow of our choice rather than invoking the find_gflow() internally.

Something of the form generate_from_graph(graph, angles, inputs, outputs, meas_planes=None, set_gflow= None) would be convenient. Incase None is passed it should proceed as usual.

Additional context NA

[shinich1]

@pafloxy Nice, I would suggest to create a separate function 'generate_from_gflow' instead.

[pafloxy]

A seperarate function as in ? Like are the things that you want to be different in this case ?

As for me, a change like this would be enough.

[shinich1]

I get the change may be small, but as a user interface, generate_from_graph should generate from graph, not from (g)flow. Adding special case that you cannot guess from the function name is not useful to everyone.

we can simply call generate_from_gflow inside generate_from_graph, if gflow is found.

[masa10-f]

generate_from_graph should generate from graph, not from (g)flow.

It seems a bit strange to me. The generate_from_graph actually constructs pattern using both (g)flow and a graph with planes and angles, not just from graph alone. In fact generate_from_graph uses find_gflow internally. I understand the method automatically finds (g)flow just for user convenience. Isn't it more logical to include the optional argument in the method rather than creating a new one, because the current version just limits the freedom of byproduct correction?

[masa10-f]

Although it might be out of context, it could be possible to create a more general method, which construct a pattern from graph, 'x_flow', and 'z_flow', not limited to (g)flow. Here 'x_flow' and 'z_flow' mean byproduct correction for X and Z(I don't know whether there exists proper names for them). For a deterministic pattern, they are equivalent to f/g and Odd(f/g). This approach would offer a more convenient way to create non-deterministic patterns than using a manual pattern addition method.

[masa10-f]

imagine being a first-time user searching for an appropriate method for creating pattern from flow. How is s/he supposed to find the optional argument trick? flow is not a graph and it’s possible s/he will miss this, unless digging into the internal code.

Why do you assume such people don't search generate_from_graph when they want to get pattern from graph and custum (g)flow? I think such a situation never happens except they misunderstand they can construct a pattern without graph.

Strictly following your claim, we would have 4 or 5 similar but separate methods like "generate_from_graph", "generate_from_graph_w_custom_flow", "generate_from_graph_w_custom_gflow", "generate_from_graph_w_custom_pflow", and "generate_from_graph_w_custom_xzflow". I don't think it's nice user interface.

[shinich1]

@masa10-f I guess you're right, switching among different flows is tricky, and you'll need a graph anyway! thanks.

How do you think we should know which flow we have, if we allow them as optional input for genarate_from_graph? perhaps add optional argument for each flow?

[masa10-f]

I don't think we need to identify type of the given flow.