Semantic errors in SQL queries: a quite complete list We investigate classes of SQL queries which are syntactically correct, but certainly not intended, no matter for which task the query was written. For instance, queries that are contradictory, i.e. always return the empty set, are obviously not intended. However, current database management systems execute such queries without any warning. In this paper, we give an extensive list of conditions that are strong indications of semantic errors. Of course, questions like the satisfiability are in general undecidable, but a significant subset of SQL queries can actually be checked. We believe that future database management systems will perform such checks and that the generated warnings will help to develop code with fewer bugs in less time. Errors in SQL queries can be classified into syntactic errors and semantic errors. A syntactic error means that the entered character string is not a valid SQL query. In this case, any DBMS will print an error message because it cannot execute the query. Thus, the error is certainly detected and usually easy to correct.. A semantic error means that a legal SQL query was entered, but the query does not or not always produce the intended results, and is therefore incorrect for the given task. Semantic errors can be further classified into cases where the task must be known in order to detect that the query is incorrect, and cases where there is sufficient evidence that the query is incorrect no matter what the task is. Our focus in this paper is on this latter class, since there is often no independent specification of the goal of the query. For instance, consider this query:. SELECT * FROM EMP WHERE JOB = 'CLERK' AND JOB = 'MANAGER' This is a legal SQL query, and it is executed e.g. in Or-acle9i and DB2 V8.1 without any warning. However, the condition is actually inconsistent, so the query result will be always empty. Since nobody would use a database in order to get an always empty result, we can state that this query is incorrect without actually knowing what the task of the query was. Such cases do happen, e.g. in one exam exercise that we analyzed, 10 out of 70 students wrote an inconsistent condition. It is well known that the consistency of formulas is undecidable, and that this applies also to database queries. However, although the task is in general undecidable, many cases that occur in practice can be detected with relatively simple algorithms.. Our work is also inspired by the program lint, which is or was a semantic checker for the "C" programming language. Today C compilers do most of the checks that lint was developed for, but in earlier times, C compilers checked just enough so that they could generate machine code. We are still at this development stage with SQL today. Printing warnings for strange SQL queries is very uncommon in current database management systems.. We currently develop a similar tool for SQL queries (called sqllint). We believe that such a tool would be useful not only in teaching, but also in application software development. At least, a good error message could speed up the debugging process. Furthermore, runtime errors are possible in SQL, e.g., in some contexts, SQL queries or subqueries must return not more than one row. The occurrence of this error depends on the database state (the data), therefore it is no necessarily found during testing. Certainly it would be good to prove that all queries in a program can never violate this condition. Our tool does not depend on the data, it only takes the schema information (including constraints) and an SQL query as input. Therefore, it is not necessary to check the queries in each execution.. The main contribution of this paper is a list of semantic errors that represents years of experience while cor-recting hundreds of exams that contained SQL queries. However, we have also tried to explain the general principles from which these errors can be derived (as far as possible). Therefore, it is not simply by chance whether an error appears on our list, but the list has a certain degree of completeness (except possibly in Section 4).. While our experience so far has only been with errors made by students, not professional programmers, most of the students will become programmers, and they will not immediately make fewer errors.. The paper is structured by reasons why SQL queries can be considered suspicious: Unnecessary complications (Section 2), inefficient formulations (Section 3), violations of standard patterns (Section 4), many duplicates (Section 5), and the possibility of runtime errors (Section 6). Furthermore we suggest some style checks in Section 7. Section 8 contains some statistics how often errors appeared in exams. Related work is discussed in Section 9.. In the examples, we use a database schema for storing information about employees and departments: EMP(EMPNO, ENAME, JOB, SAL, COMM, DEPTNO→DEPT) DEPT(DEPTNO, DNAME, LOC) This is a simplified version of an example schema that comes with the Oracle DBMS. There is a large class of SQL queries that are syntactically correct, but nevertheless certainly not intended, no matter what the task of the query might be. One could expect that a good DBMS prints a warning for such queries, but, as far as we know, no DBMS does this yet.. We are currently developing a tool "sqllint" for finding semantic errors in SQL queries. The list of error types contained in this paper can serve as a specification of the task of this tool. We have algorithms for all of the error types (for a suitable SQL subset), but for space reasons, we could not present them here (see, however, the technical report [1] ). The error checks can often be reduced to a consistency test. While the undecidability in the general case remains, we can at least use the mature methods of automated theorem proving. We also have simpler, direct sufficient conditions for some of the errors. The current state of the project is reported at: http://www.informatik.uni-halle.de /˜brass/sqllint/ In future work, we especially want to investigate patterns for SQL queries in greater detail (by analyzing a large collection of SQL queries from real projects).. The authors would be thankful for reports about any further semantic errors or violations of good style that are not treated in this paper.

O B O B B O O O O O O O O B B O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O B B O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O B O B B O O O O O B O O B O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O B B O O O O O O O O O O O O O O O B B O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O B O O O B O O O O B B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O B O O O O O O O O O O O O O O B O O O O O O O O O O O O B B O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O B O O O O O O O B B O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O B O B B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O B B O O O O O O O O O B B O O O O O O O O O O O O O O B O O O O O O O O O O O O


Evolution and sustainability of a wildlife monitoring sensor network As sensor network technologies become more mature, they are increasingly being applied to a wide variety of applications, ranging from agricultural sensing to cattle, oceanic and volcanic monitoring. Significant efforts have been made in deploying and testing sensor networks resulting in unprecedented sensing capabilities. A key challenge has become how to make these emerging wireless sensor networks more sustainable and easier to maintain over increasingly prolonged deployments.In this paper, we report the findings from a one year deployment of an automated wildlife monitoring system for analyzing the social co-location patterns of European badgers (Meles meles) residing in a dense woodland environment.We describe the stages of its evolution cycle, from implementation, deployment and testing, to various iterations of software optimization, followed by hardware enhancements, which in turn triggered the need for further software optimization. We report preliminary descriptive analyses of a subset of the data collected, demonstrating the significant potential our system has to generate new insights into badger behavior. The main lessons learned were: the need to factor in the maintenance costs while designing the system; to look carefully at software and hardware interactions; the importance of a rapid initial prototype deployment (this was key to our success); and the need for continuous interaction with domain scientists which allows for unexpected optimizations. The deployment of sensor networks in a variety of realworld applications is gradually turning from scientific vision to reality. A multitude of systems have already been deployed, ranging from glacier monitoring [4] to real time environmental and wildlife tracking [30] [20] . Such systems have enabled the collection of spatio-temporal data at unprecedented granularities, and have revolutionized the way in which scientists perform field experiments. At the same time, with the outset of new sensor deployments, the need has come to maintain sensor networks over prolonged deployment periods. Low effort maintenance and self-reconfiguration have in fact been the idealistic selling points of wireless sensor networks. Network maintenance may involve a number of tasks, such as changing batteries, replacing faulty nodes and collecting data from specialpurpose storage or gateway nodes. When the maintenance costs exceed user expectations and budget, there is a need to develop the system and make it sustainable. In this paper, we describe one such system and present our experience in building and developing a sustainable wireless sensor network. Our system consists of a distributed wireless sensor network designed to monitor wildlife and environmental conditions in a dense woodland environment, in Wytham Woods, Oxfordshire, UK. The system is made up of three components. The first consists of active RFID transmitters that are attached directly to European badgers (Meles meles) as wearable collars. They are monitored by a second component consisting of a collection of fixed detection nodes that are distributed throughout the woods at key locations close to known badger setts and latrines. The third component further complements the assembly by providing a bed of fixed sensor nodes that are deployed within badger foraging areas to monitor micro-climatic conditions and their effect on species migration and mobility patterns.. We first describe the initial 'exploratory' field-deployable prototype designed to understand the domain requirements and the usage patterns. We then describe gradual alterations to initial design based on feedback from the zoologists. In particular, we evaluate each iteration in terms of maintenance cost and find that the initial commercial off-the-shelf based design resulted in ten-fold improvement in maintenance costs, while enabling zoologists to collect unprecedented amount of high resolution data on wildlife badger behavior.. In the first phase, we optimize the system at the software level. We propose a novel sampling approach for the power hungry animal detection nodes, based on reinforcement learning. The idea is to exploit the behavior patterns of observed animals in order to more efficiently control energy consumption. We also propose a novel storage management scheme that takes into account data urgency and sink mobility to allocate sensor data to carefully selected storage nodes. We observed that these proposed software optimizations had a noticeable effect on the maintenance costs, but the network still required long hours of hands-on human intervention.. In the second phase, we proceeded to enhance the hardware of the most power-hungry nodes to reduce their energy consumption. Here we provide details of the new platform, and how it drastically reduced the need for labor-intensive field trips to replace depleting batteries. This optimization led to a dramatic improvement in terms of maintenance costs. At the same time it triggered another round of software optimizations -we revisited sampling and in-network storage in the light of the new hardware capabilities. We validate the hypothesis that evolving hardware significantly impacted the performance of algorithms running on the nodes. This prompted us to introduce a more energy-efficient sampling algorithm for detecting badgers, which was not applicable in the old platform. It furthermore impacted the performance of our storage management scheme by altering the patterns of sink mobility. The running costs of the resulting system were reduced to such extent that it made it realistic for zoologists to envision network expansion. The data collected throughout our deployment have the potential to offer zoologists a deep insight into the social life of badgers and on the correlation of their activities with weather and micro-climatic variations.. The lessons learned in this paper highlight the impact of maintenance costs on system design and the evolution, as well as the interplay between hardware and software optimizations. They also point out the need to take into account domain knowledge and application requirements to enable successful long-term deployments. The remainder of this paper is organized as follows: Section 2 introduces the characteristics and requirements of the badger monitoring application. Section 3 presents the architecture, design and deployment of our initial monitoring system. Sections 4 and 5 present the two stages of network evolution. Section 6 illustrates the costs incurred by our various stages and existing monitoring techniques. Section 7 analyzes the data collected and presents our main observations of badger behavior. We discuss related work in Section 8 while Section 9 summarizes our findings and concludes the paper. Wildlife and Environmental Monitoring A number of other wildlife monitoring deployments also exist like Zebranet [30] , DuckIsland [27] and TurtleNet [11] . Sikka et al. [26] discuss the deployment of a hybrid network consisting of mobile sensors mounted on farm animals and fixed sensors measuring soil moisture and weight of food and water consumed by animals. Selavo et al. [25] describe the deployment of wireless sensor network for measuring complex light environment in thickets and also use delay tolerant networking, fault-tolerant distributed storage and custom hardware. A number of modified Mica2 motes were deployed by Gilman et al. [28] to monitor the microclimatic conditions and solar radiation in a redwood tree for 44 days. With respect to these we have developed a very integrated heterogeneous deployment which enabled us to gather very large volumes of data. Moreover, the system is able to customise the distribution of the data depending on the urgency of the delivery required. Duty cycling: [19] propose a machine learning based approach for adaptive resource allocation for sensor networks. The sensors are modelled as self-interested agents that attempt to maximise their profit and a simulation based evaluation is presented. An adaptive sampling technique has been used to adjust the sampling rate depending on the predictability of the phenomena [7] . The incoming data is modelled using time series models and the data rate depends on the residual error between the predicted model and the actual measurements. Our work is different because we use adaptive sampling for exploiting temporal correlations for node discovery in mobile environments. Data collection: The MRME algorithm [10] schedules mobile sinks to visit static nodes before data delays expire. When data is close to expiration, multi-hop routing is used to guarantee timely data delivery. Unlike our approach, the MRME algorithm assumes control over sink mobility and assumes homogeneous data latency requirements for all data. The SensorScope project [3] describes the deployment of a low duty-cycle sensor network in which a central base station gathers data. SensorScope uses a non-standardised networking stack that is designed for remote areas that cannot be frequently accessed. Hui et al. [12] demonstrated the usability of the IPv6 standard for sensor networks as a flexible networking layer whilst maintaining a very low duty cycle. Our choice of network stack was strongly influenced by their findings. In Lance [29] , each data unit has an associated value, as well as a cost for multi-hop data delivery to a single basestation. Values and costs are taken into account to determine download scores, i.e. the priorities of data units for data delivery. Unlike Lance, we not only use priorities to rank data units, but also to rank storage nodes. In addition, we send data of different priorities to different storage nodes immediately, instead of delaying their delivery to a single node (the basestation). Jiang et al. [13] , propose EMA, an energy management architecture that enables prioritized enforcement of policy directives. If, for example, there are sufficient energy resources in the network, a sample-and-send directive is used, whereas the system gracefully degrades to sample-andstore when energy resources become scarce. Their framework could be combined with ours to offer a greater variety of policies. For example, a directive could suggest that when energy resources are scarce, a class of data must be demoted to a lower priority. As a result, this data will be delivered to a closer but less frequently visited storage node, and will incur a lower energy cost. Unlike existing systems, in which prioritization results in a binary decision (store vs. download), our system uses data priorities to select among a wide variety of data delivery options. Evolution: With any design, it is very difficult 'to get it right' for the first time, despite a lot of planning and effort. We have shown how our systems developed over time, and how we have managed to reduce the maintenance cost to a tenth of the initial costs, while still collecting substantial amounts of data.. The authors of the ZebraNet project describe in [30] the different stages of hardware upgrade they went through in their deployment. They deployed 3 different sensors, each improving on the capability of their previous ones. The improvements included solar panels, changing the radio to a more energy efficient one and increasing the on-board memory. The Glacsweb Project [21] aimed at monitoring glacial dynamics through the use of WSN. They have had yearly deployments from 2001 to 2008 in different regions and countries (including Norway and Iceland). Their deployments relied on a number of 'probes' embedded in the ice, and a base station, relaying data back from the sensors to the scientists. The base staion turned out to be their single point of failure, they redesigned it from deployment to deployment to improve on reliability and robustness.. Although we detail similar evolutions to the aforementioned projects, our overall aims are different. Here we not only focus on the long-term maintainability of our system and generally improving its reliability, but we also reconcile the inherent relationships between the necessity for specific software and hardware evolutions and highlight the resulting cost savings and benefits from such actions.

O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O


Interactionist AI and the promise of ubicomp, or, how to put your box in the world without putting the world in your box In many ways, the central problem of ubiquitous computing -how computational systems can make sense of and respond sensibly to a complex, dynamic environment laden with human meaning -is identical to that of Artificial Intelligence (AI). Indeed, some of the central challenges that ubicomp currently faces in moving from prototypes that work in restricted environments to the complexity of real-world environments -e.g. difficulties in scalability, integration, and fully formalizing context -echo some of the major issues that have challenged AI researchers over the history of their field. In this paper, we explore a key moment in AI's history where researchers grappled directly with these issues, resulting in a variety of novel technical solutions within AI. We critically reflect on six strategies from this history to suggest technical solutions for how to approach the challenge of building real-world, usable solutions in ubicomp today. In the relatively short history of our field, ubiquitous computing has frequently engaged techniques, methods and approaches from Artificial Intelligence (AI) [e.g. 29] . This is hardly a surprise, since the fields share an overlapping interest in building technologies that make sense and respond in a sensible way to the complex dynamics of human environments. This common interest supports the useful adaptation of AI methods such as machine learning, sensing, and decision algorithms to ubicomp systems. In addition, the special class of real-time, responsive, embedded AI systems share a particular affinity with ubicomp systems, since they are intended to be deployed in similar environments, share many overlapping requirements, and therefore face similar challenges in coming to grips with situations that are fast-changing, unpredictable, and laden with complex human meaning.. In particular, ubicomp is currently facing a series of challenges in scaling up from prototypes that work in restricted environments to solutions that reliably, robustly work in the full complexity of human environments [2, 26] . These challenges echo problems AI researchers tackled as the field sought to move beyond 'blocks-world' solutions to build real-time systems that could work in dynamic, complex environments. In this paper, we reflect on 6 episodes from this history where researchers found novel ways to reframe core AI problems in order to develop new technical solutions. We use these episodes as a starting point for thinking through how ubicomp may be able to draw on similar forms of reframing in order to spur the development of robust, reliable, real-time ubiquitous systems today. Our goal in this paper is not to propose interactionist AI as the magic solution to the problems of ubicomp. Indeed, the tactics of interactionist AI were often extreme, which limited the eventual efficacy of the approach. But the tactics were extreme for a reason: to provide a lens for rethinking the assumptions behind classical AI, and in particular to suggest that it was possible to make concrete technical progress without requiring general solutions, complex or consistent world representations, or full capabilities to reason about the world. This ability to spur reflection on how we might be able to do more with less are precisely what makes interactionist AI a valuable moment for reflection for ubicomp. In particular, interactionist AI arose in response to the realization that the problems AI was tackling presupposed a solution to the general problem of machine intelligence, i.e. what AI researchers termed the problem of AI-completeness. Interactionist AI researchers made the AI problem easier by avoiding tackling AIcompleteness head-on, developing alternative strategies for AI systems that achieved their design goal without having to solve the human level intelligence problem.. When seen from this lens, we can recognize that much of ubicomp is implicitly tackling a similar problem to classical AI -trying to approach a human-level understanding of the world. This is particularly noticeable in the framing of proactive computing, or "proactive environments that anticipate our needs and act on our belief" [47] -such a vision is difficult to achieve without systems that reliably and robustly can understand the world of human action. A similar implicit need for human-level understanding of the world underlies the framing of context-aware computingas Dey argues, "[o]ne of the holy grails of context-aware computing is to have applications that do the right thing at the right time" [20, p. 7] .. In solving this problem, ubicomp is using approaches that often mirror the methods of classical AI: breaking up the problem into functional modules, relying on formal representations and direct mappings between the outside world and world model, and seeking general solutions to the problems of sensing and action. This orientation is clearly reflected, for example, in Abowd and Mynatt's influential paper laying out the ubiquitous computing research agenda: "Without good representations for context, applications developers are left to develop ad hoc and limited schemes for storing and manipulating [information about context]. The evolution of more sophisticated representations will enable a wider range of capabilities and a true separation of sensing context from the programmable reaction to that context" [2, p. 37] . While this framing has clearly been useful for the field, we need to be aware that we might be able to achieve the same goals without heading down the difficult path of achieving human-level understanding, a problem which we might in our field term ubicomp-complete.. Indeed, this problem of ubicomp-completeness resonates with recent critiques within ubicomp that question the ability and desirability to attain human-level understanding of the context of use. Looking at these issues through the lens of interactionist AI provides a useful starting point for turning these conceptual critiques into concrete technical proposals.. For example, both Dourish and Salvador & Anderson argue that the separation of context and action is problematic in ubicomp because the aspects of context that will be pertinent cannot be known until the action takes place [20, 40] . The tight integration of sensing and action in interactionist AI agent architectures may support a more ad hoc, situated approach to tying context and action together than approaches which aim to separate perception of context as an individual and general functional unit.. As another example, Bell and Dourish argue that current ubicomp research is oriented around a conception of the world as orderly, homogeneous, and accessible to machine sensing and inference [7] . A major focus of ubicomp research has been on designing for such a world, in which complex representations and full world models make sense. However, Bell and Dourish argue, the world in which ubicomp systems are currently deployed is messy and heterogeneous and is likely to stay that way. If we take the messiness, heterogeneity, and unknowability of the world as a starting point for technical design, then the strategies of interactionist AI become particularly appropriate, since they do not rely on the orderliness of the world and were designed with the explicit understanding that the world is inherently contingent. These strategies suggest shifting from the goal of designing complete, integrated ubicomp systems to building many small, ad-hoc devices that leverage regularities in the environment, and in people's behaviors and perceptions, to participate usefully and engagingly in the human world. In order to better understand the problems AI researchers were addressing and their relevance to ubicomp, we begin by describing the recurrent difficulties AI was running into in the 1980s, and the ways in which what we will here term 'interactionist AI' reframed AI problems in order to move beyond these recurrent difficulties. We will then explain how these challenges are mirrored in contemporary ubicomp's push to move out of the laboratory and into the real world.

B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O


Randomized competitive algorithms for generalized caching We consider online algorithms for the generalized caching problem. Here we are given a cache of size k and pages with arbitrary sizes and fetching costs. Given a request sequence of pages, the goal is to minimize the total cost of fetching the pages into the cache. We give an online algorithm with competitive ratio O(log 2 k), which is the first algorithm for the problem with competitive ratio sublinear in k. We also give improved O(log k)-competitive algorithms for the special cases of the Bit Model and Fault model. In the Bit Model, the fetching cost is proportional to the size of the page and in the Fault model all fetching costs are uniform. Previously, an O(log 2 k)-competitive algorithm due to Irani [14] was known for both of these models. Our algorithms are based on an extension of the primal-dual framework for online algorithms which was developed by Buchbinder and Naor [7] . We first generate an O(log k)-competitive fractional algorithm for the problem. This is done by using a strengthened LP formulation with knapsack-cover constraints, where exponentially many constraints are added upon arrival of a new request. Second, we round online the fractional solution and obtain a randomized online algorithm. Our techniques provide a unified framework for caching algorithms and are substantially simpler than those previously used. Caching is one of the earliest and most effective techniques of accelerating the performance of computing systems. Thus, vast amounts of work have been invested in the improvement and refinement of caching techniques and algorithms. In the classic two-level caching problem we are given a collection of n pages and a fast memory (cache) which can hold up to k of these pages. At each time step one of the pages is requested. If the requested page is already in the cache then no cost is incurred, otherwise the algorithm must bring the page into the cache, possibly evicting some other page, and a cost of one unit is incurred. This simple model can be extended in two orthogonal directions. First, the cost of bringing a page into the cache may not be uniform for all pages. This version of the problem is called weighted caching and it models scenarios in which the cost of fetching a page is not the same due to different locations of the pages (e.g., main memory, disk, Internet). Second, the size of the pages need not be uniform. This is motivated by web caching where pages have varying sizes. Web caching is an extremely useful technique for enhancing the performance of World Wide Web applications. Since fetching a web page or any other information from the internet is usually costly, it is common practice to keep some of the pages closer to the client. This is done, for example, by the web browser itself by keeping some of the pages locally, and also by internet providers that maintain proxy servers for exactly the same purpose.. We study here several models of generalized caching from a competitive analysis point of view. In the most general setting, called the General model, pages have both non-uniform sizes and costs. Two commonly studied special cases, where the pages can have variable size, are the so-called Bit model and Fault model. In the Bit model, the cost of fetching a page is equal to its size, thus minimizing the fetching cost corresponds to minimizing the total traffic in the network. In the Fault model, the fetching cost is uniform for all pages, thus corresponding to the number of times a user has to wait for a page to be retrieved. The caching model where both size and cost are uniform is very well understood. In their seminal paper, Sleator and Tarjan [17] showed that any deterministic algorithm is at least k-competitive, and also showed that LRU (Least Recently Used) is exactly k-competitive. When randomization is allowed, Fiat et al. [12] designed the Randomized Marking algorithm which is 2H k -competitive against an oblivious adversary, where H k is the k-th Harmonic number. They also showed that any randomized algorithm is at least H kcompetitive. Subsequently, a tight H k competitive algorithm was obtained [16, 1] . More generally, the (h, k)-version of the problem has also been studied. Here the online algorithm with cache size k is compared to the offline algorithm with cache size h ≤ k. A tight k/(k − h + 1) guarantee is known for the deterministic case [17] , and a 2 ln(k/(k−h+1) guarantee is also known for the randomized case [18] .. For weighted caching (uniform size but non-uniform costs), a tight k-competitive deterministic algorithm follows from the more general work of Chrobak et al. [10] for the k-server problem on trees. Subsequently, Young [19] gave a tight k/(k − h + 1)-competitive deterministic algorithm for the more general (h, k)-caching problem. The problem of determining the randomized competitiveness of weighted caching remained open for a long time. Irani [15] gave an O(log k)-competitive algorithm for the two weight case, i.e. when each page weight is either 1 or some fixed M > 1. The case of arbitrary weights was settled only recently by Bansal, Buchbinder and Naor [3]

O O O O B I O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O


Query processing techniques for arrays Abstract. Arrays are a common and important class of data. At present, database systems do not provide adequate array support: arrays can neither be easily defined nor conveniently manipulated. Further, array manipulations are not optimized. This paper describes a language called the Array Manipulation Language (AML), for expressing array manipulations, and a collection of optimization techniques for AML expressions.In the AML framework for array manipulation, arbitrary externally-defined functions can be applied to arrays in a structured manner. AML can be adapted to different application domains by choosing appropriate external function definitions. This paper concentrates on arrays occurring in databases of digital images such as satellite or medical images.AML queries can be treated declaratively and subjected to rewrite optimizations. Rewriting minimizes the number of applications of potentially costly external functions required to compute a query result. AML queries can also be optimized for space. Query results are generated a piece at a time by pipelined execution plans, and the amount of memory required by a plan depends on the order in which pieces are generated. An optimizer can consider generating the pieces of the query result in a variety of orders, and can efficiently choose orders that require less space. An AML-based prototype array database system called ArrayDB has been built, and it is used to show the effectiveness of these optimization techniques. Arrays are an appropriate model for many types of data, including digital images, digital video, and gridded outputs from This research was partially supported by NSERC (Natural Sciences and Engineering Research Council of Canada). We are grateful to the anonymous reviewers for their comments and suggestions. computational models. Array data are common in many application domains, such as remote sensing and medical imaging [3, 21, 22] . Most database management systems (DBMS), however, provide very limited support for arrays. This paper presents the Array Manipulation Language (AML), which can be used to describe array queries. AML expressions describe how arbitrary, externally defined functions are used to generate a desired query result. Thus, by appropriate choice of functions, AML can be customized for a particular application. Because arrays may be large, and array manipulations complex, array queries may be expensive. This paper presents an array query processing algorithm that generates optimized, pipelined query evaluation plans from AML queries. The query processor is implemented in an array database system called ArrayDB. Figure 1 shows a remote sensing example that illustrates the kind of array queries for which AML is well suited. The three-dimensional array A in Fig. 1 represents a multi-spectral image captured by the Landsat Thematic Mapper. Two of the array dimensions are spatial, and the third is spectral. This array can be thought of as a stack of seven two-dimensional images of the same scene, each captured using a sensor sensitive to a different band of the electromagnetic spectrum.. Often, multi-spectral images such as A are not used directly. Instead, useful parameters are derived from them. An fnr (v0, v1, v2, v3, v4, v5, v6, v7, v8 . where b i denotes the radiance in the ith band. The TVI at each point in the scene is indicative of the amount of green biomass present there [20] . A Thematic Mapper image may include noise from a variety of sources. Since noise can degrade the true radiometric information content of the image, it may be desirable to attempt to reduce the noise before performing further calculations, such as extraction of the TVI [20] . Thus, a TVI image may be generated in two steps, as illustrated in Fig. 1 . First, noise reduction is applied to the third and fourth bands of the Thematic Mapper image, resulting in arrays B and C respectively. The TVI image (array D) is then derived from the noise-reduced bands.. There are many kinds of noise reduction techniques. To make the example concrete, we will assume that noise reduction is accomplished using a convolution filter. The filter computes the noise-reduced radiance at a particular point from original radiance at that point and the radiances of its eight immediate neighbors. (Noise reduction is applied independently to each of the bands of interest.) The exact calculation, which is adapted from [20] , is shown in Fig. 2 .. This example illustrates several points. First, there is a wide variety of complex, domain-specific array transformations that may be used to define the desired result, such as the TVI array, of an array query. An array query language should be flexible enough to express them.. Second, there is considerable room for query optimization. Array queries may have a regular structure that can be exploited. In the case of Fig. 1 , it is not difficult to determine which points in the original Thematic Mapper image (A) contribute to the TVI at a particular point in array D. Thus, if only part of array D is required, it may be possible to generate that part without using all of A. Also, the TVI values in D can be calculated in any order.. There are other opportunities as well. Redundant calculations can be eliminated using techniques such as caching and view materialization. For example, several different parameters may be derived from the noise-reduced arrays B and C, although only one is illustrated in Fig. 1 . It that case, it might be a good idea to materialize (compute and store) arrays B and C. Finally, specific array transformations may have properties that can be exploited by an optimizer that understands them. For example, the noise reduction algorithm that produces arrays B and C is a discrete two-dimensional convolution. An optimizer with some knowledge of linear systems might be able to infer, for example, that adding two noise-reduced images is equivalent to applying noise reduction to their sum. This paper makes the following contributions. First, it presents AML, a language for defining array queries. Each of the arrays B, C and D from Fig. 1 can be described as an AML query against the original Landsat Thematic Mapper image A. Since the result of an AML query is an array, AML can be used to define views, such as the TVI image, on stored base arrays, such as the multi-spectral Thematic Mapper image.. Second, it describes the array query processing techniques that are implemented in ArrayDB. ArrayDB has a rewrite optimizer that transforms AML expressions into equivalent expressions that may be much cheaper to evaluate. From these optimized expressions, ArrayDB generates pipelined query evaluation plans. Arrays flow through the pipelines in small chunks, and materialization of potentially large intermediate results can often be avoided. ArrayDB's optimizer does not exploit all of the optimization opportunities that are described above, primarily because AML itself does not capture everything needed to exploit them. For example, the optimizer does not "understand" convolution. However, AML is quite good at capturing regular structure in array queries. ArrayDB exploits this to reorder query operators, eliminate unnecessary work, and reduce space requirements.. Third, it presents an empirical evaluation of ArrayDB's query processor. The evaluation is based on a small suite of array queries, including the TVI query illustrated in Fig. 1 . The evaluation demonstrates the effectiveness of the query processor. It also illustrates some of the limitations of AML, and of ArrayDB's query evaluation strategies.. The rest of the paper is organized as follows. The array data model and the AML query language are desribed in Sect. 2 and Sect. 3 respectively. Section 4 describes ArrayDB, and the techniques that it uses for optimizing and evaluating AML queries. Section 5 describes the array query suite that serves as ArrayDB's workload for the performance evaluation. The evaluation itself is presented in Sect. 6. Section 7 consists of a survey of related work. The scenario illustrated in Fig. 1 is used as a running example throughout this paper. This paper describes AML, a query algebra for arrays, and techniques for optimizing and evaluating AML expressions. AML expressions define structured applications of uninterpreted, externally-defined functions to arrays.AML query processing is implemented in ArrayDB -a database management system for arrays. ArrayDB's query optimizer is capable of rewriting AML queries to eliminate unnecessary function applications and I/O. The optimizer also performs other optimizations, such as cost-based selection of the order in which array elements are processed. Using a suite of image processing queries, we have shown that ArrayDB's query processing techniques are effective at reducing query evaluation times and memory requirements.. The research reported in this paper can be extended in several directions. First, it would be interesting to extend AML so that it incorporates other index-based operators (such as a transpose or dimension reordering operator) and contentbased operators. A content-based operator would restructure an array, or apply functions to an array, in a manner that would depend on the value of an array element, rather than its position. Second, query optimization techniques that exploit some of the properties of the user-defined functions (such as commutativity or associativity) can be studied. An immediate question is how to describe these properties to the query optimizer so that it can reason about them and exploit them. It should not be too difficult to recognize instances where two adjacent user-defined functions can be composed by manufacturing a composite function that calls the two original function in sequence. Such an optimization avoids generation of some of the intermediate arrays during query evaluation. Third, the plan refinement phase can be generalized to consider different chunk shapes in addition to considering different chunk orders. At present, ArrayDB's physical operators assume fixed input and output chunk shapes. Physical operators such as regroup p and combine p can potentially produce and consume subar-rays of various shapes. The dynamic programming-based algorithm would need to be revisited to examine whether it can be generalized in the presence of variable chunk shapes. A fourth issue is the integration of array query processing into a relational database system or image database system. Images and other arrays are usually associated with non-array metadata. Ideally, it should be possible for an application to define queries that involve the kinds of array manipulations described in this paper, and that also use the meta-data for filtering or for other purposes.. A final issue is parallel evaluation of AML queries. AML is a data-parallel language. Data-parallel languages permit efficient parallel implementations because the operators in such languages provide implicit parallelism [37] . The query compiler does not have to do complex loop analysis to find parallelism. Some of the issues involved in building a parallel evaluator for AML are: data partitioning and layout schemes; methods for coordinating data retrieval; methods for coordinating computation; and methods for interprocessor communication. Prior research has addressed issues such as the data partitioning problem for user-defined functions that consume and produce one-dimensional streams [30] , and parallel evaluation of specialized forms of queries on remote-sensing data [6] . Languages which support array manipulation can be classified into two broad categories: collection-oriented languages and scalar-oriented languages. A language is considered collection-oriented if collection types (for example, sets, sequences, arrays, vectors, and lists) and operations for manipulating them "as a whole" are primitive in the language [37] . APL, the ImageAlgebra [34] , FORTRAN 90, andAML are examples of collection-oriented languages with array types. In scalar-oriented languages, such as C and Pascal, collections are manipulated element by element.. Some implementations of collection-oriented languages perform early filtering of array data, much as ArrayDB does. The data to be filtered are identified by lineage tracing, a kind of data-flow analysis. The complexity of such an analysis depends on the kinds of array manipulations that the language supports. Often lineage is traced only through array operators that operate independently on each individual element of an array [3, 5, 12, 42, 43] . ArrayDB and AML are notable in that they support lineage tracing (and pushdown of filtering operations) through array operators that operate on rectangular array chunks of arbitrary size [24, 25] .. A common optimization in collection-oriented languages is to (effectively) combine several consecutive array operations into a composite array operation. Evaluation of the composite operation avoids generating intermediate arrays, reduces redundant data movement, and reduces parallel loop 13 This is the reason why ArrayDB and the C++ program for DE-STRIPE do not perform the same number of I/O operations. synchronization overhead. Guibas and Wyatt's influential work on this topic [12] -performed in the context of a subset of APL operators -has subsequently been extended [4, 15, 41] . The study reported in [15] shows how to compose FOR-TRAN 90 operators such as RESHAPE, EOSHIFT, MERGE, WHERE constructs, and array reduction operations. The replacement of the contiguous sub and merge operations by a single combine p operation in ArrayDB is also an example of such an array function composition. Common subexpressions and one-to-many array operations are problematic to handle in this optimization framework [15] .. In scalar-oriented programming languages, array traversals must be coded explicitly, often using some form of looping control structure. Because of the big difference in the performance of CPU and memory (be it main memory or cache), loop optimizations try to improve the temporal and spatial locality of array accesses so that elements accessed together (temporally or spatially) can be found in faster memories. Many looprelated optimizations are known [28] . Some, such as tiling [28, p. 694] , improve cache locality by manipulating the order in which array elements are visited. Other optimizations, such as loop interchange, skewing, reversal, and the order in which they can be applied to loop nests have been studied [44] . Array restructuring is a loop-related optimization that changes the array layout in memory so that spatial data locality of array element accesses in a loop improves [18] . Array layouts chosen for one loop may affect performance of subsequent loops, and therefore, it may be necessary to find globally advantageous array layouts.. Such loop-related optimizations are similar in spirit to the iteration order optimization implemented for AML by ArrayDB. Although the optimizations are different, both seek to exploit iteration order to reduce costs associated with the memory hierarchy. In case of ArrayDB, iteration order selection produces memory-efficient plans. In such plans, pieces of several arrays can be fit into smaller and faster memories, and therefore, memory hierarchy is well utilized.

O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O


On the perturbations of a Hamiltonian system The perturbations of a Hamiltonian system having compounded cycle are studied in this paper. The existence theory and stability theory of singular closed orbits are applied to study the given perturbed systems. By using the small parametric perturbation techniques of differential equations, we study Hopf bifurcation, singular closed orbits bifurcation and give the number and distributions of limit cycles in the above perturbed near Hamiltonian system.Crown In this paper, the qualitative method of differential equation is used to study the number and distribution of limit cycles of a perturbed quintic Hamiltonian system (1). The existence and stability theory of heteroclinic loop, homoclinic loop and compound cycle are applied to study the heteroclinic loop, homoclinic loop and compound cycle bifurcations of such system under Z 4 -equivariant quintic perturbation. By combining first several Lyapunov constants of singular points of system (2), we find that the perturbed system (2) can have at least 4 limit cycles bifurcated from saddle connection loop Γ poly (ε) and have at least 3 large limit cycles and 4 medium limit cycles(or 1 medium limit cycle) bifurcated from the compound cycle Γ comp (ε).

O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O


Higher-order three-point boundary value problem on time scales In this paper, we consider a higher-order three-point boundary value problem on time scales. We study the existence of solutions of a non-eigenvalue problem and of at least one positive solution of an eigenvalue problem. Later we establish the criteria for the existence of at least two positive solutions of a non-eigenvalue problem. Examples are also included to illustrate our results. We are concerned with the dynamic three-point boundary value problem (TPBVP) 1) and the eigenvalue problem (−1) n y ∆ 2n (t) = λf (t, y σ (t)) with the same boundary conditions where λ is a positive parameter, n ≥ 1, a < η < σ (b), and f : [a, σ (b)] × R → R is continuous. We assume that σ (b) is right dense so that σ j (b) = σ (b) for j ≥ 1 and that for each 1 ≤ i ≤ n, α i , β i , γ i coefficients satisfy the following condition;. Throughout this paper we let T be any time scale (non-empty closed subset of R) and [a, b] be a subset of T such that [a, b] = {t ∈ T, a ≤ t ≤ b}.. Some preliminary definitions and theorems on time scales can be found in books [1, 2] which are excellent references for calculus of time scales.. Second-order, three-point boundary value problems for dynamic equations on time scales have been studied in recent years [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] . Anderson and Avery [13] have been interested in an even-order three-point boundary value problem on time scales with a delta-nabla differential operator. Their problem is an extension of the works [3, 7, 14] on positive solutions of a linear three-point boundary value problem.. 2nth-order two-point boundary value problems have attracted considerable attention in recent years [14] [15] [16] . Cetin and Topal [17] were interested in the following TPBVP,. (1.2). They have studied the existence of solutions and of at least one positive solution to TPBVP (1.2) . For this purpose, they used the Schauder fixed-point theorem, the monotone method and the Krasnosel'skii fixed-point theorem.. In this paper, existence results of bounded solutions of a non-eigenvalue problem are first established as a result of the Schauder fixed-point theorem. Second, the monotone method is discussed to ensure the existence of solutions of TPBVP (1.1). Third, we establish criteria for the existence of at least one positive solution of the eigenvalue problem by using the Krasnosel'skii fixed-point theorem. Later, we investigate the existence of at least two positive solutions of TPBVP (1.1) by using the Avery-Henderson fixed-point theorem. Finally, as an application, we also give some examples to demonstrate our results. Our results extend the problem (1.2). Moreover, our problem is more general than some in the existing literature on three-point boundary value problems [5, 18, 19] .

O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O B I O O O O O O B I O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O B I O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O


Smoothness-constrained quantization for wavelet image compression Abstract-Uniform quantization of wavelet coefficients introduces perceptually disturbing artifacts by decreasing visual smoothness. In this paper, local Hölder regularity is used to quantify these changes in visual smoothness. A modified uniform quantization scheme that constrains local regularity decreases is proposed. The quantizer modification is applicable to any uniform quantization scheme and requires no additional side information to be transmitted to the decoder, unlike standard deadzone quantizers. The reconstructed images show a noticeable perceptual improvement as well as an increased PSNR relative to uniform quantization Index Terms-Dead zone quantization, perceptual image compression, smoothness constrained quantization, wavelet coefficient shrinkage. Algorithms based on the wavelet transform represent the current state of the art in image compression. Quantization of wavelet coefficients in lossy compression algorithms can produce perceptually disturbing artifacts in images: ringing around edges (i.e., Gibbs phenomenon) and spurious high-frequency detail in previously smooth areas. The second type of artifact occurs when there are Kroneckerdelta-like features in the original image, as shown in Fig. 1 , and occurs when the magnitudes of fine scale wavelet coefficients in smooth areas of the image are increased during quantization. Psychovisual studies have demonstrated that humans find compression artifacts in smooth regions more disturbing than those in edge or detailed regions [1] , while errors around edges are somewhat masked [2] . As such, the focus of this work is to constrain the decreases in regularity that produce artifacts in smooth regions, rather than explicitly limiting the effect of Gibbs phenomenon.. This work analyzes changes in visual smoothness as quantified by Hölder regularity and proposes a method that mitigates perceptually disturbing decreases in local regularity. A smoothness constraint is imposed by a modified quantization scheme which reduces the probability that a coefficient will increase in magnitude. This quantizer modification requires no additional side information to be sent to the decoder, and does not rely on probabilistic models of quantization noise. Images compressed and reconstructed with this method exhibit a noticeable perceptual improvement as well as an increased PSNR relative to a uniform quantizer.. The organization of this correspondence is as follows. Section II introduces the concept of Hölder regularity and discusses how wavelet transform coefficients may be used to characterize it. Section Manuscript received April 11, 1997; revised April 22, 1999. The associate editor coordinating the review of this manuscript and approving it for publication was Dr. Christine Podilchuk.. W III introduces the smoothness-constrained quantizer. Experimental results are presented in Section IV, followed by conclusions.. In recent years, a number of high performance compression algorithms have been developed which create finely embedded compressed representations of an image [1] - [4] . All of these methods first perform a wavelet transform on the image and then scan the bit planes of the resulting coefficients from the most significant bit to the least significant bit. The compressed bit stream thus created has a number of useful properties: 1) it can be truncated to precisely achieve a desired bit rate while maintaining the best possible quality; 2) it is well suited to unequal error protection; and 3) it can be exploited to achieve transmission error resilience [5] . Unfortunately, embedded algorithms are slower than their nonembedded counterparts because they must analyze each wavelet coefficient many times. While such performance may be acceptable for still image compression, it is a major problem when real-time video compression (e.g., 30 frames/s) is required. To speed things up, we first consider dynamically adapting the embedding "fineness" so that a specified number of embedding layers is retained at the desired bit rate [6] . It turns out that this can be accomplished with little or no degradation in the rate-distortion performance. Next, we introduce the concept of cache-based zerotree processing in which the most memory intensive encoding and decoding operations are all performed exclusively on data inside the processor's cache or on-chip memory store [7] . This offers a potentially large speedup because most modern day CPU's (central processing units) and DSP's (digital signal processors) can only operate at full speed with data stored on-chip.. The paper is organized as follows. Section II details the mechanisms through which the conventional embedded zerotree wavelet (EZW) algorithm can be modified to accommodate adaptive embedding. Next, in Section III we explain the data partitioning and adaptation required to implement cache-based zerotree coding. Results are presented in Section IV, followed by conclusions in Section V. Changes in visual smoothness caused by wavelet coefficient quantization are quantified mathematically by analyzing changes in the local Hölder regularity. A smoothness-constrained quantizer limits the amount by which the regularity can decrease. Choosing the central quantization bin to be 1.2 to 1.4 times the width of the regular quantization stepsize produces improved visual results as well as an average PSNR increase of 0.25 dB relative to the uniform quantizer. Though a deadzone quantizer can produce similar smoothness decreases though with a larger central bin width, the PSNR performance of the smoothness-constrained quantizer will be slightly higher. The smoothness constraint can be applied to any quantization scheme, including successive approximation quantizers and lattice vector quantizers, with a computationally inexpensive encoder side modification.

O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I B I I B I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O


A study of the scalability of stop-the-world garbage collectors on multicores Large-scale multicore architectures create new challenges for garbage collectors (GCs). In particular, throughput-oriented stopthe-world algorithms demonstrate good performance with a small number of cores, but have been shown to degrade badly beyond approximately 8 cores on a 48-core with OpenJDK 7. This negative result raises the question whether the stop-the-world design has intrinsic limitations that would require a radically different approach.Our study suggests that the answer is no, and that there is no compelling scalability reason to discard the existing highly-optimised throughput-oriented GC code on contemporary hardware. This paper studies the default throughput-oriented garbage collector of OpenJDK 7, called Parallel Scavenge. We identify its bottlenecks, and show how to eliminate them using well-established parallel programming techniques. On the SPECjbb2005, SPECjvm2008 and DaCapo 9.12 benchmarks, the improved GC matches the performance of Parallel Scavenge at low core count, but scales well, up to 48 cores. Contemporary hardware with large memories and high core counts creates new challenges for garbage collectors (GCs). To achieve the best possible performance, throughput-oriented GCs traditionally use a stop-the-world design, in which the collector pauses the application threads during the whole collection to prevent concurrent memory accesses from the application. Stop-the-world is the simplest design and is relatively easy to combine with advanced techniques [12] . In contrast, a concurrent GC does not pause the application, but is much more complex: as it runs in parallel with application code, it requires complicated fine-grain synchronisation with the GC and costly code instrumentation to intercept reference mutations [1, 7, 16, 24, 27, 28] .. According to some authors, for instance Iyengar et al. [11] , stopthe-world collectors are not adequate on large machines because their pause time increases with available memory. This reasoning ignores the counter-balancing effect that large machines also come with many cores, translating to more parallelism. If efficiently exploited, this parallelism should reduce the pause time. However, our previous study [10] shows that the performance of the stopthe-world GCs available in OpenJDK 7 degrades beyond about 8 GC threads, taking over one-third of total application time at maximum parallelism (one GC thread for each of 48 hardware cores). This performance issue questions the design of stop-theworld collectors: are they intrinsically unable to scale with the number of cores, and thus, is it now time to pay the price of concurrent collectors to collect large heaps?. The result of our study suggests that the answer is no, at least on an off-the-shelf 48-core NUMA machine. 1 Our study is based on Parallel Scavenge [21] , the stop-the-world throughput-oriented collector used by default in OpenJDK 7. We show that its bad performance with a lot of cores is not intrinsic to its design, but is due to two bottlenecks, which we correct using well-established parallel programming techniques:. • Lack of NUMA-awareness. Many objects are allocated on a single node, overloading it, during execution of both the application and the GC code. To correct this issue, we compare three different approaches to balancing memory access among nodes. The first one focuses on balance only. The other two have a secondary goal of also improving spatial locality, by attempting to place objects on the node where they are used. • A heavily contended lock inside the parallel phase of Parallel Scavenge. To avoid this bottleneck, we remove the lock: (i) by replacing a queue with a lock-free one, and (ii) by simplifying the synchronisation protocol to begin and terminate the GC's parallel phase.. The resulting GC, called NAPS, for Numa-Aware Parallel Scavenge, distributes live objects among nodes in a balanced way, and Our approach deliberately uses the simplest possible techniques, resulting in fewer than 1000 modified lines of code. This result shows that a careful adjustment of a small portion of the code is sufficient to solve a known problem, for which a more drastic redesign is often proposed.. Our evaluation is based on the applications from three industrystandard benchmark suites, SPECjbb2005 [25] , SPECjvm2008 [26] and DaCapo-9.12 [4] , on a 48-core AMD Magny-Cours machine with eight nodes. Our results show that:. • NAPS scales well with the number of cores. At constant heap size, the collection time of NAPS decreases with the number of cores, for applications with high memory requirements. As compared to Parallel Scavenge, NAPS never degrades performance. • As a side-effect of balancing the memory access among nodes, in addition to the improved collection time, NAPS improves application time by up to 28%. The combination of GC-time improvement and better application performance doubles the throughput of SPECjbb2005, the most memory-intensive application in our evaluation. • We observe that the major improvement comes from balancing memory access among nodes, which eliminates the top bottleneck to scaling GC. Beyond 32 cores, improving memory locality also becomes important, in order to decrease the load on the interconnect. In contrast, thanks to improved memory locality, the effect of decreasing memory access latency, is marginal.. The rest of the paper is organised as follow. Section 2 describes the design of Parallel Scavenge. Section 3 describes its bottlenecks and how we solve them. Section 4 reports the evaluation results and discusses their implications. Section 5 presents an overview of related work, and Section 6 concludes the paper. Empirical studies across a wide range of applications and languages show that "most objects die young:" a recently-allocated object has a greater probability of becoming garbage than one that already survived GCs [2, 13, 31] . A generational collector exploits this by segregating the heap into multiple generations, and by collecting the young generation more frequently than the older one(s). This paper studies the problem of scalability of throughput-oriented GCs on multicore hardware. We present how we can fix these bottlenecks using well-established parallel programming techniques, and show that they were not caused by the stop-the-world design, but by some of the mechanisms that were not planned for contemporary NUMA multicores with tens of cores. Our evaluation suggests that today, there is no conceptual reason to believe that the pause time of a stop-the-world GC will increase with the increasing number of cores and memory size of multicore hardware. It leads to the conclusion that the costly and complex fine-grain synchronisation of concurrent GCs are not yet required for throughput-oriented GCs: to achieve good performance, and to scale with the increasing number of cores and heap size.. As a future work, we will explore how we can make segregated spaces perform better by avoiding most of the inter-node messages. We propose to make the old generation fragmented, which will enable us to identify most of the references in their home nodes locally.

O O O O O O O O O O O O B O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O