Merge functionality from QuDirac

[jrevels]

I've done a bit of work on the qudirac-merge branch to get us up and running with the stuff I've been working on over in the QuDirac.jl repo (which I'll likely take down soon since the functionality has been moved here).

This merge accomplishes a few things:

1. Provides a cleaner directory structure and a more comprehensive type hierarchy.
2. Organizes/cleans up existing code. BTW, I hope my style of tabbing code sections doesn't annoy anybody. This can obviously be changed if so.
3. Updates the creationop method provided by @acroy to work with arbitrary number of particles (you can pick which particle the operator should act on). I renamed it to raiseop for brevity's sake and implemented lowerop as well. These methods aren't optimized in the slightest (likely a tad slower than @acroy's original implementation), but provide a good starting point for ladder operations in multi-particle systems.
4. DiracArrays for computation using AbstractDiractypes. A more comprehensive description can be found in diracarrays.jl.
5. Two new basis types, FockBasis and LabelBasis. Descriptions for these types are in their relevant files. I'm especially excited for FockBasis, which will make DiracArrays way more performant than they could be with only the LabelBasis type.

I tried to leave detailed comments on newly added types; some of those comments might be pulled out/made into actual documentation. It's a hefty merge, but let me know what you think.

Next steps:

• Build a test suite for existing code
• Set up/write some documentation
• Implement actual methods for DiracArrays and QuArrays.
• A FunctionOperator{S,T} <: AbstractOperator{S} type. The idea is that you can define an operator functionally and then use it to perform algebra with the state types.
• A NullOperator/NullState type for handling additive identities for AbstractDirac types.
• I don't have much experience in the way of implementing solvers - if somebody wants pick that up, it'd be great. If not, I have some research to do!

[jrevels]

Just noticed mixed-tab/space usage and converted everything to spaces, which reads much nicer on GitHub.

[jrevels]

...In the meantime, I did a little bit more work on implementation for DiracVectors and QuArrays.

ketvec/bravec are pretty useful for messing around with what little functionality DiracVectors presently have:

julia> ketvec((1,0,1), 2,2,3)
KetVector{AbstractStructure} with 12 Complex{Float64} entries:
 0.0 + 0.0im | 0,0,0 ⟩
 0.0 + 0.0im | 1,0,0 ⟩
 0.0 + 0.0im | 0,1,0 ⟩
 0.0 + 0.0im | 1,1,0 ⟩
 0.0 + 0.0im | 0,0,1 ⟩
 1.0 + 0.0im | 1,0,1 ⟩
 0.0 + 0.0im | 0,1,1 ⟩
 0.0 + 0.0im | 1,1,1 ⟩
 0.0 + 0.0im | 0,0,2 ⟩
 0.0 + 0.0im | 1,0,2 ⟩
 0.0 + 0.0im | 0,1,2 ⟩
 0.0 + 0.0im | 1,1,2 ⟩

julia> ketvec((1,1,0,1))
KetVector{AbstractStructure} with 8 Complex{Float64} entries:
 0.0 + 0.0im | 0,0,0,0 ⟩
 0.0 + 0.0im | 1,0,0,0 ⟩
 0.0 + 0.0im | 0,1,0,0 ⟩
 0.0 + 0.0im | 1,1,0,0 ⟩
 0.0 + 0.0im | 0,0,0,1 ⟩
 0.0 + 0.0im | 1,0,0,1 ⟩
 0.0 + 0.0im | 0,1,0,1 ⟩
 1.0 + 0.0im | 1,1,0,1 ⟩

[acroy]

Wow, this is a quite impressive PR. Personally, I would prefer having smaller pieces to make reviewing easier. But if you don't mind to leave it open for a while and regularly rebase against master, this branch is pretty to useful to see the impact/implications of any changes we make. I also think at this stage it might be a bit too early to merge all the goodies from QuDirac. IMO we should try to settle the conceptual questions of QuArrays (#2) before we move on.

[jrevels]

Yeah, sorry for the size. Some of the recently posted roadmaps gave me the impression that folks wanted to port things straight from QuDirac, so I just lumped it all into a single merge - my bad.

But if you don't mind to leave it open for a while and regularly rebase against master, this branch is pretty to useful to see the impact/implications of any changes we make.

If that's the direction we want to take, I'd rather just stick to keeping the QuDirac stuff as its own repo (moved under the JuliaQuantum organization), and then reference QuBase as a dependency. Now that we actually have QuBase and I've made an attempt at moving things over, I can see there's going to be a lot of bloat if we try to house everything in one place. What we need in QuBase are solvers/modeling capability for coefficient arrays, a foundational type system, and a solid, general implementation for QuArrays and basis types. What I've done with QuDirac doesn't necessarily aim to accomplish all of these things, though I've ended up implementing some of them along the way. Also, if QuDirac was built on top of QuBase, rather than alongside it, it might be easier to pull in pieces of QuDirac as the need/desire arises.

What do we think about splitting this PR like so:

• quarray.jl, bases.jl, ladderops.jl, and finitebasis.jl stay in QuBase. I could make a new PR for merging just these in, which should be easier to review (though still a large PR, I admit).
• The dirac folder, and everything involving AbstactLabelBasis (fockbasis.jl, labelbasis.jl, and diracarrays.jl) would go into QuDirac, which I can make a repo for under JuliaQuantum.

For the record, I'm open to splitting it up differently, or even keeping everything in QuBase if someone lays out a persuasive argument for it. I just want things to be structured logically before we get too far in.

Also, what needs to be settled regarding QuArrays? I know there's the tensor compatibility thing - I'd appreciate it if anybody closer to the topic (@Jutho?) could make a more detailed issue for it, and that any other concerns have dedicated issues as well. On that note, the type aliases I set for QuArrays try to delineate between tensors, matrices, and vectors by basis information, rather than the coefficient arrays:

# We can't use N to tell whether something is really a vector
# since row vectors are N=2 (quite unfortunate). We can, however,
# infer the behavior from the number of bases...
typealias QuVector{B<:AbstractBasis,T,N,A} QuArray{(B,),T,N,A}
typealias QuMatrix{R<:AbstractBasis,C<:AbstractBasis,T,N,A} QuArray{(R,C),T,N,A}
typealias QuTensor{B<:(AbstractBasis...),T,N,A} QuArray{B,T,N,A}

Now that I'm reading it, I suppose defining QuTensor is pretty redundant...probably should wait to discuss this in an actual issue, though.

[acroy]

Sorry if my comment was a bit harsh. I actually appreciate your work and initiative! But I also think your suggestion about splitting the PR provides a better way to proceed, but that is of course just my opinion. We haven't really discussed what QuBase should contain, but I would agree with you that QuBase should mainly focus on QuArrays and basis types. I am not sure which kind of functionality we want to have in QuBase (apart from the array-like operations). For example, should (some) entanglement measures for quantum states be part of QuBase?

Regarding QuArrays: the only conceptional question that we might want to resolve now is IMO whether we want the basis size to be a part of the FiniteBasis type in some way or not. Of course it would be great to hear Juthos opinion as well. In any case your package shows that the proposed QuArray is not unreasonable.

[jrevels]

Sorry if my comment was a bit harsh.

No, it wasn't at all! I know the pain of digging through large PRs, I was just being lazy when I made it :p

I'll wait a bit (day or so) before making the split I suggested, but if nobody has any problems and we both agree, I see no reason not to move forward with it.