EP2147391A1 - Integrating optimization directly into databases - Google Patents

Abstract

Systems, methods and articles solve computationally complex problems. Example embodiments provide data query language features that may be used to express optimization problems. An expression of an optimization problem in the provided data query language may be transformed into a primitive problem that is equivalent to the optimization problem. An optimization solver may be invoked to provide a solution to the primitive problem. Analog processors such as quantum processors may be used to solve the primitive problem. This abstract is provided to comply with rules requiring an abstract, and is submitted with the intention that it will not be used to interpret or limit the scope or meaning of the claims.

Description

INTEGRATING OPTIMIZATION DIRECTLY INTO DATABASES

FIELD OF THE INVENTION

The present systems, methods and articles are generally related to generating solutions to discrete optimization problems and complex search problems.

BACKGROUND

A Turing machine is a theoretical computing system, described in 1936 by Alan Turing. A Turing machine that can efficiently simulate any other Turing machine is called a Universal Turing Machine (UTM). The Church-Turing thesis states that any practical computing model has either the equivalent or a subset of the capabilities of a UTM.

Analog computation involves using the natural physical evolution of a system as a computational system. A quantum computer is any physical system that harnesses one or more quantum effects to perform a computation. A quantum computer that can efficiently simulate any other quantum computer is called a Universal Quantum Computer (UQC).

In 1981 Richard P. Feynman proposed that quantum computers could be used to solve certain computational problems more efficiently than a UTM and therefore invalidate the Church-Turing thesis. See, e.g., Feynman R. P., 'Simulating Physics with Computers", International Journal of Theoretical Physics, Vol. 21 (1982) pp. 467-488. For example, Feynman noted that a quantum computer could be used to simulate certain other quantum systems, allowing exponentially faster calculation of certain properties of the simulated quantum system than is possible using a UTM. Approaches to Quantum Computation

There are several general approaches to the design and operation of quantum computers. One such approach is the "circuit model" of quantum computation. In this approach, qubits are acted upon by sequences of logical gates that are the compiled representation of an algorithm. Circuit model quantum computers have several serious barriers to practical implementation. In the circuit model, it is required that qubits remain coherent over time periods much longer than the single-gate time. This requirement arises because circuit model quantum computers require operations that are collectively called quantum error correction in order to operate. Quantum error correction cannot be performed without the circuit model quantum computer's qubits being capable of maintaining quantum coherence over time periods on the order of 1 ,000 times the single-gate time. Much research has been focused on developing qubits with coherence sufficient to form the basic information units of circuit model quantum computers. See, e.g., Shor, P. W. "Introduction to Quantum Algorithms," arXiv.org:quant-ph/0005003 (2001 ), pp. 1-27. The art is still hampered by an inability to increase the coherence of qubits to acceptable levels for designing and operating practical circuit model quantum computers.

Another approach to quantum computation, involves using the natural physical evolution of a system of coupled quantum systems as a computational system. This approach does not make critical use of quantum gates and circuits. Instead, starting from a known initial Hamiltonian, it relies upon the guided physical evolution of a system of coupled quantum systems wherein the problem to be solved has been encoded in the terms of the system's Hamiltonian, so that the final state of the system of coupled quantum systems contains information relating to the answer to the problem to be solved. This approach does not require long qubit coherence times. Examples of this type of approach include adiabatic quantum computation, cluster-state quantum computation, oneway quantum computation, quantum annealing and classical annealing, and are described, for example, in Farhi, E. et al., "Quantum Adiabatic Evolution Algorithms versus Simulated Annealing," arXiv.org:quant-ph/0201031 (2002), pp 1- 16.

Qubits As mentioned previously, qubits can be used as fundamental units of information for a quantum computer. As with bits in UTMs, qubits can refer to at least two distinct quantities; a qubit can refer to the actual physical device in which information is stored, and it can also refer to the unit of information itself, abstracted away from its physical device. Examples of qubits include quantum particles, atoms, electrons, photons, ions, and the like.

Qubits generalize the concept of a classical digital bit. A classical information storage device can encode two discrete states, typically labeled "0" and "1 ". Physically these two discrete states are represented by two different and distinguishable physical states of the classical information storage device, such as direction or magnitude of magnetic field, current, or voltage, where the quantity encoding the bit state behaves according to the laws of classical physics. A qubit also contains two discrete physical states, which can also be labeled "0" and "1". Physically these two discrete states are represented by two different and distinguishable physical states of the quantum information storage device, such as direction or magnitude of magnetic field, current, or voltage, where the quantity encoding the bit state behaves according to the laws of quantum physics. If the physical quantity that stores these states behaves quantum mechanically, the device can additionally be placed in a superposition of 0 and 1. That is, the qubit can exist in both a "0" and "1" state at the same time, and so can perform a computation on both states simultaneously. In general, N qubits can be in a superposition of 2^N states. Quantum algorithms make use of the superposition property to speed up some computations. In standard notation, the basis states of a qubit are referred to as the |0> and |1> states. During quantum computation, the state of a qubit, in general, is a superposition of basis states so that the qubit has a nonzero probability of occupying the |0> basis state and a simultaneous nonzero probability of occupying the |1> basis state. Mathematically, a superposition of basis states means that the overall state of the qubit, which is denoted |Ψ), has the form |ψ) = α|θ) + &|l) , where a and b are coefficients corresponding to the probabilities \a\² and |jb|², respectively. The coefficients a and b each have real and imaginary components, which allows the phase of the qubit to be characterized. The quantum nature of a qubit is largely derived from its ability to exist in a coherent superposition of basis states and for the state of the qubit to have a phase. A qubit will retain this ability to exist as a coherent superposition of basis states when the qubit is sufficiently isolated from sources of decoherence.

To complete a computation using a qubit, the state of the qubit is measured (i.e., read out). Typically, when a measurement of the qubit is performed, the quantum nature of the qubit is temporarily lost and the superposition of basis states collapses to either the |0> basis state or the |1> basis state and thus regaining its similarity to a conventional bit. The actual state of the qubit after it has collapsed depends on the probabilities \a\² and \b\² immediately prior to the readout operation.

Superconducting Qubits

There are many different hardware and software approaches under consideration for use in quantum computers. One hardware approach uses integrated circuits formed of superconducting materials, such as aluminum or niobium. Some of the technologies and processes involved in designing and fabricating superconducting integrated circuits are similar in some respects to those used for conventional integrated circuits. Superconducting qubits are a type of superconducting device that can be included in a superconducting integrated circuit. Typical superconducting qubits, for example, have the advantage of scalability and are generally classified depending on the physical properties used to encode information including, for example, charge and phase devices, phase or flux devices, hybrid devices, and the like. Superconducting qubits can be separated into several categories depending on the physical property used to encode information. For example, they may be separated into charge, flux and phase devices, as discussed in, for example Makhlin et al., 2001 , Reviews of Modern Physics 73, pp. 357-400. Charge devices store and manipulate information in the charge states of the device, where elementary charges consist of pairs of electrons called Cooper pairs. A Cooper pair has a charge of 2e and consists of two electrons bound together by, for example, a phonon interaction. See, e.g., Nielsen and Chuang, Quantum Computation and Quantum Information, Cambridge University Press, Cambridge (2000), pp. 343-345. Flux devices store information in a variable related to the magnetic flux through some part of the device. Phase devices store information in a variable related to the difference in superconducting phase between two regions of the phase device. Recently, hybrid devices using two or more of charge, flux and phase degrees of freedom have been developed. See, e.g., U.S. Patent No. 6,838,694 and U.S. Patent Application Publication No. 2005- 0082519.

Examples of flux qubits that may be used include rf-SQUIDs, which include a superconducting loop interrupted by one Josephson junction, or a compound junction (where a single Josephson junction is replaced by two parallel Josephson junctions), or persistent current qubits, which include a superconducting loop interrupted by three Josephson junctions, and the like. See, e.g., Mooij et al., 1999, Science 285, 1036; and Orlando et al., 1999, Phys. Rev. B 60, 15398. Other examples of superconducting qubits can be found, for example, in ll'ichev et al., 2003, Phys. Rev. Lett. 91 , 097906; Blatter et al., 2001 , Phys. Rev. B 63, 174511 , and Friedman et a/., 2000, Nature 406, 43. In addition, hybrid charge-phase qubits may also be used.

The qubits may include a corresponding local bias device. The local bias devices may include a metal loop in proximity to a superconducting qubit that provides an external flux bias to the qubit. The local bias device may also include a plurality of Josephson junctions. Each superconducting qubit in the quantum processor may have a corresponding local bias device or there may be fewer local bias devices than qubits. In some embodiments, charge-based readout and local bias devices may be used. The readout device(s) may include a plurality of dc- SQUID magnetometers, each inductively connected to a different qubit within a topology. The readout device may provide a voltage or current. The dc-SQUID magnetometers including a loop of superconducting material interrupted by at least one Josephson junctions are well known in the art.

Quantum Processor A computer processor may take the form of an analog processor, for instance a quantum processor such as a superconducting quantum processor. A quantum processor may include a number of qubits and associated local bias devices, for instance two or more superconducting qubits.

A quantum processor may include a number of coupling devices operable to selectively couple respective pairs of qubits. Examples of superconducting coupling devices include rf-SQUIDs and dc-SQUIDs, which couple qubits together by flux. SQUIDs include a superconducting loop interrupted by one Josephson junction (an rf-SQUID) or two Josephson junctions (a dc- SQUID). The coupling devices may be capable of both ferromagnetic and anti- ferromagnetic coupling, depending on how the coupling device is being utilized within the interconnected topology. In the case of flux coupling, ferromagnetic coupling implies that parallel fluxes are energetically favorable and anti- ferromagnetic coupling implies that anti-parallel fluxes are energetically favorable. Alternatively, charge-based coupling devices may also be used. Other coupling devices can be found, for example, in U.S. Patent Application Publication No. 2006-0147154, US Provisional Patent Application No. 60/886,253, US Provisional Patent Application No. 60/915,657 and US Provisional Patent Application No. 60/975,083. Respective coupling strengths of the coupling devices may be tuned between zero and a maximum value, for example, to provide ferromagnetic or anti- ferromagnetic coupling between qubits.

Databases and Query Languages

Many entities employ relational databases to store information. The information may be related to almost any aspect of business, government or individuals. For example, the information may be related to human resources, transportation, order placement or picking, warehousing, distribution, budgeting, oil exploration, surveying, polling, images, geographic maps, network topologies, identification, security, commercial transactions, etc. A relational database stores a set of "relations" or "relationships." A relation is a two-dimensional table. The columns of the table are called attributes and the rows of the table store instances or "tuples" of the relation. A tuple has one element for each attribute of the relation. The schema of the relation consists of the name of the relation and the names and data types of all attributes. Typically, many such relations are stored in the database with any given relation having perhaps millions of tuples.

Searching databases typically employs the preparation of one or more queries expressed in a declarative language, such as a data query language. One common way of formatting queries is through Structured Query Language (SQL). SQL-99 is the most recent standard, however many database vendors offer slightly different dialects or extensions of this standard. The basic query mechanism in SQL is the statement: SELECT L FROM R WHERE C, in which L identifies a list of columns in the relation(s) R, and c is a condition that evaluates to TRUE, FALSE or UNKNOWN. Typically, only tuples that evaluate to TRUE are returned. Other query languages are also known, for example DATALOG, which may be particularly useful for recursive queries.

Traditional querying or searching of databases presents a number of problems. Boolean matching is particularly onerous and unforgiving. Hence, searchers must specify a query that will locate the desired piece of information, without locating too much undesired information. Overly constrained queries will have no exact answer. Queries with insufficient constraints will have too many answers to be useful. Thus, the searcher must correctly constrain the query, with a suitable number of correctly selected constraints.

In addition, existing query languages may not be well suited to the concise expression and/or solution of complex problems, such as search and/or optimization problems. This problem is related to the operation of the standard SQL SELECT statement, which includes a tuple in a result set when a specified condition is true for the tuple. In addition, even though it may be possible to solve some search and/or optimization problems using one or more SELECT statements and other standard SQL language features, such solutions may be awkward and lengthy, making them difficult to comprehend, maintain, and/or debug. Furthermore, such solutions typically do not scale well as the size of the problem domain increases. For example, for some solutions, one or more temporary tables may need to be created, and the number of rows in the temporary tables may increase as a function of the problem size.

Furthermore, existing optimization tools are typically not well integrated with database systems. An example system that may be used to express complex problems is the MX Solver, which is a logic-based, general- purpose framework for modeling search and/or optimization problems, by solving constraint satisfaction problems. The MX Solver may call solvers to find a solution to a provided constraint satisfaction problem and additionally translate the solution provided from the solver to the MX Solver into the logic-based, general-purpose framework. Further details regarding the operation of the MX Solver are provided in Mitchell et al., "Model Expansion as a Framework for Modelling and Solving Search Problems," Simon Frasier University Technical Report TR 2006-24, 2006. The MX Solver, however, is not capable of accessing a database system to obtain data representative of a problem.

In addition, to interface a database with optimization tools currently available to users, infrastructure (e.g., a network, etc.) is required to connect the database and the optimization software and/or hardware. This infrastructure requires professionals to ensure any problems effecting the connection between database and the optimization hardware are corrected with minimal service interruption. The maintenance required to manage, sustain, or otherwise administer the connection between the database and the optimization software and/or hardware can be costly due to the professionals required to monitor the system. Also, the hardware costs of such infrastructure can be considerable depending upon the infrastructure and the types of connections that must be made between the database and the optimization hardware.

These problems limit the usefulness of existing data query languages and databases in particular, and various other programming or software development methodologies and technologies in particular. Extensions of standard query languages such as relational algebra and SQL, by adding constraint modeling capabilities, has been discussed in Cadoli et al., "Combining Relational Algebra, SQL, Constraint Modeling, and Local Search", arXiv.org:cs.AI/0601043 (2006), pp. 1-30.

BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 is a functional block diagram showing a computing system employing at least one analog processor and a relational database, according to at least one illustrated embodiment of the present systems, methods and articles. Figure 2 is a block diagram illustrating operation of, and interaction between, various functional modules that are configured to solve constraint satisfaction problems, according to at least one illustrated embodiment of the present systems, methods and articles. Figures 3A-3B illustrate various example constraint satisfaction problems that may be solved by at least one illustrated embodiment of the present systems, methods and articles.

Figure 4 is a flow diagram showing a method of operating a computing system to interact with an analog processor to solve a constraint satisfaction problem, according to at least one illustrated embodiment of the present systems, methods and articles.

Figure 5 is a flow diagram showing a method of operating a computing system to interact with a solver to solve a constraint satisfaction problem, according to at least one illustrated embodiment of the present systems, methods and articles.

Figure 6 is a flow diagram showing a method of operating a computing system to interact with a solver to solve a constraint satisfaction problem, according to at least one illustrated embodiment of the present systems, methods and articles.

SUMMARY

In one embodiment, a method for processing problems expressed in a data query language is provided, the method comprising: receiving an expression in a data query language; interacting with an analog processor configured to determine a response to at least some of the received expression; and providing the determined response.

Another embodiment provides a computer-readable medium storing instructions for causing a computing system to process problems expressed in a data query language, by performing a method comprising: receiving a statement in a data query language; utilizing an analog processor configured to determine a response to at least some of the received statement; and providing the determined response.

In another embodiment, a system for processing problems expressed in a data query language is provided, the system comprising: a memory; and a module stored on the memory that is configured, when executed, to: receive a query in a data query language; invoke an analog processor configured to determine an answer to a portion of the received query; and provide the determined answer. In yet another embodiment, a method for processing problems expressed in a data query language is provided, the method comprising: receiving an expression in a data query language; transforming the received expression into a primitive problem expression; invoking an optimization solver configured to determine one or more solutions to the primitive problem expression; and providing the determined one or more solutions as a response to the received expression.

Another embodiment provides a computer-readable medium storing instructions for causing a computing system to process problems expressed in a data query language, by performing a method comprising: receiving a query; transforming a portion of the received query into a primitive problem expression; invoking an optimization solver configured to determine one or more solutions to the primitive problem expression; and providing the determined one or more solutions as a response to the received query.

In yet another embodiment, a system for processing problems expressed in a data query language is provided, the system comprising: a memory; and a module stored on the memory that is configured, when executed, to: receive an statement in a data query language; compile a part of the received statement into a primitive problem expression; interact with an optimization solver configured to determine one or more solutions to the primitive problem expression; and provide the determined one or more solutions as a response to the received statement.

DETAILED DESCRIPTION In the following description, certain specific details are set forth in order to provide a thorough understanding of various embodiments of the present systems, methods and articles. However, one skilled in the art will understand that the present systems, methods and articles may be practiced without these details. In other instances, well-known structures associated with computers have not been shown or described in detail to avoid unnecessarily obscuring descriptions of the embodiments of the present systems, methods and articles.

Unless the context requires otherwise, throughout the specification and claims which follow, the words "comprise" and "include" and variations thereof, such as, "comprises", "comprising", "includes" and "including" are to be construed in an open, inclusive sense, that is, as "including, but not limited to." Reference throughout this specification to "one embodiment", "an embodiment", "one alternative", "an alternative" or similar phrases means that a particular feature, structure or characteristic described is included in at least one embodiment of the present systems, methods and articles. Thus, the appearances of such phrases in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. The headings provided herein are for convenience only and do not interpret the scope or meaning of the claimed invention. Unless the context requires otherwise, throughout the specification and claims which follow, references to a computer language, such as SQL, encompass various implementations of that language, regardless of whether the language standard is partially implemented or modifications have been introduced in a particular implementation. Thus, for example, when SQL is used, reference is intended to include real-world SQL implementations as used by various database servers (e.g., Oracle, MySQL, PostgreSQL, Microsoft SQL Server), regardless of an implementation's adherence to any of the SQL standards. For ease of understanding, SQL will be used as an illustrative declarative data query language and a relational database will be used as an exemplary data source but such should not be considered limiting. Those of skill in the art will appreciate that while data query languages such as SQL are occasionally referred to herein, reference to a particular data query language is for illustrative purposes only, and the present systems, methods and articles may be employed using any declarative language, data query language, and/or declarative language features provided in the context of other types of languages, such as object oriented languages, scripting languages, logic programming languages, etc.

In addition, various methods, systems, and articles for solving complex problems are discussed. Even though many examples described herein focus on generating solutions to constraint satisfaction problems, such examples are for illustrative purposes only, and the discussed techniques are equally applicable to optimization problems, such as logistics, planning, network utilization, etc., to constraint satisfaction problems, such as scheduling and configuration management, etc., as well as to other types of problems. Many classes of problems may be represented at least in part as constraint satisfaction problems. For example, an optimization problem may be expressed as a set of constraints over one or more variables and an objective function, where the goal is to find a set of values that satisfies the constraints and maximizes/minimizes the objective function and the optimization problem may be purely solved as a sequence of constraint satisfaction problems with no objective function. Accordingly, the described techniques may be utilized to solve, or to generate or construct systems that solve, a wide range of computationally complex problems. System Hardware

Figure 1 and the following discussion provide a brief and general description of a suitable computing environment in which various embodiments of the computing system may be implemented. Although not required, embodiments will be described in the general context of computer-executable instructions, such as program application modules, objects or macros being executed by a computer. Those skilled in the relevant art will appreciate that the invention can be practiced with other computing system configurations, including hand-held devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, personal computers ("PCs"), network PCs, mini-computers, mainframe computers, and the like. The embodiments can be practiced in distributed computing environments where tasks or modules are performed by remote processing devices, which are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.

Figure 1 shows a computing system 100 operable to solve constraint satisfaction problems expressed in a data query language by interacting with an analog processor, according to one illustrated embodiment.

Computing system 100 includes a digital computing subsystem 102 and an analog computing subsystem 104 communicatively coupled to digital computing subsystem 102.

Digital computing subsystem 102 includes one or more processing units 106, system memories 108, and system buses 110 that couple various system components including system memory 108 to processing unit 106. Digital computing subsystem 102 will at times be referred to in the singular herein, but this is not intended to limit the application to a single digital computing subsystem 102 since in typical embodiments, there will be more than one digital computing subsystem 102 or other device involved. Other computing systems may be employed, such as conventional and personal computers, where the size or scale of the system allows. Processing unit 106 may be any logic processing unit, such as one or more central processing units ("CPUs"), digital signal processors ("DSPs"), application-specific integrated circuits ("ASICs"), etc. Unless described otherwise, the construction and operation of the various blocks shown in Figure 1 are of conventional design. As a result, such blocks need not be described in further detail herein, as they will be understood by those skilled in the relevant art.

System bus 110 can employ any known bus structures or architectures, including a memory bus with memory controller, a peripheral bus, and a local bus. System memory 108 may include read-only memory ("ROM") and random access memory ("RAM"). A basic input/output system ("BIOS") 112, which can form part of the ROM, contains basic routines that help transfer information between elements within digital computing subsystem 102, such as during startup. Digital computing subsystem 102 also includes non-volatile memory 114. Non-volatile memory 114 may take a variety of forms, for example a hard disk drive for reading from and writing to a hard disk, and an optical disk drive and a magnetic disk drive for reading from and writing to removable optical disks and magnetic disks, respectively. The optical disk can be a CD-ROM, while the magnetic disk can be a magnetic floppy disk or diskette. The hard disk drive, optical disk drive and magnetic disk drive communicate with processing unit 106 via system bus 110. The hard disk drive, optical disk drive and magnetic disk drive may include appropriate interfaces or controllers 116 coupled between such drives and system bus 110, as is known by those skilled in the relevant art. The drives, and their associated computer-readable media, provide non-volatile storage of computer readable instructions, data structures, program modules and other data for digital computing subsystem 102. Although the depicted digital computing subsystem 102 has been described as employing hard disks, optical disks and/or magnetic disks, those skilled in the relevant art will appreciate that other types of non-volatile computer-readable media that can store data accessible by a computer may be employed, such a magnetic cassettes, flash memory cards, digital video disks ("DVD"), Bernoulli cartridges, RAMs, ROMs, smart cards, etc. Various program modules or application programs and/or data can be stored in system memory 108. For example, system memory 108 may store an operating system 118, end user application interfaces 120, server applications 122, one or more translator modules 124, one or more grounder modules 126, one or more solver modules 128, and/or one or more optimization application program interfaces ("APIs") 130. Also, system memory 108 may additionally or alternatively store one or more analog processor interface modules 132, and/or driver modules 134. The operation and function of these modules are discussed in detail below.

System memory 108 may also include one or more networking applications 135, for example a Web server application and/or Web client or browser application for permitting digital computing subsystem 102 to exchange data with sources via the Internet, corporate Intranets, or other networks as described below, as well as with other server applications on server computers such as those further discussed below. Networking application 135 in the depicted embodiment is markup language based, such as hypertext markup language ("HTML"), extensible markup language ("XML") or wireless markup language ("WML"), and operates with markup languages that use syntactically delimited characters added to the data of a document to represent the structure of the document. A number of Web server applications and Web client or browser applications are commercially available, such those available from Mozilla and Microsoft.

While shown in Figure 1 as being stored in system memory 108, operating system 118 and various applications/modules 120, 122, 124, 126, 128, 130, 132, 134 and/or data can be stored on the hard disk of the hard disk drive, the optical disk of the optical disk drive and/or the magnetic disk of the magnetic disk drive. Digital computing subsystem 102 can operate in a networked environment using logical connections to one or more client computing systems 136 (only one shown) and/or one or more database systems 170, such as one or more remote computers or networks. Digital computing subsystem 102 may be logically connected to one or more client computing systems 136 and/or database systems 170 under any known method of permitting computers to communicate, for example through a network 138 such as a local area network ("LAN") and/or a wide area network ("WAN") including, for example, the Internet. Such networking environments are well known including wired and wireless enterprise-wide computer networks, intranets, extranets, and the Internet. Other embodiments include other types of communication networks such as telecommunications networks, cellular networks, paging networks, and other mobile networks. The information sent or received via the communications channel may, or may not be encrypted. When used in a LAN networking environment, digital computing subsystem 102 is connected to the LAN through an adapter or network interface card 140 (communicatively linked to system bus 110). When used in a WAN networking environment, digital computing subsystem 102 may include an interface and modem (not shown) or other device, such as network interface card 140, for establishing communications over the WAN/Internet. In a networked environment, program modules, application programs, or data, or portions thereof, can be stored in digital computing subsystem 102 for provision to the networked computers. In one embodiment, digital computing subsystem 102 is communicatively linked through network 138 with TCP/IP middle layer network protocols; however, other similar network protocol layers are used in other embodiments, such as user datagram protocol ("UDP"). Those skilled in the relevant art will readily recognize that the network connections shown in Figure 1 are only some examples of establishing communications links between computers, and other links may be used, including wireless links. While in most instances digital computing subsystem 102 will operate automatically, where an end user application interface is provided, an operator can enter commands and information into digital computing subsystem 102 through an end user application interface 148 including input devices, such as a keyboard 144, and a pointing device, such as a mouse 146. Other input devices can include a microphone, joystick, scanner, etc. These and other input devices are connected to processing unit 106 through end user application interface 120, such as a serial port interface that couples to system bus 110, although other interfaces, such as a parallel port, a game port, or a wireless interface, or a universal serial bus ("USB") can be used. A monitor 142 or other display device is coupled to bus 110 via a video interface, such as a video adapter (not shown). Digital computing subsystem 102 can include other output devices, such as speakers, printers, etc. Analog computing subsystem 104 includes an analog processor, for example, a quantum processor 150. Quantum processor 150 includes multiple qubit nodes 152a-152n (collectively 152) and multiple coupling devices 154a-154m (collectively 154).

Analog computing subsystem 104 includes a readout device 156 for reading out one or more qubit nodes 152. For example, readout device 156 may include multiple dc-SQUID magnetometers, with each dc-SQUID magnetometer being inductively connected to a qubit node 152 and NIC 140 receiving a voltage or current from readout device 156. The dc-SQUID magnetometers comprise a loop of superconducting material interrupted by two Josephson junctions and are well known in the art.

Analog computing subsystem 104 also includes a qubit control system 158 including controller(s) for controlling or setting one or more parameters of some or all qubit nodes 152. Analog computing subsystem 104 further includes a coupling device control system 160 including coupling controller(s) for coupling devices 154. For example, each coupling controller in coupling device control system 160 may be capable of tuning the coupling strength of a coupling device 154 between a minimum and a maximum value. Coupling devices 154 may be tunable to provide ferromagnetic or anti-ferromagnetic coupling between qubit nodes 152.

Analog processor interface module 132 may include run-time instructions for coordinating the solution of computational problems using quantum processor 150. For instance, analog processor interface module 132 may initiate quantum processor 150 to solve an embedded graph problem that is representative of, or equivalent to, a constraint satisfaction problem received by server application 122, discussed below. This may include, e.g., setting initial coupling values and local bias values for coupling devices 154 (Figure 1 ) and qubit nodes 152 respectively. Qubit nodes 152 and associated local bias values may represent vertices of embedded graph, and coupling values for coupling devices 154 may represent edges in embedded graph. For example, a vertex in a graph may be embedded into quantum processor 150 as a set of qubit nodes 152 coupled to each other ferromagnetically and coupling interactions may be embedded as a ferromagnetic or anti-ferromagnetic coupling between sets of coupled qubit nodes 152. For more information, see for example US 2005- 0256007, US 2005-0250651 and US 7,135,701 each titled "Adiabatic Quantum Computation with Superconducting Qubits". Analog processor interface module 132 may also include instructions for reading out the states of one or more qubit nodes 152 at the end of an evolution. This readout may represent a solution to the computational problem.

Where computing system 100 includes a driver module 134, driver module 134 may include instructions to output signals to quantum processor 150. NIC 140 may include appropriate hardware required for interfacing with qubit nodes 152 and coupling devices 154, either directly or through readout device 156, qubit control system 158, and/or coupling device control system 160. Alternatively, NIC 140 may include software and/or hardware that translate commands from driver module 134 into signals (e.g., voltages, currents, optical signals, etc.) that are directly applied to qubit nodes 152 and coupling devices 154. In another alternative, NIC 140 may include software and/or hardware that translate signals (representing a solution to a problem or some other form of feedback) from qubit nodes 152 and coupling devices 154. In some cases, analog processor interface module 132 may communicate with driver module 134 rather than directly with NIC 140 in order to send and receive signals from quantum processor 150.

The functionality of NIC 140 can be divided into two classes of functionality: data acquisition and control. Different types of chips may be used to handle each of these discrete functional classes. Data acquisition is used to measure the physical properties of qubit nodes 152 after quantum processor 150 has completed a computation. Such data can be measured using any number of customized or commercially available data acquisition micro-controllers including, but not limited to, data acquisition cards manufactured by Elan Digital Systems (Fareham, UK) including the AD132, AD136, MF232, MF236, AD142, AD218 and CF241 cards. Alternatively, data acquisition and control may be handled by a single type of microprocessor, such as the Elan D403C or D480C. There may be multiple NICs 140 in order to provide sufficient control over qubit nodes 152 and coupling devices 154 and in order to measure the results of a computation conducted on quantum processor 150. In the illustrated embodiment, server application 122 facilitates processing of various types of problems expressed in a data query language. In particular, server application 122 receives an expression in a data query language from one of the client computing systems 136. Server application 122 may determine whether the received expression reflects a constraint satisfaction problem or a standard data query. If the received expression is a standard data query, server application 122 interacts with database system 170 to execute, interpret, evaluate, or otherwise process the received query in order to obtain a response (e.g., a result set). The obtained response is then forwarded by server application 122 to client computing system 136. If the received expression reflects a constraint satisfaction problem, the server application interacts with translator module 124, grounder modules 126, and/or solver module 128 to obtain a solution to the constraint satisfaction problem. In one embodiment, translator module 124 converts the received expression into an intermediate problem expression, which is passed to grounder module 126. Grounder module 126 converts the intermediate problem expression into a primitive problem expression, which is passed to solver module 128. Solver module 128 then interacts with analog processor interface 132 to cause quantum processor 150 to provide a solution to the constraint satisfaction problem, according to the received primitive problem expression. The solution provided by quantum processor 150 may then be translated (e.g., by translator module 124) into a response that may be forwarded (e.g., by server application 122) to client computing system 136. Additional details regarding the interaction between, and function of, translator module 124, grounder modules 126, and/or solver module 128 are described with reference to Figure 2, below.

In addition, the one or more optimization APIs 130 implement a variety of interfaces that client computing systems may utilize to access functionality provided by computing system 100, such as the processing of various types of problems expressed in a data query language. Such interfaces may be provided and/or accessed via various protocols, such as RPC ("Remote Procedure Call"), RMI ("Remote Method Invocation"), HTTP, Web Services (XML-RPC, JAX- RPC, SOAP, etc.).

System Logic

Figure 2 is a block diagram illustrating operation of, and interaction between, various functional modules that are configured to solve constraint satisfaction problems, according to at least one illustrated embodiment of the present systems, methods and articles. In particular, Figure 2 shows a constraint solver system 202 that is configured to facilitate the solution of constraint satisfaction problems expressed in a data query language. Constraint solver system 202 interacts with a client program 201 and a database 210 to obtain solutions to constraint satisfaction problems provided by client program 201. Constraint solver system 202 comprises a problem transformer module 203, a solver such as SAT ("satisfiability") solver module 206, and a translator module 207. Problem transformer module 203 comprises a translator module 204 and a grounder module 205.

In the illustrated embodiment, constraint solver system 202 receives a data query language ("DQL") expression 220 from client program 201. The received DQL expression 220 reflects constraint satisfaction problem to be solved by constraint solver system 202. For example, DQL expression 220 may reflect the problem of finding the maximum independent set of nodes in a graph comprised of multiple nodes connected by edges. The graph may be stored in database 210 (e.g., as one or more tables). In response, the problem transformer module 203 transforms (e.g., compiles, translates, converts, etc.) DQL expression 220 into a logically equivalent primitive problem expression, such as a propositional logic formula 222.

The propositional logic formula 222 is an expression in a language or other format that is suitable for processing by SAT solver 206. SAT solver 206 is configured to efficiently determine a satisfying assignment of truth values for a given propositional logic formula. Hence, if the problem expressed by DQL expression 220 is to find a maximum independent set of nodes in a given graph, problem transformer module 203 may convert this problem into an equivalent primitive problem of finding a satisfying assignment for propositional logic formula 222, where finding such an assignment is equivalent to finding the maximum independent set for the given graph. The transformation performed by problem transformer module 203 may be based at least in part on data stored in, or provided by, database 210. For example, in the context of a given maximum independent set problem, the problem graph may be represented as one or more tables in database 210. In such a case, transforming DQL expression 220 may include extracting data that represents the problem graph from database 210 and incorporating the extracted data into propositional formula 222.

SAT solver module 206 determines a satisfying assignment for the propositional logic formula 222. SAT solver module 206 may perform this function in various ways, such as by interacting with an analog processor, such as quantum processor 150 described with reference to Figure 1. In other embodiments, SAT solver module 206 may instead, or in addition, solve the provided problem by way of a local or remote solver implementation executing on a digital computer. SAT solver module 206 provides as output a primitive problem solution, such as a satisfying assignment 223 to propositional logic formula 222. Translator module 207 takes satisfying assignment 223 and converts it into a data query language response 224 that is suitable for processing by client program 201. This may include translating and/or mapping satisfying assignment 223 into the domain of the original problem provided by the client program. For example, if the problem expressed by DQL expression 220 was to find the maximum independent set of nodes in a graph, and the graph was represented in database 210, satisfying assignment 223 would be mapped to a result (e.g., a result set, a table, etc.) based on the contents of database 210. In the illustrated embodiment, problem transformer module 203 comprises translator module 204 and grounder module 205. Translator module 204 translates (e.g., compiles) the received DQL expression 220 into a first order logic formula 221. Grounder module 205 takes first order logic formula 221 and performs further conversion to generate propositional logic formula 222, such as by eliminating first order variables in first order logic formula 221 and replacing them with constant symbols. Note that in other embodiments, problem transformer module 203 may transform DQL expression 220 directly into a primitive problem expression (e.g., propositional logic formula 222) that is suitable for processing by a solver, without first translating DQL expression 220 into some intermediate form (e.g., first order logic formula).

Figure 4 shows a method 400 of interacting with an analog processor to solve a constraint satisfaction problem, according to one illustrated embodiment. Method 400 may be performed by, for example, execution of a module such as constraint solver system 202 described with reference to Figure 2. In other embodiments, method 400 may be performed by a module executing on a client computing system, such as a library or archive that provides an interface to a local and/or remote solver. Method 400 starts at 401. At 402, the module receives an expression in a data query language. The expression may be received from, for example, a client program operating on a remote computing system that is communicatively coupled (e.g., via a network) to constraint solver system 202. The received expression may specify a constraint satisfaction problem, and may be a query (e.g., expressed in SQL-like syntax), etc.

At 403, the module interacts with an analog processor configured to determine a response to at least some of the received expression. In some cases, the expression may include at least some elements that are not for processing by the analog processor. In such cases, a first portion of the received expression may be translated or otherwise transformed into a representation suitable for processing by the analog processor, while a second portion of the received expression may be handled in other ways, such as by being processed as a generic database query, arithmetic expression, input/output directive, etc. In addition, the analog processor may be remote from constraint solver system 202. At 404, the module provides the determined response, by, for example, transmitting the response to a remote client computing system, initiating display of the response on a display medium (e.g., a computer display screen), storing the response (e.g., on a hard disk, in memory, in a database system, etc.), etc. Method 400 terminates at 405, or alternatively may repeat by returning to 401. Figure 5 shows a method 500 of interacting with a solver to solve a constraint satisfaction problem, according to one illustrated embodiment. Method 500 may be performed by, for example, execution of a module such as constraint solver system 202 described with reference to Figure 2. In other embodiments, method 500 may be performed by a module executing on a client computing system, such as a library or archive that provides an interface to a local and/or remote solver.

Method 500 starts at 501. At 502, the module receives an expression in a data query language. The query may be received from, for example, a client program operating on a remote computing system that is communicatively coupled (e.g., via a network) to constraint solver 202.

At 503, the module transforms the received expression into a primitive problem expression. Transforming the received expression may include compiling, translating, grounding, or mapping the received expression into one or more increasingly primitive problem expressions, such as first order predicate logic expressions, propositional logic expressions, etc.

At 504, the module invokes a constraint solver to determine one or more solutions to the primitive problem expression. Invoking the constraint solver may include selecting constraint solver based on various factors, such as user specified settings and/or preferences, cost, problem type, etc. Various types of solvers may be provided, such as one executing on a local or remote digital computing system or one executing on an analog processor such as a quantum computer.

At 505, the module provides the determined solution as a response to the received expression. Method 500 terminates at 506, or alternatively may repeat by returning to 501.

Figure 6 shows a method 600 of interacting with a solver to solve a constraint satisfaction problem, according to one illustrated embodiment. Method 600 may be performed by, for example, execution of a module such as constraint solver system 202 described with reference to Figure 2. In other embodiments, the method may be performed by a module executing on a client computing system, such as a library or archive that provides an interface to a local and/or remote solver. Method 600 starts at 601. At 602, the module receives an expression in data query language. The query may be received from, for example, a client program operating on a remote computing system that is communicatively coupled (e.g., via a network) to constraint solver 202.

At 603, the module determines the problem type expressed by the received expression. The problem type may be determined in some embodiments by inspection of the received expression. For instance, the expression may contain a token (e.g., FIND, as discussed in more detail below), keyword, or other indication that the problem is of a particular type. If it is determined that the problem type is constraint satisfaction problem, the module proceeds to 604. If it is instead determined that the problem type is a standard database query, the module proceeds to 608. A standard database query may be identified in some embodiments by the presence or absence of a particular token, keyword, or other indication of problem type.

At 604, the module transforms the received expression into a primitive problem expression, possibly based at least in part on data obtained from a database, if it was determined that the problem type was a constraint satisfaction problem. Transforming the received expression may include compiling, translating, grounding, or mapping the received expression into one or more increasingly primitive problem expressions, such as first order predicate logic expressions, propositional logic expressions, etc. In addition, transforming the received expression may include interacting with a database system to obtain one or more data items that are the subject of the problem specified by received expression (e.g., rows, tables, columns, values, etc.) and that are to be incorporated into the primitive problem expression. At 605, the module determines a solver that is configured to solve the primitive problem expression. As noted, determining a solver may include selecting a solver based on various factors, such as cost, solver capabilities, user specification, solver load, etc. At 606, the module invokes the determined solver to determine a solution to the primitive problem expression. Invoking the determined solver may include transmitting the primitive problem expression over a network that couples the module and the determined solver. In other cases, such as when the solver is executing locally, invoking the solver may include invoking one or more functions, operations, or methods provided by the solver. In addition, the solver may be provided by, or executing on, a digital and/or an analog processor.

At 607, the module transforms the determined solution into a data query language response, possibly based at least in part on data obtained from a database. In some cases, transforming the determined solution to a data query language response may include mapping the determined solution into the language and/or modeling domain of the received expression. For example, if the received expression is an SQL-like query received from a database client program, the determined solution may be mapped into a response (e.g., a database table) suitable for display and/or further manipulation by the database client program. Mapping the determined solution may also include interacting with a database system to obtain data to populate and/or generate result sets, tables, or other data structures that are to be provided as part of the response.

At 608, the module executes the received expression as a query on a database to obtain a data query response, if it was determined that the problem type was a standard database query. As discussed above, in some embodiments, the data query language used may be an extension of a standard relational database query language (e.g., SQL extended with FIND and/or other language features, as discussed in more detail below). In cases where the received expression does not utilize any of the extended features of the data query language, the received expression is an ordinary database query that can be executed directly via a database system, without utilization of a constraint solver. At 609, the module provides the data query response determined at 607 or 608. The method 600 terminates at 610, or alternatively may repeat by returning to 601.

A Data Query Language for Expressing Complex Problems

Figures 3A-3B illustrate various example constraint satisfaction problems that may be solved by at least one illustrated embodiment of the present systems, methods and articles. In addition, Tables 1-9, below, describe a data query language and provide examples of how the data query language may be used by a user (e.g., a programmer, software developer, etc.) to express constraint satisfaction problems, such as those illustrated with respect to Figures 3A-3B. Many important classes of problems may be represented at least in part as constraint satisfaction problems. For example, an optimization problem may be expressed as a set of constraints over one or more variables and an objective function, where the goal is to find a set of values that satisfies the constraints and maximizes/minimizes the objective function.

The data query language illustrated in Tables 1-9, below, is based on Structured Query Language ("SQL"). In particular, the illustrated data query language extends SQL by adding a new type of statement, a FIND FROM WHERE statement.

The FIND FROM WHERE statement differs from the known SELECT FROM WHERE statement in a number of respects. A SELECT statement, such as SELECT * FROM T WHERE c, directs a database system to obtain those tuples (e.g., rows) from table T where condition c is satisfied. The obtained tuples are provided as a results set. If t represents a row in T, then t is included in the result set whenever t satisfies condition c ( t ) . More formally, t is in the result set if and only if c (t ) is true. However, in the context of constraint satisfaction problems, it may be more convenient to express criteria that determine whether a particular row t should be in a given result by allowing greater flexibility in a rule or expression governing what can and cannot appear in the result.

In contrast, the FIND FROM WHERE statement directs a constraint solver system, such as the one described with reference to Figures 1 and 2, to find a solution table that contains a solution to a search condition. The search condition may express any logical relationship, not just if and only if relationships. The search condition may be used to declaratively express a variety of problems, such as constraint satisfaction problems, optimization problems, search problems, etc. In response to a FIND FROM WHERE statement, the constraint solver system generates a solution (if one exists) to the problem expressed in the WHERE clause, based on data (e.g., tables) indicated by the FROM clause.

In addition, a FIND FROM WHERE statement may also be executed in a manner different than that of a SELECT FROM WHERE statement. In particular, FIND statements are translated into a primitive logical description (e.g., a propositional logic formula) and a complete search is performed for solutions that satisfy all logical constraints expressed in the query. As noted, various algorithms and/or systems may be utilized to perform such searches, such as solvers executing on digital computing systems and/or analog computing systems. Table 1 describes the syntax of the FIND statement. In Table 1 , bold type (e.g., FIND, WHERE, etc.) identifies literal characters and keywords. Quotation marks (e.g., " >") surround literal characters. Braces (e.g., { " , " SOLUTIONJΓABLE } ) are used to group multiple syntactic elements repeated zero or more times. Segments surrounded by square brackets (e.g., [NOT] ) are optional. Segments surrounded by non-literal parenthesis and followed by a plus (e.g., ( " o " - " 9 " ) +), can be repeated one or more times.

Table 1

FIND ::= FIND LINTEGERJ SOLUTIONLTABLE {",

2. SOLUTION_TABLE>

Note that the structure of the FIND statement is similar to that of the SELECT statement. In the illustrated embodiment, the name of the solution table specified by the FIND statement may not be the name of a table that already exists in the database. This is because the operation of the FIND statement is to generate a new solution table. In other embodiments, the FIND statement may be configured otherwise, such as to silently overwrite a table having the same name as the specified solution table. In addition, if the underlying database system supports views, views may be substituted for tables in the context of a FIND statement.

In the illustrated embodiment, the FIND statement supports various SQL features. For example, the FIND statement supports embedded SELECT queries; logical operators such as NOT, AND, and OR; comparison operators such as =, <>, <, >, >=, and <=; and predicates such as EXISTS, IN, ANY, ALL, and BETWEEN. Other features may also be provided, such as set operators (e.g., UNION, INTERSECT, EXCEPT); subqueries in the FROM clause of a FIND statement; specifying the number of solutions to return (as an optional parameter immediately after the keyword FIND); and allowing table names to be qualified by schema names expressed in a FIND statement.

In addition, a number of logical predicates/operators are supported, including FORALL, FORSOME, IF, IFF, and succ. Such logical predicates may be employed by users to efficiently express complex problems that are to be solved by the constraint solver. The syntax of the FORALL predicate is

FORALL (Qry) t WHERE C

In the FORALL predicate, Qry is any query that can serve as a subquery in an EXISTS predicate, t is an identifier that can be a table alias, and c is a Boolean expression. The semantics of the FORALL predicate is: for all rows t given by the query Qry, C is true.

The FORALL predicate is logically equivalent to the following SQL expression:

NOT EXISTS (SELECT * FROM (Qry) t WHERE NOT C) To complement the FORALL statement, a FORSOME predicate is also available. The syntax of the FORSOME predicate is

FORSOME (Qry) t WHERE C

The FORSOME predicate is logically equivalent to the following SQL expression:

EXISTS (SELECT * FROM (Qry) t WHERE C)

In addition, an IF and IFF operator are provided. They are binary Boolean operators (like AND and OR), and have the following syntax:

Cl IF C2 Cl IFF C2

In the IF and I FF operators, Cl and C2 are Boolean expressions. The expression ci IF C2 is logically equivalent to the expression NOT C2 OR Cl . The expression Cl IFF C2 is logically equivalent to the expression (NOT

C2 OR Cl ) AND (NOT Cl OR C2 ) . Furthermore, a binary successor predicate, succ is provided. succ (ni , n2 ) is true if n2 is the "next" element of ni. In the context of the succ predicate, the values of ni and n2 must come from the same data domain (e.g., Integers), succ may be useful for problems involving an ordering of elements. In ordinary SQL, a general expression that is equivalent to the successor predicate may be lengthy and/or complex. For example, a user would typically have to specify that ni is less than n2, and nothing exists that is greater than ni and less than n2.

In one embodiment, a software module (e.g., a Java archive, a library, etc.) utilized by a client program (e.g., a database system client) translates a FIND statement to a description suitable for a constraint solver, obtains a solution from the constraint solver, and then maps the solution to a table specified by the FIND statement. Various solvers may be utilized, as illustrated by Table 2, below. Table 2

Example Problems

Various example problems are illustrated below including an English description of each problem and a corresponding FIND statement for expressing the problem in a declarative data query language. These problems are merely examples are not intended to be inclusive.

1. The Independent Set Problem

A sample Java-like pseudo-source code segment is shown below in Table 3. Such a code segment may be used to provide, via solver API, a problem expressed as a FIND statement to a local or remote optimization solver. In other embodiments, an optimization API for client programs may be provided for various other programming languages, such as C, C++, C#, Perl, Ruby, Python, JavaScript, Visual Basic, VBScript, etc. Java is here used as a non-exclusive example. The example code segment of Table 3 solves the independent set problem. The independent set problem is to find an independent set of nodes in a graph comprised of multiple vertices (e.g., nodes) connected by edges. An independent set contains vertices of a given graph that are not directly connected to each other. The maximum independent set ("MIS") problem is related to the independent set problem. The maximum independent set is the largest independent set of a given graph. MIS is representative of a broad class of complex (e.g., NP-hard) search and optimization problems.

Figure 3A illustrates example input and output graphs for the independent set problem solved by the code segment of Table 3. In particular, Figure 3A shows an input graph 300 and an output graph 310. Output graph 310 depicts an example independent set of input graph 300. More specifically, non- shaded vertices 5 and 2 of output graph 310 are an independent set of input graph 300. As is evident from the illustration, vertices 5 and 2 are not directly connected to one another by any edge. Other example independent sets include vertices 1 and 5, vertices 3 and 5, etc. In addition, Figure 3A shows a vertex table 301 named vertex and an edge table 302 named Edge used to represent input graph 300, along with a solution table 311 named indset used to represent the illustrated solution independent set.

In the following code segment, tables named Vertex and Edge are pre-existing, and a table named indset is generated as a result of execution of the FIND statement.

Table 3

// A Simple Java Program that uses the FIND statement to find // independent sets in a database import java.sql . DriverManager ; import qava.sql .Connection; import Java. sql .Statement; import java.sql .ResultSet;

// Define class FINDINDSET public class FINDINDSET { public static void main(String args[]) throws Exception {

// Load JDBC driver.

Cl ass . forNameC'com. dwavesys . jdbc.Dn^"ver") ;

// Create a connection to the database Connection conn = DriverManager. getconnection(

In lines 12-23, the above code segment allocates and configures a new object which provides an interface to a database and a local or remote solver. Then, in lines 26-32, the code segment defines a FIND statement as a string. In line 36, the code segment invokes execution of the defined FIND statement. Finally, in line 39, the code segment obtains the result of the execution.

The FIND statement defined on lines 26-32 defines a constraint satisfaction problem that is to be solved by the underlying optimization solver. More specifically, the FIND statement of lines 26-32 directs the optimization solver to find a solution table that, for a given graph, contains vertices of the graph, such that, for every pair of vertices in the solution table, the pair is not connected by an edge of the graph. First, the FIND statement specifies the solution table named indset that contains a single column named vtx. For this problem, the solution table will contain an independent set (if any exist). By using the TYPE keyword, vtx Vertex . vtχ%TYPE specifies that indset . vtx (e.g., column vtx in table indset) has the same type as Vertex , vtx (e.g., column vtx in table Vertex). This limits the result values in indset . vtx to those in Vertex, vtx. The TYPE keyword is provided as part of SQL by at least one vendor of database systems. Other vendors and/or implementations may provide alternative syntax to express and/or manipulate data types within queries or other programmatic expressions. Alternatively, a user may utilize the INTRANGE keyword to specify that indset . vtx is limited to a range of integers (e.g., vtx INTRANGE ( l . . 5) ).

As noted above, the FIND statement uses the FROM clause to specify the table or tables that the search condition of the WHERE will be checked against. The FIND statement of lines 26-32 specifies that there is one instance table named Edge.

As also noted above, the FIND statement uses the WHERE clause to specify constraints that must hold with respect to the specified solution table. The WHERE clause may contain Boolean expressions. The WHERE clause of lines 29-32 specifies that no two vertices in the independent set may be connected by an edge. The SELECT statement of lines 30-32 constructs an anonymous table from two copies of table indset, referred to by aliases indset l and Indset2. Each record in the anonymous table is a pair of vertices: one vertex from indset l (e.g., indset l . vtx) and one from indset 2 (e.g., indset 2 . vtx). The WHERE clause of lines 29-32 specifies that each record in the anonymous table has a condition, namely, that the two vertices must be connected by the Edge. That is because the illustrated WHERE clause requires that indset i . vtx equals Edge . vtxi and that indset 2 . vtx equals Edge . vtχ2. This condition is precisely what may not be true for a solution table that contains vertices of an independent set. Accordingly, the anonymous table should be empty for any solution table that contains an independent set of vertices. As such, the SELECT statement of lines 30-32 is preceded by the NOT EXI STS operator, which returns true if a SELECT statement provides an empty table. In contrast to the FIND statement as illustrated above, standard SQL cannot express the problem of finding one independent set of any size. This is because of the implicit if-and-only-if relationship between the rows in the result and the condition. However, it is awkward but possible to use standard SQL to find all independent sets of any size. The following example of Table 4 shows, given a set of vertices in a table and a set of edges in a table, a SELECT statement to find all independent sets of size five. Each row in the result corresponds to an independent set of size five.

Table 4

1. SELECT Vl. vtx, V2.vtx, V3.vtx, V4.vtx, V5.vtx

2. FROM vertex Vl, vertex V2, vertex V3, vertex V4, Vertex V5

3. WHERE NOT EXISTS

4. (SELECT * FROM Edge

5. WHERE (Vl. vtx = Edge.vtxl AND V2.vtx = Edge.vtx2)

6. OR (Vl. vtx = Edge.vtxl AND V3.vtx = Edge.vtx2)

7. OR (Vl. vtx = Edge.vtxl AND V4.vtx = Edge.vtx2)

8. OR (Vl. vtx = Edge.vtxl AND V5.vtx = Edge.vtx2)

9. OR (V2.vtx = Edge.vtxl AND V3.vtx = Edge.vtx2) 10. OR (V2.vtx = Edge.vtxl AND V4.vtx = Edge.vtx2) 11. OR (V2.vtx = Edge.vtxl AND V5.vtx = Edge.vtx2) 12. OR (V3.vtx = Edge.vtxl AND V4.vtx = Edge.vtx2) 13. OR (V3.vtx = Edge.vtxl AND V5.vtx = Edge.vtx2) 14. OR (V4.vtx = Edge.vtxl AND V5.vtx = Edge.vtx2))

A clear disadvantage of the query of Table 4 is the need to explicitly check that an edge does not connect each pair of vertices. Such an approach does not scale easily with larger graph sizes. In particular, approximately 5000 comparisons would be required for a graph of size 100. In addition, the SQL query of Table 4 searches for all independent sets of size five. If the goal is simply to find one independent set, then the query is computationally excessive with respect to the problem statement. The FIND version of the independent set problem illustrated in Table

3 is more flexible and easier to express than the corresponding standard SQL query. In particular, it allows rules to be specified on the table being defined (e.g., indset), in addition to those given (e.g., Vertex and Edge). This allows a user to efficiently express concepts such as: "Two vertices in indset may not be connected by any edge in Edge," which applies to independent sets of any size. Furthermore, there is no implicit if-and-only-if relationship between the rows in the solution table and the condition of the FIND statement. At a high level, a FIND query directs the solver to construct a table so that the given condition is satisfied. Advantageously, such an approach applies to all constraint satisfaction problems.

In contrast, in the standard SQL version of the independent set problem illustrated in Table 4, the user must construct a table from five copies of the table vertex. The rules that may be specified are restricted to the tables existing in the database (e.g., Vertex and Edge). The five copies of vertex form a big table, in which the specified rules check each record. Each record is in the result if and only if it satisfies the specified rules. A standard SQL SELECT query may only direct the database system to construct a table from a given set of rows, such that each record is in the table if and only if it satisfies the given condition. Such an approach is clearly more restrictive than the approach provided by the FIND statement, and does not apply cleanly to typical constraint satisfaction problems. In addition, suppose the number of vertices in an input graph is N. In order to find all independent sets of any size using standard SQL, a user would write a query similar to the one illustrated in Table 4, for each number from 1 to N. The results of all the queries plus the empty set would be the final result. Such an approach does not scale well with problem size.

In general, the FIND statement and other illustrated language features advantageously facilitate the expression of problems such as search and optimization problems in a manner that parallels the typical conception of such problems. In addition, the illustrated language features encourage a modular separation of problem solution descriptions and problem instances. For example, a user may declaratively express (e.g., by formulating a query) a solution to a problem, where the expressed solution is decoupled from specific instances of the problem (e.g., the content of the query is independent of the size of the particular problem instance being solved). In addition, a user may state a problem directly within SQL, by defining the logical constraints of a solution, as opposed to specifying operations, actions, or functions that are to be performed to obtain a solution. This declarative aspect is possible in part because the FIND statement allows for the specification of a solution table in terms of constraints that must hold for some or all data that is to be part of the solution table.

2. The Latin Square Completion Problem

A Latin Square of order N, where N is a positive integer, is an N-by-N matrix. In the matrix, N distinct elements (integers 1 to N) are arranged so that each element occurs exactly once in each row and in each column. The Latin Square completion problem is to complete a partially filled Latin Square. Figure 3B shows a problem square 321 , which is a partially filled in Latin Square, and a solution square 322, which is a possible solution to the problem square 321. In addition, Figure 3B shows two database tables that may be used to represent an example problem square. In particular, Figure 3B shows an element table 331 named Element and a matrix table 332 named Preassigned. In the illustrated example, the order N is 30, the table Element stores all 30 elements (e.g., integers 1 to 30), and the table Preassigned describes the partially filled matrix.

There is one solution table named LSC for this problem. It contains three columns, el em, mrow and mcol, specified as follows: LSC ( eletn Element . elem%TYPE , mrow INTRANGE ( 1 . . 3 0 ) , mcol INTRANGE ( 1 . . 3 O ) )

Each record in LSC will indicate that the element denoted by elem is in cell (mrow, mcol) in the matrix. Table 5, below, includes a FIND statement that may be used to solve the Latin Squares problem, as outlined above. Table 5

1. FIND LSC (el em Element. el em%TYPE,

2. mrow INTRANGE(I..30) ,

3. mcol INTRANGE(I..30))

4. FROM Preassigned p, Element e, INTRANGE(I. .30) n

5. WHERE EXISTS (SELECT * FROM LSC 1

6. WHERE l.elem = p.elem

7. AND l.mrow = p.mrow

8. AND l.mcol = p. mcol)

9. AND EXISTS (SELECT * FROM LSC 1

10. WHERE 1.el em = e.elem

11. AND l.mrow = n.intvalue)

12. AND EXISTS (SELECT * FROM LSC 1

13. WHERE l.elem = e.elem

14. AND l.mcol = n.intvalue)

15. AND NOT EXISTS (SELECT * FROM LSC U, LSC 12

16. WHERE U. el em = 12. el em

17. AND 1 l.mrow = 12. mrow

18. AND 1 l.mcol <> 12. mcol)

19. AND NOT EXISTS (SELECT * FROM LSC U, LSC 12

20. WHERE U.elem = 12.elem

21. AND 11. mrow <> 12. mrow

22. AND U. mcol = 12. mcol)

23. AND NOT EXISTS (SELECT * FROM LSC U, LSC 12

24. WHERE 1 l.mrow = 12. mrow

25. AND 1 l.mcol = 12. mcol

26. AND 11. el em <> 12. el em)

The example FIND statement of Table 5 shows how the keyword INTRANGE is used to declare the type of a column in the solution table. The columns mrow and mcol in LSC are given the type INTRANGE ( l . . 30 ) . This means that the possible values for both columns are integers 1 to 30.

In addition, an integer range type like INTRANGE ( I . .30 ) may be used as a table. This provides a convenient way to treat an integer range like a table when in fact it is not stored as a table in the database. In the illustrated example, on line 5, INTRANGE ( l . .30 ) is used to represent a table in the FROM clause. This table has one column, intvalue, whose possible values are exactly the integers in the range. 3. The Social Golfer Problem

The Social Golfer problem involves scheduling G ^* S golfers into G groups of S players over W weeks, where G, S and W are positive integers, such that no two golfers play in the same group for more than one week. In the following example, G is six, S is six and W is two. Therefore, there are a total of 6 * 6 = 36 golfers. The following example also specifies a solution table named Plays. Each record in Plays will denote that a golfer plr plays in the group grp in the week wk. The table Plays is specified as follows:

Plays (plr INTRANGE (1..36) , wk INTRANGE(I..2) , grp INTRANGE ( 1..6 ) )

To ensure that the size of each group is six, another solution table Map is introduced, which maps each week-player pair to a number between one and six. Players in the same group in any week must be mapped to unique numbers. Accordingly, because players can only be mapped to six numbers, the size of each group must be six. The table Map is specified as follows:

Map (wk INTRANGE ( 1..2 ), plr INTRANGE(I..36) , gs INTRANGE(I..6) ) Even though there are two solution tables, Plays and Map, a user would not ordinarily be interested in the definition of Map, because that table is just an auxiliary table that helps describe the problem. To exclude all Map rows from the result, the WANT clause may be used to specify that a user only wants to see the columns for Plays, as follows: WANT Plays. plr, Plays. wk, Plays. grp

Alternatively, since plr, wk and grp are all of the columns of the Plays table, a wildcard version of the WANT clause could be utilized. The following example specifies that a user wants to see all columns for plays.

WANT Pl ays . * Table 6, below, includes a FIND statement that may be used to solve the Social Golfer problem, as outlined above.

Table 6

4. The K-Coloring Problem

The K-Coloring problem states that, given a graph, color all its vertices using K different colors, where K is a positive integer, so that adjacent vertices have different colors. Two vertices are adjacent if they share the same edge. In this illustration, it is assumed that the database contains three tables named Vertex, Edge and Color, respectively. The solution table will be Coloring.

Table 7, below, includes a FIND statement that may be used to solve the K-Coloring problem, as outlined above.

Table 7

5. The SONET Problem

The following illustration is based on a simplification of the SONET problem. A SONET communication network has a number of rings, each of which connects some computers. The problem requires that, given N computers, where N is a positive integer, the N computers must be installed in rings, such that that a given communications demand is satisfied. The communications demand specifies which pairs of computers must communicate with each other. Two computers can communicate with each other if and only if they are in the same ring.

A positive integer, M, bounds the number of computers in each ring. In this illustration, M is three. It is further assumed that the database contains two tables named Computer and Demand, respectively, and that the solution table is named Network. Table 8, below, includes a FIND statement that may be used to solve a variation of the SONET problem outlined above. In this example, the SONET problem is simplified by allowing computer identifiers to be used as ring identifiers, and thus the columns cid and rid may be of the same type. This is possible because the number of rings is at most the number of computers.

Table 8

1. FIND Network (cid Computer.cid%TYPE,

2. rid Computer.cid%TYPE,

3. pos INTRANGE(I..3))

4. WANT cid, rid

5. FROM Computer com, Demand dmnd

6. WHERE com. cid IN (SELECT cid FROM Network)

7. AND EXISTS (SELECT * FROM Network nl, Network n2

8. WHERE nl.cid = dmnd.cidl

9. AND n2.cid = dmnd.cid2

10. AND nl.rid = n2.rid)

11. AND NOT EXISTS (SELECT * FROM Network nl, Network n2

12. WHERE nl.cid <> n2.cid

13. AND nl. rid = n2. rid

14. AND nl.pos = n2.pos)

15. AND NOT EXISTS (SELECT * FROM Network nl, Network n2

16. WHERE nl.cid = n2.cid

17. AND nl. rid = n2. rid

18. AND nl.pos <> n2.pos)

6. The Bounded Spanning Tree Problem

A spanning tree of a graph is a sub-graph that is a tree, which covers every vertex. In the bounded spanning tree problem, given a directed graph and a positive integer K, the problem seeks to find a spanning tree in which no vertex has an out-degree larger than K. In this illustration, K is two. It is further assumed that the database contains two tables named Vertex and Edge, respectively. In addition, the first solution table, Bstedge, includes the edges in the spanning tree. The second solution table, Permute, gives a permutation of the vertices in the graph. A permutation of the vertices ensures that each edge in the spanning tree must be from a vertex in a lower position in the permutation to a vertex in a higher position. Such an approach will prevent cycles from occurring. The third solution table, Map, maps each vertex to an integer between one and two. The table Map ensures that if there is an edge from a vertex v1 to vertex v2 and an edge from vertex v1 to vertex v3, then vertex v2 and vertex v3 must be mapped to different numbers. This approach restricts the out-degree of each vertex to be at most two.

Table 9, below, includes a FIND statement that may be used to solve a variation of the bounded spanning tree problem outlined above.

Table 9

In the FIND statement above in Table 9, the two NOT EXI STS predicates may have a nested NOT EXISTS predicate as shown below: NOT EXISTS (SELECT * FROM Permute p WHERE p . vtxl > 1

AND NOT EXISTS (SELECT * FROM Bstedge b

WHERE p.vtx2 = b.vtx2))

NOT EXISTS (SELECT * FROM Bstedge b

WHERE NOT EXISTS (SELECT * FROM Edge e

WHERE b.vtxl = e.vtxl AND b.vtx2 = e.vtx2))

The two predicates may be rewritten to remove the "double negation", (e.g., the nested NOT EXI STS predicate within the NOT EXI STS predicates). A FORALL predicate may be written as shown below to remove the "double negation":

(FORALL (SELECT * FROM Permute WHERE vtxl > 1) p

WHERE EXISTS (SELECT * FROM Bstedge b WHERE p.vtx2 = b.vtx2))

(FORALL (SELECT * FROM Bstedge) b

WHERE EXISTS (SELECT * FROM Edge e

WHERE b.vtxl = e.vtxl AND b.vtx2 = e.vtx2))

Although SQL was used as an illustrative data query language, other data query languages may be utilized such as, Object Query Language ("OQL"), Enterprise Java Beans Query Language ("EJBQL"), XQUERY, etc. In addition, at least some of the described techniques may be integrated into other types of programming languages, software development environments, or modeling systems, possibly for use in domains other than databases. Other types of programming languages include scripting languages, imperative languages (e.g., C, Pascal, Ada, etc.), functional languages (e.g., ML, Haskell, Miranda, etc.), logic programming languages (e.g., Prolog), constraint programming languages (e.g., CLP(R)), object-oriented languages (e.g., C#, Java, Smalltalk, etc.), etc. For example, extensions to SQL described herein may be equivalently implemented as a form of language integrated query in a language such as C# or Visual Basic. In addition, the methods, system, and article may be used in other problem domains, not just for databases. For example, the techniques described herein may be utilized in the context of modeling systems and/or frameworks, such as GAMS ("General Algebraic Modeling System"), AMPL ("A Modeling Language for Mathematical Programming"), etc.

Furthermore, while relational databases were used as an exemplary data source, the methods, system, and article may be utilized with various data sources. For example, in one embodiment, an object oriented database and/or an XML database may be used in addition to, or instead of, a relational database.

In addition, although the above examples illustrate language features that may be utilized by a user to obtain a result (e.g., a database table) that exactly matches a specified set of constraints, other matching semantics may also be supported. For example, in some embodiments, when no solution is found for a specified set of constraints, the constraints may be automatically relaxed so as to obtain one or more "approximate" solutions, even though that solution may not exactly match the specified set of constraints. In some cases, such approximate solutions may be ranked based on various criteria (e.g., number of constraints matched), so as to provide a "best" solution. In one embodiment, such automatic constraint relaxation may be implemented by configuring an analog processor to solve a maximum clique in a graph representative of the specified set of constraints. Additional details regarding automatic constraint relaxation and other techniques related to processing relational database problems using analog processors are provided in commonly assigned U.S. Provisional Patent Application No. 60/864,127, filed on November 2, 2006, and entitled "PROCESSING RELATIONAL DATABASE PROBLEMS USING ANALOG PROCESSORS". Conclusion

All of the U.S. patents, U.S. patent application publications, U.S. patent applications, foreign patents, foreign patent applications and non-patent publications referred to in this specification, including but not limited to U.S. Patent Application Publication No. 2006-0147154, U.S. Provisional Patent Application Serial No. 60/815,490, U.S. Provisional Patent Application Serial No. 60/864,127, US Provisional Patent Application No. 60/886,253, US Provisional Patent Application No. 60/915,657, and US Provisional Patent Application No. 60/975,083 are incorporated herein by reference, in their entirety and for all purposes. As will be apparent to those skilled in the art, the various embodiments described above can be combined to provide further embodiments. Aspects of the present systems, methods and articles can be modified, if necessary, to employ systems, methods, articles and concepts of the various patents, applications and publications to provide yet further embodiments of the invention. For example, the various methods described above may omit some acts, include other acts, and/or execute acts in a different order than set out in the illustrated embodiments.

Various ones of the modules may be implemented in existing database software, whether client-side or server-side. Suitable client-side software packages include use in database API layering (e.g., ODBC, JDBC). Similarly, suitable server-side software packages include, but are not limited to, SQL-based database engines (e.g., MySQL, Microsoft SQL Server, PostgreSQL, Oracle, etc.).

The present methods, systems and articles also may be implemented as a computer program product that comprises a computer program mechanism embedded in a computer readable storage medium. For instance, the computer program product could contain program modules. These program modules may be stored on CD-ROM, DVD, magnetic disk storage product, flash media or any other computer readable data or program storage product. The software modules in the computer program product may also be distributed electronically, via the Internet or otherwise, by transmission of a data signal (in which the software modules are embedded) such as embodied in a carrier wave. For instance, the foregoing detailed description has set forth various embodiments of the devices and/or processes via the use of block diagrams, schematics, and examples. Insofar as such block diagrams, schematics, and examples contain one or more functions and/or operations, it will be understood by those skilled in the art that each function and/or operation within such block diagrams, flowcharts, or examples can be implemented, individually and/or collectively, by a wide range of hardware, software, firmware, or virtually any combination thereof. In one embodiment, the present subject matter may be implemented via Application Specific Integrated Circuits (ASICs). However, those skilled in the art will recognize that the embodiments disclosed herein, in whole or in part, can be equivalently implemented in standard integrated circuits, as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more controllers (e.g., microcontrollers) as one or more programs running on one or more processors (e.g., microprocessors), as firmware, or as virtually any combination thereof, and that designing the circuitry and/or writing the code for the software and or firmware would be well within the skill of one of ordinary skill in the art in light of this disclosure.

In addition, those skilled in the art will appreciate that the mechanisms taught herein are capable of being distributed as a program product in a variety of forms, and that an illustrative embodiment applies equally regardless of the particular type of signal bearing media used to actually carry out the distribution. Examples of signal bearing media include, but are not limited to, the following: recordable type media such as floppy disks, hard disk drives, CD ROMs, digital tape, flash drives and computer memory; and transmission type media such as digital and analog communication links using TDM or IP based communication links (e.g., packet links).

Further, in the methods taught herein, the various acts may be performed in a different order than that illustrated and described. Additionally, the methods can omit some acts, and/or employ additional acts.

These and other changes can be made to the present systems, methods and articles in light of the above description. In general, in the following claims, the terms used should not be construed to limit the invention to the specific embodiments disclosed in the specification and the claims, but should be construed to include all possible embodiments along with the full scope of equivalents to which such claims are entitled. Accordingly, the invention is not limited by the disclosure, but instead its scope is to be determined entirely by the following claims.

While certain aspects of the invention are presented below in certain claim forms, the inventors contemplate the various aspects of the invention in any available claim form. For example, while only some aspects of the invention may currently be recited as being embodied in a computer-readable medium, other aspects may likewise be so embodied.

Claims

CLAIMSWe claim:

1. A method for processing problems expressed in a data query language, the method comprising: receiving an expression in a data query language; interacting with an analog processor configured to determine a response to at least some of the received expression; and providing the determined response.

2. The method of claim 1 , further comprising: transforming the received expression into a primitive problem expression.

3. The method of claim 2 wherein interacting with an analog processor includes invoking an optimization solver configured to determine a solution to the primitive problem expression, the optimization solver executing on the analog processor.

4. The method of claim 2 wherein transforming the received expression into a primitive problem expression includes transforming the received expression into a propositional logic formula, and wherein the analog processor is configured to determine a satisfying assignment to the propositional logic formula.

5. The method of claim 2 wherein transforming the received expression includes interacting with one or more data sources to obtain data, and wherein the primitive problem expression is based at least in part on the obtained data.

6. The method of claim 1 wherein receiving an expression in a data query language includes receiving an expression of an optimization problem.

7. The method of claim 1 wherein receiving an expression in a data query language includes receiving an expression of a constraint satisfaction problem.

8. The method of claim 1 wherein the receiving an expression in a data query language includes receiving an expression of a search problem.

9. The method of claim 1 , further comprising: interacting with a digital processor configured to determine a response to at least some of the received expression.

10. A computer-readable medium storing instructions for causing a computing system to process problems expressed in a data query language, by performing a method comprising: receiving a statement in a data query language; utilizing an analog processor configured to determine a response to at least some of the received statement; and providing the determined response.

11. The computer-readable medium of claim 10 wherein the determined response includes a plurality of solutions, and wherein providing the determined response includes providing two or more of the plurality of solutions.

12. The computer-readable medium of claim 10 wherein receiving a statement in a data query language includes receiving a statement that requests a predetermined number of solutions to an optimization problem.

13. The computer-readable medium of claim 10 wherein providing the determined response includes translating the determined response into a solution.

14. The computer-readable medium of claim 10 wherein providing the determined response includes mapping the determined response to a data query response based at least in part on data stored in a database.

15. The computer-readable medium of claim 10 wherein the method further comprises: obtaining data from a database based on a portion of the received statement, the portion of the received statement being distinct from the at least some of the received statement, wherein providing the determined response is based at least in part on the obtained data.

16. The computer-readable medium of claim 10 wherein the computer- readable medium is a recordable computer-readable medium.

17. The computer-readable medium of claim 10 wherein the computer readable medium is a data transmission medium.

18. A system for processing problems expressed in a data query language, the system comprising: a memory; and a module stored on the memory that is configured, when executed, to: receive a query in a data query language; invoke an analog processor configured to determine an answer to a portion of the received query; and provide the determined answer.

19. The system of claim 18 wherein the system is a computing system, and wherein the module contains instructions for execution in the memory of the computing system.

20. The system of claim 18 wherein the module is an optimization solver system.

21. The system of claim 18 wherein the analog processor includes a quantum processor including a plurality of qubits and a plurality of coupling devices coupling respective pairs of qubits.

22. The system of claim 18 wherein the portion of the received query expresses an optimization problem, and wherein the analog processor is configured to solve a graph problem that is equivalent to the optimization problem.

23. The system of claim 18 wherein the query is received from a client program executing on a remote computing system.

24. The system of claim 18 wherein the module is further configured to compile the query into a primitive problem solvable by the analog processor.

25. The system of claim 18, further comprising: a module stored on the memory that is configured, when executed, to invoke a digital processor configured to determine an answer to a portion of the received query.

26. A method for processing problems expressed in a data query language, the method comprising: receiving an expression in a data query language; transforming the received expression into a primitive problem expression; invoking an optimization solver configured to determine one or more solutions to the primitive problem expression; and providing the determined one or more solutions as a response to the received expression.

27. The method of claim 26 wherein the optimization solver executes on one or more analog processors.

28. The method of claim 26 wherein the optimization solver executes on a digital processor.

29. The method of claim 26 wherein receiving an expression in a data query language includes receiving an expression of a constraint satisfaction problem.

30. The method of claim 29 wherein invoking an optimization solver includes configuring an analog processor to provide an approximate solution to the constraint satisfaction problem by solving a graph problem representative of the constraint satisfaction problem.

31. The method of claim 26 wherein the receiving an expression in a data query language includes receiving an expression of a search problem.

32. The method of claim 26 wherein transforming the received expression into a primitive problem expression includes compiling the received expression into the primitive problem expression.

33. The method of claim 26 wherein transforming the received expression into a primitive problem expression includes grounding a first order logic formula into a propositional logic formula by replacing variables in the first order logic formula with constant symbols based at least in part on data stored in a database.

34. The method of claim 26 wherein the received expression includes a token indicating that the received expression specifies an optimization problem.

35. The method of claim 26, further comprising: receiving a second expression in a data query language; determining that the second expression does not specify an optimization problem; interacting with a database system configured to determine a response to the second expression; and providing the determined response to the received second expression.

36. The method of claim 35 wherein determining that the second expression does not specify an optimization problem is based at least in part on the second expression not including a token indicating that the second expression specifies an optimization problem.

37. The method of claim 26 wherein receiving an expression in a data query language includes receiving an expression of an NP-hard problem.

38. The method of claim 26, further comprising: performing the method a first time to obtain a solution to a specified problem with respect to a dataset of a first size; performing the method a second time to obtain a solution to the specified problem with respect to a dataset of a second size, wherein the second size is larger than the first size, and wherein the received expression is unchanged between the first and second performance of the method.

39. A computer-readable medium storing instructions for causing a computing system to process problems expressed in a data query language, by performing a method comprising: receiving a query; transforming a portion of the received query into a primitive problem expression; invoking an optimization solver configured to determine one or more solutions to the primitive problem expression; and providing the determined one or more solutions as a response to the received query.

40. The computer-readable medium of claim 39 wherein invoking an optimization solver includes interacting with a quantum processor configured to solve optimization problems.

41. The computer-readable medium of claim 39 wherein the method further comprises: obtaining data from a database based on at least some of the received query, the at least some of the received query being distinct from the portion of the received query, wherein providing the determined one or more solutions is based at least in part on the obtained data.

42. The computer-readable medium of claim 39 wherein receiving a query includes receiving a query that requests multiple solutions to an optimization problem, wherein the determined response includes a plurality of solutions, and wherein providing the determined one or more solutions includes providing two or more of the plurality of solutions.

43. The computer-readable medium of claim 39 wherein providing the determined one or more solutions includes translating at least one of the one or more solutions into data query language response based on data provided by a remote database system.

44. A system for processing problems expressed in a data query language, the system comprising: a memory; and a module stored on the memory that is configured, when executed, to: receive an statement in a data query language; compile a part of the received statement into a primitive problem expression; interact with an optimization solver configured to determine one or more solutions to the primitive problem expression; and provide the determined one or more solutions as a response to the received statement.

45. The system of claim 44 wherein the system is a computing system, and wherein the module contains instructions for execution in the memory of the computing system.

46. The system of claim 44 wherein the module is an optimization solver system.

47. The system of claim 44 wherein the optimization solver executes on a remote analog processor.

48. The system of claim 44 wherein the statement expresses an optimization problem, and wherein the optimization solver is configured to solve a graph problem that is equivalent to the optimization problem.

49. The system of claim 44 wherein the statement is received from a program executing on a remote computing system coupled to the system via a network.

50. The system of claim 44 wherein the data query language includes at least one of SQL, OQL, and EJBQL.

51. The system of claim 44 wherein the module includes an interface configured to provide data query functionality to a client program, the data query functionality being accessed by instructions of the client program, the instructions being in a programming language that is not a data query language.

52. The system of claim 51 , wherein the programming language is Java.