proposal: spec: remove complex numbers

[bradfitz]

Go supports complex numbers, but ~nobody uses them.

The only thing complex numbers add to Go is their complexity to Go's runtime, compiler, and standard library.

I propose we remove them from Go 2.

[splace]

really it seems like its only the generics you really lose, going from builtin to std.lib (maybe some 'visibility', but complex users, seem to me, to be more likely to look for themselves.)

as for multidimensional arrays..

seems that builtin support is useful for standardization, (but being in std.lib. does that.) but also, as pointed out by sbinet, a single block of memory is efficient, AND if its also standardized, will then allow simple interfacing to a world of c mathematical code.

so for multidimensional array of complex....

for a memory block storage technique the data probably needs to be in one particular type, with a particular access structure, so for that it really makes sense for the complex maths to not be generic, which then removes to only reason to be builtin.

[wsc1]

there is also the gonum fourier package, go-dsp, software defined radio dsp, zikichombo/dsp,...

[talglobus]

Here's my 50 cents, hopefully worth more than that to most people:

Today, a Go project blog post was published giving us a defined set of criteria by which to consider potential changes, described as follows.

A proposal must at the very least:

1. address an important issue for many people,

2. have minimal impact on everybody else, and

3. come with a clear and well-understood solution.

Let's consider this proposal under these new guidelines. I'll address each of the above in order, by number.

1. There do seem to be a decent number of people interested in this proposal, with 53 comments so far, 89 upvotes, and 68 downvotes, making this the 12th most commented proposal out of the Go 2 issues list. There are two groups to be considered regarding positive impact, those working on the language and those working with the language, with the latter group significantly outnumbering the former. As mentioned repeatedly above, the presence of complex numbers in the language doesn't affect anyone who isn't using them as far as those working with the language is concerned. Regarding those working on the language, removing complex numbers could make maintenance of the language and standard library a little bit easier. However, we have to consider the balance of the former and latter groups, with the group helped being far smaller than the group being unaffected. So intriguing debate here, lots of interest, but fairly minimal positive impact. Half points for solving important, impactful problems

2. This criterion specifically addresses who is being harmed by the change, with the goal being to minimize this number. Again, impact is divided between those working on the language and those working with the language. On the user side, this change would clearly have a strong negative impact on those that use complex numbers. On the contributor side, no negative impact, and indeed a weak positive impact. But, the criterion is worded as "everybody else", lumping those working on the language in with those working with the language, with the latter group having, again, significantly more members. So, net impact is negative. No points for not being harmful

3. This criterion is the easiest. Moving complex numbers out of the language proper and into its own library is fairly simple, and quite elegant. There's definitely room for debate and tweaks as proven above, but overall, this has a clear and well-understood solution. Full points for solution clarity and completeness

The verdict? 1.5 out of 3. Not terrible, but not great either.

But to go a bit further and venture a few guesses about our beloved language and its users, let's speculate for a minute and consider not only current Go users, but future users as well. Given increasing demand for data science and other computation-heavy spaces within the software sector, there does seem to be a clear trend as far as the future of mathematical computation in software, for lack of a better term. This would seem to indicate that looking forward, we can only expect demand for features like complex numbers to be used more.

This is especially true considering that certain areas, like quaternion mathematics (mentioned above) are widely used in applying transformations to representations of objects in space, a cornerstone of graphics, gaming, and anything seeking to model the physical world. Additionally, complex numbers hold an important role in linear algebra, which underlies machine learning, and Fourier transforms, which form the foundation of signal processing and analysis. Therefore, it seems reasonable to posit that this change most likely stands to cast a stronger negative impact as time progresses, which is worrying.

Overall? It would seem we should leave complex numbers in.

[chipkent]

I have to say that the removal of complex numbers is a terrible idea. They are important for many areas of mathematical and scientific computing. At go's current stage, the necessary library support for doing mathematical, scientific, and AI computing is not there. (Tensorflow's second class go support is an example.) As a result, we should not expect the current usage of complex numbers to be high.

The number of relevant libraries has been increasing, and it is almost possible to get useful mathematical, scientific, or AI work done in go without having to construct all necessary libraries from scratch. In time, the libraries will exist, and scientific users will come. Complex numbers are an investment in that future.

Pulling complex numbers out and into a separate package is not a great solution. It leads to fragmented and incompatible packages, syntactically ugly code, and (often) less efficient executions. It is no accident that python and fortran have large user bases in the scientific community, even though they are poor languages -- they have native complex numbers.

[kortschak]

Removing complex numbers from the language will anger Z̢̢̟͖̹̰̣̦̫̖͍͉̳̹͚̫̰͎͕̰̱̮͇͍̟͓̹͓̦͇̫͔̗̩͓͖͕̘̖͎̘͔͓̠͙̺̭͈͓̼̳̩̪̦͉̞̗͖̝̠̠̮̲̟̟̦͎̗̜͇̺̝̜̭͚̦̦͚̞̜̭̙̺̠̟̙̙̟̻̩͓͕͖͓̫͓̳͎̦͔̺͔̲͕̝̜̣͉̝̟̞̱̱̭͈̼̻̻͍̰͍̰̼͚̻̬̼͉͕̪̦̯̳͙̘̬͚̣̬̮͕̩̭̺̳̺̣͉̜͍̪͙̹͓̙̹͙̼͉͔͈͖̫̩̞͔̗̠̾ͧ͢͠ͅͅͅâ̷̶̸̖̫͍̱̣̹̜̮̩̬̖̝͔̭̳̲̣̟̮̲̹̖̤̠̦͎̻̥͕̰̳͖̹̣̬̼̺̠̱̣̱̻͙͎̩̪̪̳̲͓͖̥̩̩̥͕̞̱͓̝̥̻̣͙̱̹̟͚͙̥̘̼̪̣͉̪̠̩͍͔̜͉̠̪͉͉̝̙̣͔̝̭̳̥̻̤̪̙͔̟̙̱͚̗̫͉̙̺̜̞͇̪̝̰̟̟̝̫̹̭̘͈̗͔̞̲̘͔̜͍̠̰͈͙̗̭̼̟̪̼̻̲̜̞̪̝̙̫͍̫̠̗̟̯̺̞͕̳̞̣̝̫̜̯̫̯͛̕ͅͅͅͅlͦ̾ģ́͞҉̜͇͓̭̙̲̲̪̤͉͙̭̥̞͓̖̙̬̯̯̫̥̣̜̱̲͈̻̞̻̪̝̜͙̠̥͍͚̙͈͕̮̪̥̭͉̜̖̟̲͖̬̺̱̝̩̠͍̞͉̯̤̰͔̰͇̰̭̣̝̗̘̦̦̤͖͔̝̜̼̬̱͙͉̖̹̳̼̝̯̻̬̦̣͉̬͔̹̫͓̣͔̮͈̟̗͎̰̘̼͈͔̣̭̹̬̞̪̤̹̳͚͙̫͈͕͉̙̪̥͖̙͓̝̣̻̣͇̜̟̹̯̞̠̤̗̹̮̭̳͔̹̘͙̠͎͓̭̬̗͇͚̱̦̥͙̘̭͓̱ͅͅo̫̫̞̘̯͎̙̲̹̬̺̙̥͖̥̬̰͈̲͍̜̗̹̝͇̘̬͉̥̯͈̝̤͈̜̜̦̥̻̝̥̙̰̥̜͖̱̰̺̠̻̤͉̳̰͈̣̱̗̣̘͚͖̼̟̻̦̟̬̖̼͔͓̱̖͈̜̯̗̜͎̝̥̹͇͚͉̩̲̖̞̗̮̬̭̟̘̝͓̫̖͙̻̖̠͔̤̰͈̹̭͔̳̣͓͉̙̼͕͙͙̺̞̗̘͙̠͇̪͚̙̖̱̦̥͚͓̠̤͚͓̟̫͉̭̲̭̻͎̝͓̫̭̝̣̪̭̠̤̫͚̬͈̙̳͖̪̲ͥ͂ͅͅͅͅͅ, or at least stop it from building.

[claperius]

Having complex numbers as first class citizens was a strong "pro Go" argument when I started learning a language. We have great https://www.gonum.org/ library, which depends on builtin complex numbers a lot. I think we should not make Go being narrowed to some specific domains.

[bradfitz]

Everybody is focusing on the "removing functionality" part of this bug and not the "it's weird that big.Int is in a library but complex is in the language" part. Ideally both would be in the library and both would be easy to use with nice syntax. (see "operator methods" references above)

It's my fault for writing the initial bug with so little detail. The audience I'd initially considered (Ian, Robert, et al) already knew the context.

[as]

Complex numbers in Go carry an implied algebraic representation (unlike a big integer working around hardware constraints).

Rather than ordered pairs z=(x,y), we write x+yi. This makes operations convenient.

Operator methods sound a lot scarier than complex numbers. Aside from any concerns about that:

How will operator methods allow x+yi? Specifically, what happens to the imaginary unit? How will go remove algebraic notation and still allow this algebraic notation to exist with operator methods?

[ianlancetaylor]

It's true that complex64 (and complex128) is an unusual type to have in the language. But it's here, and it's sometimes useful, and it's not that hard to learn. Removing it at this point will not be a significant improvement.