Project plan

[dlfivefifty]

1. Infinity <: Real (replaces Infinity.Infinite)
2. InfiniteCardinal{K} <: Integer (InfiniteCardinal{0} replaces InfiniteArrays.Infinity and InfiniteCardinal{K} replaces ContinuumArrays.AlephInfinity{K})
3. RealInfinity <: Real
4. ComplexInfinity <: Number for angled infinity
5. InfiniteTime <: TimeType
6. InfExtended*

I'll plan to do 1--4 by copying over the code from InfiniteArrays.jl.

[dlfivefifty]

@cjdoris For consistency in naming we should choose one of the following:

1. RealInfinity and ComplexInfinity
2. SignedInfinity and AngledInfinity

In the previous proposal it mixes terms. Which of the two do you prefer?

[cjdoris]

I prefer ComplexInfinity over AngledInfinity because then it's clear it really is meant to be a complex number, and also there are many kinds of angles.

But then if we go with 1 then logically we should also have PositiveRealInfinity (or UnsignedRealInfinity or URealInfinity) instead of Infinity.

[dlfivefifty]

I think just Infinity is fine for PositiveRealInfinity, as it will be the one with ∞ as the shorthand. The README can make this clear.

[cjdoris]

I'm OK with that.

[dlfivefifty]

Hmm, Note that ComplexInfinity{Bool} is actual the same as RealInfinity... Does this change anything design wise?

[cjdoris]

Does it? What does the type parameter mean?

[cjdoris]

I was thinking about it earlier, and I definitely think that ComplexInfinity{T} should represent the number z * ∞ by the non-zero complex number z :: Complex{T} and not by the angle. Firstly, this is more consistent with the existing Complex type, which uses Cartesian coordinates. Secondly, this doesn't get in the way of using Gaussian integers Complex{Int} or infinite Gaussian integers ComplexInfinity{Int} and InfExtendedComplex{Int}.

[dlfivefifty]

Does it? What does the type parameter mean?

See

Infinities.jl/src/Infinities.jl

Line 264 in 3d27318

struct ComplexInfinity{T<:Real} <: Number

I currently represent it by the angle, but stored as signbit, that is π * a.signbit. The reason I did this is so that ±∞ are exactly representable. But of course they are also exactly representable if we store z.

But I don't think I actually use InfiniteArrays.OrientedInfinity for anything important, so we can change it to your suggestion.

[JeffreySarnoff]

Projective Infinity (the infinity of the Riemann sphere)

[cjdoris]

Yes please. As a general rule I think x*∞ should be represented exactly if possible, whatever the type of x. On the whole this might mean storing x exactly, but for reals a sign bit suffices.

[cjdoris]

Projective Infinity (the infinity of the Riemann sphere)

There's already https://github.com/scheinerman/RiemannComplexNumbers.jl

No reason we couldn't add projective infinities in general though, if there's demand.

[dlfivefifty]

Hmm, I think what we really want are union types that are subtypes of Real or Number. In other words, we wish we could do:

const RiemannSphere{T} = Union{Complex{T}, ComplexInfinity{T}}

but we cannot since Union is not <: Number.

But what do you think about this:

struct IntegerUnion{TYPES<:Union} <: Integer
    types::TYPES
end
struct RealUnion{TYPES<:Union} <: Real
    types::TYPES
end
struct ComplexUnion{TYPES<:Union} <: Number
     types::TYPES
end

const ExtendedInt = IntegerUnion{Union{Int,RealInfinity}}
const ExtendedComplex{T} = ComplexUnion{Union{Complex{T},ComplexInfinity{T}}}
const RiemannSphere{T} = ComplexUnion{Union{Complex{T},Infinity}}

[dlfivefifty]

Sorry, I was wrong:

julia> Union{Real,Complex} <: Number
true

So actually, my new proposal is have no special types for extended numbers and just do:

const ExtendedInt = Union{Int,RealInfinity}
const ExtendedComplex{T} = Union{Complex{T},ComplexInfinity{T}}
const RiemannSphere{T} = Union{Complex{T},Infinity}

What if any draw back would there be?

[cjdoris]

Type instability and promotion craziness! This is what InfExtendedReal{Int} solves, by being a single concrete type.

[dlfivefifty]

Small union types do not suffer from type instability: this is the whole point of Union{T,Missing}.