Generalized CTranspose + conversion methods and promotion rules

[jrevels]

This PR generalizes the CTranspose type to store Q<:AbstractQuArray and supplies the appropriate promotion rules and conversion methods. Once this is merged, we can close #31.

The only thing left before merging this in (unless something needs to be altered or I missed something) is to add some tests.

(I also snuck in a generalization of LabeledQuArray, a type alias that probably won't see much love for a while but for which I have future plans).

This also makes it simpler to call similar_type by adding a method that auto-extracts the type of a value argument (and promotes the types of two value arguments).

[acroy]

Looks good. I really like the new similar_type! I will try to play with it tomorrow. Any idea how we should test these things?

[acroy]

I guess this one you forgot?

[jrevels]

Good catch. I fixed it, and in the process of doing so uncovered an issue.

I found out that n-ary calls of tensor weren't dispatching properly because of the restriction that all arguments share a basis type. Since we parameterize the number of factors in our basis types, computing things like the following wouldn't work:

a = QuArray(rand(Complex{Float64},4), FiniteBasis(2,2))
b = QuArray(rand(Complex{Float64},1), FiniteBasis(1,1))
c = QuArray(rand(Complex{Float64},3))

ab = tensor(a,b)
tensor(ab, c) # fails, ab has a different basis type than c since the number of factors are different

After removing the basis type restriction, I added a test similar to the above. It's currently failing because type promotion for bases of different factor length is ambiguous:

julia> promote_type(typeof(ab), typeof(c))
ERROR: type: QuArray: in B, expected B<:AbstractBasis{S<:AbstractStructure}, got Type{FiniteBasis{S,N}}
 in promote_type at promotion.jl:110

I don't know what the right decision is here...perhaps we should consider abandon parameterizing factor length for basis types? Will any functions in the future require factor length as a parameter for type stability? Otherwise, we can just pull it from instances using the nfactors function (requiring it to be defined for all B<:AbstractBasis), and treat factor length as a value.

[acroy]

It feels like we had this discussion already? Anyways, at least at the moment we don't have anything that needs the factor length as a parameter, so we can just treat it as a value for now and switch back if necessary :-) I think when we introduced this I had in mind that doing partial traces/transpose could profit from it, but IMO this is to vague to stop this PR.

[jrevels]

I added a bunch of unit tests for the QuArray and CTranspose types.

This PR should be ready to merge, given that the tests pass (and I didn't miss anything).

[acroy]

I am probably just missing it, but does that make sense?

[jrevels]

I guess it's a matter of intent...I mainly defined that thinking that if one takes the tensor product of Bra and a Ket, they would expect the outer product of the states? For example, isn't the following is an accepted use of the ⊗ notation:

⟨ ψ | ⊗ | ϕ ⟩ = | ϕ ⟩ ⊗ ⟨ ψ | = | ϕ ⟩⟨ ψ |

Not a peer-reviewed publication, obviously, but: http://physics.stackexchange.com/questions/134575/tensor-product-of-a-bra-and-a-ket

[acroy]

I see. Never thought about it that way, but it makes perfect sense of course!

[acroy]

This is really good stuff! Let's see what Travis says ...

Maybe it is time to include code coverage via Coverage.jl (in a separate PR of course)?

[jrevels]

Definitely agree!

[jrevels]

Seems like things passed!

Let me know when you're done reviewing so I can merge it (or you can merge it when you're done, if you want).

[acroy]

I am done - you can merge.