Control and noise operators are at the moment stored as NumPy arrays which has a few disadvantages:
Multi-qubit operators are explicit tensor products whose single-qubit components are not stored. While it is possible to manipulate the product chain (implemented by util.tensor_insert, util.tensor_transpose, util.tensor_merge), accessing its individual elements is not. This is however very useful when extending a pulse to a larger Hilbert space. In this situation, the additional qubits idle and their filter function is very easy to compute (just a FID mostly). However, when an explicit tensor product is given as an additional noise Hamiltonian, we cannot know if this new operator is only non-trivial on an idling qubit (in which case we could trivially compute the filter function) or not. Explicitly calculating the filter function might be very costly in such a case since the pulse might have a large number of time steps.
Coefficients are stored as arrays of shape (n_ops, n_dt) even if some might be very repetitive (e.g. only zeros). This of course introduces a lot of unnecessary overhead when calculating filter functions.
Most of these issues might be addressed by making the code more object-oriented:
Introduce a Operator class with an identifier property. This might be a subclass of ndarray such that einsum and other NumPy operations still work with it.
Introduce a TensorProduct class which implicitly stores the elements of the tensor product and has a evaluate() method
to compute the explicit matrix. This would immediately make a lot of code redundant (all the tensor_* functions above) on top of giving access to the underlying structure of a tensor product.
Introduce a Coefficients class with an overloaded __getitem__ method that allows einsum to work with coefficient arrays of different lengths (I am not sure how straightforward this would be to implement).
The downside of all these changes would be a larger degree of complexity for constructing a PulseSequence. Moreover, at this point it's unclear if the package will actually be used for algorithms, i.e. more than two qubits, and thus falls under premature optimization.
thangleiter
commented
5 years ago
Control and noise operators are at the moment stored as NumPy arrays which has a few disadvantages:
util.tensor_insert,util.tensor_transpose,util.tensor_merge), accessing its individual elements is not. This is however very useful whenextending a pulse to a larger Hilbert space. In this situation, the additional qubits idle and their filter function is very easy to compute (just a FID mostly). However, when an explicit tensor product is given as an additional noise Hamiltonian, we cannot know if this new operator is only non-trivial on an idling qubit (in which case we could trivially compute the filter function) or not. Explicitly calculating the filter function might be very costly in such a case since the pulse might have a large number of time steps.(n_ops, n_dt)even if some might be very repetitive (e.g. only zeros). This of course introduces a lot of unnecessary overhead when calculating filter functions.Most of these issues might be addressed by making the code more object-oriented:
Operatorclass with anidentifierproperty. This might be a subclass ofndarraysuch thateinsumand other NumPy operations still work with it.TensorProductclass which implicitly stores the elements of the tensor product and has aevaluate()method to compute the explicit matrix. This would immediately make a lot of code redundant (all thetensor_*functions above) on top of giving access to the underlying structure of a tensor product.Coefficientsclass with an overloaded__getitem__method that allowseinsumto work with coefficient arrays of different lengths (I am not sure how straightforward this would be to implement).The downside of all these changes would be a larger degree of complexity for constructing a
PulseSequence. Moreover, at this point it's unclear if the package will actually be used for algorithms, i.e. more than two qubits, and thus falls under premature optimization.