Proposal for a Quantum Capabilities Label for Quantum Computers, Algorithms, and Applications

Sifting through all of the hype of press releases and puffy articles about quantum computing, it’s very difficult to discern the capabilities of a particular quantum computer, or what quantum computing capabilities are needed for a particular quantum algorithm or application. This informal paper proposes a very simplified label to provide this information. This will make it possible to tell at a quick glance what algorithms or applications a given quantum computer can run, or what capabilities a quantum computer needs to run a given quantum algorithm or application.

Topics discussed in this paper:

  1. In a nutshell
  2. The needs
  3. Goals
  4. Demand transparency — transparency is mandatory
  5. What won’t be covered by this proposal
  6. Capabilities and metrics
  7. Units for capabilities and metrics
  8. Quantum computer vs. quantum processor
  9. Proposed list of quantum computing capabilities
  10. Prototype vs. production
  11. Research vs. commercial
  12. Other capabilities and characteristics
  13. Principles of Operation and Implementation Specifications for all details on a quantum computer
  14. Some capabilities may not be known at present
  15. Quantum computer label
  16. Combined label for a family of quantum computer models
  17. Abbreviated quantum computer label
  18. #AQ (Algorithmic Qubits)
  19. Quantum Volume (QV) limit of 50 qubits
  20. A list of capabilities to provide a fuller picture than a single metric
  21. Other benchmarks
  22. Differences for the label for a quantum algorithm or application
  23. Present quantum algorithm and application requirements as both formulas and representative values in tabular form
  24. Not all quantum algorithms and applications have requirements for all capabilities of a quantum computer
  25. Labels for speculative or future quantum computers, algorithms, and applications
  26. Qubit count
  27. Quantum error correction (QEC)
  28. Qubit fidelity
  29. Gate fidelity
  30. Measurement fidelity
  31. Qubit fidelity under quantum error correction
  32. Logical qubits — in the future
  33. Qubit connectivity
  34. Qubit topology
  35. Fine granularity of phase and probability amplitude
  36. Coherence time
  37. Maximum circuit depth vs. maximum circuit size — is there opportunity for parallelism?
  38. Maximum circuit size vs. total circuit size
  39. Total circuit size vs. maximum circuit depth — is there opportunity for parallelism?
  40. Precision of quantum Fourier transform (QFT)
  41. Quantum advantage for quantum algorithms and applications
  42. Define metadata to facilitate searching, sorting, and matching for both quantum computers and quantum algorithms and applications
  43. Overall letter grade?
  44. Graphic treatment of label
  45. Identification information — essential but beyond the scope of this proposal
  46. Essential details for papers on quantum computers, algorithms, and applications
  47. Essential details for press releases for quantum computers, algorithms, and applications
  48. Essential details for journalists writing about quantum computers, algorithms, and applications
  49. Basis for a report card on progress in quantum computing
  50. Focus here is primarily quantum computer hardware, not software
  51. My original proposal for this topic
  52. Summary and conclusions

In a nutshell

  1. Readers and reviewers need to quickly grasp the capabilities of a particular quantum computer, or of the capabilities required by a particular quantum algorithm or application.
  2. Demand transparency. Transparency is mandatory. No excuses.
  3. A label is proposed which is an abbreviated summary of quantum computing capabilities. Primarily performance and capacity.
  4. Easy to grasp at a quick glance. No need for a careful reading or deep study.
  5. Applies equally to quantum computers, quantum algorithms, and quantum applications.
  6. For quantum algorithms and applications it lists the required quantum computing capabilities. But they’re generally from the same list of capabilities as a quantum computer.
  7. Full details are available elsewhere. The proposed label is a small subset of the full details which can be found in the Principles of Operation and Implementation Specifications documents for particular quantum computers, and similarly the specifications or source code or published papers on a quantum algorithm or application would give the full details about the required quantum computing capabilities.
  8. Select the small set of essential details. The point of this paper is to identify a very small set of such details which give a decent sense of the overall capabilities or requirements of a particular quantum computer, algorithm, or application at a quick glance.
  9. Ideal for metadata for a database. The brevity of the details on the label would make it ideal for metadata for a database search for quantum computers, algorithms, and applications.
  10. Facilitate comparisons. A modest set of capabilities should make it easier to compare and contrast two or more quantum computers, quantum algorithms, or quantum applications.
  11. Who supports what. Having compatible capabilities used between quantum computers and algorithms and applications should make it easier to ascertain which quantum computers will support a given quantum algorithm or application, as well as which algorithms and applications are supported by a particular quantum computer.
  12. Call attention to important details. The label should also have the effect of calling attention to capabilities which are not currently given enough attention, such as degree of fine granularity of phase and probability amplitude and lack of support for high-precision quantum Fourier transform (QFT).
  13. Focus on quantitative details rather than hype. The label should also have the effect of calling attention to specific quantitative measures of the capabilities of quantum computers as well as calling attention to hardware requirements of quantum algorithms and applications. In contrast to today’s hype, rhetoric, hand-waving, and overall confusion.
  14. A family label as well. Either a table which combines all of the labels of the individual models of the family for easy comparison, or a single label with ranges for any metrics which are not constant across all models of quantum computers in the family.
  15. An abbreviated label as well. A briefer subset of the most important information.
  16. Label can be applied to speculative or future quantum computers, algorithms, and applications as well. An estimated date would be helpful.
  17. Rich graphical treatment is warranted. But it is beyond the scope of this paper, and beyond my own interest and ability.
  18. Generally the label for quantum algorithms and applications will parallel the label for quantum computers, with some differences. Some capabilities may not be relevant or no useful metric value is available.
  19. Quantum advantage for quantum algorithms and applications. Roughly what performance advantage does the quantum approach have over the best classical solution. This is an exception in that it is a capability rather than a required capability.
  20. Prototype vs. production. A quantum computer, quantum algorithm, or quantum application will generally be intended to be either a prototype for experimentation, or intended for production usage. It would be helpful for the label to designate which purpose is intended.
  21. Research vs. commercial. A quantum computer, quantum algorithm, or quantum application will generally be intended to be for research purposes only or intended to represent commercial usage. It would be helpful for the label to designate which purpose is intended.
  22. Identification information — essential but beyond the scope of this proposal. There is also identification information which needs to be included on the label, but the details of identification are beyond the scope of this proposal.
  23. Essential details for papers on quantum computers, algorithms, and applications. The label also defines the essential information that should be presented in any paper on a quantum computer, algorithm, or application.
  24. Essential details for press releases for quantum computers, algorithms, and applications. The label also defines the essential information that should be presented in a press release for a quantum computer, algorithm, or application.
  25. Essential details for journalists writing about quantum computers, algorithms, and applications. The label also defines the essential information that journalists should be aware of when writing about a quantum computer, algorithm, or application.
  26. The label can also be used as the basis for a report card on progress in quantum computing capabilities. Each of the listed capabilities is where progress is needed.
  27. Focus here is primarily quantum computer hardware, not software. There are lots of software capabilities as well, very worthy of attention, but that’s beyond the scope of this paper.

The needs

A user of a quantum computer (or a customer buying one) or a programmer using a quantum algorithm or developing a quantum application (or a manager responsible for the use of quantum algorithms and applications) needs to know the following:

  1. The capabilities of a quantum computer. The resources which are available and what capabilities they provide.
  2. The capabilities required by a quantum algorithm or application. The quantum computing resources and capabilities which a quantum algorithm requires.

Goals

  1. Transparency. What capabilities does a particular quantum computer have, or what capabilities does a particular quantum algorithm or application require.
  2. Utility. How easily can we tell what sorts of algorithms or applications can be run on a particular quantum computer, and how easily can we identify what quantum computers are capable of supporting a particular quantum algorithm or application.
  3. Make it easy to tell what kind of quantum computer is needed to support a particular quantum algorithm or application.
  4. Make it easy to tell what sorts of algorithms or applications can be supported by a particular quantum computer.
  5. Define metadata to facilitate searching, sorting, and matching for both quantum computers and quantum algorithms and applications. The capabilities for quantum computers and requirements for quantum algorithms and applications would greatly facilitate creation and querying of databases of quantum computers and quantum algorithms and applications.
  6. Make it easier to see where quantum computers need improvements.
  7. Make it easier to see how far ahead of quantum computer hardware quantum algorithms and applications really are.
  8. Make it easier to see what improvements are needed for quantum computers to run existing quantum algorithms and applications.
  9. Provide information needed to help set research priorities.
  10. Get a sense of how close quantum computers, algorithms, and applications are to supporting production-scale commercialization of quantum computing.
  11. Gain a fuller picture of capabilities than is possible using a single metric.
  12. Provide the essential details for papers on quantum computers, algorithms, and applications. Assure that readers quickly get to the point about what quantum computing capabilities are involved.
  13. Provide the essential details for press releases for quantum computers, algorithms, and applications. Assure that readers quickly get past all of the hype.
  14. Provide the essential details for journalists to write about quantum computers, algorithms, and applications. Assure that readers quickly get past all of the hype.
  15. Provide a list of capabilities which can also be used as the basis for a report card on progress of quantum computing.
  16. Generally nudge people in the direction of quantitative detail rather than hype.

Demand transparency — transparency is mandatory

We deserve transparency on capabilities of quantum computers, algorithms, and applications.

In fact, the quantum computers, algorithms, and applications themselves deserve transparency.

It’s very easy for vendors to pay lip service to transparency, but walking the talk is more difficult — and more rare.

We should:

  1. Expect transparency. Transparency is a reasonable default expectation.
  2. Assume transparency. We shouldn’t have to lift a finger to get transparency.
  3. Wait for transparency. Maybe hold off on products and services which lack sufficient transparency.
  4. Request transparency. We shouldn’t have to ask for transparency, but…
  5. Insist on transparency. We shouldn’t have to go beyond asking politely and nicely, but…
  6. Demand transparency. Hold their feet to the fire. Transparency shouldn’t be optional. And lack of transparency shouldn’t be tolerated.
  7. Transparency is mandatory. No ifs, ands, or buts. No excuses. Just do it!
  8. Without transparency, you have nothing!

What won’t be covered by this proposal

This proposal covers all systems that meet the common interpretation of the term quantum computer. More technically, it covers two-level gate-based quantum computers. This excludes:

  1. Multi-level quantum computers with more than two levels. Only two-level qubits are covered here.
  2. Qutrits. Three-level qubits.
  3. Qudits. Ten-level qubits.
  4. Continuous-variable (CV) qumodes. As on photonic quantum computers.
  5. Squeezed states. As on photonic quantum computers.
  6. Fusion-based quantum computing (FBQC). Again, primarily photonic quantum computers.
  7. Non-gate quantum computers. Such as quantum annealing from D-Wave Systems. These are quite interesting, but beyond the scope of the information presented in this paper.
  8. Specialized quantum physics simulation hardware. Again, these are very interesting, but beyond the scope of the concept of quantum computation covered by this paper.

It’s not that such systems aren’t of any significant interest, but the needs get a little less cut and dried fairly quickly. Some of those scenarios could be easily handled by modest extensions of this proposal (e.g., more than two levels but still gate-based) while other scenarios would require more radical revision.

In any case, this proposal covers what I consider the common case.

Capabilities and metrics

Generally, each capability of a quantum computer will be expressed as a metric. Or, we can say that a metric expresses the measure of a capability.

In this paper I focus on capabilities, the what that is being measured by a metric.

In a fair number of cases the metric is simply the capability.

Although I do recognize that other people may prefer to refer directly to metrics.

Units for capabilities and metrics

Generally, I don’t bother expressing what units are required for a given capability or metric. Usually it is fairly obvious or the common-sense expectation. Or it can vary, such as what unit of time to use (minute, second, millisecond, microsecond, nanosecond.)

The general philosophy is that the creator of the label can use whatever units they feel are appropriate. If the unit is completely obvious, it can be omitted, but generally it should be stated explicitly.

Quantum computer vs. quantum processor

For the purposes of this informal paper, the following are all essentially synonymous unless clearly distinguished by context:

  1. Quantum computer.
  2. Quantum computer system.
  3. Quantum processor.
  4. Quantum processor unit (QPU).
  5. Quantum processing unit (QPU).
  6. QPU.

There are technical distinctions, but they are mostly not relevant to this proposal.

And there is some confusion and ambiguity about where exactly the lines are drawn for what constitutes the quantum processing unit (QPU) itself versus all of the other components that collectively constitute the overall quantum computer system.

Generally, most of the capabilities discussed in this paper relate to the quantum processing unit (QPU) itself (the raw qubits and their connectivity), but also to some of the components outside of but directly connected to the QPU, such as the classical electronics outside of the cryostat, such as gate execution, for example.

In short, the proposed label of this paper applies to both the overall quantum computer system overall, as well as the inner quantum processing unit (QPU) itself.

Proposed list of quantum computing capabilities

This is a clean, very limited subset of all of the capabilities either of a quantum computer or required for a quantum algorithm or application:

  1. Qubit technology. Superconducting transmon qubit, trapped-ion, neutral-atom, silicon spin, etc. Standardized abbreviations would be nice.
  2. Qubit count. Initially physical qubit count, but with quantum error correction it would be both logical qubit count and physical qubit count.
  3. Quantum error correction (QEC). Is it supported? Is there a specific scheme or multiple schemes supported? Are there any parameters supported? Can the ratio of physical to logical qubits be specified or controlled? This is still all off in the future.
  4. Qubit fidelity. Nines of qubit fidelity. If error correction is supported, both the fidelity based on any residual error rate and the fidelity of the raw physical qubits. For now, it would simply be the physical qubit fidelity. Can call out gate fidelity and measurement fidelity separately, but qubit fidelity should be the lesser of two-qubit gate fidelity and measurement fidelity.
  5. Qubit connectivity. Nearest neighbor, full, less than nearest neighbor, better than nearest neighbor. Unlimited or how limited. Standardized abbreviations would be nice.
  6. Fine granularity of phase and probability amplitude. Number of gradations. Generally approximated as a power of ten or a power of two — 100, 1,000, one million, a billion, or 2¹⁰, 2²⁰, 2³⁰. Generally needed for quantum Fourier transform (QFT) precision.
  7. Coherence time. For physical qubits. Under quantum error correction, logical qubits either have infinite, indefinite coherence or possibly some residual limitation on coherence time.
  8. Gate execution time and rate. Time to execute a single quantum logic gate as well as how many gates can be executed per second.
  9. Maximum circuit depth. Generally either the coherence time divided by the gate execution time or some arbitrary limit if coherence time is indefinite.
  10. Maximum circuit size. May be greater than the maximum circuit depth if gates can be executed in parallel. Otherwise it should be identical to the maximum circuit depth.
  11. Quantum Volume (QV). And log2(QV) as well, since it’s the number of qubits which can effectively be used in a significant computation.
  12. Benchmarks. Optionally, any other standardized benchmark results — benchmark name and metric value — other than Quantum Volume (QV).
  13. Quantum Fourier transform (QFT) precision. How many qubits can be transformed and achieve high quality results.
  14. Circuit executions per second. Maximum rate for the shortest circuits. Includes time to reset all qubits. Within a single network request. Comparable to IBM’s Circuit Layer Operations Per Second (CLOPS).
  15. Network requests per second. Distinct jobs and users.
  16. Runtime support. Any ability to support running of classical application code on the quantum computer. Qiskit Runtime is one example.
  17. Calibration overhead. Percentage of time spent running calibration process. Frequency. Time duration per calibration run.

Yes, there will be more capabilities, but the label is designed to display only the most important and useful capabilities — for the average reader.

Prototype vs. production

A quantum computer, quantum algorithm, or quantum application will generally be intended to be either a prototype for experimentation, or intended for production usage.

It would be helpful for the label to designate which purpose is intended.

Research vs. commercial

A quantum computer, quantum algorithm, or quantum application will generally be intended to be for research purposes only or intended to represent commercial usage.

It would be helpful for the label to designate which purpose is intended.

Other capabilities and characteristics

Any number of other capability measures could be considered for inclusion on the label for either a quantum computer or a quantum algorithm or application, but for now, the goal is to keep the list relatively short and most relevant.

Generally, additional capabilities and characteristics should be found in the Principles of Operation and Implementation Specifications documents for a quantum computer or in the technical documentation for a quantum algorithm or application, including any published papers and source code or GitHub repository.

Principles of Operation and Implementation Specifications for all details on a quantum computer

The proposal of this paper covers only a small subset of the total capabilities of a quantum computer, sufficient to get a general sense of capabilities at a quick glance. For the full details of the total capabilities of a quantum computer, see the Principles of Operation document for the quantum computer, which tells a programmer everything they need to know about a computer system to write code for the system. Typically there would be one document for a whole family of processors.

This would exclude processor-specific details such as performance and capacity.

There would be a separate document, the Implementation Specification, for each processor of the family which tells a programmer all of the details they might want to know to code well for that particular processor, such as performance and capacity, and any details which might vary between members of the processor family.

The point of this paper is to identify a very small set of such details which give a decent sense of the overall capabilities of a particular quantum computer.

For more discussion of Principles of Operation and Implementation Specifications for quantum computers, see my paper:

  1. Framework for Principles of Operation for a Quantum Computer
  2. https://jackkrupansky.medium.com/framework-for-principles-of-operation-for-a-quantum-computer-652ead10bc48

Some capabilities may not be known at present

In an effort to be forward-looking, this proposal includes some capabilities which may not be fully characterized now or in the near future. The values on the label for such capabilities would simply have to be listed as unknown or not known. Over time the set of such capabilities should shrink and eventually completely evaporate, although additional capabilities may appear on occasion so that the set of unknown capabilities may never or infrequently dissipate completely.

Some examples at present:

  1. Quantum error correction (QEC). Still an area of very active research. Difficult to say with confidence what the metrics will actually look like.
  2. Fine granularity of phase and probability amplitude. Less important today but will increase in importance as quantum Fourier transform (QFT) becomes more feasible — due to the need for fine granularity of phase and probability amplitude.
  3. Quantum Fourier transform (QFT) precision. Won’t become important until fine granularity of phase is supported to enable high-precision quantum Fourier transform.

Quantum computer label

Some points particular to the label for a quantum computer system:

  1. Potential for multiple processors. A single quantum computer system with multiple processors, which may or may not work in tandem or independently. But this does not exist today.
  2. Possibly present as a table for all processors in a family. Each could have a completely separate label or join them as a table. Maybe both as a choice.
  3. When logical qubits are available and configurable, present as a table. List the possible configuration settings for physical qubits per logical qubit, or a sample list of values if it is a continuous value with a large number of possible settings.

Combined label for a family of quantum computer models

Although each model of quantum computer should always have its own label of capabilities, it will also be helpful and informative to have a combined label when there is a family of quantum computer models.

The family label could be presented in two distinct forms:

  1. A table which is simply the combination of all of the labels of the individual members of the family. Makes it easy to compare and contrast the models.
  2. A single merged label. Discrete metric values when they are constant across all models. A range of metric values when they vary across the models.

Abbreviated quantum computer label

For some purposes an even more abbreviated label might be appropriate to roughly and generally describe a quantum computer:

  1. Qubit count. Initially physical qubit count, but with quantum error correction it would be both logical qubit count and physical qubit count.
  2. Qubit fidelity. Nines of qubit fidelity.
  3. Qubit connectivity. Nearest neighbor, full, less than nearest neighbor, better than nearest neighbor.
  4. Fine granularity of phase and probability amplitude. Number of gradations.
  5. Maximum circuit depth. The coherence time divided by the gate execution time.
  6. Quantum Volume (QV). Maybe log2(QV) as well, since it’s the number of qubits which can effectively be used in a significant computation.

Maybe qubit technology as well, but generally it’s the functional characteristics which really matter the most.

#AQ (Algorithmic Qubits)

IonQ has its own proprietary metric for its quantum computers, #AQ for Algorithmic Qubits.

They would like to see other vendors use this metric as well, but… we’ll see how that goes.

They do provide a full definition for #AQ, but unfortunately it’s rather complicated and can’t readily be reduced to one simple sentence.

Actually, originally, they did simply define it as:

  • we have roughly defined an #AQ of N as the size of the largest circuit you can successfully accomplish with N qubits and N² two-qubit gates.

So, for example, for #AQ of 20, you could execute 400 (20 times 20) two-qubit gates successfully.

But, they recently made it significantly more complicated.

For more details, see:

Quantum Volume (QV) limit of 50 qubits

In theory, the Quantum Volume (QV) metric is limited to roughly 50 qubits, QV of 2⁵⁰, since assessing Quantum Volume requires doing a full classical simulation of the quantum circuit.

In practice, the limit is probably much less than 50 qubits, maybe not even 32 qubits, since even high-performance, high-capacity classical quantum simulators may not have sufficient capacity for such high-end simulations of significant circuit depth.

But, in practice, most real quantum computers don’t have sufficient qubit fidelity to achieve correct quantum results with the deeper circuits required for assessing Quantum Volume, so the limit of 50 or even 32 is not practically an issue in the near-term.

But maybe three to five years from now these limits could become issues and lead to Quantum Volume failing to be a practical metric for the quality of quantum computations.

The expectation is that by then there will be a satisfactory replacement benchmark for Quantum Volume.

For more on this issue, see my paper:

A list of capabilities to provide a fuller picture than a single metric

There have been attempts to try to reduce all of quantum computing to a single metric, such as Quantum Volume (QV) and Algorithmic Qubits (#AQ), but such approaches leave a lot to be desired.

They simply don’t provide quantum algorithm designers and quantum application developers with enough information to effectively utilize quantum computers.

And if someone seeks to buy a quantum computer capable of running a particular quantum algorithm or application, a single metric won’t tell them much at all.

Quantum algorithm designers and quantum application developers need to look at and balance all of the factors which affect their needs. An average, best case, worst case, or least common denominator won’t tell them much that will really help them.

In some cases a single metric might say that no quantum computer can run a particular quantum algorithm or application. In other cases, the single metric may be gross overkill for the actual requirements for a particular quantum algorithm or application.

It’s best to match the specific needs of quantum computers, quantum algorithms, and quantum applications.

Other benchmarks

Someday there will be a range of standardized benchmark tests which can be run on a candidate quantum computer, much as Quantum Volume (QV) is today, and it would be appropriate to report some of these benchmark results on the label for a quantum computer.

Besides Quantum Volume (QV) and Algorithmic Qubits (#AQ), there could be any number of other benchmarks that could be run on a particular quantum computer, but I’m reluctant to suggest that such benchmarking results be added to the quantum computer label at this time.

Some vendors may have some preferred benchmarks which they might add to the label.

But overall, detailing of any specific benchmark tests — with the possible exception of Quantum Volume (QV) — is beyond the scope of the proposed label and this paper.

Unless such benchmarks are run relatively uniformly across most quantum computers the net result would be a collection of distinct labels which were not comparable.

If some consensus does develop around some reasonably small number of benchmarks some day, then they can be considered for inclusion here.

Differences for the label for a quantum algorithm or application

Not all of the capabilities for a quantum computer would be relevant to specifying the requirements for a particular quantum algorithm or application. Most of it is the same, but not all of it. In addition, there are requirements for the use of a quantum computer by a quantum algorithm or application which are not distinct capabilities of a quantum computer per se.

General capabilities which are typically not relevant to quantum algorithms or applications:

  1. Gate execution time and rate.
  2. Quantum Volume (QV).
  3. Circuit executions per second.
  4. Network requests per second.

Some points particular to the label for a quantum algorithm or application which aren’t relevant to a quantum computer:

  1. Qubit technology. Hopefully, and in theory, most quantum algorithms and applications will be independent of the qubit technology. But, in some cases, maybe they may be dependent.
  2. Scaling requirements. Based on input data size. Capability requirements should be presented as a formula based on input data size. As well as a table or graph (or both) showing capability requirements for a sample of representative input data sizes.
  3. Shot requirements. Circuit repetitions (shot count or shots) required based on input data size and any algorithm input parameters. Should be a formula, but also presented as a table to show actual shot couts for a sample of input data sizes. Shot requirement has two components: shots due to error rate, and shots due to the inherent probabilistic nature of quantum computations.
  4. Some additional general capabilities might not be relevant. For example, quantum Fourier transform (QFT) precision.
  5. Maximum circuit depth. May be less than maximum circuit size if gates can be executed in parallel. Otherwise it should be the same as the total circuit size. Could vary based on input data size, so see scaling requirements above.
  6. Total circuit size. Replaces maximum circuit size. Total count of quantum logic gates in the circuit for the algorithm. May be greater than the maximum circuit depth if gates can be executed in parallel. Otherwise it should be identical to the maximum circuit depth. Could vary based on input data size, so see scaling requirements above.
  7. Quantum advantage for quantum algorithms and applications. Roughly what performance advantage does the quantum approach have over the best classical solution.

For more detail on shot counts or circuit repetitions, see my paper:

Present quantum algorithm and application requirements as both formulas and representative values in tabular form

One of the biggest differences of the requirements of a quantum algorithm or application from the capabilities of a quantum computer is that they will commonly not be fixed constants, but vary or scale based on the size of the input data and any input parameter values.

Generally it is preferred to reduce such requirements to formulas with input data size and input parameter values as parameters of the formula, but in addition it will generally be desirable to show the requirements in tabular form with a separate column for at least some representative input data sizes and input parameter values to give the casual reader a more intuitive and explicit sense of capability requirements.

Simple quantum algorithms and applications won’t need this added complexity, but the intention is to support more complex and more sophisticated quantum algorithms and applications as soon as possible.

Not all quantum algorithms and applications have requirements for all capabilities of a quantum computer

Some, many, or even most quantum algorithms and applications can have shorter labels than a typical quantum computer since they are simply not dependent on various capabilities, typically because the algorithm or application is simpler, less sophisticated, or uses fewer of the capabilities.

It will be up to the quantum algorithm designer or application developer to decide what requirements need to be specified.

Labels for speculative or future quantum computers, algorithms, and applications

Although the primary focus of this paper is actual, current, real quantum computers, algorithms, and applications, the concept of a label for capabilities is also applicable to speculative or future quantum computers, algorithms, and applications. In fact, I would strongly encourage it.

The label should be clearly marked as speculative or future, possibly even with an estimated date when it is expected to be introduced, made available, or go into service.

Qubit count

Qubit count is the simplest capability of a quantum computer to specify — how many qubits there are.

Actually, that’s not quite true — the simplest capability to specify is the qubit technology, although qubit technology isn’t particularly relevant to quantum algorithms and applications. But next to qubit technology, qubit count is the simplest capability to specify.

There is an exception to that — where quantum error correction is supported so that we have two distinct qubit counts — the logical qubit count and the physical qubit count.

Quantum error correction (QEC)

If quantum error correction is supported by a quantum computer, then there are two qubit counts — the logical qubit count and the physical qubit count.

I don’t think it is absolutely necessary to have an explicit label to say that quantum error correction is supported, but simply to have that implied when there are two qubit counts given.

That said, it might be appropriate to have a separate field if there are parameters involved in supporting quantum error correction, such as:

  1. A choice of coding scheme. The name of the coding or correction scheme.
  2. The number of physical qubits per logical qubit. Either this is a parameter which can be changed, or it is computed automatically by dividing the number of physical qubits by the number of logical qubits.
  3. Any other parameters for the coding scheme. Some schemes may have additional parameters.

In any case, since quantum error correction is an active area of research and is not yet supported by any vendor, it simply isn’t known what information will really be appropriate on the label other than counts of physical and logical qubits.

Qubit fidelity

Qubit fidelity is an extremely important factor in quantum computing. There are a variety of methods for representing qubit fidelity, but I see that nines of qubit fidelity is the simplest and easiest to make sense out of — the more nines the better.

The more common values of nines of qubit fidelity would be:

  1. Below 1 nine — below 90% reliability.
  2. 1 nine — 90% reliability.
  3. Below 1.5 nines — below 95% reliability.
  4. 1.5 nines — 95% reliability.
  5. 1.75 nines — 97.5%.
  6. 1.8 nines — 98%.
  7. 1.85 nines — 98.5%.
  8. 2 nines — 99%.
  9. 2.25 nines — 99.25%.
  10. 2.5 nines — 99.5%.
  11. 2.75 nines — 99.75%.
  12. 3 nines — 99.9%.
  13. 3.25 nines — 99.925%.
  14. 3.5 nines — 99.95%.
  15. 3.75 nines — 99.975%.
  16. 4 nines — 99.99%.
  17. 4.25 nines — 99.9925%.
  18. 4.5 nines — 99.995%.
  19. 4.75 nines — 99.9975%.
  20. 5 nines — 99.999%.

As for usability for practical computation:

  1. Whether 2 to 2.5 nines of qubit fidelity is sufficient for any applications is a stretch.
  2. 2.75 to 3 to 3.25 nines of qubit fidelity are verging on near-perfect qubits, good enough for some applications.
  3. 3.5 nines may be close enough to near-perfect qubits for many applications.
  4. 3.75 nines will be close enough to near-perfect qubits for many applications.
  5. 4 nines of qubit fidelity will generally be near-perfect qubits sufficient for most applications.

At least that is my own personal assessment. Others may feel differently.

Also, it does depend on circuit depth — shorter circuits can tolerate lower fidelity, while deeper circuits will require higher fidelity to keep the total error rate down.

For more on the topic of nines of qubit fidelity, see my paper:

For more on near-perfect qubits, see my paper:

Gate fidelity

Technically, a lot of what is nominally referred to as qubit fidelity is really gate fidelity — how reliably can a quantum logic gate be executed on a qubit, or more importantly, between two interacting qubits.

I take the position that gate fidelity should be lumped in with overall qubit fidelity.

Still, a hardware vendor or algorithm designer might wish to separately call out gate fidelity distinct from overall combined qubit fidelity.

Measurement fidelity

Technically, another significant fraction of what is nominally referred to as qubit fidelity is really measurement fidelity — how reliably can a qubit be measured.

You would think that measuring a qubit (sometimes called readout) would be trivial since it just causes the complex quantum state to collapse to a classical binary 0 or 1, but apparently it’s more complicated than that.

The net result is that measurement of a qubit can introduce errors, and in fact those errors can be worse than any errors introduced by executing a two-qubit quantum logic gate.

A hardware vendor or algorithm designer might wish to separately call out measurement fidelity distinct from overall combined qubit fidelity.

Qubit fidelity under quantum error correction

The preceding sections presumed that there was no support for quantum error correction (QEC). Once quantum error correction is supported, then we get two sets of numbers:

  1. Qubit fidelity of physical qubits. What we just discussed.
  2. Qubit fidelity of logical qubits. Reflect any residual or lingering error rate after quantum error correction.

The theory is that quantum error correction will alleviate most errors, but even under the best quantum error correction there is likely to be some residual errors or a residual error rate. And what that residual error rate would be would depend on any number of factors, including:

  1. Base qubit fidelity. How close to near-perfect qubits are the physical qubits.
  2. Choice of physical qubits per logical qubit.
  3. Choice of coding scheme.
  4. Other parameters of the coding scheme.
  5. Residual impact on coherence time.
  6. Residual gate execution error rate.
  7. Residual two-gate gate execution error rate.
  8. Residual qubit measurement error rate.

Logical qubits — in the future

At present, we have no sense of full, automatic, and transparent quantum error correction (QEC). As a result, we have no sense of perfect logical qubits — all we have are raw physical qubits.

Even once quantum error correction does appear, it will likely initially be optional, so we will have three stages:

  1. Physical qubits only. Where we are today and for the indefinite future.
  2. Mix or choice of logical and physical qubits. Some quantum algorithms or applications may opt to stick with raw physical qubits for raw capacity, raw performance, or compatibility, while other quantum algorithms or applications may opt to go with perfect logical qubits.
  3. Logical qubits only. Physical qubits are only under the hood. All that the quantum algorithms and applications see are perfect logical qubits.

Qubit connectivity

Qubit connectivity is tricky. Ideally, you should be able to connect any two qubits in a two-input gate, but that isn’t always true.

Generally, there are four possibilities:

  1. Nearest neighbor connectivity. Any two physically adjacent qubits can be connected. Such as Google Sycamore.
  2. Full connectivity. Best. Common for trapped-ion and neutral-atom qubits.
  3. Less than nearest neighbor connectivity. Typical for IBM as they optimized minimization of crosstalk.
  4. Better than nearest neighbor connectivity. None that I am aware of at this time.

There may be other possibilities as well. Or degrees.

Generally when dealing with qubit connectivity we start with two gating questions:

  1. Is full connectivity supported? If so, we’re good to go.
  2. Where are we relative to pure nearest neighbor? Assuming a rectangular grid with four connections: up, down, left, and right. Are we exactly nearest neighbor, less than nearest neighbor, or somewhat greater than nearest neighbor (but not full connectivity)?

And selected qubits can have distinct connectivities different from other qubits in the same quantum computer. A common example is where the qubits are arranged in a rectangular grid, so that the qubits on the edges of the grid have a different connectivity than the qubits interior to the grid — sometimes three, sometimes two, and sometimes only a single connection is possible.

Qubit topology

I didn’t call out qubit topology (how qubits are arranged and connected) for the label. In theory, applications and algorithms shouldn’t really care about qubit topology, but ultimately it does affect connectivity, which algorithms do rely on. But the approach I took here is to focus on qubit fidelity and connectivity rather than qubit topology.

I have no great objection to some sort of specification of qubit topology on the label for a quantum computer, but I don’t have any preference for what it should look like either. Hardware vendors might choose to use a small graphical map of the qubit arrangement and connectivity — as many do today already.

Qubit topology would seem to make even less sense for the label for a quantum algorithm, primarily since the connectivity requirements for the algorithm would imply enough information to infer what sort of topology might be required.

Fine granularity of phase and probability amplitude

Unlike the basis states of the quantum state of a qubit which are strictly binary 0 and 1, phase and probability are continuous values, real numbers between 0.0 and 1.0 (and the negative values as well.) This begs the question of exactly how many distinct values can be represented by phase or probability amplitude. In theory, an infinite number, in practice, implemented by actual digital and analog circuit components, there won’t be an infinity of values.

The question for a given quantum computer or quantum algorithm or application is how many unique values or gradations of value are supported by the hardware or required by an algorithm or application.

Generally, this would be approximated as a power of ten or a power of two, such as:

  1. 100.
  2. 1,000.
  3. One million.
  4. A billion.
  5. A trillion.
  6. A quadrillion. I kind of doubt there could be more gradations than this or even close to this.
  7. 2¹⁰. 1024.
  8. 2¹⁶. 64K.
  9. 2²⁰. One million.
  10. 2³⁰. One billion.
  11. 2³². Four billion. Corresponds to a 32-bit integer.
  12. 2⁴⁰. One trillion.
  13. 2⁵⁰. One quadrillion.

One limiting factor would be the DAC (digital to analog conversion) hardware which converts a digital signal to an analog signal. Even 10 or 12 bits of precision might be a stretch. 20 or 30 or 32 bits might be an upper limit, for current hardware.

I just don’t know what the true limits are for current hardware technology in general, let alone for any given quantum computer. This is why it needs to be disclosed on the label for a quantum computer.

But for algorithms and applications, the designer or developer really does need to be fully cognizant of how fine-grained their reliance on phase or probability amplitude really is — to know what hardware it needs. Commonly this shows up in the use of quantum Fourier transform (QFT).

Actually, it would be helpful to have analytic tools which could analyze a quantum algorithm and report its range of reliance on fine granularity of phase and probability amplitude.

Generally, one needs to be very careful when considering algorithms which will depend on a very fine granularity of phase or probability amplitude.

For more on this topic, see my paper:

Coherence time

The quantum state of a qubit tends to decay over time.

Coherence time could be relatively short, such as under 100 microseconds, or could be relatively long, such as seconds, minutes, or even hours.

Generally coherence time refers to physical qubits.

Under quantum error correction, logical qubits either have infinite, indefinite coherence or possibly some residual limitation on coherence time.

There are some very technical aspects of coherence time such as T1, T2, and T2*. And coherence tends to vary over time. Such details are beyond the scope of this paper and the labels proposed by this paper.

The proposal of this paper is to use the minimum of T1, T2, and T2* as the stated coherence time. All three metrics can be given as well.

Maximum circuit depth vs. maximum circuit size — is there opportunity for parallelism?

Technically, a quantum circuit is a graph, so that theoretically portions of the circuit could be executed in parallel so that more quantum logic gates could get executed before the coherence time expires.

That’s in theory, but I personally haven’t seen any technical documentation or technical specifications to suggest that any quantum computer will execute any quantum circuit any more efficiently than executing all of the gates of the circuit in a sequence.

But that could change.

In any case, the label for a quantum computer should indicate whether gates can be executed in parallel so that the total circuit size could be somewhat greater than the maximum circuit depth.

Maximum circuit size vs. total circuit size

Maximum circuit size and total circuit size are really the same thing, just that the former is used for a quantum computer to indicate the largest circuit that is supported, while the latter is used for a quantum algorithm or application to indicate the actual size of the quantum circuit.

Total circuit size vs. maximum circuit depth — is there opportunity for parallelism?

Technically, a quantum circuit is a graph, so that theoretically portions of the circuit could be executed in parallel so that more quantum logic gates could get executed before the coherence time expires.

That’s in theory, but I personally haven’t seen any technical documentation or technical specifications to suggest that any quantum computer will execute any quantum circuit any more efficiently than executing all of the gates of the circuit in a sequence.

But that could change.

In any case, the label for a quantum algorithm should indicate whether gates can be executed in parallel so that the total circuit size could be somewhat greater than the maximum circuit depth.

But a lazy writer might just set the maximum circuit depth to be identical to the total circuit size.

Precision of quantum Fourier transform (QFT)

Some applications such as quantum computational chemistry or Shor’s factoring algorithm need the advanced quantum parallelism of quantum Fourier transform (QFT). The width or precision of the transform can be problematic, being critically dependent on fine granularity of phase and probability amplitude.

Even some current quantum computers can perform a quantum Fourier transform for a few bits, but more than a handful of bits is beyond the capability of current and near-term quantum computers, due to lack of fine granularity of phase and probability amplitude.

But as quantum hardware advances, it is expected that finer granularity of phase and probability amplitude will be supported, enabling an increase in the precision of quantum Fourier transform which can be handled by a quantum computer.

Given current hardware limitations, quantum Fourier transform is virtually useless, so that this field of the label will have little utility for the near future.

See the Fine granularity of phase and probability amplitude section for more details.

Quantum advantage for quantum algorithms and applications

The whole point of pursuing a quantum solution to a problem rather than a classical solution is to achieve a dramatic performance speedup. This entry of the label for a quantum algorithm or application will summarize the advantage. It will be roughly the performance advantage that a quantum algorithm or application offers over the best classical solution.

The actual quantum advantage will generally vary based on the size of the input data.

The value displayed on the label should correspond to the actual quantum advantage when production-scale input data is used. Again, the goal is to give the reader a reasonable expectation of what they can expect from the quantum algorithm or application.

For simplicity, the label could just give a simple integer approximating the performance advantage over the best classical solution for production-scale input. Such as 100X, 1,000X, 1,000,000X, or even one quadrillion X.

Technically, the quantum advantage should be a formula based on the size of the input data and possibly input parameters. That can be specified if it is available. Otherwise, a simple numerical advantage for production-scale input should be sufficient.

For more on quantum advantage in general, see my paper:

For more on quantum advantage based on actual input data, see my paper:

For more on dramatic quantum advantage, the ultimate goal of quantum computing, see my paper:

For more on fractional quantum advantage, the best we can hope for until we get much more capable quantum hardware, see my paper:

Define metadata to facilitate searching, sorting, and matching for both quantum computers and quantum algorithms and applications

The capabilities for quantum computers and requirements for quantum algorithms and applications defined in this paper would greatly facilitate the creation and querying of databases of quantum computers and quantum algorithms and applications.

Each of the capabilities or requirements would correspond to a column in a database.

Standard SQL-type database queries would be a very powerful tool to select and discover both quantum computers and quantum algorithms and applications.

What such databases might look like is beyond the scope of this paper. The goal here is simply to enable such solutions.

Overall letter grade?

It certainly is tempting to want to provide an overall letter grade for a quantum computer or quantum algorithm or application, but both are too multidimensional to be scored with a simple scalar.

I also considered a letter grade for individual capabilities or groups of capabilities, but even then it is more common that the capability cannot be easily reduced to a simplified scalar score.

In many cases a score would be completely subjective. If a quantum computer meets your needs, that’s all that matters — a score is irrelevant. And a quantum algorithm or application needs what it needs — its needs are what they are and no score is relevant.

Ultimately the only score which is relevant is how close a particular quantum computer comes to meeting the needs of a particular quantum algorithm or application. And it either meets the needs or it doesn’t — a binary test.

I haven’t given up hope, but for now the notion of an overall letter grade is beyond reach — or within reach but beyond utility.

Graphic treatment of label

It would probably be advantageous to have a distinctive graphical treatment for the label for quantum computers and quantum algorithms and applications, but that’s beyond the scope of this paper and beyond my own personal interest and ability.

But I welcome and encourage others to take on such a task.

I know nothing about graphic design, but I do realize that it needs to be clean and simple and not jam-packed full of dense text, so I suggest two graphical treatments:

  1. Full page. All of the suggested capabilities. Try to simplify the text a moderate amount.
  2. Mini-side bar box. A very modest subset of the information. A true quick glance.

Use the abbreviated label suggested previously:

  1. Qubit count.
  2. Qubit fidelity. Nines of qubit fidelity.
  3. Qubit connectivity.
  4. Fine granularity of phase and probability amplitude. Number of gradations.
  5. Maximum circuit depth.
  6. Quantum Volume (QV). Maybe log2(QV) as well, since it’s the number of qubits which can effectively be used in a significant computation.

That excludes the qubit technology. I don’t think it’s functionally needed, but some people might prefer it.

Identification information — essential but beyond the scope of this proposal

There is also identification information which needs to be included on the label, but the details of identification are beyond the scope of this proposal. For example:

  1. Vendor name. Both overall quantum computer system vendor and the quantum processing unit (QPU) vendor, which may be different.
  2. Family name. Family of processors to which this processor belongs. Or, if the label is for the entire family rather than a particular member of the family.
  3. Model name or number. The specific model of a quantum computer system, within a family.
  4. Configuration options. Any configuration settings which were chosen which cause a different label even for the same basic model.
  5. Version, release, or revision. When capabilities of a quantum computer, algorithm, or application may change due to updates.
  6. Dates. When was the information on the label captured and recorded. When did the quantum computer, algorithm, or application first go into service — or expected to enter service. Optionally, when did the quantum computer, algorithm, or application go out of service.

Essential details for papers on quantum computers, algorithms, and applications

The label also defines the essential information that should be presented in any paper on a quantum computer, algorithm, or application. Whether formal academic papers in peer-reviewed journals or less formal white papers, the information included in the label proposed by this paper would allow readers to quickly get a sense of what quantum computing capabilities are involved. What is the paper actually talking about.

The bottom line is that nobody reading or scanning a paper on a quantum computer, algorithm, or application should be deprived of any of the information detailed in the basic capability list shown in the label.

Essential details for press releases for quantum computers, algorithms, and applications

The label also defines the essential information that should be presented in a press release for a quantum computer, algorithm, or application.

Maybe in some cases that might be more detail than makes sense in a light press release, but it at least deserves to be included with or linked with the press release so that anybody reading the press release can quickly view the capabilities on the label.

The bottom line is that nobody viewing a press release for a quantum computer, algorithm, or application should be deprived of the basic capability list shown on the label.

Essential details for journalists writing about quantum computers, algorithms, and applications

The label also defines the essential information that journalists should be aware of when writing about a quantum computer, algorithm, or application.

Whether a given journalist will be interested in or need to write about all of that information, or how much of it to write about will vary, but at least they should have all of that information at their fingertips to choose from.

The bottom line is that no journalist writing about a quantum computer, algorithm, or application should be deprived of the basic capability list shown on the label.

Basis for a report card on progress in quantum computing

The label can also be used as the basis for a report card on progress in quantum computing capabilities. Each of the listed capabilities is where progress is needed, as well as what progress has been made.

Two indicators are needed for progress in each area (capability):

  1. Where we are relative to what is needed. Gives a sense of how much further progress is needed. Are we 90% there? 50%?
  2. What improvement has been made. Has progress even been made? Over some indicated reporting period like quarterly, semiannually, annually, or biannually. Maybe show all four.

Such a report card is beyond the scope of the proposal of this paper, but the list of capabilities proposed by this paper would definitely provide a sound basis for such a report card.

Focus here is primarily quantum computer hardware, not software

The proposal of this paper focuses primarily on quantum computer hardware capabilities. There are lots of software capabilities as well, such as:

  1. Infrastructure software.
  2. System management.
  3. Utilities.
  4. Tools.
  5. Compilers.
  6. Programming languages.
  7. Libraries.
  8. Application frameworks.

It would indeed probably make sense to have a distinct capabilities label for software capabilities, but that’s well beyond the scope of the proposal of this paper.

And there are capabilities beyond even software, such as:

  1. Documentation.
  2. Testing.
  3. Training.
  4. Educational materials.
  5. Support.
  6. Services.
  7. Reliability.
  8. Maintenance.
  9. Frequent or timely upgrades.

My original proposal for this topic

For reference, here is the original proposal I had for this topic. It may have some value for some people wanting a more concise summary of this paper.

  • Proposal for a Good Housekeeping label for quantum computers and quantum algorithms. Quickly tells you all the basics you need to know about the capabilities of a particular quantum computer or the capabilities required by a particular quantum algorithm. Qubit technology (superconducting transmon qubit, trapped-ion, neutral-atom, silicon spin, etc.) Qubit count. Qubit fidelity (nines.) Qubit connectivity (nearest neighbor, full, less than nearest neighbor, better than nearest neighbor.) Granularity of phase and probability amplitudes (number of gradations.) Coherence time. Gate execution time. Maximum circuit depth. Quantum Volume. Qubits of quantum Fourier transform (QFT) for high quality results. CLOPS — circuit repetitions per second. NLOPS — network requests per second. Can call out measurement fidelity separately, but qubit fidelity should be the lesser of two-qubit gate fidelity and measurement fidelity. Sure, there’s plenty of additional info to be disclosed, but these basics should be a short summary upfront.

Summary and conclusions

  1. Readers and reviewers need to quickly grasp the capabilities of a particular quantum computer, or of the capabilities required by a particular quantum algorithm or application.
  2. Demand transparency. Transparency is mandatory. No excuses.
  3. A label is proposed which is an abbreviated summary of quantum computing capabilities. Primarily performance and capacity.
  4. Easy to grasp at a quick glance. No need for a careful reading or deep study.
  5. Applies equally to quantum computers, quantum algorithms, and quantum applications.
  6. For quantum algorithms and applications it lists the required quantum computing capabilities. But they’re generally from the same list of capabilities as a quantum computer.
  7. Full details are available elsewhere. The proposed label is a small subset of the full details which can be found in the Principles of Operation and Implementation Specifications documents for particular quantum computers, and similarly the specifications or source code or published papers on a quantum algorithm or application would give the full details about the required quantum computing capabilities.
  8. Select the small set of essential details. The point of this paper is to identify a very small set of such details which give a decent sense of the overall capabilities or requirements of a particular quantum computer, algorithm, or application at a quick glance.
  9. Ideal for metadata for a database. The brevity of the details on the label would make it ideal for metadata for a database search for quantum computers, algorithms, and applications.
  10. Facilitate comparisons. A modest set of capabilities should make it easier to compare and contrast two or more quantum computers, quantum algorithms, or quantum applications.
  11. Who supports what. Having compatible capabilities used between quantum computers and algorithms and applications should make it easier to ascertain which quantum computers will support a given quantum algorithm or application, as well as which algorithms and applications are supported by a particular quantum computer.
  12. Call attention to important details. The label should also have the effect of calling attention to capabilities which are not currently given enough attention, such as degree of fine granularity of phase and probability amplitude and lack of support for high-precision quantum Fourier transform (QFT).
  13. Focus on quantitative details rather than hype. The label should also have the effect of calling attention to specific quantitative measures of the capabilities of quantum computers as well as calling attention to hardware requirements of quantum algorithms and applications. In contrast to today’s hype, rhetoric, hand-waving, and overall confusion.
  14. A family label as well. Either a table which combines all of the labels of the individual models of the family for easy comparison, or a single label with ranges for any metrics which are not constant across all models of quantum computers in the family.
  15. An abbreviated label as well. A briefer subset of the most important information.
  16. Label can be applied to speculative or future quantum computers, algorithms, and applications as well. An estimated date would be helpful.
  17. Rich graphical treatment is warranted. But it is beyond the scope of this paper, and beyond my own interest and ability.
  18. Generally the label for quantum algorithms and applications will parallel the label for quantum computers, with some differences. Some capabilities may not be relevant or no useful metric value is available.
  19. Quantum advantage for quantum algorithms and applications. Roughly what performance advantage does the quantum approach have over the best classical solution. This is an exception in that it is a capability rather than a required capability.
  20. Identification information — essential but beyond the scope of this proposal. There is also identification information which needs to be included on the label, but the details of identification are beyond the scope of this proposal.
  21. Essential details for papers on quantum computers, algorithms, and applications. The label also defines the essential information that should be presented in any paper on a quantum computer, algorithm, or application.
  22. Essential details for press releases for quantum computers, algorithms, and applications. The label also defines the essential information that should be presented in a press release for a quantum computer, algorithm, or application.
  23. Essential details for journalists writing about quantum computers, algorithms, and applications. The label also defines the essential information that journalists should be aware of when writing about a quantum computer, algorithm, or application.
  24. The label can also be used as the basis for a report card on progress in quantum computing capabilities. Each of the listed capabilities is where progress is needed.
  25. Focus here is primarily quantum computer hardware, not software. There are lots of software capabilities as well, very worthy of attention, but that’s beyond the scope of this paper.

--

--

Freelance Consultant

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store