登录

没有账号?快速注册
合作账号登录

文章资讯 News每一个设计作品都举世无双

当前位置:主页 > 文章资讯 > 行业资讯 > 如何评价微软刚刚发布的量子编程语言 Q# ?

如何评价微软刚刚发布的量子编程语言 Q# ?

日期:2016-12-04 / 人气:43    分享到:


这里从程序语言的角度评价一下Q#

微软这次的Q#相当于IBM等的xxxkit而言,最大的不同是它是一个独立的程序语言,而后者只是一个程序包,或者是依赖json/xml的线路描述格式。

Q#非常强烈地体现了微软的一种思维:用语言定义行为,用语言规范框架。微软当年搞.Net Framework,觉得Java等不好用,就干脆重新造了一个新的语言C#; 微软想增强原来的命令行脚本,觉得原来的cmd没救了,干脆发明了一个新语言框架 Powershell; 而现在微软做前端框架和Nodejs库,觉得Javascript动态类型问题多,干脆发明了一个新语言Typescript; 而最近微软用coq这些做代码验证搞烦了,于是就新造了 Dafny 语言。这次微软搞 Q#,可以说完全在意料之中。

Q#通过自身的语言特性,试图解决以下问题:

1. 可扩展性,可重构性。Q#之前很多语言都是变相的标记语言,不过披着Python等的外衣。这些标记语言“忠实”地描述量子线路的结构以实现程序。这点类似于最早期的FORTRAN程序,它们跳转和循环是依赖行号的(相比早期汇编的地址已经是巨大进步了),一旦程序需要重构或者在中间加几行,往往是灾难性的:你需要自己更改全部行号。直到后来do-enddo,以及跳转标签等结构的引入,才为大规模程序设计铺平道路(典型地Pascal语言的发明使得编写通用操作系统变得更加可行(比如DOS“抄袭”的CPM系统),后来C的发明极大推进了这个过程)。
现在基于线路描述的量子程序存在同样的问题,一旦程序要进行扩展,或者重构,对原来的设计是灾难性的。Q#在更高的层级上描述量子程序,免去了这部分问题。

2. 动态性。用IBM等的工具构建量子线路时,一个显著的缺点在于无法动态运行线路。比如说,我希望通过测量某些qubit的结果,来控制接下来的量子线路的行为。虽然我们几乎总是可以才用延迟测量或者计数符合等方式避免中途测量,但是显然在实际实现中,越早进行测量是越好的,这是因为搭建经典控制线路的代价远低于量子线路,特别是在规模化的情况下,一个原则是尽可能增加线路经典部分,这样可以节约稀缺的量子线路资源,并且抵抗消相干等问题。而很多构建工具需要显示地预先compile线路,这样就没有办法执行复杂的经典控制。

3. 语义性。如何融合量子计算和经典计算之间的语义差异?我们可以看到,很多经典计算中的语义在量子计算中无法使用,比如递归(递归变量是qubit?),赋值(量子不可克隆原理),循环(同样地,qubit难以做循环控制变量)。为了解决这一点,Q#构建了一套基于类型系统的语义逻辑: 将qubit的“赋值”拆为2个部分,分别是Set和M,其中Set制备初态,将经典比特转化为量子比特; M是测量,将量子比特转化为经典比特。通过类型系统,经典比特得以进行我们熟知的各种运算,而量子比特只允许限定的量子门操作,或者被经典比特控制。这套系统可以通过类型检查来排除一些潜在的错误操作,熟悉编译原理也可以通过这个类型系统生成对应的控制逻辑。

当然最后一个问题是。。。Q#就目前而言在实际中有用吗?我想可能用处甚微,主要是目前的量子线路规模太小了,用手画都可以两三笔画出一个现在还没有实现的线路。。。Q#显然针对的是规模化的通用量子计算,可以认为这是微软对于量子计算高地的一个展望,但显然离真正发挥它的作用还差很远。


编辑:墨阁网络工作室


上一篇:网站制作标准化的优势介绍       下一篇:时光项目案例30