Closed jrevels closed 9 years ago
I removed the factor parameterization for FiniteBasis in order to allow operations like |A⟩⟨B|⟨C| --> |A⟩⟨BC| ...
I can't really come up with a use case either. Would it be better/sufficient to force the user to explicitly convert either |A> or <BC|?
Would it be better/sufficient to force the user to explicitly convert either |A> or <BC|?
I suppose so - I can always re-implement the more general thing if we end up actually needing it.
Also, I believe that's the same thing as saying we won't allow mixed-order tensor products...which makes writing the tensor product generally really easy (for orthonormal bases, anyway).
The most recent commits on this branch...
coeffs
for getting end-result coefficients, and rawbases
so that we have the same flexibility in accessing bases as we do coefficients.Thoughts?
Looks good, although I haven't tested it. Could you rebase & squash your commits?
This PR delivers a set of tensor product functions for QuArrays and their duals. Like our current set of multiplication functions, these functions only cover objects of N < 3 with orthonormal bases.
In addition, I realized that having basis types parameterize the number of factors can break construction of QuArrays where bases along different dimensions have different numbers of factors, e.g.
I removed the factor parameterization for FiniteBasis in order to allow operations like |A⟩⟨B|⟨C| --> |A⟩⟨BC|. I don't explicitly know when that kind of operation would be useful, but I think it's mathematically valid to define linear maps between spaces with explicit factors (e.g. H_BC) to a space without explicit factors (e.g. H_A), so I went ahead and did so. I might be over-generalizing here...