abstract type

[JeffreySarnoff]

We should follow Tim Holy and use

abstract type AbstractInterval{T} end

parameterizing the underlying type
that fits well with an emerging pattern
AbstractTime{T} etc.

[JeffreySarnoff]

I would go so far as to have a separate micro-API-ish package

module AbstractIntervals

export AbstractInterval, LoHiInterval 

abstract type AbstractInterval{T} end

struct LoHiInterval{T} <: AbstractInterval{T}
    lo::T
    hi::T
end

end # module

as that will help get other interval packages all conformant

[dpsanders]

In principle I certainly agree.

However, currently we need to have intervals be a subtype of Real for use with ForwardDiff.jl.

[JeffreySarnoff]

are you referring to dual.jl or another file?

[dpsanders]

Yes, to be able to create Duals of Intervals, to do e.g.

julia v0.5> using ValidatedNumerics, ForwardDiff

julia v0.5> f(x) = x^2 - 2;

julia v0.5> X = 3..4   # Interval
[3, 4]

julia v0.5> ForwardDiff.derivative(f, X)
[6, 8]

to get an enclosure of the derivative of f over the interval X.

[dpsanders]

And that restriction on Dual (that it takes Reals) will not be able to be removed until we have traits in Julia.

Of course, we could certainly do

abstract type AbstractInterval{T} <: Real end

but I'm not sure if Tim will be happy with that for IntervalSets.jl.

[JeffreySarnoff]

abstract type AbstractInterval{T, Orderedness<TotallyOrdered, e.g. linearly connected>} <: Real end

maybe you have a better fitting second param (to become trait, probably)

[JeffreySarnoff]

@timholy
What are your thoughts? Is this a good place for your way of entraiting (only if it would easily slip into the Julia future realization ... this would propagate). Is a second (ignorable) param better/worse/ much the same?

(why can we not already pre-furgate mathematical abstractions without tangling the numerical hierarchy?)

[timholy]

In principle, I don't think an interval should be a subtype of Real or even Number; anything that can be thought of as a pair of numbers certainly isn't the same thing as a single number, even if you can define a lot of similar operations for them. I would say this is even clearer than the case of whether a Factorization should be an AbstractArray:

julia> Factorization <: AbstractArray
false

even though a Factorization is simply a representation of an AbstractArray F = A*B.

More practically, I think (hope) I understand the bind this puts you in. Could one relax the requirement on Real in ForwardDiff? I did some brief experiments and it seems one can get fairly far:

$ git diff
diff --git a/src/dual.jl b/src/dual.jl
index dfed492..0b56063 100644
--- a/src/dual.jl
+++ b/src/dual.jl
@@ -4,7 +4,7 @@ const ExternalReal = Union{subtypes(Real)...}
 # Dual #
 ########
 
-immutable Dual{N,T<:Real} <: Real
+immutable Dual{N,T}
     value::T
     partials::Partials{N,T}
 end
@@ -13,7 +13,7 @@ end
 # Constructors #
 ################
 
-Dual{N,T}(value::T, partials::Partials{N,T}) = Dual{N,T}(value, partials)
+# Dual{N,T}(value::T, partials::Partials{N,T}) = Dual{N,T}(value, partials)
 
 function Dual{N,A,B}(value::A, partials::Partials{N,B})
     T = promote_type(A, B)
@@ -144,11 +144,11 @@ end
 
 isconstant(n::Dual) = iszero(partials(n))
 
-@ambiguous Base.isequal{N}(a::Dual{N}, b::Dual{N}) = isequal(value(a), value(b))
-@ambiguous Base.:(==){N}(a::Dual{N}, b::Dual{N}) = value(a) == value(b)
-@ambiguous Base.isless{N}(a::Dual{N}, b::Dual{N}) = value(a) < value(b)
-@ambiguous Base.:<{N}(a::Dual{N}, b::Dual{N}) = isless(a, b)
-@ambiguous Base.:(<=){N}(a::Dual{N}, b::Dual{N}) = <=(value(a), value(b))
+Base.isequal{N}(a::Dual{N}, b::Dual{N}) = isequal(value(a), value(b))
+Base.:(==){N}(a::Dual{N}, b::Dual{N}) = value(a) == value(b)
+Base.isless{N}(a::Dual{N}, b::Dual{N}) = value(a) < value(b)
+Base.:<{N}(a::Dual{N}, b::Dual{N}) = isless(a, b)
+Base.:(<=){N}(a::Dual{N}, b::Dual{N}) = <=(value(a), value(b))
 
 for T in (AbstractFloat, Irrational, Real)
     Base.isequal(n::Dual, x::T) = isequal(value(n), x)
@@ -210,11 +210,11 @@ Base.float{N,T}(n::Dual{N,T}) = Dual{N,promote_type(T, Float16)}(n)
 # Addition/Subtraction #
 #----------------------#
 
-@ambiguous @inline Base.:+{N}(n1::Dual{N}, n2::Dual{N}) = Dual(value(n1) + value(n2), partials(n1) + partials(n2))
+@inline Base.:+{N}(n1::Dual{N}, n2::Dual{N}) = Dual(value(n1) + value(n2), partials(n1) + partials(n2))
 @ambiguous @inline Base.:+(n::Dual, x::Real) = Dual(value(n) + x, partials(n))
 @ambiguous @inline Base.:+(x::Real, n::Dual) = n + x
 
-@ambiguous @inline Base.:-{N}(n1::Dual{N}, n2::Dual{N}) = Dual(value(n1) - value(n2), partials(n1) - partials(n2))
+@inline Base.:-{N}(n1::Dual{N}, n2::Dual{N}) = Dual(value(n1) - value(n2), partials(n1) - partials(n2))
 @ambiguous @inline Base.:-(n::Dual, x::Real) = Dual(value(n) - x, partials(n))
 @ambiguous @inline Base.:-(x::Real, n::Dual) = Dual(x - value(n), -(partials(n)))
 @inline Base.:-(n::Dual) = Dual(-(value(n)), -(partials(n)))
@@ -225,7 +225,7 @@ Base.float{N,T}(n::Dual{N,T}) = Dual{N,promote_type(T, Float16)}(n)
 @inline Base.:*(n::Dual, x::Bool) = x ? n : (signbit(value(n))==0 ? zero(n) : -zero(n))
 @inline Base.:*(x::Bool, n::Dual) = n * x
 
-@ambiguous @inline function Base.:*{N}(n1::Dual{N}, n2::Dual{N})
+@inline function Base.:*{N}(n1::Dual{N}, n2::Dual{N})
     v1, v2 = value(n1), value(n2)
     return Dual(v1 * v2, _mul_partials(partials(n1), partials(n2), v2, v1))
 end
@@ -236,7 +236,7 @@ end
 # Division #
 #----------#
 
-@ambiguous @inline function Base.:/{N}(n1::Dual{N}, n2::Dual{N})
+@inline function Base.:/{N}(n1::Dual{N}, n2::Dual{N})
     v1, v2 = value(n1), value(n2)
     return Dual(v1 / v2, _div_partials(partials(n1), partials(n2), v1, v2))
 end
@@ -254,7 +254,7 @@ end
 
 for f in (:(Base.:^), :(NaNMath.pow))
     @eval begin
-        @ambiguous @inline function ($f){N}(n1::Dual{N}, n2::Dual{N})
+        @inline function ($f){N}(n1::Dual{N}, n2::Dual{N})
             v1, v2 = value(n1), value(n2)
             expv = ($f)(v1, v2)
             powval = v2 * ($f)(v1, v2 - 1)

It doesn't pass DualTests.jl but it's clear that most stuff works. I'm not going to push forward on this myself, but perhaps others could pick it up.

[timholy]

Though one should get in touch with @jrevels before going down this road too far.

If just removing the type restriction won't fly, one can still control dispatch even without "official" traits. One can use SimpleTraits.jl or just write them out manually:

foo(x) = _foo(DualWorthy(x), x)
_foo(::SafeForDual, x) = blah blah
_foo(::Any, x) = error(x, " is not worthy of being dual-ified")

DualWorthy can satisfy an interface somewhat like another trait that Base uses heavily, IndexStyle. Or you could even make DualWorthy(x) itself throw the error.

[dpsanders]

In Julia at the moment, there simply isn't any way of saying that an interval (or a dual number, for that matter) is "something number-like" (e.g. is something like a ring, in the abstract algebra sense), without making it a subtype of Real or Number.

In that sense, currently, Real in Base seems to be something approximating "real numbers", but in the wider ecosystem has come to take on rather the meaning of "something number-like".

I was discussing this offline with @jrevels, who may wish to comment about ForwardDiff.jl.

[timholy]

We may have had a "race condition" in our comments, but in case not: DualWorthy would allow you to opt-in for any type that you are willing to support the necessary operations for Dual. Types that don't support the needed interface could either automatically throw an error or could simply dispatch differently (that second _foo above could simply do something different).

[timholy]

The docs on the AbstractArray interface may be a helpful model showing how IndexStyle solves these problems.

[dpsanders]

Thanks @timholy, that's a very nice idea.