un complex returns real and imaginary parts in opposite orders in array

[aoanla]

In uiua 0.17.2, trying to "un complex" an array of complex values returns two arrays with opposite ordering - the real parts are ordered correctly as in the source array, but the imaginary parts are in reverse order.
This means that "complex un complex" is not an identity operation!

Example:

°ℂ[¯0.5+0.8660254037844387i ¯0.5-0.8660254037844387i 1]

output:
[¯0.5 ¯0.5 1]
[0 0.8660254037844387 ¯0.8660254037844387]

and thus doing

ℂ°ℂ[¯0.5+0.8660254037844387i ¯0.5-0.8660254037844387i 1]

results in
[¯0.5 ¯0.5+0.8660254037844387i 1-0.8660254037844387i]

[aoanla]

Ah, no, I see: this is actually a problem with uiua's repl and how it handles cut-and-paste of complex-valued arrays.
It seems like (even though this is how uiua itself returns and represents complex values), the parser actually interprets the array as an array of the values -0.5 , 0.866...i-0.5, -0.866...i+1 rather than what they actually were calculated as.

[kaikalii]

The parser doesn't use the notation with + and -. Those get read as their normal dyadic function meaning.
What you likely wanted was [¯0.5r0.8660254037844387i ¯0.5r¯0.8660254037844387i 1].

Whether the number should be printed that way instead is another matter.

[aoanla]

There's definitely a bug somewhere here - I agree that the bug is probably in the repl output. It feels wrong that the repl's output isn't parsable by it!

[kaikalii]

Consider stuff like

°△2_3

╭─       
╷ 0 1 2  
  3 4 5  
        ╯

The parser doesn't parse that. Output is formatted for human reading, not for plugging back into the interpreter. If that's something you want, use repr.

[aoanla]

Sure, however, I think the special case of complex numbers (which are just pairs) probably justifies a "cut-and-pasteable" representation in the repl output - unlike matrices, there's always just 2 values in a complex pair, so the representation is never going to be "unwieldy" or hard for a human to interpret. (It also serves as a reminder to someone who's learning the language how complex values should be represented - just as the pretty-printing echo of a line of input in the repl gives the mapping of the "long" forms of operators to their symbols.)
This is perhaps especially true because the current notation is interpreted differently, but without error messages, by the parser - whilst chucking a pretty-printed array back into the parser generates actual error messages.