Display complex numbers - alignment

[strickek]

Actual for Complex[Float64] the decimal of the real part is used as anchor (whole imaginary part right of it), complex without decimal are printed like pre-decimal places:

For complex numbers I suggest to use the sign of the imaginary part as anchor, so the example above would look this way:

Code for example:
DataFrame(Test_Integer=[123+5im, 45-56im, 1-234im], Test_Float=[1.234+2.3im, 12.1-23.4im, 1.3-1.456im], Test_Number=Number[12.1-23.4im, 1//3+4//5im, 45-56im])

[bkamins]

The corner case is bare im which is valid:

julia> true*im
im

julia> im
im

but I guess that could be handled.

Also I guess we can ensure handling of of complex alignment for columns that have complex eltype (possibly a union with Missing). For non-concrete cases like Number I would leave things as they are (as such column can mix values of various types).

[ronisbr]

Ok! It should be easy (except for the missing part).

[ronisbr]

Well, we can do this:

1. For columns that are Complex, use this regex: (?<!^)[+|-]
2. For columns that are AbstractFloat, use this regex: \.
3. For columns that are Integer, do not use regex.
4. For columns that are Number, use this regex: (?(?=(.*im$))(?<!^)[+|-]|\.)

The idea here is to avoid the last regex as much as we can. It uses conditionals and lookbehind, which tends to be very slow.

Using this selection of regexes, we have:

julia> DataFrame(Test_Integer=[123+5im, 45-56im, 1-234im], Test_Float=[1.234+2.3im, 12.1-23.4im, 1.3-1.456im], Test_Number=Number[12.1-23.4im, 1//3+4//5im, 45-56im])

julia> a = Union{Missing, Number}[im, 1 + im, -1 - im, 1.123 + 123im, -2.323 - 32im, -1//3 - 4//5im,  1028.23123, missing, randn(), 2123123, rand()];

julia> b = [10^(i-1) for i = 1:11];

julia> c = [i == 5 ? missing : 10.0^(i-4) for i = 1:11];

julia> DataFrame(a = a, b = b, c = c)

Notice that this is the best I can do at the moment with the im.

[ronisbr]

Oops, I forgot that we can have 1e-5 + 1im. Hence, I need to check if the signal is also preceded by e.

[ronisbr]

Done! I really need help testing this new algorithm to check if all corner cases were handled.

[bkamins]

@ronisbr - thank you for working on this. I will have a look at the branch in more detail later this week. My fear is to avoid making a super complex algorithm for the case that is very rarely needed, so @strickek - could you please have a look at #2756 also and comment which cases are actually useful in practice? Thank you!

[ronisbr]

My fear is to avoid making a super complex algorithm for the case that is very rarely needed

I fully understand your concern. In fact, using those complex regexes can backfire if we did not see a corner case. The biggest problem is that it can affect things that are working. That's why I split the regex depending on the column specialization.

[bkamins]

Agreed - let us wait for @strickek to comment what is really needed and minimize the changes I think (otherwise in 5 years no one will understand the logic we have here).

[ronisbr]

IMHO the alignment of complex numbers can be kept. It is contained for columns that are <:Complex. However, what really scares me is the alignment of Number. We have two options:

1. If the column is <:Number, but it is not <:Real, just align the numbers to the right.
2. If the column is <:Number, align to the decimal point if it exits.

The latter is the current version, but it does has problems if the column contains complex numbers.

[bkamins]

I would go for:

If the column is <:Number, but it is not <:Real, just align the numbers to the right.

[strickek]

I agree. Number was from an old test. <complex is ok.

[strickek]

I agree number is not necessary, so I would also skip case nr 4). Thank you for your fast solution.

[ronisbr]

OK! I will change the PR.