abstract complex?

[Roger-luo]

I'm wondering if it is good to have AbstractComplex, I think this is pretty useful since there can be different representation format for complex number as well, and they should share some similar interface and be treated both as complex number. e.g

1. complex number can be represented as radius and angle
2. or in my case I would like to define a symbolic type for complex number, which will directly inherit most of the complex number interfaces and make a lot function "just work"
3. in some cases we only use exp(theta*im), it only need one floating point or number.
4. I believe there can be more...

on the other hand, currently use some traits might help, but this will make complex numbers different from other numbers...

PS. integers have Integer, real numbers have Real, but complex number have none... it is not fair :-)

[StefanKarpinski]

Seems good. Would allow e.g. PolarComplex <: AbstractComplex to inherit most generic code.

[stevengj]

I'm not necessarily opposed to an abstract supertype per se, but polar representations are a poor motivation.

The possibility of internally representing complex numbers in polar or cartesian form is one of those shibboleths that OOP textbooks like to give as examples of abstraction, but which are never used in practice. The basic issue is that practically the only thing you would ever want to do with the polar representation is multiplication/division, but for these restricted operations a Number abstraction is not useful — you can and should just work with (r,φ) directly. You don't need or want an "internal" polar representation that is hidden by abstraction: you have to work with the polar form explicitly to ensure that the only operations you do on this format are multiplication and similar.

or in my case I would like to define a symbolic type for complex number, which will directly inherit most of the complex number interfaces and make a lot function "just work"

If you have a symbolic type for a real number that is a <: Real, then you can use it with the existing Complex type already. Or you can make your SymbolicComplex a subtype of Number (or Any), since virtually nothing will "just work" on a complex type that doesn't share the structure of Complex and doesn't represent a specific numeric value anyway.

I'd like to see a useful example of an alternative AbstractComplex subtype where nontrivial existing Complex code would actually work if it were changed to use the new type…

[Roger-luo]

Thanks for the comment @stevengj , the main motivation for me is the symbolic calculations. I just think other cases can also benefit from this.

If you have a symbolic type for a real number that is a <: Real, then you can use it with the existing Complex type already.

I actually tried this solution at first, but it seems not working so well, this is because expressions can be complex as well, and it might not be
able to be divided into 2 real symbolic expression easily (and not necessarily), it will be much easier to define the imaginary unit and merge similar terms when possible then tag the expression's domain. Handling the imaginary numbers with correct printing also seems to be painful with this solution.

Or you can make your SymbolicComplex a subtype of Number (or Any), since virtually nothing will "just work" on a complex type that doesn't share the structure of Complex and doesn't represent a specific numeric value anyway.

This is basically what I'm doing now, I made SymComplex and SymReal to be a symbolic tag of expressions, they will tag the expression's domain via type inference. so they will be treated correctly in practice, however since I cannot define SymComplex <: AbstractComplex, this means in practice other packages (like our own) which contains boundary constrains on Complex won't work but it should work in principal, a simplified version:

struct ArrayReg{B, T<:Complex, MT <: AbstractMatrix{T}} <: AbstractRegister{B}
   # blabla
end

(we don't actually do type checks here, but in constructors) and if I feed my symbolic complex number, it will give me warnings saying this is not a complex number currently, which is not very elegant.

or another case here: https://github.com/QuantumBFS/YaoBlocks.jl/blob/cc3344559ae7ac8bde7d293ddadb054ac8a4e0f3/src/primitive/reflect_gate.jl

the point is existing Complex do not actually allow users to define a generic upper bound of the desired complex type if we consider there are things like symbolic complex numbers. It limits the possibility of extending this object.

[stevengj]

If a function specifies T <: Complex, and cannot handle T <: Number, then it is hard for me to imagine that any nontrivial code would actually support a totally different symbolic complex-number type. If the code does support your symbolic complex type, then it would probably support Number as well and should be widened accordingly.

e.g. in the quantum code you linked, if it is generic enough to handle your symbolic type, then arguably it is also generic enough to handle e.g. quaternion quantum states and should be widened to Number.

[Roger-luo]

So do you suggest we could use Number as some sort of AbstractComplex here? if

If a function specifies T <: Complex, and cannot handle T <: Number, then it is hard for me to imagine that any nontrivial code would actually support a totally different symbolic complex-number type.

I think we add that <:Complex bound mainly because we wanted a complex domain upper bound just for readability it work for Number indeed.

[JeffBezanson]

Triage is ok with this. Adding the type seems harmless enough. Adding a pure imaginary type is one possible application.

The tricky part of this is going through and figuring out which methods in Base could apply to AbstractComplex. It's nontrivial, since presumably every AbstractComplex type can implement reim but that doesn't necessarily mean the method is useful (a loose analogy perhaps is calling dense matrix fallback implementations on sparse arrays).

[MasonProtter]

I don't think Number is a good substitute for AbstractComplex because one can imagine wanting to write a f(::AbstractComplex) that doesn't work on say Quaternions or CliffordNumbers.

[StefanKarpinski]

This is tentatively approved but there is work to do to move it forward: someone needs to go through the various method definitions for Complex and decide which ones are specific to the concrete Complex type and which ones are applicable to AbstractComplex.

[baggepinnen]

I would like to implement a type ComplexParticles <: AbstractComplex that internally represents the number as a collection of samples from a distribution. This already works very well for real numbers in MonteCarloMeasurements.jl, but all the code generation there assumes that
Particles{T} <: Real and T<: Real such that every function that accepts a particle type also accepts one of its internal samples. If I represent this as Complex{Particles{T<: Real}} I need to reimplement a lot of functions, and the reverse Particles{Complex{T}} does not work as it violates the assumption that Particles and its samples are the "same" type.

[StefanKarpinski]

That's an interesting use case. The path here is open:

someone needs to go through the various method definitions for Complex and decide which ones are specific to the concrete Complex type and which ones are applicable to AbstractComplex.

To be clear, I'm not aware of anyone who is currently planning on doing this, so if someone wants an AbstractComplex type they should perhaps work on this.

[MasonProtter]

I'm interested in working on this. I'll try to open a PR sometime in the next week.