In this chapter, we will introduce you to the tools you need to begin using MATLAB effectively. These include: some relevant information on computer platforms and software versions; installation and location protocols; how to launch the program, enter commands, use online help, and recover from hangups; a roster of MATLAB's various windows; and finally, how to quit the software. We know you are anxious to get started using MATLAB, so we will keep this chapter brief. After you complete it, you can go immediately to Chapter 2 to find concrete and simple instructions for the use of MATLAB. We describe the MATLAB interface more elaborately in Chapter 3.

Platforms and Versions

It is likely that you will run MATLAB on a PC (running Windows or Linux) or on some form of UNIX operating system. (The developers of MATLAB, The MathWorks, Inc., are no longer supporting Macintosh. Earlier versions of MATLAB were available for Macintosh; if you are running one of those, you should find that our instructions for Windows platforms will suffice for your needs.) Unlike previous versions of MATLAB, version 6 looks virtually identical on Windows and UNIX platforms. For definitiveness, we shall assume the reader is using a PC in a Windows environment. In those very few instances where our instructions must be tailored differently for Linux or UNIX users, we shall point it out clearly.

Jai alai is a sport of Basque origin in which opposing players or teams alternate hurling a ball against the wall and catching it until one of them finally misses and loses the point. The throwing and catching are done with an enlarged basket or cesta. The ball or pelota is made of goatskin and hard rubber, and the wall is of granite or concrete – which is a combination that leads to fast and exciting action. Jai alai is a popular spectator sport in Europe and the Americas. In the United States, it is most associated with the states of Florida, Connecticut, and Rhode Island, which permit parimutuel wagering on the sport.

In this chapter, we will delve deeper into the history and culture of jai alai. From the standpoint purely crass of winning money through gambling, much of this material is not strictly necessary, but a little history and culture never hurt anybody. Be my guest if you want to skip ahead to the more mercenary or technical parts of the book, but don't neglect to review the basic types of bets in jai alai and the Spectacular Seven scoring system. Understanding the implications of the scoring system is perhaps the single most important factor in successful jai alai wagering.

Much of this background material has been lifted from the fronton Websites described later in this chapter and earlier books on jai alai.

Economists are very concerned with the concept of market efficiency. Markets are efficient whenever prices reflect underlying values. Market efficiency implies that everyone has the same information about what is available and processes it correctly.

The question of whether the jai alai bettors' market is efficient goes straight to the heart of whether there is any hope to make money betting on it. All of the information that we use to predict the outcome of jai alai matches is available to the general public. Because we are betting against the public, we can only win if we can interpret this data more successfully than the rest of the market. We can win money if and only if the market is inefficient.

Analyzing market efficiency requires us to build a model of how the general public bets. Once we have an accurate betting model, we can compare it with the results of our Monte Carlo simulation to look for inefficiencies. Any bet that the public rates higher than our simulation is one to stay away from, whereas any bet that the simulation rates higher than the public represents a market inefficiency potentially worth exploiting.

The issue of market efficiency rears its head most dramatically in the stock market. Billions of dollars are traded daily in the major markets by tens of thousands of people watching minute-by-minute stock ticker reports. Quantitative market analysts (the so-called quants) believe that there are indeed inefficiencies in the stock market that show up as statistical patterns.

This is a book about predicting the future. It describes my attempt to master a small enough corner of the universe to glimpse the events of tomorrow, today. The degree to which one can do this in my tiny toy domain tells us something about our potential to foresee larger and more interesting futures.

Considered less prosaically, this is the story of my 25-year obsession with predicting the results of jai alai matches in order to bet on them successfully. As obsessions go, it probably does not rank with yearning for the love of one you will never have or questing for the freedom of an oppressed and downtrodden people. But it is my obsession – one that has led me down paths that were unimaginable at the beginning of the journey.

This book marks the successful completion of my long quest and gives me a chance to share what I have learned and experienced. I think the attentive reader will come to understand the worlds of mathematics, computers, gambling, and sports quite differently after reading this book.

My interest in jai alai began during my parents' annual escape from the cold of a New Jersey winter to the promised land of Florida. They stuffed the kids into a Ford station wagon and drove a thousand miles in 2 days each way. Florida held many attractions for a kid: the sun and the beach, Disney World, Grampa, Aunt Fanny, and Uncle Sam. But the biggest draw came to be the one night each trip when we went to a fronton, or jai alai stadium, and watched them play.

Mom was the biggest jai alai fan in the family and the real motivation behind our excursions. We loaded up the station wagon and drove to the Dania Jai-Alai fronton located midway between Miami and Fort Lauderdale. In the interests of preserving capital for later investment, my father carefully avoided the valet parking in favor of the do-it-yourself lot. We followed a trail of palm trees past the cashiers' windows into the fronton.

Walking into the fronton was an exciting experience. The playing court sat in a vast open space, three stories tall, surrounded by several tiers of stadium seating. To my eyes, at least, this was big-league, big-time sport. Particularly “cool” was the sign saying that no minors would be admitted without a parent. This was a very big deal when I was only 12 years old.

We followed the usher who led us to our seats. The first game had already started.

In this chapter we define and study one-way functions. One-way functions capture our notion of “useful” computational difficulty and serve as a basis for most of the results presented in this book. Loosely speaking, a one-way function is a function that is easy to evaluate but hard to invert (in an average-case sense). (See the illustration in Figure 2.1.) In particular, we define strong and weak one-way functions and prove that the existence of weak one-way functions implies the existence of strong ones. The proof provides a good example of a reducibility argument, which is a strong type of “reduction” used to establish most of the results in the area. Furthermore, the proof provides a simple example of a case where a computational statement is much harder to prove than its “information-theoretic analogue.”

In addition, we define hard-core predicates and prove that every one-way function has a hard-core predicate. Hard-core predicates will play an important role in almost all subsequent chapters (the chapter on signature scheme being the exception).

Organization. In Section 2.1 we motivate the definition of one-way functions by arguing informally that it is implicit in various natural cryptographic primitives. The basic definitions are given in Section 2.2, and in Section 2.3 we show that weak one-way functions can be used to construct strong ones. A more efficient construction (for certain restricted cases) is postponed to Section 2.6.

This book is the outgrowth of an effort to provide a course covering the general topic of uncertain inference. Philosophy students have long lacked a treatment of inductive logic that was acceptable; in fact, many professional philosophers would deny that there was any such thing and would replace it with a study of probability. Yet, there seems to many to be something more traditional than the shifting sands of subjective probabilities that is worth studying. Students of computer science may encounter a wide variety of ways of treating uncertainty and uncertain inference, ranging from nonmonotonic logic to probability to belief functions to fuzzy logic. All of these approaches are discussed in their own terms, but it is rare for their relations and interconnections to be explored. Cognitive science students learn early that the processes by which people make inferences are not quite like the formal logic processes that they study in philosophy, but they often have little exposure to the variety of ideas developed in philosophy and computer science. Much of the uncertain inference of science is statistical inference, but statistics rarely enter directly into the treatment of uncertainty to which any of these three groups of students are exposed.

At what level should such a course be taught? Because a broad and interdisciplinary understanding of uncertainty seemed to be just as lacking among graduate students as among undergraduates, and because without assuming some formal background all that could be accomplished would be rather superficial, the course was developed for upper-level undergraduates and beginning graduate students in these three disciplines. The original goal was to develop a course that would serve all of these groups.

Introduction

In Chapter 3, we discussed the axioms of the probability calculus and derived some of its theorems. We never said, however, what “probability” meant. From a formal or mathematical point of view, there was no need to: we could state and prove facts about the relations among probabilities without knowing what a probability is, just as we can state and prove theorems about points and lines without knowing what they are. (As Bertrand Russell said [Russell, 1901, p. 83] “Mathematics may be defined as the subject where we never know what we are talking about, nor whether what we are saying is true.”)

Nevertheless, because our goal is to make use of the notion of probability in understanding uncertain inference and induction, we must be explicit about its interpretation. There are several reasons for this. In the first place, if we are hoping to follow the injunction to believe what is probable, we have to know what is probable. There is no hope of assigning values to probabilities unless we have some idea of what probability means. What determines those values? Second, we need to know what the import of probability is for us. How is it supposed to bear on our epistemic states or our decisions? Third, what is the domain of the probability function? In the last chapter we took the domain to be a field, but that merely assigns structure to the domain: it doesn't tell us what the domain objects are.

There is no generally accepted interpretation of probability.

In this chapter, we describe some of the finer points of MATLAB and review in more detail some of the concepts introduced in Chapter 2. We explore enough of MATLAB's internal structure to improve your ability to work with complicated functions, expressions, and commands. At the end of this chapter, we introduce some of the MATLAB commands for doing calculus.

Suppressing Output

Some MATLAB commands produce output that is superfluous. For example, when you assign a value to a variable, MATLAB echoes the value. You can suppress the output of a command by putting a semicolon after the command. Here is an example:

The semicolon does not affect the way MATLAB processes the command internally, as you can see from its response to the command z.

You can also use semicolons to separate a string of commands when you are interested only in the output of the final command (several examples appear later in the chapter). Commas can also be used to separate commands without suppressing output. If you use a semicolon after a graphics command, it will not suppress the graphic.

⇒ The most common use of the semicolon is to suppress the printing of a long vector, as indicated in Chapter 2.

Another object that you may want to suppress is MATLAB's label for the output of a command. The command disp is designed to achieve that; typing disp(x) will print the value of the variable x without printing the label and the equal sign.