Wikifunctions:Type proposals/complex128

Summary

A complex128 is simply a pair of float64.

Uses

Structure

Either stored as a pair of float64, or as a string. If the latter, we also need to consider whether to use i or j to represent the imaginary unit.

Example values

Value 0

{
  "type": "complex128",
  "real part": {
    "type": "float64",
    "value": "0.0"
  },
  "imaginary part": {
    "type": "float64",
    "value": "0.0"
  }
}

{
  "Z1K1": "Zxx",
  "ZxxK1": {
    "Z1K1": "Zyy",
    "ZyyK1": "0.0"
  },
  "ZxxK2": {
    "Z1K1": "Zyy",
    "ZyyK1": "0.0"
  }
}

Persistent objects

At least we should have an object for i.

Validator

The validator ensures that:

real part and imaginary part are valid float64

Identity

Converting to code

Python

For example: (3+5j).imag=5.0

JavaScript

JavaScript does not natively support complex number, so we have to represent it as an object.

Renderer

We can display it as a+bj format.

Parsers

First extract a and b (we may also have a-bj or only bj), then parse a and b as float64.

Alternatives

We can have a general type for complex number whose real and imaginary part are specific number type. This can be used to express e.g. Gaussian integer.
Another common representation of a general complex number is with a modulus (distance from 0 on the imaginary plane) and an argument (angle from 0 to 2pi, going anticlockwise from the real axis). This would suit some applications better.

Comments

Support Useful, but let's revisit this once we have float64 working well. --99of9 (talk) 02:38, 19 June 2024 (UTC)[reply]
Updating this to say that while float64 is generally working, it still has two changes that should be made before other types like this one rely on it: dealing with subnormals, and matching the IEEE values for the ignored keys of special values. --99of9 (talk) 03:35, 17 June 2025 (UTC)[reply]
Oppose, see my comment on the float type proposal. Basically, I'd like to find a way to represent these all-in-one. Feeglgeef (talk) 00:51, 1 December 2024 (UTC). I've long been partial to the rational type, I would prefer having a complex rational type first, as more numbers can be represented this way. Feeglgeef (talk) 02:35, 1 March 2025 (UTC)[reply]
I think it's a good time to restart this conversation, since floats now here. My question is: do we prefer to have float-based complex numbers or rational-based complex numbers, or both? --Denny (talk) 14:34, 7 February 2025 (UTC)[reply]
Support complex numbers --Ameisenigel (talk) 20:08, 7 February 2025 (UTC)[reply]
Thanks, agreed, but with two Z20838 or two Z19677? --Denny (talk) 07:31, 8 February 2025 (UTC)[reply]
Not sure about this, both have pros and cons. --Ameisenigel (talk) 18:56, 8 February 2025 (UTC)[reply]
Support This should be useful. I think float64 is a decent type for this, using rational numbers seems like it would be situational. Also, not sure about displaying i as j. I know Python does it that way and it's some engineering notation but practically everything everywhere uses i. Looking around, people seeing i displayed as j in Python seems to elicit confused reactions ("why is the suffix j instead of i?") because everyone familiar with imaginary numbers knows that it's not usually represented that way. I'm aware that Python is one of the languages this would be implemented in, but I'd much prefer if we went with the most consistent and highly-used notation rather than one that aligns with the syntax of one language. On the subject of having a type-independent implementation that has number types specified manually; this could be useful, but I think the tedium of specifying the type for each operation outweighs any drawbacks of just assuming the best type (float64, IMHO) and sticking to that consistently. — rae <talk> 17:13, 28 February 2025 (UTC)[reply]
I definitely agree it should be a+bi, the Wikipedias definitely have a very strong consensus that i is correct here. I disagree that float is better because float64 is very arbitrary and IIRC the consensus at the time was that float64 should only be used if a) the function needs to use irrational numbers, b) it was a technical function related to float64. Additionally, the long-held consensus has been that we don't bend to arbitrary limits, we've ignored the Javascript maximum safe integer, ignored the python date limit, and always gone with the solution that gives greater support. Feeglgeef (talk) 02:39, 1 March 2025 (UTC)[reply]
To be frank, I am just not very used to the concept of representing numbers in computers fractionally at all, and I apologize for being ignorant and choosing the "safe" option that I'm more familiar with. I'm aware you probably could represent any decimal without loss of precision with rational numbers up to a certain point by just writing out the decimal as the numerator and having the denominator be some multiple of ten, but the concept still feels unusual to me from a UX standpoint; although, if I had to decide on the question of which number type to use a month before now when you had to manually specify every parameter of floats yourself, I definitely would have argued for rational numbers. I am assuming that the operations done on these rational numbers are just basic maths to the point where they don't need to be converted to anything as an intermediary value and can have operations done on them atomically just as with any other type of number. My only concern is any extra overhead spent on the software/display strings simplifying the fractions and converting to them from decimal. I think most users, seeing a complex datatype, will want to use decimal input which is fortunately allowed in rational number inputs. However, I suspect those same people will likewise expect a decimal output, unless either half is an irrational number, like one-third and &c; although, judging from what you said, I don't know if rational numbers can even handle that sort of thing? Of course, as you said, we don't have to bend to arbitrary limits, and I would want to use a decimal number type that can represent precise numbers without loss of precision, but the n/d system of rational numbers is not something I'm familiar with, having always opted solely for double-precision and fixed-point numbers/arithmetic whenever I would need to represent fractional values in my code. This is just speaking from personal experience, though, and I'm not opposed to opting for this even if it's different in certain ways. — rae^5e <talk>
Support but point out that a complex number can have a polar form: the absolute value and the angle. Should we include it in this type somehow, or create a separate type? --Tohaomg (talk) 08:38, 3 May 2025 (UTC)[reply]
If it's just another representation it would be better served as a function that converts. Feeglgeef (talk) 22:54, 3 May 2025 (UTC)[reply]