Thank you Dan.
On Sunday, November 22, 2015 at 6:25:54 PM UTC+10:30, Dan wrote:
>
> Regarding the last printing point only
> print(string(eltype(8)) * ", " * string(eltype(8)))
>
> is probably what you meant. AbstractString(Int64), tries to create an
> AbstractString from an Int64, while string(Int64) asks for a string
> representation. The latter semantics is more accurate, and works.
>
> On Sunday, November 22, 2015 at 7:46:17 AM UTC+2, Zygmunt Szpak wrote:
>>
>> Hi All,
>>
>> I've been perusing the Coveralls/Codecov reports looking for
>> opportunities to write some additional tests.
>> I was looking at the promote_rule in int.jl and noticed that some
>> promote_rules were apparently missing tests.
>>
>> See for example:
>> promote_rule(::Type{Int64}, ::Type{Int8} ) = Int64
>>
>>
>>
>> https://codecov.io/github/JuliaLang/julia/base/int.jl?ref=e6cd2bc8c6ab2444d7750cf42d43b4c45e8f3545
>>
>> Apparently, this line is not covered by any test as indicated by the red
>> highlight.
>>
>> However, the test file for int.jl
>>
>> https://github.com/JuliaLang/julia/blob/master/test/int.jl
>>
>> contains the following tests:
>>
>> UItypes = (UInt8, UInt16, UInt32, UInt64, UInt128)
>> SItypes = (Int8, Int16, Int32, Int64, Int128)
>>
>>
>> for T in UItypes, S in UItypes
>> @test promote(S(3), T(3)) === (sizeof(T) < sizeof(S) ? (S(3), S(3)) :
>> (T(3), T(3)))
>> end
>>
>>
>> for T in SItypes, S in SItypes
>> @test promote(S(3), T(3)) === (sizeof(T) < sizeof(S) ? (S(3), S(3)) :
>> (T(3), T(3)))
>> end
>>
>>
>> for T in SItypes, S in UItypes
>> R = sizeof(S) < sizeof(Int) ? Int : S
>> @test promote(R(3), T(3)) === (sizeof(R) < sizeof(T) ? (T(3), T(3)) :
>> (R(3), R(3)))
>> end
>>
>> Looking deeper at one of these tests using the following code:
>>
>> for T in SItypes, S in SItypes
>> print(eltype(S(3)) )
>> print(", ")
>> print(eltype(T(3)) )
>> print(" -> ")
>> print(eltype(promote(S(3), T(3))))
>> print(" | ")
>> print(@which promote(S(3), T(3)))
>> println(" ")
>> end
>>
>> which yields:
>>
>> Int8, Int8 -> Int8 | promote{T,S}(x::T, y::S) at promotion.jl:132
>>> Int16, Int8 -> Int16 | promote{T,S}(x::T, y::S) at promotion.jl:132
>>> Int32, Int8 -> Int32 | promote{T,S}(x::T, y::S) at promotion.jl:132
>>> *Int64, Int8 -> Int64 | promote{T,S}(x::T, y::S) at promotion.jl:132 *
>>> Int128, Int8 -> Int128 | promote{T,S}(x::T, y::S) at promotion.jl:132
>>> Int8, Int16 -> Int16 | promote{T,S}(x::T, y::S) at promotion.jl:132
>>> Int16, Int16 -> Int16 | promote{T,S}(x::T, y::S) at promotion.jl:132
>>> Int32, Int16 -> Int32 | promote{T,S}(x::T, y::S) at promotion.jl:132
>>> Int64, Int16 -> Int64 | promote{T,S}(x::T, y::S) at promotion.jl:132
>>> Int128, Int16 -> Int128 | promote{T,S}(x::T, y::S) at promotion.jl:132
>>> Int8, Int32 -> Int32 | promote{T,S}(x::T, y::S) at promotion.jl:132
>>> Int16, Int32 -> Int32 | promote{T,S}(x::T, y::S) at promotion.jl:132
>>> Int32, Int32 -> Int32 | promote{T,S}(x::T, y::S) at promotion.jl:132
>>> Int64, Int32 -> Int64 | promote{T,S}(x::T, y::S) at promotion.jl:132
>>> Int128, Int32 -> Int128 | promote{T,S}(x::T, y::S) at promotion.jl:132
>>> Int8, Int64 -> Int64 | promote{T,S}(x::T, y::S) at promotion.jl:132
>>> Int16, Int64 -> Int64 | promote{T,S}(x::T, y::S) at promotion.jl:132
>>> Int32, Int64 -> Int64 | promote{T,S}(x::T, y::S) at promotion.jl:132
>>> Int64, Int64 -> Int64 | promote{T,S}(x::T, y::S) at promotion.jl:132
>>> Int128, Int64 -> Int128 | promote{T,S}(x::T, y::S) at promotion.jl:132
>>> Int8, Int128 -> Int128 | promote{T,S}(x::T, y::S) at promotion.jl:132
>>> Int16, Int128 -> Int128 | promote{T,S}(x::T, y::S) at promotion.jl:132
>>> Int32, Int128 -> Int128 | promote{T,S}(x::T, y::S) at promotion.jl:132
>>> Int64, Int128 -> Int128 | promote{T,S}(x::T, y::S) at promotion.jl:132
>>> Int128, Int128 -> Int128 | promote{T,S}(x::T, y::S) at promotion.jl:132
>>
>>
>> it would appear that the line *highlighted in blue* above is indeed
>> testing:
>> promote_rule(::Type{Int64}, ::Type{Int8} ) = Int64
>>
>> contrary to what the Coveralls/Codecov is reporting. I'm not sure how
>> to reconcile these results, and would appreciate any insight.
>>
>> On a sightly different note, could anyone suggest a neat way of printing
>> element types on a single
>> line such as:
>>
>>> Int64, Int64 -> Int64
>>
>>
>> For example, is there a way to convert Tuples to Strings?
>>
>> I've tried things such as:
>> print(AbstractString(eltype(8)) * ", " * AbstractString(eltype(8)))
>>
>> LoadError: MethodError: `convert` has no method matching
>>> convert(::Type{AbstractString}, ::Type{Int64})
>>> This may have arisen from a call to the constructor AbstractString(...),
>>> since type constructors fall back to convert methods.
>>> Closest candidates are:
>>> call{T}(::Type{T}, ::Any)
>>> convert{T<:AbstractString,S<:Union{Char,Int32,UInt32}}(::Type{T<:AbstractString},
>>>
>>> !Matched::AbstractArray{S<:Union{Char,Int32,UInt32},1})
>>> convert{S<:AbstractString}(::Type{S<:AbstractString},
>>> !Matched::Base.UTF8proc.GraphemeIterator{S<:AbstractString})
>>> ...
>>> while loading In[128], in expression starting on line 1 in call at
>>> essentials.jl:56
>>
>>
>> from which I understand that there is currently no conversion method from
>> Types to Strings.
>>
>> Many thanks for your time.
>>
>> Zygmunt
>>
>>
