You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the following example, the second convert method isn't called even if it's more specific than the first one. Defining it first fixes the problem. This happens in both 0.4.6 and master.
type CategoricalArray{T, N, R <:Integer}
refs::Array{R, N}
pool::Array{T, N}endimport Base.convert
convert{T, N, R}(::Type{CategoricalArray{T, N, R}}, A::CategoricalArray) =1convert{T, N, R}(::Type{CategoricalArray{T, N, R}}, A::CategoricalArray{T, N, R}) =2
x =CategoricalArray([1,2], ["a", "b"]);
convert(typeof(x), x)
The ambiguity warning on 0.4.6 gives a hint about what's happening:
WARNING: New definition
convert(Type{Main.CategoricalArray{#T<:Any, #N<:Any, #R<:Any}}, Main.CategoricalArray) at none:1
is ambiguous with:convert(Type{Main.CategoricalArray{#T<:Any, #N<:Any, #R<:Any}}, Main.CategoricalArray{#T<:Any, #N<:Any, #R<:Any}) at none:1.
To fix, define
convert(Type{Main.CategoricalArray{#T<:Any, #N<:Any, #R<:Any}}, Main.CategoricalArray{#T<:Any, #N<:Any, _<:Integer})
before the new definition.
So IIUC the constraint R <: Integer, which is implicit in the first method, is the cause of the ambiguity. Indeed, adding that constraint to the second method allows it to be called.
I'm not quite sure why the constraint isn't automatically added to the second method, but at least we should get an ambiguity error instead of the current behaviour.
The text was updated successfully, but these errors were encountered:
Which version are you using? I do get the following error on both 0.6.0-dev.577 and 0.5.0-rc4
julia> type CategoricalArray{T, N, R <:Integer}
refs::Array{R, N}
pool::Array{T, N}end
julia>
julia>import Base.convert
julia>
julia>convert{T, N, R}(::Type{CategoricalArray{T, N, R}}, A::CategoricalArray) =1
convert (generic function with 598 methods)
julia>convert{T, N, R}(::Type{CategoricalArray{T, N, R}}, A::CategoricalArray{T, N, R}) =2
convert (generic function with 599 methods)
julia>
julia> x =CategoricalArray([1,2], ["a", "b"]);
julia>convert(typeof(x), x)
ERROR: MethodError:convert(::Type{CategoricalArray{String,1,Int64}}, ::CategoricalArray{String,1,Int64}) is ambiguous. Candidates:convert{T,N,R}(::Type{CategoricalArray{T,N,R}}, A::CategoricalArray{T,N,R}) at REPL[4]:1convert{T,N,R}(::Type{CategoricalArray{T,N,R}}, A::CategoricalArray) at REPL[3]:1
Indeed, I confirm I get an error on master. I had only tried with 0.6.0-dev.456 (2016-09-03 13:57 UTC), so it looks like it's been (semi-)fixed last week.
In the following example, the second
convert
method isn't called even if it's more specific than the first one. Defining it first fixes the problem. This happens in both 0.4.6 and master.The ambiguity warning on 0.4.6 gives a hint about what's happening:
So IIUC the constraint
R <: Integer
, which is implicit in the first method, is the cause of the ambiguity. Indeed, adding that constraint to the second method allows it to be called.I'm not quite sure why the constraint isn't automatically added to the second method, but at least we should get an ambiguity error instead of the current behaviour.
The text was updated successfully, but these errors were encountered: