What about Complex{Irrational}?

[giordano]

A Complex{Irrational} is allowed (e.g., Complex(pi, pi)), but there are a few functions that currently don't work with this type (e.g., exp, exp2, exp10; exp can be easily fixed if #21203 is merged, the other two functions can be fixed as part of the fix to #21200).

Should this type be kept (and non-working functions fixed) or automatically converted to, say, Complex{Float64}? I don't think this type is widely used (its odd representation in the REPL seems to confirm this) and any mathematical operation with it promotes it to another type, but I think that a decision should be taken about its status.

TODO list:

• make big(complex(pi, pi)) work (PR Define methods for big(T) #21218)
• fix exp (PR Make exp(::Complex{Irrational}) work #21596)
• make sinpi(complex(pi, pi)) work (actually, not even sinpi(pi) works right now). Same for cospi. Requires More efficient float(T) for rationals and big*, works with Irrational #21219 (PR Fix sinpi and cospi with Irrational arguments #21781)
• fix log1p: can be fixed with one(float(T)) in place of float(one(T)) (which is also more efficient for Big numbers, only one number is allocated) if More efficient float(T) for rationals and big*, works with Irrational #21219 if merged (PR Fix log1p with complex Irrational argument #21784)
• fix exp2 and exp10: see this comment below, requires PR More efficient float(T) for rationals and big*, works with Irrational #21219 (PR Fix complex exp2 and exp10 with boolean and irrational argument #21874)
• make complex(pi) work (PR Define method for complex(x::Irrational) #22928) The decision was to not make complex(irrational) work at all.

[ararslan]

IMO we should add/widen methods to allow Complex{Irrational}. Seems silly to convert arguments when simply wrapping them in Complex.

[giordano]

Seems silly to convert arguments when simply wrapping them in Complex.

I tend to agree. They can be promoted to Complex{BigFloat} by performing operations together with this type, but a method for big(::Complex{Irrational}) is currently missing:

big(z::Complex{<:Irrational}) = Complex{BigFloat}(z)

BTW, my fix for #21200 is to define

exp2(z::Complex{<:Real}) = exp2(float(z))

and change the current signature of exp2 to

function exp2(z::Complex{T}) where {T<:AbstractFloat}

Does it make sense?

[ararslan]

Might make sense to define a big method for types that returns the Big* version, akin to what we do for float (e.g. float(Int64) == Float64). Then the method

big{T<:Real}(z::Complex{T}) = Complex{big(T)}(z)

could replace the separate ones for Integer and AbstractFloat.

[giordano]

I'd like to work on this, but I'm unsure about what's the best way. I was going to define a method of big for each of Integer, Rational, Irrational and AbstractFloat (and automatically for their subtypes), but then noticed that float(T) is defined as

float{T<:Number}(::Type{T}) = typeof(float(zero(T)))

This is inefficient for Big* and doesn't handle Irrationals. Maybe define a method for big like this as fallback and then define a method for each type as I suggested above? What do you think?

[ararslan]

big(::Type{<:Integer}) = BigInt
big(::Type{<:Union{AbstractFloat,Irrational}}) = BigFloat
big(::Type) = typeof(big(zero(T)))

should suffice I would think.

Backing up, how is big relevant to Complex{Irrational}?

[giordano]

Backing up, how is big relevant to Complex{Irrational}?

Those methods allow promoting Complex{Irrational} to Complex{BigFloat} with the maximum precision. In general, Complex{Irrational} needs some love, that PR is part of this process ;-)

[TotalVerb]

I really don't see the purpose of Complex{Irrational{:π}} or similar singleton types. What is the significance of these values?

[giordano]

I don't have a particular purpose, but the type just exists, I don't see why making it impossible to use if it can be done with little effort (actually by improving other functions). In addition, complex(pi, pi) keeps the "irrationality" features, which can be sometimes useful, see above.

exp2(pi) doesn't work with x being Complex{Irrational} for the same reason for which doesn't work if x is Complex{Bool}. Fixing the functions listed in the first message can in turn make them wok for other custom types, this isn't limited to Complex{Irrational} at all.

[mschauer]

Hm, there cannot be an irrational zero, I am pessimistic about the last bullet point.

[ararslan]

You mean of allowing complex(π)? IMO that should be fine, just complex(π) = π + 0im.

[mschauer]

You can achieve Complex{Float64}(0, pi) or even Complex{Real}(0, pi), but there cannot be a z::Complex{Irrational} which has real(z) == 0 because there is no irrational 0.

[ararslan]

there cannot be a z::Complex{Irrational} which has real(z) = 0 because there is no irrational 0

Right. Though Complex{Irrational} could error on construction for rational input.

[giordano]

Each irrational number is a different type, given how Complex works now it's impossible to have real and imaginary parts with different types, even defining an "irrational zero".

The easiest fix is probably

complex(x::Irrational) = Complex{Float64}(x)