Proposal: Complex numbers

[gordanr]

This was previously requested in a comment on #11993, but now is this feature request submitted as a new issue.

Syntax

This proposal introduces in a language level a new keyword 'complex'. Imaginary unit could be written as 'i' and 'j' interchangeably.

Old style

Complex z1 = new Complex(2,3);
Complex z2 = new Complex(3.1,4.2);
Complex z3 = new Complex(0,3);
Complex z4 = new Complex(0,5);
Complex z5 = new Complex(2,0);

New syntax

complex z1 = 2 + 3i;
var z2 = 3.1 + 4.2j;
complex z3 = 3i;
var z4 = 5j;
complex z5 = 2;

One more example

Complex z1 = new Complex(5.1, -6.2) + 3.3 + new Complex(1.1, 2.1) + 4;

complex z1 = 5.1 - 6.2i + 3.3 + 1.1 + 2.1j + 4;

Motivation

There is important psychological reason for introducing complex numbers in language level. As I come from university circles, I can say that c# is not recognized enough as a language for scientific computation. You couldn't believe how many scientists and engineers (not professional programmers) use fortran and console applications.
(The second myth among scientists and engineers is using Linux instead of Windows for no good reason.)

[HaloFour]

The only way that I could imagine something like this working would be if i is treated as a literal type suffix for a complex imaginary number so that 5i would really be new Complex(0, 5). That would make 4 + 5i be equivalent to Complex.op_Addition(4, new Complex(0, 5)) which would produce the expected result. Otherwise I couldn't imagine the C# compiler attempting to treat the mathematical expression 4 + 5i as some kind of new literal.

Having two suffixes seems extraneous. Would electrical engineers be so offended that their preferred notation isn't supported that they would change their programming language? If so, we'd better also include type literal prefixes as 4 + i5 is also a commonly used notation.

As for the motivation, people use what they know and what their professor before them used. I don't believe for a moment that such a minor change such as this would have the slightest effect on that. I'm sure more of academia is also using Java, where the above examples would be a horrendous mess of nested parenthesized method calls.

[ViIvanov]

Why not
var z1 = 5.1 - 6.2i + 3.3 + 1.1 + 2.1j + 4;

[HaloFour]

While the proposal was already closed (due to a lack of lexical grammar) I'd rather go the same route as C++ and support custom literal suffixes:

To borrow from the syntax of that proposal:

public struct Complex {
    ...
    public static literal operator Complex i(double imaginary) {
        return new Complex(0.0, imaginary);
    }
}

and that would allow for:

var z1 = 5.1 - 6.2i + 3.3 + 1.1 + 2.1i + 4;

[HaloFour]

You also have the option of using extension methods:

public static class ComplexExtensions {
    public static Complex(this int real, int imaginary) {
        return new Complex(real, imaginary);
    }
}
...

var complex = 4.i(5);

[gordanr]

The only way that I could imagine something like this working would be if i is treated as a literal type suffix for a complex imaginary number so that 5i would really be new Complex(0, 5) . That would make 4 + 5i be equivalent to Complex.op_Addition(4, new Complex(0, 5)) which would produce the expected result. Otherwise I couldn't imagine the C# compiler attempting to treat the mathematical expression 4 + 5i as some kind of new literal.

I agree completely with you.

Would electrical engineers be so offended that their preferred notation isn't supported that they would change their programming language?

Of course, they wouldn't. It is not a must, but including 'j' side by side with 'i' would be really cool thing with a minimum effort. Something unique and recognizable among programming languages.

[gordanr]

I would also like to quote @svick's interesting approach to this topic.

static class ComplexConstants
{
    public static readonly Complex i = Complex.ImaginaryOne;
}

using static ComplexConstants; 

Complex z = 2.3 + 5.7*i;
Complex z = 5.7*i;

That means that we have 4 notations.

var z = 4.i(5);
var z = 4 + 5*i;
var z = 4 + i5;

var z = 4 + 5i; // This proposal

[miloush]

Why not quaternions?

[miloush]

While I agree that @svick's solution is elegant, it is conflicting with a variable name frequently used for iterations...

[gordanr]

Why not quaternions?

Good question. Why not? Then we couldn't use 'j' as imaginary part. 😃

[dsaf]

User-defined literals would potentially be a good fit: #263.

[gafter]

We are now taking language feature discussion in other repositories:

• https://github.com/dotnet/csharplang for C# specific issues
• https://github.com/dotnet/vblang for VB-specific features
• https://github.com/dotnet/csharplang for features that affect both languages

Features that are under active design or development, or which are "championed" by someone on the language design team, have already been moved either as issues or as checked-in design documents. For example, the proposal in this repo "Proposal: Partial interface implementation a.k.a. Traits" (issue 16139 and a few other issues that request the same thing) are now tracked by the language team at issue 52 in https://github.com/dotnet/csharplang/issues, and there is a draft spec at https://github.com/dotnet/csharplang/blob/master/proposals/default-interface-methods.md and further discussion at issue 288 in https://github.com/dotnet/csharplang/issues. Prototyping of the compiler portion of language features is still tracked here; see, for example, https://github.com/dotnet/roslyn/tree/features/DefaultInterfaceImplementation and issue 17952.

In order to facilitate that transition, we have started closing language design discussions from the roslyn repo with a note briefly explaining why. When we are aware of an existing discussion for the feature already in the new repo, we are adding a link to that. But we're not adding new issues to the new repos for existing discussions in this repo that the language design team does not currently envision taking on. Our intent is to eventually close the language design issues in the Roslyn repo and encourage discussion in one of the new repos instead.

Our intent is not to shut down discussion on language design - you can still continue discussion on the closed issues if you want - but rather we would like to encourage people to move discussion to where we are more likely to be paying attention (the new repo), or to abandon discussions that are no longer of interest to you.

If you happen to notice that one of the closed issues has a relevant issue in the new repo, and we have not added a link to the new issue, we would appreciate you providing a link from the old to the new discussion. That way people who are still interested in the discussion can start paying attention to the new issue.

Also, we'd welcome any ideas you might have on how we could better manage the transition. Comments and discussion about closing and/or moving issues should be directed to #18002. Comments and discussion about this issue can take place here or on an issue in the relevant repo.

---

I have not moved this feature request to the csharplang repo because I don't believe it would ever rise in priority over other requests to be something we would ever do in any particular release. However, you are welcome to move discussion to the new repo if this still interests you.