Overflow when rounding rationals in edge case

[pkofod]

Rounding rationals uses the good ol' right bit shift

function round{T}(::Type{T}, x::Rational, ::RoundingMode{:Nearest})
    q,r = divrem(x.num,x.den)
    s = abs(r) < (x.den+one(x.den)+iseven(q))>>1 ? q : q+copysign(one(q),x.num)
    convert(T,s)
end
round{T}(::Type{T}, x::Rational) = round(T,x,RoundNearest)
function round{T}(::Type{T}, x::Rational, ::RoundingMode{:NearestTiesAway})
    q,r = divrem(x.num,x.den)
    s = abs(r) < (x.den+one(x.den))>>1 ? q : q+copysign(one(q),x.num)
    convert(T,s)
end
function round{T}(::Type{T}, x::Rational, ::RoundingMode{:NearestTiesUp})
    q,r = divrem(x.num,x.den)
    s = abs(r) < (x.den+one(x.den)+(x.num<0))>>1 ? q : q+copysign(one(q),x.num)
    convert(T,s)
end

This is fine, except the +one(x.den) addition gives a problematic edge case, when x.den == typemax(T) where T = typeof(x.den). It's problematic because it overflows, and we get:

julia> r = Rational(rand(Int32)), typemax(Int32))
234//2147483647
julia> round(r)
1//1

The result is independent of the realization of rand(IntType) as the overflow will happen no matter what, resulting in a negative rounded half denominator which is always strictly smaller than abs(r). This means that even if you get 1//1 when num>den it is not because of a correct calculation, but a buggy result, that coincides with the correct answer.

I would love to fix it, but I'm not sure what people would prefer. I know it is not Matlab, and Julia doesn't warn users of typemax(::Type)+one(::Type), but in round() we can actually find the answer if we are careful in how we compare when den(r)==typemax(typeof(r)). It will come with a perf cost, but I guess the round of a Rational is rarely important performance wise.

[simonbyrne]

This should certainly be fixed. For Rationals we generally favour correctness over performance optimisations.

[pkofod]

I'll submit a pr later then.

[simonbyrne]

Fantastic, thanks!

[pkofod]

I'll make a PR soon, but I just have a style question. In the current code, the numerator and denominator are retrived as:

x.num
x.den

but wouldn't functions (they are already defined!) be more Julian than dots?

num(x)
den(x)

?

[simonbyrne]

Yes, particularly if we make the changes discussed in #11522