# Wrong output from det(Array{Complex})
**URL:** https://discourse.julialang.org/t/wrong-output-from-det-array-complex/10022
**Category:** General Usage
**Tags:** linearalgebra
**Created:** [March 27, 2018, 10:18pm UTC](https://discourse.julialang.org/t/wrong-output-from-det-array-complex/10022 "2018-03-27T22:18:20Z")
**Posts on this page:** 1
**Showing post:** 12
### Author:  [@greg\_plowman](https://discourse.julialang.org/u/greg_plowman)
#### Post date: [March 31, 2018, 2:54am UTC](https://discourse.julialang.org/t/wrong-output-from-det-array-complex/10022/12 "2018-03-31T02:54:14Z")
> [@PetrKryslUCSD](#):
>
> Are you sure? I think 32 stands for the number of bits in both the real and imaginary parts.
> [@tkoolen](#):
>
> Ah, I guess this will be changed in 0.7 (ComplexF32 is not a thing in 0.6)
I think this has long been a source of ambiguity and confusion.
See discussion and PR:
> [@Rename Complex2n to Complexn?](https://discourse.julialang.org/t/rename-complex2n-to-complexn/6081):
>
> 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 nam…
>
>
> Cf. https://discourse.julialang.org/t/rename-complex2n-to-complexn/6081 for back…ground.
> Here is a recollection from this thread of 3 reasons to deprecate the \`ComplexN\` aliases:
>
> \- In \`Complex128\`, \`128\` refers to no semantic reality connected to the type. It only refers to the very low-level fact that it's its number of bits. Actually, in the initial discourse thread, I suggested renaming \`Complex128\` to \`Complex64\` with the idea "the coordinates of a \`Complex64\` is \`Float64\`", so there is a clearer connection between the 2 types.
> \- \`Complex128\` is ambiguous, since any eltype with 64 bit size (e.g. Int64) will give you a Complex type of size 128 (@Keno);
> \- Historically, the \`Complex128\` type actually preceded \`Complex{Float64}\` — it was originally a bits type because Julia didn’t have immutable types. So, at this point, deprecating \`Complex128\` makes a lot of sense (@stevengj).
---
_[View the full topic](https://discourse.julialang.org/t/wrong-output-from-det-array-complex/10022)._