distinct types for positive and negative (Real) infinity

[tpapp]

In order to make use of this package for TransformVariables.jl, I would like to ask for distinct types for positive and negative (real) infinity, ideally accessible with ∞ and -∞. I need types I can dispatch on for type stability.

Basically this code does what I need.

(cf discussion)

[dlfivefifty]

OK I misunderstood. I thought you wanted const ∞ = SignedInfinity() so that typeof(-∞) == typeof(∞). But it sounds like you really want to change it so ∞ and -∞ are two different types.

I see zero problems. Would you be willing to make a PR?

[tpapp]

Sure. Should I just extend Infinity with a type parameter for the sign bit?

[dlfivefifty]

Yes, just replace struct Infinity <: Real end with struct Infinity{signbit} <: Real end, as you are doing.

[JeffreySarnoff]

related #6

[tpapp]

@dlfivefifty: I am kind of done with this change, but before making a PR, I thought I would ask if I should keep RealInfinity, or remove it. TBH, I think with the proposed change it becomes redundant, and the special cases of op(::Infinity, ::RealInfinty) are numerous and make maintaining this package more difficult.

[dlfivefifty]

I think I'm OK either way.

@cjdoris do you have any opinions?

[JeffreySarnoff]

I do not want to advocate for something that mostly brings crossclutter. If you are trimming Infinities, I would choose to keep ProjectiveInfinity over ComplexInfinity because it is a more flexible concept (geometrical as well as Riemannian extension). If RealInfinity be dropped, then ComplexInfinity is more terminology than portion.

AbstractInfinity as a shared locus of typic infinite realizations is, imo, good math.

[dlfivefifty]

ComplexInfinity is needed in ApproxFun to represent contours going to infinity at an angle

AbstractInfinity can be done as a union type, with a different name

[JeffreySarnoff]

ok (thanks to each of you for this effort)

[dlfivefifty]

For comparison: Mathematica is usually a good reference implementation, which only has DirectedInfinity, which is analogous to ComplexInfinity.

A special case is DirectedInfinity[] (also known as ComplexInfinity) which corresponds to an infinity with no known direction, which we can take to mean the same as ProjectiveInfinity.

I'm surprised not to see any cardinal numbers in Mathematica. So I'm not sure if there's a reference implementation for them. I only needed ℵ₁ in ContinuumArrays.jl to represent a notion of length for intervals.

[tpapp]

Just to clarify: I am not planning to touch anything other than Infinity (extend) and RealInfinity (remove) in the upcoming PR.

They can be renamed later on as far as I am concerned. I will wait few days for input from @cjdoris regarding the removal of RealInfinity; it would be best to arrive at a consensus and there is no need to rush.

[cjdoris]

To be honest, my personal interest in this package is in the InfExtended* types which I am yet to migrate over from Infinity.jl (partly time, partly letting these questions be resolved.)

I'm not especially wed to RealInfinity, I'll leave it to you to decide the best type system for the "pure infinity" types. It doesn't affect InfExtended* too much, the main interaction will be that there will be some promotion rules such as Infinity + Real => InfExtendedReal.

I'm a bit lost, can you summarise the proposed types?

PS Sorry I didn't notice the mention.

[dlfivefifty]

I think the proposal is to add Infinity{posneg}() in place of RealInfinity(posneg). Everything else will stay the same.

[cjdoris]

Ah ok. Is it <: Real?

[tpapp]

For my purposes, it does not have to be, but it is fine if it is. You decide.

[cjdoris]

I also don't mind, just curious. I think it's natural, since they coincide with Inf and -Inf.

[tpapp]

Thanks for the feedback, this is sufficient for me to complete the PR, I hope to finish it soon.

[dlfivefifty]

Yes we would want <: Real so that it can replace RealInfinity.