This preview shows pages 1–3. Sign up to view the full content.
This preview has intentionally blurred sections. Sign up to view the full version.View Full Document
Unformatted text preview: M AP R EDUCE , C HURCH N UMERALS 10 GEORGE WANG email@example.com Department of Electrical Engineering and Computer Sciences University of California, Berkeley July 7, 2010 1 Generic Operators: Dyadic Operations Our shape example is easier than the arithmetic example in the book because our operations only require one operand, not two. For arithmetic operations like +, its not good enough to connect the operation with a type; the two operands might have two different types. What should you do if you have to add a rational number to a complex number? There is no perfect solution to this problem. For the particular case of arithmetic, were lucky in that the different types form a sequence of larger and larger sets. Every integer is a rational number; every rational is a real; every real is a complex. So we can deal with type mismatch by raising the less-complicated operand to the type of the other one. To add a rational number to a complex number, raise the rational number to complex and then youre left with the problem of adding two complex numbers. So we only need n addition algorithms, not n 2 algorithms, where n is the number of types. Do we need n 2 raising algorithms? No, because we dont have to know directly how to raise a rational number to complex. We can raise the rational number to the next higher type (real), and then raise that real number to complex. So if we want to add 1 , 3 , and 2 + 5 i the answer comes out 2 . 3333 + 5 i . As this example shows, nonchalant raising can lose information. It would be better, perhaps, if we could get the answer 7 3 + 5 i instead of the decimal approximation. Numbers are a rats nest full of traps for the unwary. You will live longer if you only write programs about integers. 1 2 MapReduce 2.1 Background In the past, functional programming, and higher-order functions in particular, have been considered eso- teric and unimportant by most programmers. But the advent of highly parallel computation is changing that, because functional programming has the very useful property that the different pieces of a program dont interfere with each other, so it doesnt matter in what order they are invoked. Later this semester, when we have more sophisticated functional mechanisms to work with, well be examining one famous ex- ample of functional programming at work: the MapReduce programming paradigm developed by Google that uses higher-order functions to allow a programmer to process large amount of data in parallel on many computers. Much of the computing done at Google consists of relatively simple algorithms applied to massive amounts of data, such as the entire World Wide Web. Its routine for them to use clusters consisting of many thou- sands of processors, all running the same program, with a distributed filesystem that gives each processor local access to part of the data....
View Full Document