Quantum computing is the delicate art of using a quantum-mechanical system to perform some kind of computation. Such a system differs in a number of significant ways from ordinary computers:• A quantum computer actually does a lot of computations at the same time, each solution is represented by a particular possible state. This is inherent to the physical properties of such a system.• Unless you are sure that you have reached the final (unique) solution, you can not "look" at the "values" of the variables in the computer program that is being run: since all solutions are possible at the same time, observing the values will influence the system and put it into one particular, but otherwise arbitrary, state.• All computations must be reversible, that is, a statement like "a = 5" can only appear in the initialization phase of a program, because the previous value will be lost. On the other hand, a statement like "a = a + 5" is reversible, since you can retrieve the original value.The properties of such a quantum computer make it possible to devise very efficient algorithms. One such algorithm, described by L. Grover (see the references), is searching in an unsorted array of items. With ordinary computers this can not be done more efficiently than in O(N) steps (an exhaustive search: each item is examined in the worst case), with this quantum algorithm, however, the number of steps needed is O(N1/2).Devising quantum algorithms requires a thorough understanding of quantum mechanics, there is no doubt about that. Another question is: do we need quantum computers and special programming languages to program (or perhaps emulate) these algorithms? This article tries to show that, at least for the quantum search algorithm, a classical programming language like Fortran is quite fit (yes, the pun is fortunate).
量子计算是使用量子力学系统来执行某种计算的微妙艺术。这样的系统在许多重要方面与普通计算机不同:•量子计算机实际上同时进行大量计算，每个解决方案都由特定的可能状态表示。这是这种系统的物理特性所固有的。除非你确信你已经得到了最终的(唯一的)解，否则你不能“看”正在运行的计算机程序中变量的“值”:因为所有的解都可能同时出现，观察这些值会影响系统，使它进入一个特定的，但在其他方面是任意的状态。•所有的计算必须是可逆的，也就是说，像“a = 5”这样的语句只能出现在程序的初始化阶段，因为之前的值会丢失。另一方面，像“a = a + 5”这样的语句是可逆的，因为您可以检索原始值。这种量子计算机的特性使得设计非常高效的算法成为可能。L. Grover描述的一种这样的算法(请参阅参考资料)是在未排序的项数组中进行搜索。对于普通计算机来说，这比O(N)步(一个穷举搜索:在最坏的情况下检查每个项目)更有效，但是对于这个量子算法，所需的步骤数是O(N1/2)。设计量子算法需要对量子力学有透彻的理解，这是毫无疑问的。另一个问题是:我们是否需要量子计算机和特殊的编程语言来编程(或者模拟)这些算法?本文试图表明，至少对于量子搜索算法，像Fortran这样的经典编程语言是非常合适的(是的，双关语是幸运的)。
{"title":"Quantum computing in Fortran","authors":"A. Markus","doi":"10.1145/1024334.1024335","DOIUrl":"https://doi.org/10.1145/1024334.1024335","url":null,"abstract":"Quantum computing is the delicate art of using a quantum-mechanical system to perform some kind of computation. Such a system differs in a number of significant ways from ordinary computers:• A quantum computer actually does a lot of computations at the same time, each solution is represented by a particular possible state. This is inherent to the physical properties of such a system.• Unless you are sure that you have reached the final (unique) solution, you can not \"look\" at the \"values\" of the variables in the computer program that is being run: since all solutions are possible at the same time, observing the values will influence the system and put it into one particular, but otherwise arbitrary, state.• All computations must be reversible, that is, a statement like \"a = 5\" can only appear in the initialization phase of a program, because the previous value will be lost. On the other hand, a statement like \"a = a + 5\" is reversible, since you can retrieve the original value.The properties of such a quantum computer make it possible to devise very efficient algorithms. One such algorithm, described by L. Grover (see the references), is searching in an unsorted array of items. With ordinary computers this can not be done more efficiently than in O(N) steps (an exhaustive search: each item is examined in the worst case), with this quantum algorithm, however, the number of steps needed is O(N1/2).Devising quantum algorithms requires a thorough understanding of quantum mechanics, there is no doubt about that. Another question is: do we need quantum computers and special programming languages to program (or perhaps emulate) these algorithms? This article tries to show that, at least for the quantum search algorithm, a classical programming language like Fortran is quite fit (yes, the pun is fortunate).","PeriodicalId":379614,"journal":{"name":"ACM SIGPLAN Fortran Forum","volume":"29 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2004-08-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"134505361","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
The concept is that you start with a base source routine that contains more-or-less normal source. This source also contains a number of tokens that start with "$". Make_rood replaces these tokens with strings that are dependent on things such as the data type for which a routine is being built and the ranks of the input and output arrays. The replacement of tokens is done a number of times, creating a collection of subroutines for all the data types and ranks of interest. Make_rood outputs a module that contains all the required header information and the collection of specific routines. From a single common routine you can create a module that might contain hundreds of specific routines.
{"title":"A methodology for creating large modules","authors":"T. Kaiser","doi":"10.1145/962180.962182","DOIUrl":"https://doi.org/10.1145/962180.962182","url":null,"abstract":"The concept is that you start with a base source routine that contains more-or-less normal source. This source also contains a number of tokens that start with \"$\". Make_rood replaces these tokens with strings that are dependent on things such as the data type for which a routine is being built and the ranks of the input and output arrays. The replacement of tokens is done a number of times, creating a collection of subroutines for all the data types and ranks of interest. Make_rood outputs a module that contains all the required header information and the collection of specific routines. From a single common routine you can create a module that might contain hundreds of specific routines.","PeriodicalId":379614,"journal":{"name":"ACM SIGPLAN Fortran Forum","volume":"68 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2003-12-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"114668479","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
This article discusses a semiautomatic method of determining the floating-point and integer types available to a Fortran compiler on a given machine. These types are then characterized using a collection of intrinsic routines and other algorithms. Also, the possibility of unexpected truncation when assigning constants to variables is examined. The use of the algorithms discussed herein can lead to a better understanding of a particular compiler or machine and, more portable and accurate programs.
{"title":"Semiautomatic characterization of Fortran 90 compilers","authors":"T. Kaiser","doi":"10.1145/962180.962181","DOIUrl":"https://doi.org/10.1145/962180.962181","url":null,"abstract":"This article discusses a semiautomatic method of determining the floating-point and integer types available to a Fortran compiler on a given machine. These types are then characterized using a collection of intrinsic routines and other algorithms. Also, the possibility of unexpected truncation when assigning constants to variables is examined. The use of the algorithms discussed herein can lead to a better understanding of a particular compiler or machine and, more portable and accurate programs.","PeriodicalId":379614,"journal":{"name":"ACM SIGPLAN Fortran Forum","volume":"32 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2003-12-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"129329612","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
In a note in the Fortran Forum, Markus describes a technique for avoiding memory leaks with derived types. In this note, we show by a simple example that this technique does not work when the object in question is a parameter in nested subprogram invocations. A fix is proposed and illustrated with code from MATRAN, a Fortran 95 package for performing matrix manipulations.
{"title":"Memory leaks in derived types revisited","authors":"G. Stewart","doi":"10.1145/962180.962183","DOIUrl":"https://doi.org/10.1145/962180.962183","url":null,"abstract":"In a note in the Fortran Forum, Markus describes a technique for avoiding memory leaks with derived types. In this note, we show by a simple example that this technique does not work when the object in question is a parameter in nested subprogram invocations. A fix is proposed and illustrated with code from MATRAN, a Fortran 95 package for performing matrix manipulations.","PeriodicalId":379614,"journal":{"name":"ACM SIGPLAN Fortran Forum","volume":"22 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2003-12-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"126267733","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
In this short note a solution is presented for one particular type of memory leak that can occur with derived types. With the advent of Fortran 2X and, before that, the adoption of Technical Report ISO/IEC 15581: 1998(E) (the "allocatable array extension") this solution will be superfluous, nevertheless it seems worthwhile to describe it, as it can solve the problem in the short term.
{"title":"Avoiding memory leaks with derived types","authors":"A. Markus","doi":"10.1145/941558.941559","DOIUrl":"https://doi.org/10.1145/941558.941559","url":null,"abstract":"In this short note a solution is presented for one particular type of memory leak that can occur with derived types. With the advent of Fortran 2X and, before that, the adoption of Technical Report ISO/IEC 15581: 1998(E) (the \"allocatable array extension\") this solution will be superfluous, nevertheless it seems worthwhile to describe it, as it can solve the problem in the short term.","PeriodicalId":379614,"journal":{"name":"ACM SIGPLAN Fortran Forum","volume":"11 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2003-08-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"125630578","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
In Las Vegas, WG5 held a joint meeting with J3 and considered all the ballot comments (details in N1506 and N1509) and agreed on how to respond (see N1520). WG5 decided to delegate editorial comments and very minor technical comments to J3 to take whatever action it considered appropriate. The 35 items that came with detailed edits and were considered by WG5 itself are summarized in N1521. Of these, the UK proposed 20, USA proposed 15, and Germany proposed 11 (some items were proposed more than once, sometimes with slightly different details). 28 of the items were accepted (UK: 17, USA: 13, Germany: 8). All the comments from Japan were minor and were delegated to J3.
{"title":"Fortran 2000 CD ballot and WG5's response","authors":"J. Reid","doi":"10.1145/941558.941562","DOIUrl":"https://doi.org/10.1145/941558.941562","url":null,"abstract":"In Las Vegas, WG5 held a joint meeting with J3 and considered all the ballot comments (details in N1506 and N1509) and agreed on how to respond (see N1520). WG5 decided to delegate editorial comments and very minor technical comments to J3 to take whatever action it considered appropriate. The 35 items that came with detailed edits and were considered by WG5 itself are summarized in N1521. Of these, the UK proposed 20, USA proposed 15, and Germany proposed 11 (some items were proposed more than once, sometimes with slightly different details). 28 of the items were accepted (UK: 17, USA: 13, Germany: 8). All the comments from Japan were minor and were delegated to J3.","PeriodicalId":379614,"journal":{"name":"ACM SIGPLAN Fortran Forum","volume":"22 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2003-08-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"131479959","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
This paper does not contain examples; you can find examples in earlier papers describing Fortran 2000 features and in the draft document itself. This paper is merely a status report of which features are contained, and which have been removed during the last few meetings (especially the joint WG5/J3 meeting held last spring in Las Vegas). Readers may also fmd last August's Fortran Forum and WG5 paper N1522 to be interesting.
{"title":"What's new in Fortran 2000?","authors":"D. Nagle","doi":"10.1145/941558.941561","DOIUrl":"https://doi.org/10.1145/941558.941561","url":null,"abstract":"This paper does not contain examples; you can find examples in earlier papers describing Fortran 2000 features and in the draft document itself. This paper is merely a status report of which features are contained, and which have been removed during the last few meetings (especially the joint WG5/J3 meeting held last spring in Las Vegas). Readers may also fmd last August's Fortran Forum and WG5 paper N1522 to be interesting.","PeriodicalId":379614,"journal":{"name":"ACM SIGPLAN Fortran Forum","volume":"129 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2003-08-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"121809753","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Who should read the book? Anyone, I would say, with a fair knowledge of FORTRAN 77 who wants to get acquainted with new constructs that Fortran 90/95 offers, because the book discusses array operations, source code organization via modules and so on. Also, anyone with knowledge of Fortran 90/95 who wants to know more about object-oriented programming. The last category that I would like to list are those who are interested in the capabilities of various programming languages.
{"title":"Review of \"Object-oriented Programming via Fortran 90/95 by Ed Akin.\" Cambridge University Press, 2003","authors":"A. Markus","doi":"10.1145/941558.941560","DOIUrl":"https://doi.org/10.1145/941558.941560","url":null,"abstract":"Who should read the book? Anyone, I would say, with a fair knowledge of FORTRAN 77 who wants to get acquainted with new constructs that Fortran 90/95 offers, because the book discusses array operations, source code organization via modules and so on. Also, anyone with knowledge of Fortran 90/95 who wants to know more about object-oriented programming. The last category that I would like to list are those who are interested in the capabilities of various programming languages.","PeriodicalId":379614,"journal":{"name":"ACM SIGPLAN Fortran Forum","volume":"22 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2003-08-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"130231250","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
京公网安备 11010802042870号
京ICP备2023020795号-1
扫码关注我们
求助内容：
应助结果提醒方式：