Re: Improved Complex number string representation

[didlybom]

@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.

Re: Improved Complex number string representation

[Krux02]

@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.

Re: Improved Complex number string representation

[smitty]

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

Re: Improved Complex number string representation

[Krux02]

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


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. 

Re: Improved Complex number string representation

[didlybom]

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.

Re: Improved Complex number string representation

[mihirparadkar]

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

Python does 


 1 + 2j

R does 


 0+1i

Julia does 


 0.0 + 1.0im

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


(0.0, 1.0)

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

Improved Complex number string representation

[didlybom]

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 & ")"


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"


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


.