Read Here
Abstract:
I propose to consider the question, "Can machines think?" This should begin with definitions of the meaning of the terms "machine" and "think." The definitions might be framed so as to reflect so far as possible the normal use of the words, but this attitude is dangerous, If he meaning of the words "machine" and "think" are to be found by examining how they are commonly used it is difficult to escape the conclusion that the meaning and the answer to the question, "Can machines think?" is to be sought in a statistical survey such as a Gallup poll. But this is absurd. Instead of attempting such a definition I shall replace the question by another, which is closely related to it and is expressed in relatively unambiguous words.
Read Here
Abstract:
Within one generation, software has become one of the principal sources of wealth in the world. The development and use of software has grown faster than for any artifact in the history of the world. Probably no topic or subject in history has accelerated in its rate of practice as software has. Software development now needs to mature into a disciplined activity to overcome the difficulties that have traditionally plagued it. Software developers, engineers, and project managers need a reference that describes the evolution of software: where it has been, and where it is going. The Laws of Software Process: A New Model for the Production and Management of Software reveals a novel and compelling structure for development that redefines the very nature and purpose of software. The author explains how, in the modern "knowledge economy," software systems are not "products" in the classical sense, but is the modern medium for the conveyance of information. Literally, software is the currency of the knowledge basis of wealth in today's society.From this definition flows a new assessment of the basics of software development: the purpose of methods and processes; a comparison of programming languages; and an analysis of quality management, cost estimation, and project management and completion. The groundbreaking perspective outlined in this book serves as an expert guide for successful planning and execution of development projects.
Read Here
Abstract:
The Priority Inbox feature of Gmail ranks mail by the probability that the user will perform an action on that mail. Because “importance” is highly personal, we try to predict it by learning a per-user statistical model, updated as frequently as possible. This research note describes the challenges of online learning over millions of models, and the solutions adopted.
Read Here
Abstract:
The term psi denotes anomalous processes of information or energy transfer that are currently unexplained in terms of known physical or biological mechanisms. Two variants of psi are precognition (conscious cognitive awareness) and premonition (affective apprehension) of a future event that could not otherwise be anticipated through any known inferential process. Precognition and premonition are themselves special cases of a more general phenomenon: the anomalous retroactive influence of some future event on an individual’s current responses, whether those responses are conscious or nonconscious, cognitive or affective. This article reports 9 experiments, involving more than 1,000 participants, that test for retroactive influence by “timereversing” well-established psychological effects so that the individual’s responses are obtained before the putatively causal stimulus events occur. Data are presented for 4 time-reversed effects: precognitive approach to erotic stimuli and precognitive avoidance of negative stimuli; retroactive priming; retroactive habituation; and retroactive facilitation of recall. All but one of the experiments yielded statistically significant results; and, across all 9 experiments, Stouffer’s z = 6.66, p = 1.34 × 10-11 with a mean effect size (d) of 0.22. The individual-difference variable of stimulus seeking, a component of extraversion, was significantly correlated with psi performance in 5 of the experiments, with participants who scored above the midpoint on a scale of stimulus seeking achieving a mean effect size of 0.43. Skepticism about psi, issues of replication, and theories of psi are also discussed.
Read Here
Abstract:
This document first began as an effort to help teams within Google, but we thought it'd be just as useful to webmasters that are new to the topic of search engine optimization and wish to improve their sites' interaction with both users and search engines. Although this guide won't tell you any secrets that'll automatically rank your site first for queries in Google (sorry!), following the best practices outlined below will make it easier for search engines to crawl, index and understand your content. Search engine optimization is often about making small modifications to parts of your website. When viewed individually, these changes might seem like incremental improvements, but when combined with other optimizations, they could have a noticeable impact on your site's user experience and performance in organic search results. You're likely already familiar with many of the topics in this guide, because they're essential ingredients for any web page, but you may not be making the most out of them.
Read Now
Abstract:
As software becomes more and more complex, it is more and more
important to structure it well. Well-structured software is easy to write
and to debug, and provides a collection of modules that can be reused
to reduce future programming costs. In this paper we show that two features of functional languages in particular, higher-order functions and lazy
evaluation, can contribute significantly to modularity. As examples, we
manipulate lists and trees, program several numerical algorithms, and implement the alpha-beta heuristic (an algorithm from Artificial Intelligence
used in game-playing programs). We conclude that since modularity is the
key to successful programming, functional programming offers important
advantages for software development.
Read Now
Abstract:
Crash-only programs crash safely and recover quickly.
There is only one way to stop such software—by crashing
it—and only one way to bring it up—by initiating recov-
ery. Crash-only systems are built from crash-only compo-
nents, and the use of transparent component-level retries
hides intra-system component crashes from end users. In
this paper we advocate a crash-only design for Internet sys-
tems, showing that it can lead to more reliable, predictable
code and faster, more effective recovery. We present ideas
on how to build such crash-only Internet services, taking
successful techniques to their logical extreme.
