Type issue for proxL1

[aTrotier]

function proxL1!(x::AbstractArray{Tc}, λ::T; sparseTrafo::Trafo=nothing, kargs...) where {T, Tc <: Union{T, Complex{T}}}

λ::T should be λ::Float64 ?

issue related to : MagneticResonanceImaging/MRIReco.jl#78

[migrosser]

The restriction Tc <: Union{T, Complex{T}} actually makes a lot of sense because it avoids having to perform type-conversions when the element-type of x and λ don't match.
However, I agree that it would be better if one didn't have to worry about this issue when performing high-level reconstruction, e.g. in MRIReco.
A possible solution would be to update our factory method for building Regularization-objects, such that the type of the underlying data is taken into account. Potentially, one could even parametrize the type Regularization correspondingly. What do you think @tknopp ?

[aTrotier]

Yeah seems better than my option. It was just a quick fix to see if it works Le lun. 9 mai 2022 à 12:39, migrosser ***@***.***> a écrit :

…

The restriction Tc <: Union{T, Complex{T}} actually makes a lot of sense because it avoids having to perform type-conversions when the element-type of x and λ don't match. However, I agree that it would be better if one didn't have to worry about this issue when performing high-level reconstruction, e.g. in MRIReco. A possible solution would be to update our factory method for building Regularization-objects, such that the type of the underlying data is taken into account. Potentially, one could even parametrize the type Regularization correspondingly. What do you think @tknopp <https://github.com/tknopp> ? — Reply to this email directly, view it on GitHub <#39 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC5P7OYJGTYW734B6WWKONDVJD2Q3ANCNFSM5VH63XGQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[aTrotier]

closed by commit : MagneticResonanceImaging/MRIReco.jl@b84a9ee