Scientific notation in QASM output causes export to other platform to fail

RobertSchuh commented 1 year ago

Environment

Qiskit version: {'qiskit-terra': '0.24.0', 'qiskit-aer': '0.12.0', 'qiskit-ignis': '0.7.1', 'qiskit-ibmq-provider': '0.20.2', 'qiskit': '0.43.0', 'qiskit-nature': None, 'qiskit-finance': None, 'qiskit-optimization': None, 'qiskit-machine-learning': None}
Python version: 3.10.6
Operating system: Linux Mint

What is happening?

Exporting a circuit with small rotation gates through circuit.qasm() results in scientific notation being used. This causes issues when importing the QASM code into another quantum computing platform.

How can we reproduce the issue?

from qiskit import QuantumCircuit
qc = QuantumCircuit(1)
qc.rx(0.00001, 0)
print(qc.qasm())

output:

OPENQASM 2.0;
include "qelib1.inc";
qreg q[1];
creg meas[1];
rx(1e-05) q[0];
barrier q[0];
measure q[0] -> meas[0];

What should happen?

output:

OPENQASM 2.0;
include "qelib1.inc";
qreg q[1];
creg meas[1];
rx(0.00001) q[0];
barrier q[0];
measure q[0] -> meas[0];

Any suggestions?

The conversion from float to string happens in pi_check. The call is pi_check(0.00001, output="qasm", eps=1e-12) and returns '1e-05'.

mtreinish commented 1 year ago

I'd argue this actually a bug in the qasm 2 parser you're using. Scientific notation is listed in the qasm2 specification as a feature of the language for real numbers. If the other framework is erroring on that input it seems like an issue on their end. See: https://arxiv.org/abs/1707.03429 see page 5, it's in the footnote of scientific calculator features for real numbers.

jakelishman commented 1 year ago

Fwiw, scientific notation is allowed in OQ2, but due to (what I believe to be) an oversight in the formal grammar in the paper, 1e-5 is still technically not valid - all floats in OQ2 must have a decimal point by the letter of the spec. Our parser enforces that in "strict" mode, but allows it in the default permissive mode because I thought it was a needlessly pedantic distinction, and would lead to situations like this one.

Personally I think the right choice here is to get rid of pi_check from the OQ2 exporter - it does nothing but cause problems, really, and it's basically just a Qiskit-blessed numerical error in the output. I can see the function making some sense for visualisations, but not for this. Alternatively, it's possible to change the output format to always use at least 1 decimal point of precision.

Qiskit / qiskit