Re: Dimension and shape of Qobjects

[Paul Nation]

The dimensionality and shape of a Qobj differ only when one considers states and operators formed from the tensor product of two or more Hilbert spaces (i.e two spin 1/2 systems).  The shape property just tell you the shape of the underlying matrix, while the dims property records the tensor product structure of the object.  For example:

A=qeye(4)

B=tensor(sigmax()**2,sigmax()**2)

both of these objects correspond to a 4x4 identity matrix, however the later matrix will have a different dimensionality, [[2,2],[2,2]] instead of [[4],[4]], that tells us that the object was made via the tenor product of two 2-level systems.

If one is not careful then QuTiP will throw an error when doing operations on operators with different dims properties as these operations would not make sense mathematically.

Paul

On Friday, May 24, 2013 at 1:37 AM, ander...@gmail.com wrote:

What is the deal with having both a dimension and a shape of Qobjects?
I am trying to do some more advanced stuff, but I am constantly running into the 'Incompatible quantum object dimensions' error.
It seems to happen even when what I am doing is technically correct, and I have to set the dims variable myself.

Another small question. Is there no function for making an empty quantum object matrix? Right now I am doing
N = 64
Qobj(np.zeros((N, N)))


Cheers
Anders Lund

--
You received this message because you are subscribed to the Google Groups "qutip" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qutip+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Paul Nation]

Oops, also at present, there is no way to create a blank Qobj with a given dimensionality.  But this can easily be added.

One can also do

0*qeye(N)

[safi...@gmail.com]

how i can add two matrix with same shape and different dimension. I need to add a and b. my a has the property ,Quantum object: dims = [[2, 2, 4], [2, 2, 4]], shape = [16, 16], type = oper. B has the propery  Quantum object: dims = [[4, 2, 2], [4, 2, 2]], shape = [16, 16], type = oper. while i adding these it showing following error.

TypeError                                 Traceback (most recent call last)
<ipython-input-67-f1d53b280433> in <module>()
----> 1 a+b

/usr/local/lib/python2.7/dist-packages/qutip/qobj.pyc in __add__(self, other)
    340 
    341         elif self.dims != other.dims:
--> 342             raise TypeError('Incompatible quantum object dimensions')
    343 
    344         elif self.shape != other.shape:

TypeError: Incompatible quantum object dimensions...


please help me to do this

[nonher...@gmail.com]

Qutip is complaining because the operation you are doing makes no sense given the differing tensor product structures. However, if you really want to do that then you can use Q.data to access the underlying sparse matrices. 

-P

--
You received this message because you are subscribed to the Google Groups "QuTiP: Quantum Toolbox in Python" group.

To unsubscribe from this group and stop receiving emails from it, send an email to qutip+un...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[jayam...@gmail.com]

How can one find the eigenstates of a matrix of such a structure. If I access the matrix using data I can't use the eigenstates operation after this. 

[Paul Nation]

You need to use the eigensolvers in SciPy.

-P

To unsubscribe from this group and stop receiving emails from it, send an email to qutip+unsubscribe@googlegroups.com.

[Parth Jatakia]

Hey,

I had a small doubt regarding the shape and dimension of Qobj. I get the idea that the dimension sort of has the record of the tensor products done to get that object. However what I don't get is the purpose of doing this. Since this definitely increases the hassle to keep the dimensions same of two objects undergoing a certain operation even if the shape is the same.

Regards

Parth

[stevenkor...@gmail.com]

I agree with @Parth, this limits the ability to do algebraic operations on otherwise equivalent matrices. It is good to carry this information around but we should still be able to manipulate two matrices of the same shape but different dimensions. Ie, we should be able to add the following two matrices:

A = dims = [[2, 2, 2, 2], [2, 2, 2, 2]], shape = (16, 16), type = oper, isherm = True

B = dims = [[16], [16]], shape = (16, 16), type = oper, isherm = True

It is not a show stopper because we can extract the underlying data and make it work, but I think this is a design error. It seems like there might need to be an idea of isormorphic underlying spaces so that the superoperator perspective is still maintained.

Would love to hear someone's thoughts!

Thanks,

[sc.rama...@gmail.com]

I was able to do the stuff after converting the Qobj.data to numpy array, but then one has to be carefully while doing matrix operation like multiplication, because when you are working with numpy arrays then for matrix multiplication one has to use np.dot(a,b) for matrices a and B

On Friday, May 24, 2013 at 3:24:52 AM UTC+5:30, Paul Nation wrote:

To unsubscribe from this group and stop receiving emails from it, send an email to qu...@googlegroups.com.

[Jake Lishman]

You should always be able to achieve what you want by fixing the `dims` parameter of the Qobj when you construct it.  I get that this is somewhat frustrating on occasion, but it's a frustration that has to appear somewhere in the library, and we chose to put it at Qobj construction time because that ends up with the most consistent experience.  You can create your Qobj with `Qobj(data, dims=...)` to ensure it has the correct product structure.

I would suggest that you do not access the Qobj.data object, but instead override the Qobj.dims parameter if you want to do "unsafe" tensor product operations.  We want QuTiP to be "safe" by default, which means doing "unsafe" operations should involve being a bit more explicit.  If you override the dimensions, you retain access to all the niceties that `Qobj` provides, but as you guys have found, you lose that if you access the `data` parameter. (And on a minor sidenote, QuTiP 5 will use custom data structures underneath, so direct access will not be very convenient, though you'll of course always be able to do `Qobj.full()` to get a the dense numpy representation.)

Think about setting the `dims` parameter as defining the isomorphism between spaces.  Currently QuTiP does not keep track of what basis its underlying matrices represent their Hilbert spaces in, but we may be interested in adding that, and if so, there would not be a sensible implicit isomorphism we could define between a matrix of dimension 4 and one of [2, 2] - how would we know which basis the dimension 4 matrix is represented in?  We'd have to assume that it's the same, but then it'd be rather too easy for users to accidentally combine operators in different representations without any possible warnings.  We're already a bit unsafe in this regard, because we don't keep track of the basis used, but we do provide a "transform" function.  In this sense, I think we're more likely to strengthen the "dimensions" requirement into a "basis" requirement rather than relax it.

Further, should we allow isomorphism of objects with dimensions `[2, 3, 4, 5]` and `[5, 4, 3, 2]`?  The underlying tensor spaces here are clearly intended to be incompatible, so surely the answer should be no.  What about `[2, 4]` and `[4, 2]`?  Now we have no idea if they're both intended to be operators on a Hilbert space of three qubits, or if they're both operators on a qubit and a 4d space, but with the tensor order switched.  If we allow this, the error checking and type safety of the `dims` parameter has been completely lost if it's the second case, but if we disallow it while allowing implicit isomorphism with `[8]`, then we lose transitivity of isomorphism.

In QIP applications we also have more reasons for not allowing the implicit isomorphism, for example `permute` and `ptrace`.  If dimensions of [2, 2, 2, 2] and [16] are implicitly isomorphic, then Qobjs with those dimensions should be completely interchangeable, otherwise users will get rather inconsistent errors with the "same" object.  However, an object with dimensions [16] can't be used with either `ptrace` or `permute`, which operate directly on the tensor structure, which wouldn't be known.  `x.ptrace(1)` gives completely different results if `x` has dimensions `[2, 4]` or `[4, 2]` like in the previous paragraph, but maybe the user intended the subspace to be 3 qubits, and now neither answer we might get is correct.  In this case, the user still has to "carry around" the dimensions with them, which defeats the whole purpose of the implicit isomorphism in the first place.

If you think about quantum operators as "matrices", you've kind of already implied more isomorphisms than necessarily exist in the theory.  We're not perfect about enforcing safety with regards to this, but we're likely to get more safe (by default), not less.

I hope this explains why things are the way they are a little bit more.

Jake

[Andrew M. C. Dawes]

I definitely upvote this: “In this sense, I think we're more likely to strengthen the "dimensions" requirement into a "basis" requirement rather than relax it.”

In teaching with QuTiP it would be very helpful to track (and check) basis during calculations. I do understand this can add some computational cost but having it as an optional feature would be huge.

Happy to help on this, I played with it a bit a while ago but didn’t get very far.

Best

Andy

You received this message because you are subscribed to the Google Groups "QuTiP: Quantum Toolbox in Python" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qutip+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qutip/ba7bb862-6033-4898-b540-7aaa78b49db0n%40googlegroups.com.

[Tanya Garg]

Hi,

I came across the different interpretation of tensor product and density matrices while trying to implement the noise Kraus operators on my state. After going through the thread, I believe the different treatment of tensor products and density matrices is highly justified. But, this would be rather confusing for a number of people and a tedious job to work around finding a different method. I wanted to ask if the usage of a 'basis' parameter or adding a section in the tutorial regarding this will solve some of the problems? I believe that it could be a nice addition and give a good explanation of the concepts.

Would love to hear anybody's thoughts on this

Thank you

[Tanya Garg]

Hi,

I came across the different treatment of a regular Qobj and a tensor product while trying to apply noise model Kraus operators on my state. After going through the thread I agree with the fact that the different dimensionality does justice to the basic concepts of a quantum system. But, I reckon a number of other people would not be able to easily figure this out especially the beginners. I wanted to ask if the addition of a 'basis' parameter can solve a few problems? By keeping track of the basis parameter we can allow the users to do operations on the tensor state accordingly. Kindly correct me if I interpreted it wrongly.

I was able to understand how the distinguishability of the two is important but it really becomes troubling at times when you know that the theory behind your code is fine. 

Would love to hear someone's thoughts :)

Thanks

On Saturday, August 1, 2020 at 10:58:22 PM UTC+5:30 andrew...@gmail.com wrote:

[Jake Lishman]

Hi Tanya,

It sounds like the existing "dims" parameter might what you're looking for.  If you know that you're always going to be working with a system of 3 qubits, then kets on this system will have dimensions of [[2, 2, 2], [1, 1, 1]], and density matrices and other maps will have dimensions of [[2, 2, 2], [2, 2, 2]].  If you are creating Qobj directly from numpy arrays, you can pass these dimensions as the "dims" parameter in the constructor:

    rnd_array = np.random.rand(8, 8)

    op = qutip.Qobj(rnd_array, dims=[[2, 2, 2], [2, 2, 2]])

This marks "op" as being a map on a compound Hilbert space of 3 qubits.  You could store the dimensions "[[2]*n_qubits, [2]*n_qubits]" in a variable called "basis", and pass that whenever you are constructing a Qobj map (similarly "[[2]*n_qubits, [1]*n_qubits]" for a ket).  Most of the Qobj construction routines (e.g. qutip.rand_herm) similarly take a "dims" parameter that you can supply to pass this information on.  I'd agree that the documentation isn't the best on this - at best it's present but implicit.  We're currently talking about changing how dimensions are parsed and stored (but not how they operate) internally, and part of that will hopefully involve us extending the documentation on dims.

As far as QuTiP is concerned, there's no such thing as a "regular" Qobj, or at least that's not fundamentally different to one that lives in a compound Hilbert space.  If your Kraus operators are defined on the same Hilbert space as your states, QuTiP operations shouldn't be complaining about dimensional mismatches. If it is, that's a problem (please open an issue on GitHub/email here with a small minimal example!).  However, QuTiP will not apply any implicit isomorphisms between spaces of dimension 8 and spaces of dimension (2*2*2); if you create a Kraus operator from some external numpy array without specifying that the Hilbert space should be compound, that's incompatible with a state constructed by `qutip.tensor(qubit1, qubit2, qubit3)`.  This may be how your theory is valid, but QuTiP is complaining - the backing matrices are the same size, but QuTiP sees them as living in/on different vector spaces.

Jake

[Tanya Garg]

Hi Jake,

Thank you so much for the explanation and suggesting a way to deal with the issue. It is great to hear that there might be some updates in the dims documentation.

Thank you for your help :)

Tanya

You received this message because you are subscribed to a topic in the Google Groups "QuTiP: Quantum Toolbox in Python" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/qutip/NAGU4iKZNBY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to qutip+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qutip/504e7196-a0f9-4cf1-bf0e-09e2d071815fn%40googlegroups.com.