DumpMachine output uses different ket symbols depending on the relative phase

[tcNickolas]

Describe the bug

DumpMachine uses different ket symbols for states with real and complex amplitudes. This happens both for full state simulator and for sparse simulator.

To Reproduce

The following code produces the following output on full state simulator:

use qs = Qubit[2] {
    H(qs[0]);
    Controlled Rx([qs[0]], (1.56, qs[1]));
    DumpMachine();
    ResetAll(qs);
}

The output for sparse simulator is the same, minus the basis state with zero amplitude.

Expected behavior

I expect DumpMachine to use the same ket symbol always, preferably the one that renders in the output (the one currently used for basis states with relative phase).

System information

• OS: Windows 11
• .NET Core Version: 6.0.400
• QDK version: 0.24.201332, 0.25.222597

[DmitryVasilevsky]

Please note that if you copy/paste this from the console to notepad, the symbols will appear correctly. This may be an issue with the way symbols are displayed. They are printed out by the same code on every line and for both real and complex amplitudes.

[billti]

Interesting. It does appear to be an issue with the old Windows console host. If I use the new Windows Terminal, I don't see an issue. (See screen shot below with Terminal app in the background, and old Console in the foreground, both running exactly the same project). I assume there is no issue on other OSes? (i.e. Mac or Linux)

I thought it might just be the non-Unicode code page used by default (e.g. see https://stackoverflow.com/questions/57131654/using-utf-8-encoding-chcp-65001-in-command-prompt-windows-powershell-window), but even changing that didn't help in the old console.

Being that the new Terminal app is the default on Windows going forward (see https://devblogs.microsoft.com/commandline/windows-terminal-as-your-default-command-line-experience/), I'm not sure how much time we should spend on this one.

[billti]

One last comment. Directing the output to file and examining in a hex editor, I can see the correct UTF-8 chars are in the output stream for all places the right angle bracket is emitted (i.e. e2 9f a9 - see table at the bottom of https://unicode-table.com/en/27E9/ ). As Dmitry already mentioned, pasting the text from the console where it is displaying incorrectly into notepad makes it appear correctly. (The fact the right bracket on |3> is showing correctly proves it is not a font issue). So looks like a bug in the old Windows Console, which will almost certainly not get fixed. Either we move to using a regular ASCII right bracket by default, or just recommend people use the new Windows Terminal for console execution.

[billti]

(Oh, and it looks fine in the VS Code terminal on Windows too)