ProjectQ和IBMQ量子计算机

IBMQ提供了使用量子计算机的接口,ProjectQ用Python语言提供了一套量子计算描述语言,能够用于包含IBMQ真实量子计算机以及量子的经典模拟(通过算符运算)在内的多个后台。

由于教学(让学生做习题并且能够在实际量子计算机上验证)和研究(考虑量子博弈的真人实验)的需要,需要用量子计算机。就学习了一下。发现,非常简单易用,也很有系统性。

首先,在量子计算中,最基本的量子单位是自旋。于是,自旋的状态(二维Hilbert空间矢量)和算符(二维Hilbert空间矢量上的算符,例如Pauli矩阵、Hadamard门、围绕Z轴的旋转、测量等),就是这个ProjectQ的基本单元。当然,一些常用的高级功能例如CNOT门,以及Hadamard门和CNOT合起来的作用——称作纠缠算符等,也在ProjectQ中做了实现。

具体的文档见ProjectQIBMQ上的说明。下面用一个例子来说明一下整体结构,这样以后再一次学习起来简单。

这是我试着编写的程序quantum.py:

  1. 导入后台(模拟器、IBMQ、tex)和算符(H、测量、CNOT)

  2. from projectq import MainEngine
    from projectq.ops import H, Measure, CNOT
    from projectq.backends import CircuitDrawer
    import projectq.setups.ibm
    from projectq.backends import IBMBackend

  3. 这部分接收程序运行参数,在这里就是决定用什么后台。

  4. import sys, getopt

    def main(argv):
    s=1 #indicator of running this program via simulator or not
    tex=0 #indicator of converting this program into tex or not
    IBMQ=0 #indicator of running this program via IBMQ or not
    #take parameters from command-line input
    try:
    opts, args = getopt.getopt(argv, "s:", ["tex=", "IBMQ="])
    except getopt.GetoptError:
    print ("Error: please use the command as quantum.py -s --tex --IBMQ ")
    sys.exit(2)
    for opt, arg in opts:
    if opt == "-h":
    print("quantum.py -r --tex --IBMQ ")
    sys.exit()
    elif opt =="-s":
    s = int(arg) #when s=1, we need to run this program via simulator
    elif opt == "--IBMQ":
    IBMQ = int(arg) # when tex=1, we need to convert this program into a tex file
    s = 0 #when tex=1, we set s=0 (not to run this program in force)
    elif opt == "--tex":
    tex = int(arg) # when tex=1, we need to convert this program into a tex file
    s = 0 #when tex=1, we set s=0 (not to run this program in force)
    IBMQ = 0 #when tex=1, we set IBMQ=0 (not to run this program in force)
    #parameter input ends here

  5. 按照运行参数,开辟一个针对相应后台的环境。在这个环境之上,所有的命令不再需要关心后台的问题。

  6. # create a main compiler engine
    if(tex):
    drawing_engine = CircuitDrawer()
    eng = MainEngine(drawing_engine)
    elif(s):
    eng = MainEngine()
    elif(IBMQ):
    eng = MainEngine(IBMBackend(use_hardware=True, num_runs=1024, verbose=False, device='ibmqx4'))
    # allocate 2 qubit

  7. 在环境里面初始化qubit,并且把需要的算符一个个作用到这些个qubit上。

  8. qunum = eng.allocate_qureg(2)

    # put qubit 1 in superposition
    H | qunum[0]
    # put the two qubit in engtanglement
    CNOT | (qunum[0],qunum[1])
    # measure
    Measure | (qunum[0],qunum[1])

  9. 运行这些初始化状态和算符。

  10. eng.flush()

  11. 输出结果。

  12. if(tex):
    print(drawing_engine.get_latex())
    if(s):
    print("q1={}".format(int(qunum[0])))
    print("q2={}".format(int(qunum[1])))
    if(IBMQ):
    # access the probabilities via the back-end:
    results = eng.backend.get_probabilities(qunum)
    for state in results:
    print("Measured {} with p = {}.".format(state, results[state]))
    # return one (random) measurement outcome.
    return [int(q) for q in qunum]

最后运行python quantum.py就可以在不同的后台运行了。如果需要在IBMQ上运行,需要IBMQ的帐号和密码。

数学和科学、生活

今天这个例子就发生在上一个帖子的作者——一个差不多懂了系联性思考的硕士学生身上。同样非常有借鉴意义。我整理出来,分享在这里。

我用doodle设立了一个投票来确定这个学期的研究小组讨论时间。需要每一个参与讨论的人来参加这个投票,提供对自己来说可以实现的时间,然后,doodle就会做好一张网页表格,把每一个选项放在列上,每一个参与者的选择放在行上。我这个创建投票的人只需要看这张表就可以确定一个对所有人或者大多数人都能够用的时间了。

然后,这个学生选了三个选项。我就很好奇。问:为什么这样选啊?具体选择什么当然我也关心,不过我更好奇为什么这样选,真的只有这三个时间是可行的对这个学生来说?经过一番努力的沟通,发现,这个学生是这样来理解这个投票的。所谓投票就是在一堆选项中选自己最喜欢的,然后,最后,统计每一个选项有多少人喜欢,创建人选择得票最多的就行了。

确实,一般的称为“投票”的东西确实如此。

然后,学生意识到,可能我这么问,则表示这个背后的确定最后的选项的过程可能并不是这样。就说,我觉得可能这个doodle的程序不是这样运作的,得去想想这个程序如何运作。

另两个学生这时候提示,确定讨论时间的运算,实际上是在做集合的交集:把每一个参与者的集合拿过来,计算所有人的交集。

于是,首先,这个程序背后的算法不用去猜的,那就是计算交集,而且这个计算的人,就是我,doodle仅仅提供这张大表而已。

其次,更加根本的问题是,数学描述、数学计算过程或者软件系统背后的算法,都是为了解决某个具体问题的。我们只需要从问题开始思考,而不是从计算过程、软件算法开始思考。如果这个算法或者过程不能解决这个问题,那么,是算法和过程错了,而不是问题错了。

在具体这个问题上,就是你只需要思考确定一群人讨论的时间是什么样一个问题就可以了:由于首先的要求是要找到满足绝大多数人的选项,而不是选择所有人合起来最喜欢的选项,集合的并是最好的数学描述,而不是数票数。当然,如果每一个参与者把自己的喜好完全地揭示出来,则数票数和求集合的并是等价的。但是,一旦参与者用数票数的思路来提供信息——也就是仅仅选择自己最喜欢的选项而不是所有可能的选项(当然,将来还可以做更复杂的赋权),则两者就不等价了。结果上,很有可能这个参与者的最喜欢的选项被完全忽视。

因此,除了没有从问题开始思考,从情景开始思考,而是去猜背后可能的计算过程或者算法,还有另一个层面的问题:套路。当一个学生面对一个叫做“投票”的问题的时候,很可能就会直接套用投票的思路,而不去思考实际问题和情景。套路,真的要不得啊。面对任何具体问题,都要去思考,这个问题中有哪些因素,这些因素决定了我们必须用什么样的计算或者分析,而不是生搬硬套。

后来,我发现,这样来做会议时间投票的人还不少。看来,看不到“数学就是对问题和思考的表达,对问题里面的关系的描述”的人,还是真不少啊。可能大多数人的思考方式,真的是套路——先看看有没有一个自己知道如何应对的相似的,尽管可能仅仅是名以上、名字上相似,而不是关系上相似,问题,然后把这个问题里面的应对方式直接照搬过来。

顺便,关于这个问题,我们正在设计一个实验研究:一个情景A,一个情景B,两者具有一定相似性,但是,如果真的想明白则两者不一样,而且,我们保证实验参与者真的两者都是之前就了解的,甚至教过的学过的,然后我们来让实验参与者做决策。在这里,我们想探讨两个问题,知道(学过的能通过考试的)到能用(能够面对实际情景)的距离,以及基于套路而不是基于理性思考的决策的普遍性。将来我来报高这个研究结果。

用这个例子,来体现什么是数学,以及数学和科学、生活的关系。