JuliaAttic
QuArray vs. base Array type promotion
At some point, we need to figure out how QuArrays promote with other array types (e.g. Julia's base Array).
For example, what should the following operations return?
+(::AbstractQuArray, ::Array)
kron(::AbstractQuArray, ::Array)
*(::AbstractQuArray, ::Array)
@jrevels it would be really helpful to have some application of the cases, just to have an idea of the expected behavior of the mentioned constructs.
For a silly example, if a user does something like:
julia> v = [1, 0, 0]
3-element Array{Int64,1}:
1
0
0
julia> qv = statevec(3)
3-element QuVector in FiniteBasis{Orthonormal,1}:
...coefficients: Array{Float64,1}
[0.0,0.0,1.0]
julia> 1/√2 * (v + qv)
What do we do? Should we return a QuVector([1/√2, 0, 1/√2]), or an Array with those same values (we could throw an error, but that would probably get annoying)?
Another way to look at this is: Do we assume qv's basis information holds for v, or do we throw away qv's basis information since we don't know v's in detail? IMO, the former would be more intuitive behavior for the most part, but others might not agree.
@jrevels I guess it should be an error, atleast in this case as we have defined QuVector to be a combination of coeffs in a particular basis, so we should be strict on the error atleast I assume as there is no total information about the bases of an array when it is added to QuArray. But if there is a real use case we could use the promotion rule, and convert the v to QuArray and return QuArray as you mentioned assuming qv's basis holds for v.
The main problem I see with silently converting v to QuArray with qv's basis is that the meaning of v depends on the context. You can consider this a bug or a feature :-) From this perspective, I agree with @amitjamadagni that we should enforce explicit conversions. On the other hand it would certainly be convenient for many applications...
