# Rename Complex2n to Complexn?

**URL:** https://discourse.julialang.org/t/rename-complex2n-to-complexn/6081
**Category:** Internals & Design
**Created:** [September 26, 2017, 11:28am UTC](https://discourse.julialang.org/t/rename-complex2n-to-complexn/6081 "2017-09-26T11:28:08Z")
**Posts on this page:** 7
**Page:** 1

<div class="post-metadata">

### Author: ![rfourquet](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/rfourquet/32/3610_2.png) [@rfourquet](https://discourse.julialang.org/u/rfourquet)
#### Post date: [September 26, 2017, 11:28am UTC](https://discourse.julialang.org/t/rename-complex2n-to-complexn/6081/1 "2017-09-26T11:28:08Z")

</div>

I have always been bugged by the names `Complex128 = Complex{Float64}`, etc, as there is always (probably because I’m not a heavy user) a tiny mental step to divide the number to know the actual precision (64 bits for Complex128). I would find it clearer to have `Complex64` meaning `Complex{Float64}`, so that the number indicates directly the float type used. Also, it seems more scalable: `Quaternion256` starts to be unreadable, let alone `Octonion512`. My concern is also that it makes a precedent for naming things, like `Point3d_192 = Point3d{Float64}`; but imho, 192 carries much less interesting information (“192 bits are used in total”) than 64 (“coordinates are encoded as `Float64`”).  
What do you think about deprecating those alias, and later on defining `Complex64 = Complex{Float64}`, etc ?

---

<div class="post-metadata">

### Author: ![ExpandingMan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/expandingman/32/866_2.png) [@ExpandingMan](https://discourse.julialang.org/u/ExpandingMan)
#### Post date: [September 26, 2017, 2:22pm UTC](https://discourse.julialang.org/t/rename-complex2n-to-complexn/6081/2 "2017-09-26T14:22:30Z")

</div>

As far as I know, currently it is the case that all `isbits` types in Julia that have names indicating the number of bits have names indicating the _actual_ number of bits. `Complex{Float64}` _really is_ a 128 bit object. I think it would be confusing if some types had names indicating the actual number of bits, but other types had names indicating the number of bits of one of their fields.

---

<div class="post-metadata">

### Author: ![rfourquet](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/rfourquet/32/3610_2.png) [@rfourquet](https://discourse.julialang.org/u/rfourquet)
#### Post date: [September 26, 2017, 2:39pm UTC](https://discourse.julialang.org/t/rename-complex2n-to-complexn/6081/3 "2017-09-26T14:39:07Z")

</div>

I’m not aware of Base types _having_ fields which are named after their number of bits, except for `Complex`; the basic integer and float types are `primitive type` and have no fields, so they are not fully on the same level as `Complex`. But if the proposal seems confusing, I would actually also be fine with only deprecating `Complex128` etc. without adding later `Complex64 = Complex{Float64}`.

---

<div class="post-metadata">

### Author: ![Keno](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/keno/32/285_2.png) [@Keno](https://discourse.julialang.org/u/Keno)
#### Post date: [September 27, 2017, 6:28pm UTC](https://discourse.julialang.org/t/rename-complex2n-to-complexn/6081/4 "2017-09-27T18:28:04Z")

</div>

I’m mildly in favor of getting rid of these, if only because `Complex128` is ambiguous, since any eltype with 64bit size (e.g. Int64) will give you a Complex type of size 128.

---

<div class="post-metadata">

### Author: ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)
#### Post date: [September 27, 2017, 9:07pm UTC](https://discourse.julialang.org/t/rename-complex2n-to-complexn/6081/5 "2017-09-27T21:07:54Z")

</div>

Historically, the `Complex128` type actually preceded `Complex{Float64}` — it was originally a bits type because Julia didn’t have immutable types. ([https://github.com/JuliaLang/julia/issues/13](https://github.com/JuliaLang/julia/issues/13))

So, at this point, deprecating `Complex128` makes a lot of sense.

---

<div class="post-metadata">

### Author: ![tobias.knopp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tobias.knopp/32/7551_2.png) [@tobias.knopp](https://discourse.julialang.org/u/tobias.knopp)
#### Post date: [September 27, 2017, 9:43pm UTC](https://discourse.julialang.org/t/rename-complex2n-to-complexn/6081/6 "2017-09-27T21:43:34Z")

</div>

`complex128` and `complex64` are also present in numpy. So there is some more history than just Julia for these primitives

---

<div class="post-metadata">

### Author: ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)
#### Post date: [September 27, 2017, 10:36pm UTC](https://discourse.julialang.org/t/rename-complex2n-to-complexn/6081/7 "2017-09-27T22:36:20Z")

</div>

Note that in NumPy they are a primitive type, for performance reasons, and the name reflects that. In Julia this is not the case, and the name is a historical artifact.

(However, I agree that using `Complex32` for `Complex{Float32}` could add to the confusion. Better to drop the aliases entirely.)
