Mirror of forum.nim-lang.org

2461 :: Improved Complex number string representation

• didlybom (orginal) [2016-08-12T00:28:14+02:00] view original

  I find that the string representation of the complex numbers defined on the complex module could be improved. Currently they are just represented as tuples. Instead I think it would be much nicer if nim did an arithmetic representation (e.g. 1.5-2.2j). Do you think that would be a good idea?

  That is, rather than:

  
  proc `$`*(z: Complex): string =
    ## Returns `z`'s string representation as ``"(re, im)"``.
    result = "(" & $z.re & ", " & $z.im & ")"
  Run

  I'd prefer if nim did something like:

  
  proc `$`*(z: Complex): string =
    ## Returns `z`'s string representation (e.g. 2.1-1.3j).
    result =
      if z.im == 0.0:
        $z.re
      elif z.re == 0.0:
        $z.im & "j"
      elif z.im < 0.0:
        $z.re & "-" & $(-z.im) & "j"
      else:
        $z.re & "+" & $z.im & "j"
  Run

  This is what Python and tools such as Matlab do.

  Additionally it would be great if it were possible to use the same sort of representation in complex literals, e.g.:

  
  var a = 1.0+2.2j
  Run

  .

---

• mihirparadkar (orginal) [2016-08-28T05:15:28+02:00] view original

  Every language with complex number support seems to have its own representation of them.

  Python does

  1 + 2j
  Run

  R does

   0+1i
  Run

  Julia does

   0.0 + 1.0im
  Run

  Nim seems to follow the same convention as C++ std::complex with

  (0.0, 1.0)
  Run

  I don't know if one of those is inherently any better than another.

---

• didlybom (orginal) [2016-08-30T09:04:17+02:00] view original

  It is true that every programming language represents complex numbers differently. However most use a variation on the "mathematical representation" A + Bj (or A + Bi). Nim and C++ are a bit unique in this regard IMHO.

  I think that for a language that can be used for mathematical work, such as Nim, it does not make sense to follow C++'s lead here.

---

• Krux02 (orginal) [2016-08-30T12:01:24+02:00] view original

  I've learned that the tuple representation is equally correct as the term representation. And I do like the tuple representation, because printing complex numbers in terms don't need extra braces:

  
  echo complex1, "*", complex2
  # output A: (0.0, 1.0)*(1.0, 0.0)
  # output B: 0.0 + 1.0im*1.0 + 0.0im
  Run

  There is valid points for each representation, and in the end you can get used to any of them. So I don't see need for a change as long as there is not something wrong or inconsistent with this representation.

---

• smitty (orginal) [2016-09-01T21:07:40+02:00] view original

  To interop with c/fortran for blas/lapack, complex numbers need to be passed as array[2, float32|float64].

---

• Krux02 (orginal) [2016-09-01T21:22:40+02:00] view original

  @smitty, that has nothing to do with string representation. The complex numbers are internally nothing more than two numbers. So even though the type is different, it should be safe to simply cast from Complex to array[2, float]. But honestly, I just looked it up, I couldn't find any Complex32 or Complex64 type. I think, that would clearly be worth invenstigating.

---

• didlybom (orginal) [2016-09-02T11:36:11+02:00] view original

  @Krux02 I disagree with your assessment. It is true that both representation types (tuple and arithmetic) are valid. However one of them is much more used both in real life (i.e. people doing arithmetic on paper) and in those programming languages that have made good math support one of their key objectives.

  I think the "echo" advantage is quite minor, and is much less important that simply being able to view complex number using their usual "paper" representation. This is even more important now that there are projects to create a Jupyter nim kernel, for example.

---