Complex-valued variables

[projekter]

This is in conjuction with https://github.com/JuliaAlgebra/MultivariatePolynomials.jl/pull/213 and provides the DynamicPolynomials implementation of the complex-valued variable functionality.

[projekter]

Issue with sometimes working implementation for incomplete substitution (I just quote the code comment)

We may assign a complex or real variable to its value (ordinary substitution). We may also assign a complex value to its conjugate, or just the real or imaginary parts Any combination of z, conj(z), real(z), imag(z), imag(conj(z)) can occur in either the polynomial or the substitution, and we must handle all of them correctly. Note: This may or may not work... Issues can arise if the substitutions contain the real and imaginary (or only one of those) of a variable separately whenever vals is not of the correct type:

• Unless subs() originally had a polynomial-valued rhs, vals will be scalars, monomials, or terms. So when we try to assign a polynomial to its value (which is necessary, as the one-step substitution of only the real or only the imaginary part is incomplete), this is an impossible conversion.
• The coefficients in vals might not be complex-valued; but to assign only a part of the variable, we necessarily need to introduce an explicit imaginary coefficient to the value. Currently, we don't do anything to catch these errors.

Design question: With the new implementation, the "dynamic" part becomes slightly more "typed", as the variable and monomial ordering are now also part of the type. Still, the complex kind is a field instead of a type parameter. While I definitely would keep this to distinguish between the variable, its conjugate, its real and imaginary part (else all containers holding such variables would need to be abstract containers, making this very inefficient), it may be debatable whether the issue of "is this a complex type at all" should be encoded as a type parameter. Pro: Some replacements may be simpler to decide based on static dispatch. Con: Duplication of information; and mixing real and complex variables again has to fall back to a generic implementation.

[blegat]

Yes, I would definitely not incorporate whether it's a real, imaginary part etc... as type as it would disallow mixing different ones in a polynomial etc... About whether there should be a type for saying whether it was created with @polyvar and @polycvar, that would disallow mixing the two types of variables in the same polynomial for instance so that wouldn't be ideal right ?

[projekter]

This would depend on the actual implementation in Monomial. Combining both would still work if the vars vectors still only contained elements of type Variable{V,M}, not specializing the concrete complex type C. But then, this would be horribly inefficient as Julia would have to generate type checks and dynamic dispatches on every operation. So I agree this would be very "not ideal".

[blegat]

@projekter I forgot about this PR, we should merge it. I'll try to take a look next week, remind me if I don't

[projekter]

@blegat Here's a reminder