TranspilerError with Unconventional Physical Qubit Indices in Layout #13536
Comments
|
Why would we add an option to pass bad types into the transpiler? This kind of error is exactly protection against things going wrong more mysteriously further down - good library design doesn't have type checking within every single function, it normalises user input as it's encountered, then can assume the invariants that were enforced once, rather than wasting the user's time doing it over and over. These "unconventional" physical indices are simply incorrect physical indices per Qiskit's data model, which specifies that physical qubit indices in a layout are the integers 0 to n-1. The message can potentially be improved slightly, but the error is correct. The standard way to pass Fwiw, it's not necessarily good practice for a Python project to optimise for somebody "stress testing" the input types to every function. The allowed types are documented, and typically you should use static code analysis like Mypy to check typing correctness, not expect that every function spends runtime enforcing it - this penalises the happy paths for mistakes that are mostly only made deliberately (as you are), or are obvious as soon as the first exception is raised. |
|
I really appreciate the insight into Qiskit’s design philosophy. It makes sense that the focus is on performance and optimising for the “happy path,” which I’m sure is what the majority of users need. That said, since we’re a group of academic researchers stress testing the framework (definitely not the “typical user” 😅), we’re deliberately pushing edge cases to test how robustly unexpected inputs are handled. I also appreciate you mentioning that By the way, could you point us to the documentation you mentioned about the allowed types for Thanks again for all your time and effort - it’s clear a lot of thought goes into making Qiskit work so well, and these discussions help us better understand the design choices. |
|
Exploring hyperparameters is a common practice in software engineering methods, not only in the context of reliability and security but also for methods like search-based optimization and genetic algorithms. Consequently, knowing sensible values for these parameters is crucial for automating optimization processes. In this case, it would be helpful if documentation clarified the following:
Additionally, support for a wider range of "good values," even those less commonly used, will be super useful for such methods. |
|
When you're deliberately pushing incorrect types, it's worth considering whether these are things that are actually likely to occur by mistake, or whether they're only going to happen if somebody does it deliberately very wrong, and what it would cost to insert checks in those situations. Python as a language is almost always used via an interpreter, and the typing is highly dynamic. This means it's always going to be possible to pass something bad to a function, whereas in a static and strict type system, a compiler might reject it from even building. We don't have that luxury in Python, so any time we want to do a type check, we have to trade off the fact that it needs to happen at run-time, not compile-time, so it penalises all users, even ones who are following the documentation. We typically make this trade-off by ensuring that high-level user-facing functions normalise and type check inputs (directly with (edit: this comment is mostly in response to the bits about typing, not the bits about using the correct types but passing invalid values in those - it's a problem when we don't gracefully handle values of a type without warning.) |
|
@karineek: what hyperparameters are you referring to? Physical qubit indices aren't "parameters" to be tuned, they're labels for the actual qubits that exist on a physical device. Similarly, what "wider range of good values" are you meaning here? The allowed values are "however many physical qubits the device has", a I agree that the documentation of the Documentation of the I suspect that the main trouble here is actually that nothing is (directly) checking that |
|
From a software engineering perspective, all interface parameters, including Layout indices (also circuit size etc), are subject to auto-exploration. There are three points here: documentation, simulator support and what is sensible for the hardware. I struggle with the documentation and the simulator, as it is unclear for example if 50, or 100 is a good number. At some point, maybe a bit above the currently known hardware limit, the value is no longer sensible, but this is exactly what we are missing here. I think 30 is a conservative value and not the actual possible max value. On a GPU, I know it is around 40-50, but this can change at any time. |
|
Yes, you are entirely free to explore changing the values you pass in and auto-optimising those, just like lots of successful projects have done using Qiskit. The maximum number of qubits reported by the simulator is set by the simulator. The example above instantiated a CPU-bound, RAM-based statevector simulator, and will have determined the maximum number of qubits based on those constraints. If you'd instantiated a different simulator, the constraints would have been different, because it would have been a completely different device. You can see what number of qubits the backed supports by looking at the If you used, for example, Beyond that, your inputs to The transpiler is entirely correct to raise an error in the example given at the top. The only real troubles that I see are that the error message could be clearer and have happened sooner in the pipeline, and that we don't have a huge amount of centralised documentation about the common data representations of the transpiler. Both of those can be improved. |
|
Thanks for the detailed explanation! I think adding a check much earlier sounds like a good solution. More specific documentation is super useful especially since the analysis of these documents commonly is done by Gen-AI tools, which might miss the context you added here. In the end, we are trying to build models that can sensibly explore these systems. |
Environment
What is happening?
Providing unconventional physical qubit indices (e.g., -1, 1000000000) in the initial_layout for stress testing results in a TranspilerError without a clear explanation. The error states that the layout is “not full,” which is misleading as all virtual qubits are mapped. This behaviour limits testing scenarios where users intentionally supply extreme indices.
Full Traceback:
How can we reproduce the issue?
What should happen?
Any suggestions?
The text was updated successfully, but these errors were encountered: