ACM-SE 28最新文献

{"title":"An analysis of Ill-formed input in natural language queries","authors":"C. Young, C. Eastman, R. Oakman","doi":"10.1145/98949.99098","DOIUrl":"https://doi.org/10.1145/98949.99098","url":null,"abstract":"The most common errors were missing conjunc­ tions; 18.31 per cent of the queries lacked a needed con­ junction. In almost all of these, the English conjunction and was needed to connect a list of words in a scries. The next most serious problem was punctuation errors; these were cither incorrect, missing or misplaced punctuation. Most involved the comma or quotation mark combined with other punctuation markj. The queries containing punctuation errors totaled 6.81 per cent. The third most common type of ill-formed input was spelling errors; 2.34 per cent of the queries had a spelling error. Since some of the spelling errors had been corrected when the data was entered for the computer analysis, it is almost certain Uiat the original queries contained more spelling errors. We did not find any co-occurrence violations such as subjccl/vcrb disagreement or use of ellipsis. Slightly less than one third of the queries examined contained some form of error. This rate is comparable to that found in an earlier study (Eastman and McLean, 1981). However, at least one earlier study found almost no instances of ill-formed input (Fineman, 1983).","PeriodicalId":409883,"journal":{"name":"ACM-SE 28","volume":"16 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1990-04-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"115382392","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}

{"title":"Condition handlers for dataflow procedures","authors":"D. Langan","doi":"10.1145/98949.99092","DOIUrl":"https://doi.org/10.1145/98949.99092","url":null,"abstract":"In \"A Localized Condition Handling Construct for a Graphical Dataflow Language\" (this proceedings), a condition handling mechanism, called a node supervisor, is introduced. That construct is intended only for nodes and is used to provide condition detection and handling at the individual node level. The work described in that paper has been extended to consider additional issues that arise when considering conditions that impact the graph as a whole. If a node supervisor is unable to fully or properly respond to a given condition then that condition is posted to a \"higher\" level. That higher level, is called a procedure supervisor. A procedure supervisor can provide some of the same functionality as described for node supervisors, including input acceptance testing (IAT), output acceptance testing (OAT) and condition handling (CH). Procedure supervisors differ from node supervisors in several significant ways. In particular: (1) The conditions being posted to the condition handler may be coming from any one of the nodes hence node identification may be required as part of the condition posting process. (2) The procedure condition tokens may arrive in an asynchronous fashion at the dataflow procedure condition handler. (3) Support for a retry of the procedure as a whole requires additional system support in terms of the ability to halt currently executing nodes and to dispose of tokens scattered throughout the graph. (4) Termination of a dataflow procedure may be more difficult to detect than termination of an individual node. As with node supervisors, procedure supervisors can respond to conditions detected and posted by the system support. At the procedure wide level this can include conditions related to the configuration of the graph at lime of termination. For example, a programmer might have expectations that the graph and any initial tokens present return to the \"initial state\" by the time the procedure has finished executing. The notion of a snapshot that captures the details of a graph at some point during the execution is convenient. Expectations regarding the final state of the graph can be slated in terms of the terminal snapshot and the defining snapshot (i.e. the description of the original graph). Various levels of invariance can be identified in terms of differences between these two (c.g., variant, token invariant and totally invariant). The concept of a snapshot also proves to be a valuable one with respect to a condition handler requesting system support to capture the \"current” stale of execution for debugging purposes. One difficulty regarding gathering snapshots during execution is that, due to liming issues, the snapshot may not reflect the true stale at the moment that the request was made. The system support required for procedure supervisors is more extensive than that required for nodes supervisors. This is seen by looking at the need (a) to propagate a HALT to all nodes, (b) to delect procedure termination, (c) to gathe","PeriodicalId":409883,"journal":{"name":"ACM-SE 28","volume":"2 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1990-04-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"121039443","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}

{"title":"Predicting execution time of real-time programs on contemporary machines","authors":"M. Harmon","doi":"10.1145/98949.99074","DOIUrl":"https://doi.org/10.1145/98949.99074","url":null,"abstract":"A computer program that interacts with and reponds to real world processes in a timely fashion, and must com­ plete execution prior to its scheduled deadline, is called a ’’hard” real-time program. It is not sufficient for the implemented algorithm to be correct. The real-time pro­ gram must provide the correct response (computation) on time. A late computation is usually no better, possi­ bly even worse, than one that is on time but imprecise. The timing behavior of each real-time program compo­ nent (task) must be predictable if one is to build reliable deterministic real-time systems. Much of the research in real-time scheduling assumes that the execution lime of each task is known (e.g., Liu and Layland [2]). Work by Mok [3], on the use of semaphores, rendezvous, and monitors in real-time systems assumes that the (worst case) execution time of code segments is known. Stoyenko’s work [8] on the schedulability analyzer for Real-Time Euclid addressed the problem of worst case timing analysis of tasks, by assuming the execution time of each instruction is con­ stant. However, even the hardware builders [4] concede that the exact execution time of a given instruction may vary, depending upon the surrounding instructions and the current 6tate of the machine. Park and Shaw [5] implemented a timing tool for a subset of C, which is based on the notion of a timing schema presented in [7]. A method very similar to that of Shaw is presented by Puschner and Koza [6]. Shaw acknowledges that al­ though his approach seems to work well when applied to determinisitic hardware, more research is needed to determine timing predictability on contemporary ma­ chines.","PeriodicalId":409883,"journal":{"name":"ACM-SE 28","volume":"6 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1990-04-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"127533296","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}

{"title":"Delphi study of systems analysis","authors":"Clark B. Archer","doi":"10.1145/98949.98990","DOIUrl":"https://doi.org/10.1145/98949.98990","url":null,"abstract":"What does a systems analyst typically do on the job? What tasks and duties are associated with the process of software production and maintenance? To answer these questions the Delphi approach to expert consensus was used to define the areas of responsibility thought to be associated with software production and maintenance. Within each area of respon­ sibility duties were identified and enumerated. In a typical Delphi session, a group of experts is formed and presented with a specific problem. Experts were chosen from aerospace, academic, financial, textile, and software development or­ ganizations. The original question posed to the five experts was \"categorize the major areas of responsibility for systems analysis and design.\" After several iterations the panel of experts agreed that there are four major areas: • Provide ongoing support of existing systems. • Analysis and planning (for new systems). • Design support. • Project management. Based on the panel's consensus a questionnaire was constructed and sent to locations throughout the United States. Firms responding to the questionnaire represent the banking, aerospace, educa­ tion, chemical production, textile manu­ facturing, research, software develop­ ment, and defense industries. Of 114 questionnaires distributed a total of 94 completed questionnaires were received. The questionnaire data reveals a wide range of job titles. Ranging from very specific titles such as \"senior systems analyst for business systems\" to very","PeriodicalId":409883,"journal":{"name":"ACM-SE 28","volume":"61 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1990-04-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"124697323","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}

{"title":"A localized condition handling construct for a graphical dataflow language","authors":"D. Langan","doi":"10.1145/98949.99015","DOIUrl":"https://doi.org/10.1145/98949.99015","url":null,"abstract":"This paper gives a brief description of dataflow programming and of the condition handling constructs used in existing dataflow languages. It is argued that existing mechanisms arc deficient both in terms of flexibility and performance. A construct that provides for increased flexibility and improved performance is presented. The construct described here is called a supervisor and has three component parts called (a) the input acceptance lest, (b) the condition handler and (c) the output acceptance test. The basic dataflow model is expanded to include condition arcs and tokens. The construct presented here is a part of a more comprehensive scheme for condition handling in dataflow models [Langan 88]. AN INTRODUCTION TO DATAFLOW The increased use of computers, the decrease in (heir cost, and the application of computers to more complex problems, has led to languages and architectures designed to take advantage of increased processing power. Languages have evolved that allow the programmer to identify computations that can be executed in asynchronous fashion (e.g., Ada and Modula-2). Such parallel processing languages allow for a clear statement of algorithms that require parallel execution. The languages mentioned above all have one aspect in common; they are control flow based languages which assume multiple loci of execution. Another approach for the description of parallel computations is dataflow. The essential characteristics of basic datallow arc: (1) A dataflow graph is collection of nodes, each providing a side effect free function, connected by directed arcs. The arcs arc the data paths along which the data tokens flow from node to node. (2) A node executes (or fires), consuming its input tokens, only if the input it requires is available and if adequate space is available for anv output tokens.____________________________ Permission lo copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct com­ mercial advantage, live ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or lo republish, requires a fee and/or specific per­ mission. © 1990 ACM 0-89791-356-6/90/0400/0118 $1.50 (3) All communication including input values, output values and synchronization signals is via tokens. Figure 1: A Dataflow Graph Figure 1 shows a dataflow graph called G dial computes (a+b)*(a-b). The compulations for + and can be performed as soon as tokens holding values for a and b, appear on the input arcs to the nodes labeled N1 and N2. The + and may be executed in parallel. Dataflow languages differ from oilier parallel processing languages in that their execution is data driven as opposed lo being driven by control flow. Many descriptions of dataflow have appeared in the literature of the past twenty years. [Karp 1966, Dennis 1975, Landry 1981, Veen 1986], define","PeriodicalId":409883,"journal":{"name":"ACM-SE 28","volume":"45 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1990-04-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"130394015","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}

{"title":"Developing a modular image processing system under UNIX","authors":"S. A. Cover","doi":"10.1145/98949.99154","DOIUrl":"https://doi.org/10.1145/98949.99154","url":null,"abstract":"results o f an ongoing student project to create the softw are for a m odular general purpose digital im age p rocessing system suited to our departm ent's needs. The system serves a variety o f purposes. It is intended for use as a laboratory resource in conjunction with coursew ork as well as aid ing independen t research p ro jec ts in im age processing and com puter vision. In order to be effective as a laboratory resource, the system m ust have capabilities that arc both flex ib le and easy to use. M odular com ponents functioning like tools o r filters allow for the flexibility needed in a learning environm ent. For independent research p ro jec ts , it should provide a consistent set o f general u tilities that reduce the w orkload involved in experim entation. C onsequently , it is desirable to have a softw are system that is h ighly m odular and w hose com ponents can be used as tools in various com binations for specific tasks. M odularity provides ease o f use in that prospective users need to leam only about those com ponents that they need or desire to em ploy. M odifiability and increm ental expansion also resu lt from the use o f m odularity in the system. Other system s have been developed along these lines [1]. In short, an im age processing system in the sense that we intend it is a co n c is lcn t env ironm en t fo r the m anagem ent, storage, and p rocessing o f digital im age flics. The system was designed and developed for the departm ent's Hewlett Packard 9000 running HP-UX, a proprietary version o f the UNIX operating system. The UNIX environm ent offers a num ber o f advantages in realiz ing the staled objectives. One o f these advantages is the ability to reduce overhead by using processing pipes. The use o f software p ipelines in image processing is a generally accepted concept [2], Shell scripting also aids in the com bination of m odules that work together. Currently our progress has been focused on basic file m anipulation and upon some basic processing functions. We plan to add softw are to perform other standard image convolu tions such as the Fast Fourier Transform (FFT), as well as creating piped prefilters to adjust file form ats. A lthough progress has been made on creating an im age p rocessing system for use at Furm an U niversity , there is certainly a great deal o f work yet to be d o n e .","PeriodicalId":409883,"journal":{"name":"ACM-SE 28","volume":"185 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1990-04-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"126785504","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}

{"title":"Understanding chaos","authors":"E. Bax","doi":"10.1145/98949.99161","DOIUrl":"https://doi.org/10.1145/98949.99161","url":null,"abstract":"Over the summer of 1989 I worked as an undergraduate research student with Dr. Hayden Porter through a COSEN grant funded by the Pew Memorial Trust on a project entitled \"Understanding Chaos.\" I studied some of the history of research in the area of nonlinear systems, and my studies so far have concentrated mainly upon the logistic equation its behavior on both the real line and the complex plane, its properties, including scaling factors among some of the structures that arise within its domain, and how it can serve as a simplified model for studies of chaos in general. This paper represents a report on work which is still in progress as well as a review of some of the literature on nonlinear dynamics and a documentation of some of our results.","PeriodicalId":409883,"journal":{"name":"ACM-SE 28","volume":"43 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1990-04-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"114707054","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}

{"title":"A model for studying the spread of computer viruses","authors":"J. K. Harris, R. Trueblood","doi":"10.1145/98949.99127","DOIUrl":"https://doi.org/10.1145/98949.99127","url":null,"abstract":"Lillie or no data exists on the spread of computer viruses. It is unethical to release even a controlled virus and monitor its activity since that virus, while it is active, steals CPU cycles and storage space from an unknowing participant. Another avenue of study is to model a computer environment and simulate the model. The simulated model can then be studied without the undesirable side effects of a real virus. The model can also be used to gauge the vulnerability of computer systems to viral infections as well as to provide a means for determining preventative measures against viral infections. The model implemented consists of a college computer center and the activities that take place around the computer center. A virus is released into the modeled computer center, and the effects arc observed. The modeled computer center accommodates Five types of users: students, majors, graduate students (grads), faculty, and system managers. The model contains a set of general purpose microcomputers for students, majors, and grads. Each microcomputer has two floppy disk drives and a connection to a central file server. Access to the file server is controlled. Each user type can have read, rcad/writc, or no access to the file server node. The model provides each faculty member and system manager with a microcomputer that is networked to the file server node and is equipped with a hard disk drive. All users have their own personal set of diskettes. A typical user's activity is modeled in the following manner. Users enter the computer center, choose what media they need to access (file server, personal diskettes, etc.), and perform transactions. A transaction can be copying a program, deleting a program, or executing a program. At some point in lime, a virus is introduced. When an infected program is executed, the virus seeks out and infects an eligible program (or programs). The spread of the virus is monitored. Up to three viruses can be introduced at various times. The initial infection occurs on a diskette, a hard drive, or the file server. If two different viruses infect the same program, only the most recent infection is active. Robert P. Trucbloocl Departm ent o f Com puter Science U niversity o f South Carolina Colum bia, South C arolina 29208 After an infected program is executed a given number of times, the virus has the option to trigger (i.e., become active). A triggered virus lias the option to do one of three things. It can delete one program, delete all programs on a diskette, or delete all programs on a hard drive or file server. After a given period of time, llic virus has the option to deactivate and the next lime (lie host program is executed, the virus removes itself from the program. Users also can copy or delete programs. When users copy programs, they can copy the program to themselves or to a friend. Each user has a clique of friends. When users are Finished with the computer, they sign off and leave the computer center. This model","PeriodicalId":409883,"journal":{"name":"ACM-SE 28","volume":"15 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1990-04-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"115824488","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}

{"title":"The inclusion of data frames illustrating data flow in control structure charts for novice students","authors":"M. V. Doran, H. Longenecker","doi":"10.1145/98949.99083","DOIUrl":"https://doi.org/10.1145/98949.99083","url":null,"abstract":"Studies [3], [5] have demonstrated the power of graphical versus textual presentations. Our postulate slates that graphical definition must include a graphical representation of the data structures used [1]. Current research addresses the representation issue, the goal being not only to visually present graphical control flows but also the data being transformed by those control structures. The initial problem solving course at the USA is designed to teach concepts of algorithm formation as a method of solving formal analytic problems. Algorithms are defined graphically in control structure charts using textual dictionaries of variables. With this method, data is visualized graphically as it flows through the al­ gorithm. Research has been undertaken to investigate the necessary components and features required to support the environment. This research is based on Law’s work [4] defining structure charts in the SLAW (Structure Language Algorithm Writer) environment. A graphical tree represents the control flow of the algorithm. Textual dictionaries define the data structures employed. The flow of control is indicated by a hierarchy of shapes. SLAW has successfully been used as a teaching tool [2]. The primary focus of this research is the generation and investigation of a method for algorithm develop­ ment, DATA (Data to Algorithm Translation Analysis), entirely free of any programming language syntax, has been developed to graphically represent data structures and flows which yield structure charts in the SLAW method of algorithm development. The user creates a structure chart. Multiple dictionaries are now defined, each using graphical iconic symbols. Each lask/action in the chart will have associated with it a dictionary bubble which will become active and expand into a data window at the execution or reference of the lask/action. The data windows allow the user to monitor the data flows.","PeriodicalId":409883,"journal":{"name":"ACM-SE 28","volume":"44 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1990-04-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"127557372","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}

{"title":"The FHDL PLA tools","authors":"P. Maurer, C. D. Morency","doi":"10.1145/98949.98955","DOIUrl":"https://doi.org/10.1145/98949.98955","url":null,"abstract":"The FHDL (Florida Hardware Design Language) PLA tools provide a means for specifying, simulating, and automatically laying out Programmed Logic Arrays (PLAs). These tools were created to facilitate VLSI design projects, to improve the quality of hardware design courses, and to serve as a basis for future research in VLSI design automation. At the specification level, the PLA tools allow the contents of a PLA to be specified as a set of logic equations. In addition, they provide features for facilitating the construction of PLA-based state machines. Once a PLA has been specified, it can be simulated at a high level in coordination with the simulation of the other portions of a VLSI design. After a PLA has been verified through simulation, it can be laid out automatically through an interface to the Berkeley PLA layout tools. The primary motivation for developing these tools was to provide a basis for future research in VLSI design automation.","PeriodicalId":409883,"journal":{"name":"ACM-SE 28","volume":"113 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1990-04-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"117293334","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}