Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP : Spin Operators, Tests. WD : +,-,ops added. #22

Closed
wants to merge 9 commits into from

Conversation

amitjamadagni
Copy link
Contributor

WIP :

  • Spin operators to be implemented
  • Tests

Implemented

  • +,- on QuArray, CTranspose
  • momentm_op, position_op added.

@@ -61,6 +61,9 @@ end

*(dm1::DualMatrix, dm2::DualMatrix) = (dm1.qarr*dm2.qarr)'

+(qarr1::Union(QuArray,CTranspose), qarr2::Union(QuArray,CTranspose)) = bases(qarr1) == bases(qarr2) ? (return QuArray(coeffs(qarr1)+coeffs(qarr2), bases(qarr1))) : "Not compatible"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you want to use error("Bases not compatible.") here. Should we use type parameters (for the basis and N) to restrict the functions in the first place?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@acroy something like

function +{B<:AbstractBasis,N}(qarr1::Union(QuArray{B,N}, CTranspose{B,N}), qarr2::Union(QuArray{B,N},CTranspose{B,N}))

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that way we get e MethodError "for free" if someone tries to add say a QuVector and a QuMatrix. Nevertheless we have to check that the bases are the same (I am not sure if == works though).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think == is the right thing to do here, since it can be overloaded to work properly for each basis type - "value" equality is what we're looking for here, yes? Also, all we need to do to support mixed-basis type operations is to simply define some promotion rules between the various basis types, of which there aren't that many.

after_eye(lens, pivot))
end

function positionop(n::Int)
cop = raiseop(n)
return (cop+cop')/sqrt(2.)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should use scale! here since + already makes a copy and / would make another one (same for momentumop below).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@acroy Ah! Once again, I comment only to find that you've beat me to it by the time I'm done writing. I'm starting to believe that you are, in fact, a ninja...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, I just realized we won't be able to perform an in-place scaling of the Float64 array by a complex number; see my edit on my comment below.

@amitjamadagni
Copy link
Contributor Author

@jrevels I was thinking a bit off on it. I realize it is costlier. Anyways thanks for this :).

@acroy
Copy link
Contributor

acroy commented Mar 31, 2015

For spin operators we might want to keep an eye on FixedSizeArrays.jl (also JuliaLang/julia#7568)?

@amitjamadagni
Copy link
Contributor Author

@acroy I was doing something like this based on QuTiP :

function spin_j(j)
          m = reverse([-j:j-1])
          N = length(m)+1
          m_coeffs = [sqrt(j*(j+1.0) - (x+1.0)*x) for x in m]
          return QuArray(spdiagm(m_coeffs,1,N,N))
end

As far as my understanding of FixedSizeArrays.jl goes we are trying to create the array in a more efficient way with focus on the size. I am still trying to further understand but please do let me know if this is going in the right direction.

@acroy
Copy link
Contributor

acroy commented Apr 1, 2015

@amitjamadagni : for now we probably want (have) to use sparse matrices as containers as you do. I just stumbled across FixedSizeArrays and thought those could be useful for stuff like Pauli spin matrices, which are quite common. AFAICT the FixedSizeArrays need Julia 0.4 anyways, so this is something for QuBase 2.0 :-)

@amitjamadagni
Copy link
Contributor Author

@acroy @jrevels a review would be helpful. I have added the spin operators. Thanks

@acroy
Copy link
Contributor

acroy commented Apr 3, 2015

You have to rebase against the latest master and maybe we should put the spin operators into a separate file?

@amitjamadagni
Copy link
Contributor Author

@acroy sure okay. But could we move the entire machinery into a single file with the name as operators.jl ??

return scale(im/sqrt(2.), cop-cop')
end

function spin_h1(j::Float64)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe it is more elegant to use Rationals here (see docs)?

@acroy
Copy link
Contributor

acroy commented Apr 3, 2015

Let's see what Jarrett says, he has a better overview of the repo structure. I thought we could move the spin operators into a file spinops.jl or such ...

Conflicts:
	src/arrays/quarray.jl
@amitjamadagni amitjamadagni force-pushed the op_machinery branch 4 times, most recently from 62145d3 to 9d59b67 Compare April 3, 2015 13:06
@amitjamadagni
Copy link
Contributor Author

@acroy I am trying to rebase against the latest master. In the attempt I created a bit of mess with the commits. Any pointers relating to rebase would be helpful. Thanks.

@jrevels
Copy link
Contributor

jrevels commented Apr 3, 2015

I agree with using Rationals for the spin operators and moving them to their own file ("spinops.jl" sounds good to me).

@amitjamadagni You might've already seen this before, but I found this tutorial very helpful when learning to rebase. Is there a specific thing you're having trouble with, error message, etc.?

@amitjamadagni
Copy link
Contributor Author

@jrevels Yeah I have been trying and playing around but the problem I end up is I am unable to see the previous commits when I do a rebase -i master, to squash. I will give it a try once again and let you know.

@amitjamadagni
Copy link
Contributor Author

@acroy @jrevels I have made an attempt. A review would be helpful.

@acroy
Copy link
Contributor

acroy commented Apr 10, 2015

I think it is basically Ok. If you still have energy, you could add some comments to that spin function, in particular reminding us that it is not type stable. It would also be great if you could squash your commits.

@amitjamadagni
Copy link
Contributor Author

@acroy I am unable to squash some of the previous commits.

@acroy
Copy link
Contributor

acroy commented Apr 10, 2015

Why?

@amitjamadagni
Copy link
Contributor Author

I dont get the previous 8 commits before the last when i do a git rebase -i master.

@acroy
Copy link
Contributor

acroy commented Apr 10, 2015

It should probably be git rebase -i HEAD~9.

@amitjamadagni
Copy link
Contributor Author

@acroy Thanks for the help. Done squashing.

@acroy
Copy link
Contributor

acroy commented Apr 10, 2015

Mhm, I can't merge it. Maybe you have to rebase again?

@amitjamadagni amitjamadagni force-pushed the op_machinery branch 14 times, most recently from f409ff7 to 77d22e1 Compare April 10, 2015 22:45
Position and momentum, Spin operators, Related Tests.
@amitjamadagni
Copy link
Contributor Author

@acroy seems like I am stuck in a loop. Can I close this and open an another pull request ??

@amitjamadagni amitjamadagni deleted the op_machinery branch April 11, 2015 05:43
@amitjamadagni amitjamadagni mentioned this pull request Apr 11, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants