-
Notifications
You must be signed in to change notification settings - Fork 175
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[c++] qvector initialization from vector of doubles fails for f32 simulator #1670
Closed
4 tasks done
Comments
schweitzpgi
added a commit
to schweitzpgi/cuda-quantum
that referenced
this issue
May 14, 2024
It may be the case that the state vector data is in a precision that does not match that of the simulator. The runtime library knows precisely what simulator has been selected and can therefore convert the state vector to the expected format at runtime. This conversion may be *expensive* if the state vector is quite long. As a result, the runtime may want to emit a warning when a conversion path is taken. The following conversions happen at runtime with this change: vector<float> -> vector<complex<float>> vector<float> -> vector<complex<double>> vector<double> -> vector<complex<float>> vector<double> -> vector<complex<double>> vector<complex<float>> -> vector<complex<double>> vector<complex<double>> -> vector<complex<float>> If the input is vector<complex<float>> or vector<complex<double>> and the simulator's precision is a precise match, no conversions or runtime overhead is incurred. Fix NVIDIA#1670
schweitzpgi
added a commit
to schweitzpgi/cuda-quantum
that referenced
this issue
May 15, 2024
It may be the case that the state vector data is in a precision that does not match that of the simulator. The runtime library knows precisely what simulator has been selected and can therefore convert the state vector to the expected format at runtime. This conversion may be *expensive* if the state vector is quite long. As a result, the runtime may want to emit a warning when a conversion path is taken. The following conversions happen at runtime with this change: vector<float> -> vector<complex<float>> vector<float> -> vector<complex<double>> vector<double> -> vector<complex<float>> vector<double> -> vector<complex<double>> vector<complex<float>> -> vector<complex<double>> vector<complex<double>> -> vector<complex<float>> If the input is vector<complex<float>> or vector<complex<double>> and the simulator's precision is a precise match, no conversions or runtime overhead is incurred. Fix NVIDIA#1670
schweitzpgi
added a commit
to schweitzpgi/cuda-quantum
that referenced
this issue
May 15, 2024
It may be the case that the state vector data is in a precision that does not match that of the simulator. The runtime library knows precisely what simulator has been selected and can therefore convert the state vector to the expected format at runtime. This conversion may be *expensive* if the state vector is quite long. As a result, the runtime may want to emit a warning when a conversion path is taken. The following conversions happen at runtime with this change: vector<float> -> vector<complex<float>> vector<float> -> vector<complex<double>> vector<double> -> vector<complex<float>> vector<double> -> vector<complex<double>> vector<complex<float>> -> vector<complex<double>> vector<complex<double>> -> vector<complex<float>> If the input is vector<complex<float>> or vector<complex<double>> and the simulator's precision is a precise match, no conversions or runtime overhead is incurred. Fix NVIDIA#1670
schweitzpgi
added a commit
to schweitzpgi/cuda-quantum
that referenced
this issue
May 16, 2024
It may be the case that the state vector data is in a precision that does not match that of the simulator. The runtime library knows precisely what simulator has been selected and can therefore convert the state vector to the expected format at runtime. This conversion may be *expensive* if the state vector is quite long. As a result, the runtime may want to emit a warning when a conversion path is taken. The following conversions happen at runtime with this change: vector<float> -> vector<complex<float>> vector<float> -> vector<complex<double>> vector<double> -> vector<complex<float>> vector<double> -> vector<complex<double>> vector<complex<float>> -> vector<complex<double>> vector<complex<double>> -> vector<complex<float>> If the input is vector<complex<float>> or vector<complex<double>> and the simulator's precision is a precise match, no conversions or runtime overhead is incurred. Fix NVIDIA#1670
schweitzpgi
added a commit
that referenced
this issue
May 16, 2024
…1680) * Fix mismatches between input state and simulation engine precision. It may be the case that the state vector data is in a precision that does not match that of the simulator. The runtime library knows precisely what simulator has been selected and can therefore convert the state vector to the expected format at runtime. This conversion may be *expensive* if the state vector is quite long. As a result, the runtime may want to emit a warning when a conversion path is taken. The following conversions happen at runtime with this change: vector<float> -> vector<complex<float>> vector<float> -> vector<complex<double>> vector<double> -> vector<complex<float>> vector<double> -> vector<complex<double>> vector<complex<float>> -> vector<complex<double>> vector<complex<double>> -> vector<complex<float>> If the input is vector<complex<float>> or vector<complex<double>> and the simulator's precision is a precise match, no conversions or runtime overhead is incurred. Fix #1670 * Remove c++20 code. Wheel builder was choking on it. * Add test from issue.
Update: looks like the code generates unexpected results now, after the PRs above:
Expected: 2 |
@annagrin Is this still an issue or can it be closed? |
This looks like it is working correctly to me now. The above example now returns:
Any objections to closing this @annagrin? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Required prerequisites
Describe the bug
Running
Running this example on a f32 simulator results in a runtime failure:
nvq++ --enable-mlir -v from_state.cpp -o temp && ./temp
MLIR
cudaq-quake -D CUDAQ_SIMULATION_SCALAR_FP32 from_state.cpp |cudaq-opt
Steps to reproduce the bug
nvq++ --enable-mlir -v from_state.cpp -o temp && ./temp
Expected behavior
Qvector
constructor should copy and cast the initializer data to the data types matching the simulation precision, so the example should complete successfullyIs this a regression? If it is, put the last known working version (or commit) here.
Not a regression
Environment
Suggestions
No response
The text was updated successfully, but these errors were encountered: