Channels

[alecandido]

In the Kraus representation, we can represent channels as a list of (coefficient, gate) pairs.

This means that we can mostly represent a channel as a series of gates in the queue, and the corresponding coefficients in the parameters list (+ composing gates' own parameters), as per #22 (comment).

However, we will need some extra to mark the span of a channel (which gates are composing a certain channel). This could be the BeginChannel and EndChannel gates, that would just delimit the channels' gates when added to the queue.

[alecandido]

In principle, the noise parameters have a different role than other variational parameters, since it is not something the user controls.
However, when this is true (hardware execution) channels will not be available at all for execution. And when channels are available (selected simulations backends), in principle you could train the noise parameters for a cost function that is forcing the result to adhere to actual data (just a possible example).

So, after all, they might not be that different from regular variational parameters on the platforms where they are available. Otherwise, they will simply not be available, and that is up to the backend.
What do you think? @stavros11 @BrunoLiegiBastonLiegi

[stavros11]

Extending this question beyond Channels (and possibly relating more to #22 than the current issue), do we know how we are going to handle the trainable flag that is currently supported in qibo? If I remember correctly, this can be used to hide parameters from circuit.set_parameters, therefore handling this could also tell us how to handle the channel parameters in question.

[alecandido]

That feature I was treating as high-level interface: every parameter is a trainable parameter, if you can change it.

What we can do for the interface is applying a mask for parameters that can not be mutated. But we'll also have to do more than that, since we're changing layout in qibo-core, by flattening. Unless we want break the present Qibo interface, flattening even there.

[stavros11]

That feature I was treating as high-level interface: every parameter is a trainable parameter, if you can change it.

Then maybe we can follow the same approach for channels. That should be fine, as long as all the parameters in question are floats.

What we can do for the interface is applying a mask for parameters that can not be mutated. But we'll also have to do more than that, since we're changing layout in qibo-core, by flattening. Unless we want break the present Qibo interface, flattening even there.

I think set_parameters is already supporting a flattened array. Maybe it is also supporting additional formats, like dicts or nested arrays but indeed these can be maintained (if we wish to keep them) outside qibo-core. As for trainable, I agree that mask would work so there is no need to propagate here.

[BrunoLiegiBastonLiegi]

Yeah regarding the noise parameters I totally support treating them as Variational parameters of the circuit, as this can indeed be very useful in qml related scenarios I believe as @alecandido mentioned. About the shape and type, instead, I think it might be helpful in some cases to have them as arrays of the used backend directly, either the global one or user specified. For the shape, I support having them flattened and with the batched execution in mind as a two dimensional tensor ideally, but this is probably a little bit premature to think about...

[renatomello]

I’m kinda out of the loop, but can I ask what you guys mean by flattened channels?

…

On Sat, 15 Jun 2024 at 16:27, BrunoLiegiBastonLiegi < ***@***.***> wrote: Yeah regarding the noise parameters I totally support treating them as Variational parameters of the circuit, as this can indeed be very useful in qml related scenarios I believe as @alecandido <https://github.com/alecandido> mentioned. About the shape and type, instead, I think it might be helpful in some cases to have them as arrays of the used backend directly, either the global one or user specified. For the shape, I support having them flattened and with the batched execution in mind as a two dimensional tensor ideally, but this is probably a little bit premature to think about... — Reply to this email directly, view it on GitHub <#27 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABH5QVR2MDHDNMIKX6T4S4TZHQXKFAVCNFSM6AAAAABJH5RUK6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRZGQ3DQNJSGI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[alecandido]

I’m kinda out of the loop, but can I ask what you guys mean by flattened
channels?

Hi @renatomello, I guess flattened channels are just the result of a misunderstanding.
The channels will be the usual ones. Nothing more, nothing less. And that's exactly the goal: making sure that the representation is minimal and suitable not to lose information.

Then, we are deciding which is the most convenient way to represent the parameters of the channels, and the proposal was to treat them as any other parameter of the other gates.
And here it comes the flattening: all parameters involved in a circuit will not be stored any longer in the gates, but in a unique array of floats, flattened over a single dimension. Instead, the relation between a certain gate and the position of its parameters will be reconstructed internally by the circuit.

[alecandido]

For the shape, I support having them flattened and with the batched execution in mind as a two dimensional tensor ideally, but this is probably a little bit premature to think about...

@BrunoLiegiBastonLiegi the shape is always represented by all frameworks as metadata, so it should not affect the memory layout (that will always be flattened, since the memory model is 1D in any case).
About the batching, this is something that will have to be bargained with the execution backend: batching will only be relevant for QML, not for plain simulation, and mostly not even hardware (in case, you could "unroll" the circuit, but let's discuss separately).

In practice, I'd even propose to more or less bypass qibo-core for batching: the .parameters will be a flattened array of floats, but you will be able to read and write arbitrary numbers for arbitrary lengths.
We will provide some helper methods to reconstruct the relations between gates and their parameters, but within a certain backend you will be free to ignore them, and directly access the parameters array.
Thus, if you have a circuit with n parameters, and you want to have a batch of 7, you will be able to take a (7, n)-shaped array with all your parameters, flatten, set as .parameters, and then read on the backend and reshape.
The only addition required is that the backend will need to know the batch size. But whenever we'll have the backends (and specifically the backprop one), we can worry about how this communication should happen.