diff --git a/docs/choose_hw.md b/docs/choose_hw.md index 96721ed7..8f931082 100644 --- a/docs/choose_hw.md +++ b/docs/choose_hw.md @@ -73,7 +73,7 @@ backends and do not involve sampling bitstrings (i.e. no measure gates). For GPU-based simulations, you can either use qsim's native GPU backend or the NVIDIA cuQuantum backend. While the native qsim GPU backend is performant for extracting amplitudes of specific quantum states, it is not optimized for -sampling bitstrings, i.e. for simulating circuits that have measurement gates. For +sampling bitstrings, i.e., for simulating circuits that have measurement gates. For that purpose, cuQuantum performs significantly better. cuQuantum is also needed for multi-GPU support. More specifically, there are three options for GPU-based simulations: @@ -132,9 +132,9 @@ Alternatively, you can use your own hardware. Note the [hardware requirements](https://docs.nvidia.com/cuda/cuquantum/getting_started.html#custatevec) for NVIDIA's cuQuantum when picking a GPU; in particular, it must have CUDA Compute Capability 7.0 or higher. -At the time of writing, the following compatable GPUs are available on GCP: +At the time of writing, the following compatible GPUs are available on GCP: * [NVIDIA T4](https://www.techpowerup.com/gpu-specs/tesla-t4.c3316). - This is the least expensive compatable GPU on GCP. + This is the least expensive compatible GPU on GCP. It has 16GB of memory and can therefore simulate up to 30 qubits. It is not compatible with multi-GPU simulations. * [NVIDIA V100](https://www.techpowerup.com/gpu-specs/tesla-v100-pcie-16-gb.c2957). diff --git a/docs/type_reference.md b/docs/type_reference.md index f6bc4dbd..e463b7b0 100644 --- a/docs/type_reference.md +++ b/docs/type_reference.md @@ -12,11 +12,11 @@ they fulfill the same expectations. | Bitstring | Alias for `uint64_t`. | | Circuit | [`Circuit`](https://github.com/quantumlib/qsim/tree/master/lib/circuit.h) | | Container (util.h) | A vector of strings, or `Op`'s output type. | -| Ctype | A complex type, e.g. `std::complex`. | +| Ctype | A complex type, e.g., `std::complex`. | | For | `for` loop abstractions, see below. | | ForArgs | Arguments for constructing `For` objects, see below. | | FP (simulator_basic.h) | Same as `fp_type`. | -| fp_type | A floating-point type, i.e. `float` or `double`. | +| fp_type | A floating-point type, i.e., `float` or `double`. | | Function (parfor.h) | Any function; args are specified with `Args`. | | FuserT | [`BasicGateFuser`](https://github.com/quantumlib/qsim/tree/master/lib/fuser_basic.h) | | Gate | [`Gate`](https://github.com/quantumlib/qsim/tree/master/lib/gate.h) | diff --git a/lib/fuser_basic.h b/lib/fuser_basic.h index 5f61ace0..3191bd2d 100644 --- a/lib/fuser_basic.h +++ b/lib/fuser_basic.h @@ -128,7 +128,7 @@ class BasicGateFuser final : public Fuser { * @param gfirst, glast The iterator range [gfirst, glast) to fuse gates * (or pointers to gates) in. Gate times of the gates that act on the same * qubits should be ordered. Gates that are out of time order should not - * cross the time boundaries set by `times_to_split_at` or by measurment + * cross the time boundaries set by `times_to_split_at` or by measurement * gates. * @param times_to_split_at Ordered list of time steps (boundaries) at which * to separate fused gates. Each element of the output will contain gates diff --git a/lib/fuser_mqubit.h b/lib/fuser_mqubit.h index fdbfddb0..c75b1a01 100644 --- a/lib/fuser_mqubit.h +++ b/lib/fuser_mqubit.h @@ -226,7 +226,7 @@ class MultiQubitGateFuser final : public Fuser { * @param gfirst, glast The iterator range [gfirst, glast) to fuse gates * (or pointers to gates) in. Gate times of the gates that act on the same * qubits should be ordered. Gates that are out of time order should not - * cross the time boundaries set by `times_to_split_at` or by measurment + * cross the time boundaries set by `times_to_split_at` or by measurement * gates. * @param times_to_split_at Ordered list of time steps (boundaries) at which * to separate fused gates. Each element of the output will contain gates diff --git a/qsimcirq/qsim_simulator.py b/qsimcirq/qsim_simulator.py index 2513ba50..85cc8224 100644 --- a/qsimcirq/qsim_simulator.py +++ b/qsimcirq/qsim_simulator.py @@ -388,10 +388,10 @@ def compute_amplitudes_sweep_iter( bitstrings: The bitstrings whose amplitudes are desired, input as an string array where each string is formed from measured qubit values according to `qubit_order` from most to least significant qubit, - i.e. in big-endian ordering. + i.e., in big-endian ordering. param_resolver: Parameters to run with the program. qubit_order: Determines the canonical ordering of the qubits. This is - often used in specifying the initial state, i.e. the ordering of the + often used in specifying the initial state, i.e., the ordering of the computational basis states. Yields: @@ -539,7 +539,7 @@ def simulate_sweep_iter( program: The circuit to simulate. params: Parameters to run with the program. qubit_order: Determines the canonical ordering of the qubits. This is - often used in specifying the initial state, i.e. the ordering of the + often used in specifying the initial state, i.e., the ordering of the computational basis states. initial_state: The initial state for the simulation. This can either be an integer representing a pure state (e.g. 11010) or a numpy @@ -587,7 +587,7 @@ def simulate_expectation_values_sweep_iter( observables: An observable or list of observables. params: Parameters to run with the program. qubit_order: Determines the canonical ordering of the qubits. This - is often used in specifying the initial state, i.e. the + is often used in specifying the initial state, i.e., the ordering of the computational basis states. initial_state: The initial state for the simulation. The form of this state depends on the simulation implementation. See @@ -706,7 +706,7 @@ def simulate_moment_expectation_values( or observable list to calculate after ALL moments. param_resolver: Parameters to run with the program. qubit_order: Determines the canonical ordering of the qubits. This - is often used in specifying the initial state, i.e. the + is often used in specifying the initial state, i.e., the ordering of the computational basis states. initial_state: The initial state for the simulation. The form of this state depends on the simulation implementation. See diff --git a/requirements.txt b/requirements.txt index 26173852..db0d0054 100644 --- a/requirements.txt +++ b/requirements.txt @@ -3,3 +3,4 @@ cirq-core~=1.0 numpy~=1.16 pybind11 typing_extensions +setuptools \ No newline at end of file diff --git a/setup.py b/setup.py index 70ebca47..d1e9b3a1 100644 --- a/setup.py +++ b/setup.py @@ -7,7 +7,6 @@ from setuptools import setup, Extension from setuptools.command.build_ext import build_ext -from distutils.version import LooseVersion class CMakeExtension(Extension): @@ -27,10 +26,12 @@ def run(self): ) if platform.system() == "Windows": - cmake_version = LooseVersion( + from packaging.version import parse + + cmake_version = parse( re.search(r"version\s*([\d.]+)", out.decode()).group(1) ) - if cmake_version < "3.1.0": + if cmake_version < parse("3.1.0"): raise RuntimeError("CMake >= 3.1.0 is required on Windows") for ext in self.extensions: @@ -116,6 +117,7 @@ def build_extension(self, ext): author_email="devabathini92@gmail.com", python_requires=">=3.7.0", install_requires=requirements, + setup_requires=["packaging"], extras_require={ "dev": dev_requirements, },