Eric K. Reuter, John P. Jeter, J. W. Anderson, B. Shriver
{"title":"区间算法的一些实验","authors":"Eric K. Reuter, John P. Jeter, J. W. Anderson, B. Shriver","doi":"10.1109/ARITH.1978.6155754","DOIUrl":null,"url":null,"abstract":"This paper reviews past experiences and discusses future work in the area of interval arithmetic at the University of Southwestern Louisiana(USL). Two versions of interval arithmetic were developed and implemented at USL(∗). An interval data type declaration and the necessary mathematical functions for this data type were added to Fortran via the preprocessor Augment(4, 5). In the first version, the endpoints of the intervals were represented as single percision floating point numbers. In the other version, the endpoints were represented to 56 decimal digits. Production engineering programs were run as benchmarks(8). The accumulation ot computational and algorithmic error could be observed as a widening of the intervals. The benchmarks were also run in normal single and double precision arithmetic. In some instances, the result obtained from a single or double precision calculation was not bounded by the corresponding interval result indicating some problem with the algorithm. The widening of an interval does not necessarily indicate a data sensitivity nor error in an algorithm. However, these large intervals can be used as indicator of no problems. As could be expected, the 56-decimal digit precision interval gave better results in terms of smaller intervals due to the increased amount of precision. The obvious problem with this version is that the amount of overhead required for its execution is high.","PeriodicalId":443215,"journal":{"name":"1978 IEEE 4th Symposium onomputer Arithmetic (ARITH)","volume":"55 1","pages":"0"},"PeriodicalIF":0.0000,"publicationDate":"1978-10-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":"9","resultStr":"{\"title\":\"Some experiments using interval arithmetic\",\"authors\":\"Eric K. Reuter, John P. Jeter, J. W. Anderson, B. Shriver\",\"doi\":\"10.1109/ARITH.1978.6155754\",\"DOIUrl\":null,\"url\":null,\"abstract\":\"This paper reviews past experiences and discusses future work in the area of interval arithmetic at the University of Southwestern Louisiana(USL). Two versions of interval arithmetic were developed and implemented at USL(∗). An interval data type declaration and the necessary mathematical functions for this data type were added to Fortran via the preprocessor Augment(4, 5). In the first version, the endpoints of the intervals were represented as single percision floating point numbers. In the other version, the endpoints were represented to 56 decimal digits. Production engineering programs were run as benchmarks(8). The accumulation ot computational and algorithmic error could be observed as a widening of the intervals. The benchmarks were also run in normal single and double precision arithmetic. In some instances, the result obtained from a single or double precision calculation was not bounded by the corresponding interval result indicating some problem with the algorithm. The widening of an interval does not necessarily indicate a data sensitivity nor error in an algorithm. However, these large intervals can be used as indicator of no problems. As could be expected, the 56-decimal digit precision interval gave better results in terms of smaller intervals due to the increased amount of precision. The obvious problem with this version is that the amount of overhead required for its execution is high.\",\"PeriodicalId\":443215,\"journal\":{\"name\":\"1978 IEEE 4th Symposium onomputer Arithmetic (ARITH)\",\"volume\":\"55 1\",\"pages\":\"0\"},\"PeriodicalIF\":0.0000,\"publicationDate\":\"1978-10-01\",\"publicationTypes\":\"Journal Article\",\"fieldsOfStudy\":null,\"isOpenAccess\":false,\"openAccessPdf\":\"\",\"citationCount\":\"9\",\"resultStr\":null,\"platform\":\"Semanticscholar\",\"paperid\":null,\"PeriodicalName\":\"1978 IEEE 4th Symposium onomputer Arithmetic (ARITH)\",\"FirstCategoryId\":\"1085\",\"ListUrlMain\":\"https://doi.org/10.1109/ARITH.1978.6155754\",\"RegionNum\":0,\"RegionCategory\":null,\"ArticlePicture\":[],\"TitleCN\":null,\"AbstractTextCN\":null,\"PMCID\":null,\"EPubDate\":\"\",\"PubModel\":\"\",\"JCR\":\"\",\"JCRName\":\"\",\"Score\":null,\"Total\":0}","platform":"Semanticscholar","paperid":null,"PeriodicalName":"1978 IEEE 4th Symposium onomputer Arithmetic (ARITH)","FirstCategoryId":"1085","ListUrlMain":"https://doi.org/10.1109/ARITH.1978.6155754","RegionNum":0,"RegionCategory":null,"ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":null,"EPubDate":"","PubModel":"","JCR":"","JCRName":"","Score":null,"Total":0}
This paper reviews past experiences and discusses future work in the area of interval arithmetic at the University of Southwestern Louisiana(USL). Two versions of interval arithmetic were developed and implemented at USL(∗). An interval data type declaration and the necessary mathematical functions for this data type were added to Fortran via the preprocessor Augment(4, 5). In the first version, the endpoints of the intervals were represented as single percision floating point numbers. In the other version, the endpoints were represented to 56 decimal digits. Production engineering programs were run as benchmarks(8). The accumulation ot computational and algorithmic error could be observed as a widening of the intervals. The benchmarks were also run in normal single and double precision arithmetic. In some instances, the result obtained from a single or double precision calculation was not bounded by the corresponding interval result indicating some problem with the algorithm. The widening of an interval does not necessarily indicate a data sensitivity nor error in an algorithm. However, these large intervals can be used as indicator of no problems. As could be expected, the 56-decimal digit precision interval gave better results in terms of smaller intervals due to the increased amount of precision. The obvious problem with this version is that the amount of overhead required for its execution is high.