promote fallback for division

[StefanKarpinski]

Leaving this here as a breadcrumb, but if someone else wants to go for it, feel free:

https://discourse.julialang.org/t/playing-around-with-intmod/980/10

I think we should probably have a /(a::Number, b::Number) = /(promote(a,b)...) fallback. This would allow directly defining division for an integer type and promotion with e.g. Int to make 1/n to work, whereas currently it won't because the rule to convert to float first kicks in.

[p-i-]

I would love to have a go at this one.

However I'm not quite following. Julia already contains that fallback: https://github.com/JuliaLang/julia/blob/master/base/promotion.jl#L193

The problem is that 1/k where k subtypes Integer hits /(x::Integer, y::Integer) = float(x)/float(y) on https://github.com/JuliaLang/julia/blob/master/base/int.jl#L35 as Integer is more specific than Number.

The following seems to work:

/{T <: Integer}(a::T, b::Integer) = /(promote(a,b)...)
/{T <: Integer}(a::Integer, b::T) = /(promote(a,b)...)

Does this look decent?

I am not confident it is robust against some awkward scenario, e.g. S and T both subtyping Integer maybe even T <: S <: Integer

[KristofferC]

The conversion to float kicks in first because that functioj is defined for two Integers which is more specific than the promote function, which is for two Numbers (and as been said, already exist).

[p-i-]

How about we simply replace /(x::Integer, y::Integer) = float(x)/float(y) on https://github.com/JuliaLang/julia/blob/master/base/int.jl#L35 with:

/{T <: Integer}(a::T, b::T) = float(a) / float(b)  # Same type
/(a::Integer, b::Integer) = /(promote(a,b)...)     # Differing types

This means if the parameters are of different types we will promote them to a common type T. If the user wishes to supply a specific overload for /(T,T) great! Otherwise we attempt to convert both to float.

Can anyone see a problem with this?

If not I'll wire it in.

[StefanKarpinski]

The only potential problem would be if the integer promotion was potentially lossy, e.g. Int with UInt. So it might be a bit trickier than it initially seemed to get speed in the fast cases and correctness in the others.

[p-i-]

mmm...

julia> UInt64(1) / Int64(-1)
ERROR: InexactError()
 in /(::UInt64, ::Int64) at ./REPL[31]:1

julia> typeof( promote(UInt64(1), Int64(1)) )
Tuple{UInt64,UInt64}

julia> typeof( promote(UInt64(1), Int64(-1)) )
ERROR: InexactError()
 in promote(::UInt64, ::Int64) at /usr/local/Cellar/julia/HEAD-51b6b06/lib/julia/sys.dylib:?
 in promote(::UInt64, ::Int64) at /usr/local/Cellar/julia/HEAD-51b6b06/lib/julia/sys.dylib:?

So maybe {UInt64, Int64} and {Int64, UInt64} can be handled manually as special cases?

/(a::Int64, b::UInt64) = float(a) / float(b)
/(a::UInt64, b::Int64) = float(a) / float(b)

< 64 bits is no problem as e.g.

julia> typeof( promote(UInt16(1),Int16(-1)) )
Tuple{Int64,Int64}

Explicit overloads could be provided in the same way for 128-bit.

I don't feel confident to patch this through, I think it needs someone with a better perspective.

[JeffBezanson]

#19645 ?