Machine Learning is the study of methods for programming computers to learn. Computers are applied to a wide range of tasks, and for most of these it is relatively easy for programmers to design and implement the necessary software. However, there are many tasks for which this is difficult or impossible. These can be divided into four general categories. First, there are problems for which there exist no human experts. For example, in modern automated manufacturing facilities, there is a need to predict machine failures before they occur by analyzing sensor readings. Because the machines are new, there are no human experts who can be interviewed by a programmer to provide the knowledge necessary to build a computer system. A machine learning system can study recorded data and subsequent machine failures and learn prediction rules. Second, there are problems where human experts exist, but where they are unable to explain their expertise. This is the case in many perceptual tasks, such as speech recognition, hand-writing recognition, and natural language understanding. Virtually all humans exhibit expert-level abilities on these tasks, but none of them can describe the detailed steps that they follow as they perform them. Fortunately, humans can provide machines with examples of the inputs and correct outputs for these tasks, so machine learning algorithms can learn to map the inputs to the outputs. Third, there are problems where phenomena are changing rapidly. In finance, for example, people would like to predict the future behavior of the stock market, of consumer purchases, or of exchange rates. These behaviors change frequently, so that even if a programmer could construct a good predictive computer program, it would need to be rewritten frequently. A learning program can relieve the programmer of this burden by constantly modifying and tuning a set of learned prediction rules. Fourth, there are applications that need to be customized for each computer user separately. Consider, for example, a program to filter unwanted electronic mail messages. Different users will need different filters. It is unreasonable to expect each user to program his or her own rules, and it is infeasible to provide every user with a software engineer to keep the rules up-to-date. A machine learning system can learn which mail messages the user rejects and maintain the filtering rules automatically. Machine learning addresses many of the same research questions as the fields of statistics, data mining, and psychology, but with differences of emphasis. Statistics focuses on understanding the phenomena that have generated the data, often with the goal of testing different hypotheses about those phenomena. Data mining seeks to find patterns in the data that are understandable by people. Psychological studies of human learning aspire to understand the mechanisms underlying the various learning behaviors exhibited by people (concept learning, skill acquisition, strategy change, etc.).

Machine learning

Deposits of clastic carbonate-dominated (calciclastic) sedimentary slope systems in the rock record have been identified mostly as linearly-consistent carbonate apron deposits, even though most ancient clastic carbonate slope deposits fit the submarine fan systems better. Calciclastic submarine fans are consequently rarely described and are poorly understood. Subsequently, very little is known especially in mud-dominated calciclastic submarine fan systems. Presented in this study are a sedimentological core and petrographic characterisation of samples from eleven boreholes from the Lower Carboniferous of Bowland Basin (Northwest England) that reveals a >250 m thick calciturbidite complex deposited in a calciclastic submarine fan setting. Seven facies are recognised from core and thin section characterisation and are grouped into three carbonate turbidite sequences. They include: 1) Calciturbidites, comprising mostly of highto low-density, wavy-laminated bioclast-rich facies; 2) low-density densite mudstones which are characterised by planar laminated and unlaminated muddominated facies; and 3) Calcidebrites which are muddy or hyper-concentrated debrisflow deposits occurring as poorly-sorted, chaotic, mud-supported floatstones. These

Phd by thesis

物件導向軟體之架構(Object-Oriented Software Construction)探討

Well adapted to the loosely coupled nature of distributed interaction in large-scale applications, the publish/subscribe communication paradigm has recently received increasing attention. With systems based on the publish/subscribe interaction scheme, subscribers register their interest in an event, or a pattern of events, and are subsequently asynchronously notified of events generated by publishers. Many variants of the paradigm have recently been proposed, each variant being specifically adapted to some given application or network model. This paper factors out the common denominator underlying these variants: full decoupling of the communicating entities in time, space, and synchronization. We use these three decoupling dimensions to better identify commonalities and divergences with traditional interaction paradigms. The many variations on the theme of publish/subscribe are classified and synthesized. In particular, their respective benefits and shortcomings are discussed both in terms of interfaces and implementations.

/pdf/the-many-faces-of-publish-subscribe-59ahrjbweq.pdf

The many faces of publish/subscribe

Aspect] is a simple and practical aspect-oriented extension to Java With just a few new constructs, AspectJ provides support for modular implementation of a range of crosscutting concerns. In AspectJ's dynamic join point model, join points are well-defined points in the execution of the program; pointcuts are collections of join points; advice are special method-like constructs that can be attached to pointcuts; and aspects are modular units of crosscutting implementation, comprising pointcuts, advice, and ordinary Java member declarations. AspectJ code is compiled into standard Java bytecode. Simple extensions to existing Java development environments make it possible to browse the crosscutting structure of aspects in the same kind of way as one browses the inheritance structure of classes. Several examples show that AspectJ is powerful, and that programs written using it are easy to understand.

An overview of AspectJ

The proper title is, of course, “Desert Island.” But like Ernestine Ulmera said, “Life is uncertain. Eat dessert first.”1 In 1995, Ross Jeffery and I were program co-chairs for the 17th International Conference on Software Engineering, and we had the incredible fortune to have three fantastic keynoters: Fred Brooks, Michael Cusumano and Michael Jackson. Serendipitously, all three of them had just published books. And with one error of omission that I’ll note below, I think that these are three books that I’d take for dessert on the desert island. At the highest level, it is not the specific material in each of these books that I find most beneficial, but rather the way of thinking upon which the books are based. Also, all three books are based on the “real world”—Brooks and Jackson have enormous practical experience in building software systems, and they are able to abstract from those experiences in ways that few others can; Cusumano (and his co-author, Rick Selby) interviewed, cajoled, studied, analyzed and then organized a tremendous amount of material that reflects on how a large company produces software that people use. Brooks once observed that he is a “dyed-in-the-wool empiricist”, and to effectively engineer quality software requires that pragmatic view of reality. (If one believes it is reasonable to ignore data and truth, one should just look at the United States of America since the 2000 election.) Fred Brooks had just published The Mythical Man-Month: Essays on Software Engineering, 20th Anniversary Edition (Addison-Wesley). It is unnecessary to say much about this book—I re-read it before every software engineering course I teach. The anniversary edition blends the old and the new in ways that only Fred can—the

Dessert Island

As software systems evolve, they often grow more brittle. Design snippets help software engineers detect brittleness and improve the ease of change of their software. By studying design snippets and code together, a software engineer can locate improvements that prevent costly changes in the long term.

Design snippets: partial design representations extracted from source code

Software systems gradually evolve over time, becoming increasingly difficult to understand as new features are added and old defects are repaired. Some modifications are harder to understand than others; e.g., an explicit method call is usually easy to trace in the source code, while a reflective method call may perplex both developers and analysis tools. Our tool, the Inconsistency Inspector, collects static and dynamic call graphs of systems and composes them to help developers more systematically address the static and dynamic implications of a change to a system.We have quantitatively validated the Inconsistency Inspector and have convinced ourselves that it can expose both interesting and surprising facets of a system's evolution. An initial case study with an industrial organization showed promise leading to the Inconsistency Inspector being installed at the organization for the past several months in preparation for a more in depth analysis.In July 2012 we will have the opportunity to examine 8 months of industrial data, enabling us to perform an in-depth longitudinal evaluation of how their system has evolved and whether the Inconsistency Inspector can expose surprising and helpful facts for the industrial team. At the USER workshop, we hope to gather opinions about evaluation options for validating the industrial utility of our approach and the complex longitudinal data we have collected.

/pdf/industrially-validating-longitudinal-static-and-dynamic-4cryz23607.pdf

Industrially validating longitudinal static and dynamic analyses

A developer modies a program to achieve particular changes while avoiding the introduction of new bugs. Many changes also introduce behaviours that are not so easily characterized as\good"or\bad": for example, a new callback into the program from a library that arises after a change. Even if the change passes all regression tests, this behaviour may or may not be benign. Whether it causes problems may in fact only become apparent over time as the behaviour interacts with other changes. We present an approach to identify specic program call dependencies where the programmer’s changes to the program source are not apparent in the system’s behaviour, or vice versa. Using a static and a dynamic call graph from each of two program versions, we partition dependencies based on their presence in each of the four graphs. Particular partitions contain dependencies that are likely to represent unforeseen parts of a change; by analyzing these partitions, the programmer can glean insight that is otherwise dicult to obtain.

https://homes.cs.washington.edu/~notkin/fse2010venn_submitted.pdf

David Notkin

Papers

Dessert Island

Design snippets: partial design representations extracted from source code

Industrially validating longitudinal static and dynamic analyses

Detecting Unforeseen Program Behaviours