# Improve \`parse\` to be able to handle complex numbers

**URL:** <https://discourse.julialang.org/t/improve-parse-to-be-able-to-handle-complex-numbers/4095>\
**Category:** Internals & Design\
**Tags:** proposal, complex-numbers\
**Created:** [June 5, 2017, 8:41pm UTC](https://discourse.julialang.org/t/improve-parse-to-be-able-to-handle-complex-numbers/4095 "2017-06-05T20:41:33Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![tparker](https://avatars.discourse-cdn.com/v4/letter/t/839c29/32.png) [@tparker](https://discourse.julialang.org/u/tparker)\
**Post date:** [June 5, 2017, 8:41pm UTC](https://discourse.julialang.org/t/improve-parse-to-be-able-to-handle-complex-numbers/4095/1 "2017-06-05T20:41:33Z")

</div>

As of v0.5.0, the `parse` command cannot directly handle string representations of complex numbers; e.g. `parse("1 + 2im")` returns an `Expr` data type. You can use `eval` to convert the expression to a `Complex{}` number, but I suspect there’s a decent amount of overhead here because the stored expression is rather complicated. Since complex numbers are low-level built-in data types, it might be nice if `parse` could handle them directly, without requiring `eval`.

---

<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:** [June 6, 2017, 1:38am UTC](https://discourse.julialang.org/t/improve-parse-to-be-able-to-handle-complex-numbers/4095/2 "2017-06-06T01:38:41Z")

</div>

Complex numbers are not “low-level built-in data types”. They are not part of the core language definition at all, in fact; the Julia parser knows nothing about them, which is why `parse("3+4im")` treats them as a generic expression. (A package could even redefine `im` to something else.) They are a component of the standard library implemented purely in Julia — you can see the entire implementation in [https://github.com/JuliaLang/julia/blob/master/base/complex.jl](https://github.com/JuliaLang/julia/blob/master/base/complex.jl)

One of the big strengths of Julia is that the core language is powerful enough to define something as “primitive” as complex numbers in pure Julia, and have it be fast and full-featured. This means that external packages can also define new fast, full-featured “primitive” types.

That being said, it would be useful and possible to implement `parse(Complex128, "3+4im")`. This is something that might be a good candidate for a package (ParseComplex?). Probably it would want to also support other common formats such as `3+4i` and `3+4j`. It would also be nice to have a `readcsv`-like function for comma-delimited complex numbers.

---

<div class="post-metadata">

**Author:** ![dlfivefifty](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dlfivefifty/32/1959_2.png) [@dlfivefifty](https://discourse.julialang.org/u/dlfivefifty)\
**Post date:** [June 6, 2017, 12:51pm UTC](https://discourse.julialang.org/t/improve-parse-to-be-able-to-handle-complex-numbers/4095/3 "2017-06-06T12:51:42Z")

</div>

> [@stevengj](#):
>
> It would also be nice to have a readcsv-like function for comma-delimited complex numbers.

Related issue: [readdlm does not support Complex · Issue #21935 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/issues/21935)

---

<div class="post-metadata">

**Author:** ![strickek](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/strickek/32/14885_2.png) [@strickek](https://discourse.julialang.org/u/strickek)\
**Post date:** [June 6, 2017, 1:27pm UTC](https://discourse.julialang.org/t/improve-parse-to-be-able-to-handle-complex-numbers/4095/4 "2017-06-06T13:27:32Z")

</div>

ReadWriteDlm2 will support this in the next Version for Julia 0.6. It is already implemented in the actual master:

[https://github.com/strickek/ReadWriteDlm2.jl](https://github.com/strickek/ReadWriteDlm2.jl)

---

<div class="post-metadata">

**Author:** ![lobingera](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/lobingera/32/211_2.png) [@lobingera](https://discourse.julialang.org/u/lobingera)\
**Post date:** [June 6, 2017, 2:22pm UTC](https://discourse.julialang.org/t/improve-parse-to-be-able-to-handle-complex-numbers/4095/5 "2017-06-06T14:22:41Z")

</div>

> [@stevengj](#):
>
> Complex numbers are not “low-level built-in data types”.

“Julia is a high-level, high-performance dynamic programming language for numerical computing.” → well…

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [June 6, 2017, 2:40pm UTC](https://discourse.julialang.org/t/improve-parse-to-be-able-to-handle-complex-numbers/4095/6 "2017-06-06T14:40:40Z")

</div>

I see no contradiction here. “Low-level builtins” are a small set of constructs that can be used to build up the language proper, which does of course include complex numbers. The fact that you can do this (and similarly for rationals, quantities with units, etc) makes the language not less, but more powerful.

Users need not care about what is a low-level builtin and what isn’t. The fact that they are not parsed directly is an orthogonal issue.

---

<div class="post-metadata">

**Author:** ![thofma](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/thofma/32/1691_2.png) [@thofma](https://discourse.julialang.org/u/thofma)\
**Post date:** [June 6, 2017, 5:10pm UTC](https://discourse.julialang.org/t/improve-parse-to-be-able-to-handle-complex-numbers/4095/7 "2017-06-06T17:10:09Z")

</div>

Since julia by default provides the constant `im` and you can do a simple `x = 3 + 2*im` anywhere, I think it is only consistent to have proper parsing built into julia and not in a package.

---

<div class="post-metadata">

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\
**Post date:** [June 6, 2017, 5:22pm UTC](https://discourse.julialang.org/t/improve-parse-to-be-able-to-handle-complex-numbers/4095/8 "2017-06-06T17:22:10Z")

</div>

> [@stevengj](#):
>
> One of the big strengths of Julia is that the core language is powerful enough to define something as “primitive” as complex numbers in pure Julia, and have it be fast and full-featured. This means that external packages can also define new fast, full-featured “primitive” types.
> 
> That being said, it would be useful and possible to implement parse(Complex128, “3+4im”). This is something that might be a good candidate for a package (ParseComplex?). Probably it would want to also support other common formats such as 3+4i and 3+4j. It would also be nice to have a readcsv-like function for comma-delimited complex numbers.

A package “can” do that, but it actually shouldn’t since that’s type piracy. `parse` is a Base function, and `Complex128` is a Base type, so packages shouldn’t be adding this dispatch. This is a job for Base.

---

<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:** [June 6, 2017, 5:37pm UTC](https://discourse.julialang.org/t/improve-parse-to-be-able-to-handle-complex-numbers/4095/9 "2017-06-06T17:37:01Z")

</div>

Good point, Chris. [https://github.com/JuliaLang/julia/issues/22250](https://github.com/JuliaLang/julia/issues/22250)

---

<div class="post-metadata">

**Author:** ![StefanKarpinski](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stefankarpinski/32/24_2.png) [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)\
**Post date:** [June 14, 2017, 7:27pm UTC](https://discourse.julialang.org/t/improve-parse-to-be-able-to-handle-complex-numbers/4095/10 "2017-06-14T19:27:33Z")

</div>

`3 + 4im` is not a literal syntax, it’s an expression involving two integer literals, a binding (`im`) that must be resolved in the evaluation context, multiplication (by juxtaposition) and an addition. Making `parse` produce a Complex value when parsing this expression completely ignores the fact that this expression can radically change meaning if any of `im`, `+` or `*` have different meanings in the context in which the expression is evaluated. That is not true of literal syntaxes like `3` – which is precisely the difference between a literal syntax and an expression. It would, however, be reasonable for `parse(Complex, "3 + 4im")` to work since the type argument determines the meaning of the expression. In that case, however, `+` and `im` and the juxtaposition would no longer mean what they mean in Julia, they would simply be part of a parsable literal syntax for complex numbers, which is independent of Julia’s syntax, but happens to coincide with it.