Typed methods to construct states
nicolamos opened this issue · 6 comments
I came across this issue while trying to make QuantumOptics interoperate with different data types. I’m not sure what should be the best approach at the moment. I see that basisstate accepts also a keyword dType to specify the data type, but this is not propagated in other places.
I think that the Julian way is to define methods accepting also a type, usually as the first argument, with default methods when the type is not given. I mean something like:
fockstate(::Type{T}, b::FockBasis, n::Integer) where {T <: Number} = …
fockstate(b::FockBasis, n::Integer) = fockstate(ComplexF64, b, n)If you think this can be useful, we can discuss the best approach to implement this, as I do not know which impact this can have and how much effort is needed to implement it.
The dType kwarg was a half-hearted approach to this. I like the signature you suggest as it does seem a lot more like idiomatic Julia.
Doing this just for states, I think we'd need to do implement methods for:
fockstatespinup,spindownnlevelstaterandstatebasisstateKetandBraconstructors?
Did I miss any? Also, we should probably deprecate the dType kwarg.
The other question is that, if we're doing this for states, do we want such methods for operators as well? That might be a bit more effort.
Wow you already did the changes, thanks! I looked into the PR and seems fine. Only one thing, why did you kept the type generic? I mean, shouldn’t the type be a subtype of Number? Are there any reasons to keep it more general?
Regarding your last point, I think that eventually this should be done also for operators, depending on how they are created (I admit I used little of all the QuantumOptics.jl ecosystem). If you can point me in the right direction, I can do the changes myself.
Only one thing, why did you kept the type generic?
My take on this is that types should only be put there if really needed to keep things as generic as possible. If the provided type is <:Number then this doesn't matter at all so why not leave it out. As a side note: I got is wrong in a lot of places in QuantumOptics.jl. Changing type-signatures that are too restrictive will be the subject of another (rather tedious) PR.
If you can point me in the right direction, I can do the changes myself.
Well that would be awesome of course, thanks :) the methods to change should be located in the same files as the ones I changed in #25, except for states.jl. All the constructors like number, create, destroy etc. need to be changed. Additionally you'll need to modify the constructors for DenseOperator and SparseOperator in operators_dense.jl and operators_sparse.jl, respectively. I think that should do it.
Ok, I see your point.
Thanks for pointing me in the right direction. I will open a new PR with the changes for operators.