The current implementations of the mutating versions of the transforms require that the input array x and output array y have the same eltype:
function _dwt!(y::AbstractVector{T}, x::AbstractVector{T},
filter::OrthoFilter, L::Integer, fw::Bool) where T<:Number
It would be useful to relax this restriction, e.g.:
function _dwt!(y::AbstractVector{Ty}, x::AbstractVector{Tx},
filter::OrthoFilter, L::Integer, fw::Bool) where {Tx<:Number, Ty<:Number}
Note that the most basic "do nothing" transform in the code reverts to simply copyto!(y,x), and copyto! itself does not require the arguments do have the same eltype. (Of course you get and InexactError if you try to copy from arbitrary Floats to Ints, or Real to Complex, but if you do precision changes like Float32 to Float64 then copyto! takes care of the conversion for you.
I'd be willing to try to make PR to provide this generality, because I think it just requires some changes to the function declarations, but I wanted to see first if there are objections or drawbacks.
Edit: I needed this for my work so I made the PR #54.
The current implementations of the mutating versions of the transforms require that the input array
x
and output arrayy
have the sameeltype
:It would be useful to relax this restriction, e.g.:
Note that the most basic "do nothing" transform in the code reverts to simply
copyto!(y,x)
, andcopyto!
itself does not require the arguments do have the sameeltype
. (Of course you get andInexactError
if you try to copy from arbitrary Floats to Ints, or Real to Complex, but if you do precision changes like Float32 to Float64 thencopyto!
takes care of the conversion for you. I'd be willing to try to make PR to provide this generality, because I think it just requires some changes to the function declarations, but I wanted to see first if there are objections or drawbacks. Edit: I needed this for my work so I made the PR #54.