Advanced R, Second Edition by Hadley

Wickham
Go to download the full and correct content document:
https://ebooksecure.com/product/advanced-r-second-edition-by-hadley-wickham/
More products digital (pdf, epub, mobi) instant
download maybe you interests ...

(eBook PDF) Advanced Pediatric Assessment, Second

Edition 2nd Edition

http://ebooksecure.com/product/ebook-pdf-advanced-pediatric-
assessment-second-edition-2nd-edition/

(Original PDF) Quantitative Corpus Linguistics with R

Second Edition

http://ebooksecure.com/product/original-pdf-quantitative-corpus-
linguistics-with-r-second-edition/

Business and Management Consulting 6th Edition Louise

Wickham - eBook PDF

https://ebooksecure.com/download/business-and-management-
consulting-ebook-pdf/

(eBook PDF) Advanced Introduction to International

Trade Law, Second Edition

http://ebooksecure.com/product/ebook-pdf-advanced-introduction-
to-international-trade-law-second-edition/
(eBook PDF) Women's Health Care in Advanced Practice
Nursing, Second Edition

http://ebooksecure.com/product/ebook-pdf-womens-health-care-in-
advanced-practice-nursing-second-edition-2/

(eBook PDF) Womens Health Care in Advanced Practice

Nursing, Second Edition

http://ebooksecure.com/product/ebook-pdf-womens-health-care-in-
advanced-practice-nursing-second-edition/

Practice Makes Perfect®: Advanced French Grammar,

Second Edition Véronique Mazet - eBook PDF

https://ebooksecure.com/download/practice-makes-perfect-advanced-
french-grammar-second-edition-ebook-pdf/

Advanced Engineering Mathematics (Gujarat Technological

University 2016) 4th Edition Ravish R Singh - eBook PDF

https://ebooksecure.com/download/advanced-engineering-
mathematics-gujarat-technological-university-2016-ebook-pdf/

Advanced Engineering Mathematics (Gujarat Technological

University 2018) 4th Edition Ravish R Singh - eBook PDF

https://ebooksecure.com/download/advanced-engineering-
mathematics-gujarat-technological-university-2018-ebook-pdf/
Contents

Preface xiii

1 Introduction 1
1.1 Why R? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Who should read this book . . . . . . . . . . . . . . . . . . . 3
1.3 What you will get out of this book . . . . . . . . . . . . . . . 4
1.4 What you will not learn . . . . . . . . . . . . . . . . . . . . . 4
1.5 Meta-techniques . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.6 Recommended reading . . . . . . . . . . . . . . . . . . . . . 5
1.7 Getting help . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.8 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
1.9 Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.10 Colophon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

I Foundations 13
Introduction 15

2 Names and values 17

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2 Binding basics . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3 Copy-on-modify . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.4 Object size . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.5 Modify-in-place . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.6 Unbinding and the garbage collector . . . . . . . . . . . . . . 36
2.7 Quiz answers . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3 Vectors 39
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2 Atomic vectors . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.3 Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.4 S3 atomic vectors . . . . . . . . . . . . . . . . . . . . . . . . 50
3.5 Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.6 Data frames and tibbles . . . . . . . . . . . . . . . . . . . . . 58

vii
viii Contents

3.7 NULL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.8 Quiz answers . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

4 Subsetting 73
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.2 Selecting multiple elements . . . . . . . . . . . . . . . . . . . 74
4.3 Selecting a single element . . . . . . . . . . . . . . . . . . . . 81
4.4 Subsetting and assignment . . . . . . . . . . . . . . . . . . . 85
4.5 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.6 Quiz answers . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

5 Control flow 97
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
5.2 Choices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
5.3 Loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
5.4 Quiz answers . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

6 Functions 107
6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
6.2 Function fundamentals . . . . . . . . . . . . . . . . . . . . . 109
6.3 Function composition . . . . . . . . . . . . . . . . . . . . . . 113
6.4 Lexical scoping . . . . . . . . . . . . . . . . . . . . . . . . . . 115
6.5 Lazy evaluation . . . . . . . . . . . . . . . . . . . . . . . . . 120
6.6 ... (dot-dot-dot) . . . . . . . . . . . . . . . . . . . . . . . . . 125
6.7 Exiting a function . . . . . . . . . . . . . . . . . . . . . . . . 128
6.8 Function forms . . . . . . . . . . . . . . . . . . . . . . . . . . 134
6.9 Quiz answers . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

7 Environments 143
7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
7.2 Environment basics . . . . . . . . . . . . . . . . . . . . . . . 144
7.3 Recursing over environments . . . . . . . . . . . . . . . . . . 153
7.4 Special environments . . . . . . . . . . . . . . . . . . . . . . 156
7.5 Call stacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
7.6 As data structures . . . . . . . . . . . . . . . . . . . . . . . . 169
7.7 Quiz answers . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

8 Conditions 171
8.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
8.2 Signalling conditions . . . . . . . . . . . . . . . . . . . . . . . 173
8.3 Ignoring conditions . . . . . . . . . . . . . . . . . . . . . . . 178
8.4 Handling conditions . . . . . . . . . . . . . . . . . . . . . . . 180
8.5 Custom conditions . . . . . . . . . . . . . . . . . . . . . . . . 188
8.6 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
8.7 Quiz answers . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Contents ix

II Functional programming 203

Introduction 205

9 Functionals 209
9.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
9.2 My first functional: map() . . . . . . . . . . . . . . . . . . . . 211
9.3 Purrr style . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
9.4 Map variants . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
9.5 Reduce family . . . . . . . . . . . . . . . . . . . . . . . . . . 233
9.6 Predicate functionals . . . . . . . . . . . . . . . . . . . . . . 239
9.7 Base functionals . . . . . . . . . . . . . . . . . . . . . . . . . 242

10 Function factories 247

10.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
10.2 Factory fundamentals . . . . . . . . . . . . . . . . . . . . . . 249
10.3 Graphical factories . . . . . . . . . . . . . . . . . . . . . . . . 256
10.4 Statistical factories . . . . . . . . . . . . . . . . . . . . . . . 261
10.5 Function factories + functionals . . . . . . . . . . . . . . . . 268

11 Function operators 271

11.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
11.2 Existing function operators . . . . . . . . . . . . . . . . . . . 272
11.3 Case study: Creating your own function operators . . . . . . 278

III Object-oriented programming 283

Introduction 285

12 Base types 291

12.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
12.2 Base versus OO objects . . . . . . . . . . . . . . . . . . . . . 292
12.3 Base types . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293

13 S3 297
13.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
13.2 Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
13.3 Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
13.4 Generics and methods . . . . . . . . . . . . . . . . . . . . . . 309
13.5 Object styles . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
13.6 Inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
13.7 Dispatch details . . . . . . . . . . . . . . . . . . . . . . . . . 320

14 R6 325
14.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
14.2 Classes and methods . . . . . . . . . . . . . . . . . . . . . . 326
x Contents

14.3 Controlling access . . . . . . . . . . . . . . . . . . . . . . . . 332

14.4 Reference semantics . . . . . . . . . . . . . . . . . . . . . . . 336
14.5 Why R6? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340

15 S4 341
15.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
15.2 Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
15.3 Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
15.4 Generics and methods . . . . . . . . . . . . . . . . . . . . . . 349
15.5 Method dispatch . . . . . . . . . . . . . . . . . . . . . . . . . 352
15.6 S4 and S3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359

16 Trade-offs 363
16.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
16.2 S4 versus S3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
16.3 R6 versus S3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 365

IV Metaprogramming 371
Introduction 373

17 Big picture 375

17.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
17.2 Code is data . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
17.3 Code is a tree . . . . . . . . . . . . . . . . . . . . . . . . . . 377
17.4 Code can generate code . . . . . . . . . . . . . . . . . . . . . 378
17.5 Evaluation runs code . . . . . . . . . . . . . . . . . . . . . . 380
17.6 Customising evaluation with functions . . . . . . . . . . . . . 381
17.7 Customising evaluation with data . . . . . . . . . . . . . . . 382
17.8 Quosures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383

18 Expressions 385
18.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
18.2 Abstract syntax trees . . . . . . . . . . . . . . . . . . . . . . 386
18.3 Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391
18.4 Parsing and grammar . . . . . . . . . . . . . . . . . . . . . . 399
18.5 Walking AST with recursive functions . . . . . . . . . . . . . 404
18.6 Specialised data structures . . . . . . . . . . . . . . . . . . . 411

19 Quasiquotation 415
19.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
19.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416
19.3 Quoting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
19.4 Unquoting . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424
19.5 Non-quoting . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
19.6 ... (dot-dot-dot) . . . . . . . . . . . . . . . . . . . . . . . . . 436
Contents xi

19.7 Case studies . . . . . . . . . . . . . . . . . . . . . . . . . . . 442

19.8 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448

20 Evaluation 451
20.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
20.2 Evaluation basics . . . . . . . . . . . . . . . . . . . . . . . . 452
20.3 Quosures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457
20.4 Data masks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
20.5 Using tidy evaluation . . . . . . . . . . . . . . . . . . . . . . 468
20.6 Base evaluation . . . . . . . . . . . . . . . . . . . . . . . . . 472

21 Translating R code 481

21.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 481
21.2 HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482
21.3 LaTeX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492

V Techniques 501
Introduction 503

22 Debugging 505
22.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 505
22.2 Overall approach . . . . . . . . . . . . . . . . . . . . . . . . . 506
22.3 Locating errors . . . . . . . . . . . . . . . . . . . . . . . . . . 507
22.4 Interactive debugger . . . . . . . . . . . . . . . . . . . . . . . 509
22.5 Non-interactive debugging . . . . . . . . . . . . . . . . . . . 513
22.6 Non-error failures . . . . . . . . . . . . . . . . . . . . . . . . 516

23 Measuring performance 519

23.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 519
23.2 Profiling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520
23.3 Microbenchmarking . . . . . . . . . . . . . . . . . . . . . . . 526

24 Improving performance 531

24.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 531
24.2 Code organisation . . . . . . . . . . . . . . . . . . . . . . . . 532
24.3 Checking for existing solutions . . . . . . . . . . . . . . . . . 534
24.4 Doing as little as possible . . . . . . . . . . . . . . . . . . . . 535
24.5 Vectorise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539
24.6 Avoiding copies . . . . . . . . . . . . . . . . . . . . . . . . . . 541
24.7 Case study: t-test . . . . . . . . . . . . . . . . . . . . . . . . 542
24.8 Other techniques . . . . . . . . . . . . . . . . . . . . . . . . . 544

25 Rewriting R code in C++ 547

25.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 547
25.2 Getting started with C++ . . . . . . . . . . . . . . . . . . . 548
xii Contents

25.3 Other classes . . . . . . . . . . . . . . . . . . . . . . . . . . . 557

25.4 Missing values . . . . . . . . . . . . . . . . . . . . . . . . . . 559
25.5 Standard Template Library . . . . . . . . . . . . . . . . . . . 563
25.6 Case studies . . . . . . . . . . . . . . . . . . . . . . . . . . . 570
25.7 Using Rcpp in a package . . . . . . . . . . . . . . . . . . . . 574
25.8 Learning more . . . . . . . . . . . . . . . . . . . . . . . . . . 575
25.9 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 576

Bibliography 577

Index 581
Preface

Welcome to the second edition of Advanced R. I had three main goals for this
edition:
• Improve coverage of important concepts that I fully understood only after
the publication of the first edition.
• Reduce coverage of topics time has shown to be less useful, or that I think
are really exciting but turn out not to be that practical.
• Generally make the material easier to understand with better text, clearer
code, and many more diagrams.
If you’re familiar with the first edition, this preface describes the major changes
so that you can focus your reading on the new areas. If you’re reading a printed
version of this book you’ll notice one big change very quickly: Advanced R is
now in colour! This has considerably improved the syntax highlighting of code
chunks, and made it much easier to create helpful diagrams. I have taken ad-
vantage of this and included over 100 new diagrams throughout the book.
Another big change in this version is the use of new packages, particularly
rlang (http://rlang.r-lib.org), which provides a clean interface to low-level
data structures and operations. The first edition used base R functions al-
most exclusively, which created some pedagogical challenges because many
functions evolved independently over multiple years, making it hard to see
the big underlying ideas hidden amongst the incidental variations in function
names and arguments. I continue to show base equivalents in sidebars, foot-
notes, and where needed, in individual sections, but if you want to see the
purest base R expression of the ideas in this book, I recommend reading the
first edition, which you can find online at http://adv-r.had.co.nz.
The foundations of R have not changed in the five years since the first edition,
but my understanding of them certainly has. Thus, the overall structure of
“Foundations” has remained roughly the same, but many of the individual
chapters have been considerably improved:
• Chapter 2, “Names and values”, is a brand new chapter that helps you
understand the difference between objects and names of objects. This helps
you more accurately predict when R will make a copy of a data structure,
and lays important groundwork to understand functional programming.

xiii
xiv Preface

• Chapter 3, “Vectors” (previously called data structures), has been rewrit-

ten to focus on vector types like integers, factors, and data frames. It
contains more details of important S3 vectors (like dates and date-times),
discusses the data frame variation provided by the tibble package [Müller
and Wickham, 2018], and generally reflects my improved understanding
of vector data types.
• Chapter 4, “Subsetting”, now distinguishes between [ and [[ by their in-
tention: [ extracts many values and [[ extracts a single value (previously
they were characterised by whether they “simplified” or “preserved”). Sec-
tion 4.3 draws the “train” to help you understand how [[ works with lists,
and introduces new functions that provide more consistent behaviour for
out-of-bounds indices.
• Chapter 5, “Control flow”, is a new chapter: somehow I previously forgot
about important tools like if statements and for loops!
• Chapter 6, “Functions”, has an improved ordering, introduces the pipe
(%>%) as a third way to compose functions (Section 6.3), and has consider-
ably improved coverage of function forms (Section 6.8).
• Chapter 7, “Environments”, has a reorganised treatment of special envi-
ronments (Section 7.4), and a much improved discussion of the call stack
(Section 7.5).
• Chapter 8, “Conditions”, contains material previously in “Exceptions and
debugging”, and much new content on how R’s condition system works. It
also shows you how to create your own custom condition classes (Section
8.5).
The chapters following Part I, Foundations, have been re-organised around the
three most important programming paradigms in R: functional programming,
object-oriented programming, and metaprogramming.
• Functional programming is now more cleanly divided into the three main
techniques: “Functionals” (Chapter 9), “Function factories” (Chapter 10),
and “Function operators” (Chapter 11). I’ve focussed in on ideas that
have practical applications in data science and reduced the amount of
pure theory.
These chapters now use functions provided by the purrr package [Henry
and Wickham, 2018a], which allow me to focus more on the underlying
ideas and less on the incidental details. This led to a considerable simpli-
fication of the function operators chapter since a major use was to work
around the absence of ellipses (...) in base functionals.
• Object-oriented programming (OOP) now forms a major section of the
book with completely new chapters on base types (Chapter 12), S3 (Chap-
ter 13), S4 (Chapter 15), R6 (Chapter 14), and the tradeoffs between the
systems (Chapter 16).
Preface xv

These chapters focus on how the different object systems work, not how
to use them effectively. This is unfortunate, but necessary, because many
of the technical details are not described elsewhere, and effective use of
OOP needs a whole book of its own.
• Metaprogramming (previously called “computing on the language”) de-
scribes the suite of tools that you can use to generate code with code.
Compared to the first edition this material has been substantially ex-
panded and now focusses on “tidy evaluation”, a set of ideas and theory
that make metaprogramming safe, well-principled, and accessible to many
more R programmers. Chapter 17, “Big picture” coarsely lays out how
all the pieces fit together; Chapter 18, “Expressions”, describes the under-
lying data structures; Chapter 19, “Quasiquotation”, covers quoting and
unquoting; Chapter 20, “Evaluation”, explains evaluation of code in spe-
cial environments; and Chapter 21, “Translations”, pulls all the themes
together to show how you might translate from one (programming) lan-
guage to another.
The final section of the book pulls together the chapters on programming
techniques: profiling, measuring and improving performance, and Rcpp. The
contents are very similar to the first edition, although the organisation is a
little different. I have made light updates throughout these chapters particu-
larly to use newer packges (microbenchmark -> bench, lineprof -> profvis),
but the majority of the text is the same.
While the second edition has mostly expanded coverage of existing material,
five chapters have been removed:
• The vocabulary chapter has been removed because it was always a bit of
an odd duck, and there are more effective ways to present vocabulary lists
than in a book chapter.
• The style chapter has been replaced with an online style guide, http:
//style.tidyverse.org/. The style guide is paired with the new styler
package [Müller and Walthert, 2018] which can automatically apply many
of the rules.
• The C chapter has been moved to https://github.com/hadley/r-
internals, which, over time, will provide a guide to writing C code that
works with R’s data structures.
• The memory chapter has been removed. Much of the material has been
integrated into Chapter 2 and the remainder felt excessively technical and
not that important to understand.
• The chapter on R’s performance as a language was removed. It delivered
few actionable insights, and became dated as R changed.
1
Introduction

I have now been programming in R for over 15 years, and have been doing
it full-time for the last five years. This has given me the luxury of time to
examine how the language works. This book is my attempt to pass on what
I’ve learned so that you can understand the intricacies of R as quickly and
painlessly as possible. Reading it will help you avoid the mistakes I’ve made
and dead ends I’ve gone down, and will teach you useful tools, techniques, and
idioms that can help you to attack many types of problems. In the process, I
hope to show that, despite its sometimes frustrating quirks, R is, at its heart,
an elegant and beautiful language, well tailored for data science.

1.1 Why R?
If you are new to R, you might wonder what makes learning such a quirky
language worthwhile. To me, some of the best features are:
• It’s free, open source, and available on every major platform. As a result,
if you do your analysis in R, anyone can easily replicate it, regardless of
where they live or how much money they earn.
• R has a diverse and welcoming community, both online (e.g. the #rstats
twitter community (https://twitter.com/search?q=%23rstats)) and in
person (like the many R meetups (https://www.meetup.com/topics/r-
programming-language/)). Two particularly inspiring community groups
are rweekly newsletter (https://rweekly.org) which makes it easy to keep
up to date with R, and R-Ladies (http://r-ladies.org) which has made a
wonderfully welcoming community for women and other minority genders.
• A massive set of packages for statistical modelling, machine learning, vi-
sualisation, and importing and manipulating data. Whatever model or
graphic you’re trying to do, chances are that someone has already tried to
do it and you can learn from their efforts.
• Powerful tools for communicating your results. RMarkdown (https://
rmarkdown.rstudio.com) makes it easy to turn your results into HTML

1
2 1 Introduction

files, PDFs, Word documents, PowerPoint presentations, dashboards and

more. Shiny (http://shiny.rstudio.com) allows you to make beautiful in-
teractive apps without any knowledge of HTML or javascript.
• RStudio, the IDE (http://www.rstudio.com/ide/), provides an integrated
development environment, tailored to the needs of data science, interactive
data analysis, and statistical programming.
• Cutting edge tools. Researchers in statistics and machine learning will of-
ten publish an R package to accompany their articles. This means imme-
diate access to the very latest statistical techniques and implementations.
• Deep-seated language support for data analysis. This includes features like
missing values, data frames, and vectorisation.
• A strong foundation of functional programming. The ideas of functional
programming are well suited to the challenges of data science, and the R
language is functional at heart, and provides many primitives needed for
effective functional programming.
• RStudio, the company (https://www.rstudio.com), which makes money by
selling professional products to teams of R users, and turns around and
invests much of that money back into the open source community (over
50% of software engineers at RStudio work on open source projects). I
work for RStudio because I fundamentally believe in its mission.
• Powerful metaprogramming facilities. R’s metaprogramming capabilities
allow you to write magically succinct and concise functions and provide an
excellent environment for designing domain-specific languages like ggplot2,
dplyr, data.table, and more.
• The ease with which R can connect to high-performance programming
languages like C, Fortran, and C++.
Of course, R is not perfect. R’s biggest challenge (and opportunity!) is that
most R users are not programmers. This means that:
• Much of the R code you’ll see in the wild is written in haste to solve a
pressing problem. As a result, code is not very elegant, fast, or easy to
understand. Most users do not revise their code to address these short-
comings.
• Compared to other programming languages, the R community is more
focussed on results than processes. Knowledge of software engineering best
practices is patchy. For example, not enough R programmers use source
code control or automated testing.
• Metaprogramming is a double-edged sword. Too many R functions use
tricks to reduce the amount of typing at the cost of making code that is
hard to understand and that can fail in unexpected ways.
1.3 Who should read this book 3

• Inconsistency is rife across contributed packages, and even within base R.

You are confronted with over 25 years of evolution every time you use R,
and this can make learning R tough because there are so many special
cases to remember.
• R is not a particularly fast programming language, and poorly written R
code can be terribly slow. R is also a profligate user of memory.
Personally, I think these challenges create a great opportunity for experienced
programmers to have a profound positive impact on R and the R community.
R users do care about writing high quality code, particularly for reproducible
research, but they don’t yet have the skills to do so. I hope this book will
not only help more R users to become R programmers, but also encourage
programmers from other languages to contribute to R.

1.2 Who should read this book

This book is aimed at two complementary audiences:
• Intermediate R programmers who want to dive deeper into R, understand
how the language works, and learn new strategies for solving diverse prob-
lems.
• Programmers from other languages who are learning R and want to un-
derstand why R works the way it does.
To get the most out of this book, you’ll need to have written a decent amount
of code in R or another programming language. You should be familiar with
the basics of data analysis (i.e. data import, manipulation, and visualisation),
have written a number of functions, and be familiar with the installation and
use of CRAN packages.
This book walks the narrow line between being a reference book (primarily
used for lookup), and being linearly readable. This involves some tradeoffs,
because it’s difficult to linearise material while still keeping related materi-
als together, and some concepts are much easier to explain if you’re already
familiar with specific technical vocabulary. I’ve tried to use footnotes and
cross-references to make sure you can still make sense even if you just dip
your toes in a chapter.
4 1 Introduction

1.3 What you will get out of this book

This book delivers the knowledge that I think an advanced R programmer
should possess: a deep understanding of the fundamentals coupled with a
broad vocabulary that means that you can tactically learn more about a topic
when needed.
After reading this book, you will:
• Be familiar with the foundations of R. You will understand complex data
types and the best ways to perform operations on them. You will have a
deep understanding of how functions work, you’ll know what environments
are, and how to make use of the condition system.
• Understand what functional programming means, and why it is a useful
tool for data science. You’ll be able to quickly learn how to use existing
tools, and have the knowledge to create your own functional tools when
needed.
• Know about R’s rich variety of object-oriented systems. You’ll be most
familiar with S3, but you’ll know of S4 and R6 and where to look for more
information when needed.
• Appreciate the double-edged sword of metaprogramming. You’ll be able
to create functions that use tidy evaluation, saving typing and creating
elegant code to express important operations. You’ll also understand the
dangers and when to avoid it.
• Have a good intuition for which operations in R are slow or use a lot of
memory. You’ll know how to use profiling to pinpoint performance bottle-
necks, and you’ll know enough C++ to convert slow R functions to fast
C++ equivalents.

1.4 What you will not learn

This book is about R the programming language, not R the data analysis tool.
If you are looking to improve your data science skills, I instead recommend
that you learn about the tidyverse (https://www.tidyverse.org/), a collection
of consistent packages developed by me and my colleagues. In this book you’ll
learn the techniques used to develop the tidyverse packages; if you want to
instead learn how to use them, I recommend R for Data Science (http://
r4ds.had.co.nz/).
1.6 Meta-techniques 5

If you want to share your R code with others, you will need to make an R pack-
age. This allows you to bundle code along with documentation and unit tests,
and easily distribute it via CRAN. In my opinion, the easiest way to develop
packages is with devtools (http://devtools.r-lib.org), roxygen2 (http://
klutometis.github.io/roxygen/), testthat (http://testthat.r-lib.org), and
usethis (http://usethis.r-lib.org). You can learn about using these pack-
ages to make your own package in R packages (http://r-pkgs.had.co.nz/).

1.5 Meta-techniques
There are two meta-techniques that are tremendously helpful for improving
your skills as an R programmer: reading source code and adopting a scientific
mindset.
Reading source code is important because it will help you write better code.
A great place to start developing this skill is to look at the source code of the
functions and packages you use most often. You’ll find things that are worth
emulating in your own code and you’ll develop a sense of taste for what makes
good R code. You will also see things that you don’t like, either because its
virtues are not obvious or it offends your sensibilities. Such code is nonetheless
valuable, because it helps make concrete your opinions on good and bad code.
A scientific mindset is extremely helpful when learning R. If you don’t under-
stand how something works, you should develop a hypothesis, design some
experiments, run them, and record the results. This exercise is extremely use-
ful since if you can’t figure something out and need to get help, you can easily
show others what you tried. Also, when you learn the right answer, you’ll be
mentally prepared to update your world view.

1.6 Recommended reading

Because the R community mostly consists of data scientists, not computer sci-
entists, there are relatively few books that go deep in the technical underpin-
nings of R. In my personal journey to understand R, I’ve found it particularly
helpful to use resources from other programming languages. R has aspects of
both functional and object-oriented (OO) programming languages. Learning
how these concepts are expressed in R will help you leverage your existing
knowledge of other programming languages, and will help you identify areas
where you can improve.
6 1 Introduction

To understand why R’s object systems work the way they do, I found The
Structure and Interpretation of Computer Programs1 [Abelson et al., 1996]
(SICP) to be particularly helpful. It’s a concise but deep book, and after read-
ing it, I felt for the first time that I could actually design my own object-
oriented system. The book was my first introduction to the encapsulated
paradigm of object-oriented programming found in R, and it helped me un-
derstand the strengths and weaknesses of this system. SICP also teaches the
functional mindset where you create functions that are simple individually,
and which become powerful when composed together.
To understand the trade-offs that R has made compared to other programming
languages, I found Concepts, Techniques and Models of Computer Program-
ming [Van-Roy and Haridi, 2004] extremely helpful. It helped me understand
that R’s copy-on-modify semantics make it substantially easier to reason about
code, and that while its current implementation is not particularly efficient,
it is a solvable problem.
If you want to learn to be a better programmer, there’s no place better to
turn than The Pragmatic Programmer [Hunt and Thomas, 1990]. This book
is language agnostic, and provides great advice for how to be a better pro-
grammer.

1.7 Getting help

Currently, there are three main venues to get help when you’re stuck and
can’t figure out what’s causing the problem: RStudio Community (https:
//community.rstudio.com/), StackOverflow (http://stackoverflow.com) and
the R-help mailing list (https://stat.ethz.ch/mailman/listinfo/r-help). You
can get fantastic help in each venue, but they do have their own cultures and
expectations. It’s usually a good idea to spend a little time lurking, learning
about community expectations, before you put up your first post.
Some good general advice:
• Make sure you have the latest version of R and of the package (or packages)
you are having problems with. It may be that your problem is the result
of a recently fixed bug.
• Spend some time creating a reproducible example, or reprex. This will
help others help you, and often leads to a solution without asking others,
because in the course of making the problem reproducible you often figure
1 You can read it online for free at https://mitpress.mit.edu/sites/default/files/sicp/
full-text/book/book.html
1.8 Acknowledgments 7

out the root cause. I highly recommend learning and using the reprex
(https://reprex.tidyverse.org/) package.
If you are looking for specific help solving the exercises in this book, solutions
from Malte Grosser and Henning Bumann are available at https://advanced-
r-solutions.rbind.io.

1.8 Acknowledgments
I would like to thank the many contributors to R-devel and R-help and,
more recently, Stack Overflow and RStudio Community. There are too many
to name individually, but I’d particularly like to thank Luke Tierney, John
Chambers, JJ Allaire, and Brian Ripley for generously giving their time and
correcting my countless misunderstandings.
This book was written in the open (https://github.com/hadley/adv-r/),
and chapters were advertised on twitter (https://twitter.com/hadleywickham)
when complete. It is truly a community effort: many people read drafts, fixed
typos, suggested improvements, and contributed content. Without those con-
tributors, the book wouldn’t be nearly as good as it is, and I’m deeply grate-
ful for their help. Special thanks go to Jeff Hammerbacher, Peter Li, Duncan
Murdoch, and Greg Wilson, who all read the book from cover-to-cover and
provided many fixes and suggestions.
A big thank you to all 386 contributors (in alphabetical order by username):
Aaron Wolen (@aaronwolen), @absolutelyNoWarranty, Adam Hunt (@adam-
phunt), @agrabovsky, Alexander Grueneberg (@agrueneberg), Anthony Dam-
ico (@ajdamico), James Manton (@ajdm), Aaron Schumacher (@ajschu-
macher), Alan Dipert (@alandipert), Alex Brown (@alexbbrown), @alexper-
rone, Alex Whitworth (@alexWhitworth), Alexandros Kokkalis (@alko989),
@amarchin, Amelia McNamara (@AmeliaMN), Bryce Mecum (@amoeba),
Andrew Laucius (@andrewla), Andrew Bray (@andrewpbray), Andrie de
Vries (@andrie), Angela Li (@angela-li), @aranlunzer, Ari Lamstein (@aril-
amstein), @asnr, Andy Teucher (@ateucher), Albert Vilella (@avilella), bap-
tiste (@baptiste), Brian G. Barkley (@BarkleyBG), Mara Averick (@batpi-
gandme), Byron (@bcjaeger), Brandon Greenwell (@bgreenwell), Brandon
Hurr (@bhive01), Jason Knight (@binarybana), Brett Klamer (@bklamer),
Jesse Anderson (@blindjesse), Brian Mayer (@blmayer), Benjamin L. Moore
(@blmoore), Brian Diggs (@BrianDiggs), Brian S. Yandell (@byandell),
@carey1024, Chip Hogg (@chiphogg), Chris Muir (@ChrisMuir), Christo-
pher Gandrud (@christophergandrud), Clay Ford (@clayford), Colin Fay
(@ColinFay), @cortinah, Cameron Plouffe (@cplouffe), Carson Sievert (@cp-
sievert), Craig Citro (@craigcitro), Craig Grabowski (@craiggrabowski),
8 1 Introduction

Christopher Roach (@croach), Peter Meilstrup (@crowding), Crt Ahlin

(@crtahlin), Carlos Scheidegger (@cscheid), Colin Gillespie (@csgillespie),
Christopher Brown (@ctbrown), Davor Cubranic (@cubranic), Darren Cu-
sanovich (@cusanovich), Christian G. Warden (@cwarden), Charlotte Wick-
ham (@cwickham), Dean Attali (@daattali), Dan Sullivan (@dan87134),
Daniel Barnett (@daniel-barnett), Daniel (@danielruc91), Kenny Darrell
(@darrkj), Tracy Nance (@datapixie), Dave Childers (@davechilders), David
Vukovic (@david-vukovic), David Rubinger (@davidrubinger), David Chudz-
icki (@dchudz), Deependra Dhakal (@DeependraD), Daisuke ICHIKAWA
(@dichika), david kahle (@dkahle), David LeBauer (@dlebauer), David
Schweizer (@dlschweizer), David Montaner (@dmontaner), @dmurdoch,
Zhuoer Dong (@dongzhuoer), Doug Mitarotonda (@dougmitarotonda),
Dragoș Moldovan-Grünfeld (@dragosmg), Jonathan Hill (@Dripdrop12),
@drtjc, Julian During (@duju211), @duncanwadsworth, @eaurele, Dirk Ed-
delbuettel (@eddelbuettel), @EdFineOKL, Eduard Szöcs (@EDiLD), Edwin
Thoen (@EdwinTh), Ethan Heinzen (@eheinzen), @eijoac, Joel Schwartz
(@eipi10), Eric Ronald Legrand (@elegrand), Elio Campitelli (@eliocamp), El-
lis Valentiner (@ellisvalentiner), Emil Hvitfeldt (@EmilHvitfeldt), Emil Rehn-
berg (@EmilRehnberg), Daniel Lee (@erget), Eric C. Anderson (@eriqande),
Enrico Spinielli (@espinielli), @etb, David Hajage (@eusebe), Fabian Scheipl
(@fabian-s), @flammy0530, François Michonneau (@fmichonneau), Fran-
cois Pepin (@fpepin), Frank Farach (@frankfarach), @freezby, Frans van
Dunné (@FvD), @fyears, @gagnagaman, Garrett Grolemund (@garrettgman),
Gavin Simpson (@gavinsimpson), Brooke Anderson (@geanders), @gezakiss7,
@gggtest, Gökçen Eraslan (@gokceneraslan), Josh Goldberg (@Goldberg-
Data), Georg Russ (@gr650), @grasshoppermouse, Gregor Thomas (@gre-
gorp), Garrett See (@gsee), Ari Friedman (@gsk3), Gunnlaugur Thor Briem
(@gthb), Greg Wilson (@gvwilson), Hamed (@hamedbh), Jeff Hammer-
bacher (@hammer), Harley Day (@harleyday), @hassaad85, @helmingstay,
Henning (@henningsway), Henrik Bengtsson (@HenrikBengtsson), Ching
Boon (@hoscb), @hplieninger, Hörmet Yiltiz (@hyiltiz), Iain Dillingham
(@iaindillingham), @IanKopacka, Ian Lyttle (@ijlyttle), Ilan Man (@ilan-
man), Imanuel Costigan (@imanuelcostigan), Thomas Bürli (@initdch),
Os Keyes (@Ironholds), @irudnyts, i (@isomorphisms), Irene Steves (@is-
teves), Jan Gleixner (@jan-glx), Jannes Muenchow (@jannes-m), Jason
Asher (@jasonasher), Jason Davies (@jasondavies), Chris (@jastingo), jcbor-
ras (@jcborras), Joe Cheng (@jcheng5), John Blischak (@jdblischak), @je-
harmse, Lukas Burk (@jemus42), Jennifer (Jenny) Bryan (@jennybc), Justin
Jent (@jentjr), Jeston (@JestonBlu), Josh Cook (@jhrcook), Jim Hester
(@jimhester), @JimInNashville, @jimmyliu2017, Jim Vine (@jimvine), Jin-
long Yang (@jinlong25), J.J. Allaire (@jjallaire), @JMHay, Jochen Van
de Velde (@jochenvdv), Johann Hibschman (@johannh), John Baumgart-
ner (@johnbaums), John Horton (@johnjosephhorton), @johnthomas12, Jon
Calder (@jonmcalder), Jon Harmon (@jonthegeek), Julia Gustavsen (@jooo-
lia), JorneBiccler (@JorneBiccler), Jeffrey Arnold (@jrnold), Joyce Rob-
Another random document with
no related content on Scribd:
always causes laughter and the artist considers that as a proof of the
success of his work.
To produce this effect, the animator selects from his studies three
or five consecutive positions of a gallop, or trot, that will animate
well. This means, specifically, that any particular drawing should,
with the next in order, give an appearance of movement when they
are synthesized. The drawings are made in a cycle so that when
used continuously in their order they will give the illusion desired.

A PANORAMA EFFECT OBTAINED BY THE USE OF THE

THREE DRAWINGS ON THE OPPOSITE PAGE.
In a panorama it is not necessary to trouble about a matter that in
other forms of screen representation of locomotion are highly
important. This is to have the feet register, by which is meant that in
any several succeeding drawings where a foot is represented as
touching, bearing down, and leaving the ground, it should do all this
on a footprint that coincides in all of the series. Tracing over the
illuminated glass, while making the drawings, is the only way to get
footprints accurately placed.
 GALLOPING HORSE.
Three phases of the action for panorama effects.
The droll-looking giraffe, with his awkwardly set limbs, has a
different sort of movement, in some of his paces, from that remarked
as natural to quadrupeds. In the giraffe, the two limbs of the same
side move at the same time and in the same direction. The camel is
also noted as going this way, and the elephant has a pace that
seems to be a combination of the amble and the typical four-footed
way of walking.
 THE ELEPHANT IN MOTION.
Now and then the animator has as one of his characters a walking
bird; an ungainly ostrich is a good example, or a droll duck, perhaps.
Here he will have plenty of scope in applying his skill as a humorous
draftsman. A nodding of the head and a bobbing of the body from
side to side in the duck, and in the case of the ostrich a wiggling of
the neck, are appropriate adjuncts to such animation.
 THE ELEPHANT IN MOTION (continued).
In the walking movement of a bird the method of getting the
different phases will be the same as that of planning a walk for the
human figure. Particularly, too, must the artist observe in the bird’s
walk, the middle phases in which one leg crosses the vertical of the
body to go forward for the implanting of its foot upon the ground.
With respect to the study of wing movement in flying birds, it is
interesting to note that the Japanese artist apprehended the various
positions that wings took in flying before the fact was demonstrated
by photography. The Occidental artist, before the days of the
instantaneous snap-shot camera, had but one or two stereotyped
positions for picturing flying birds. Generally one of these positions
had the wings pointing upward, and another with them outspread,
more or less, horizontally. But the Japanese artist anticipated the
snap-shot picture; he often had his flying birds with the wings drawn
below the level of the bird’s body and pointing downward.

PIGEON IN FLIGHT.
Note the positions with the wings pointing downward. These
are phases of wing movement anticipated by the Japanese artist
before their existence was clearly shown by instantaneous
photography.
Part of a plate in Muybridge’s “Animals in Motion.” Copyright,
1899, by Eadweard Muybridge. London, Chapman & Hall, Ltd.
New York, Charles Scribner’s Sons. A valuable work for the
artist in studying movement in animals.
 COMIC WALK OF A DUCK.
Series of drawings required to move the bird
from A to C.
One good way, if an animator wishes to represent a bird flying
across the sky, is to have several—five or seven—positions for the
action drawn on cardboard and then cut out. These little bird models
are placed, one at a time, over the general scene during the
photography and manipulated in the same way as described for
other cut-out models. The slight wavering from the direct line of the
bird’s flight that may occur by this cut-out method would not matter
very much. The bird describes a wavering line anyway as he flies—
its body dropping slightly when the wings go up and a correlative rise
occurring when the wing flap takes place.

CYCLE OF PHASES OF A WALKING DOG ARRANGED

FOR THE PHENAKISTOSCOPE.
 PHENAKISTOSCOPE WITH A CYCLE OF DRAWINGS TO
SHOW A DOG IN MOVEMENT.
If an artist wishes scrupulously to be exact in drawing a bird flying
across the sky, he should observe certain rules of perspective
applying to the case. The problem is the same as that of the
airplane, previously noted, which flew across the field of the picture.
Regarding this matter, to specify: When the bird appears on one side
it is represented in a side view, which changes as it gets near the
centre to a profile. After it has been viewed in profile, the perspective
changes again and when it reaches the other side it is again in a
perspective side view, slightly from the back.
In the mode of progression that was given as the usual one in
quadrupeds, in which a diagonally opposite fore and hind limb
moved simultaneously, there is a sinuous lateral twisting of the back-
bone. It is not so perceptible to us in the larger beasts. It is an effect,
though, that takes place in other creatures and in some of them can
be clearly seen. In the walk of the lizard, as an instance, when
viewed from above, a successive undulation of the back-bone takes
place. As one fore limb—the right, to particularize—moves forward,
that side of his body—the right shoulder, moves forward, too; while
approximately at the same time the left hind limb moves forward and
carries with it that side or the left pelvic regions. This causes an
alternating obliquity of the transverse axes of the shoulder and the
hind regions of the body of the reptile as he walks on the ground.
And this alternate changing of these axes gives rise to a continuing
sinuosity in the spine.
 RUNNING COW.
Positions selected and adapted from
Muybridge’s photographs.
PHASES OF MOVEMENT OF A WALKING
LION.
 DOG WALKING.
The mode of progression in legless creatures is distinguished, too,
by a lateral bending in and out. Snakes and eels, for example, as
they proceed agitate their bodies in wave-like motions. The waves
pass from the head to the tail, the fluctuations taking the form of
rather large loop-like wrigglings of the elongated body. A spring-like
coiling up and then an expanding—flexion and extension again—is
the principle of the locomotory manœuvre in the snake.
 VARIOUS KINDS OF WAVE MOTION.
A characteristic of many forms of movement which the
animator gets in certain of his delineations.
The undulatory motive impulse of a creeping animal is somewhat
like the sudden lashing of a whip, or the wave-like disturbance given
to a rope when it is sharply and strongly shaken in a certain way.
INANIMATE THINGS IN MOVEMENT
 CHAPTER VII

INANIMATE THINGS IN MOVEMENT

THERE is very little effect of motion on the screen of a moving

straight line by itself without any contrasting elements. Or, as the
moving-picture draftsman would say, it does not animate well.
Now supposing a picture is intended of a man tugging at a rope.
He pulls hard and the rope is taut and it appears practically straight.
The animation of the arms shows that they are moving and give a
good illusion of the tugging, but the rope shows no movement on
account of its rectilinearity. It will be only when the artist gives the
rope a little undulating—or even a snake-like—motion now and then
that he can give the effect of any disturbance in it. This sort of thing,
a slight shaking or a wavering of the line, would do for ordinary
cases but it would be better if the artist showed a loose strand of
cordage fibre creeping along in the direction that the rope is
supposed to be going. But still better would it be to have a few kinks
forming in the rope and showing them agitated as they go in the
direction of the pull on the rope. In producing this latter illusion the
likely expedient that the skilled animator would use is that of having
a set of celluloids with drawings—three or five—showing the kink
represented in a number of progressive positions. The plan would be
to have the details in a cycle, so that when the last detail of the cycle
is photographed, the first one exactly follows in a proper order. The
artist can put these rope drawings on the same sheets of paper that
hold the arm movements—we have in mind the picture of the man
tugging at the rope, of course. Then the cycle of drawings with the
arm movements and the kinks of the rope in their progressive order
can be used over and over again as long as it seems consistent with
good judgment.
 This idea of arranging things in cycles is the general way of
animating inanimate things. Nearly all the technical items in this
chapter are managed with some such plan. Generally, too, the
details are drawn on the transparent celluloids.
The problem in devising the components of any cycle is to have
these components so arranged that the orderly movements take
place from the first of the series to the last and then begin with the
first again. The action must not skip, cause a hesitation, or go
backward. This simply means that the components are to be spaced
properly with respect to their relations to each other.
It would be difficult to give by words any directions exactly how to
do this; actual drawing, with a testing in the preliminary sketches is
the surest way of accomplishing it. As general directions, however,
the advice would be to have an odd number of drawings and to vary
the spatial intervals between the separate items. They should not,
above all things, be equidistant.
Where the artist wishes to present to the spectator an animated
drawing of a waving banner, or flag, he makes a cycle of different
drawings. If it is a flag, these drawings are made with undulating
folds that pass the length of the flag as if it were agitated by the
wind. Almost any sort of rippling effect, necessitating but three
slightly different drawings, will satisfy the average audience. But if
the artist wishes to do conscientious work, he will give a little more
attention to his planning and try to make it nearer actuality. Then he
will contrive that there be one dominant drapery fold which is carried
out farther and farther along the ruffled flag. As this fold nears the
end it lessens its volume and at last disappears in a sudden flap.
This will take five or seven drawings. In planning the cycle it will be
arranged that immediately before the last flapping, the first phase of
the dominant fold begins again.
This effect of ruffling drapery by a fixed set of cycles used always
in the same order will, of course, give a monotonous waving. But it
can be diversified by an occasional break in the order in which the
separate elements of the cycle are photographed, or an added
modification obtained by a supplemental large flapping fold which
can be produced by one extra drawing.
An ordinary fragment of drapery in a garment is easily animated by
making it in three phases. This will give a satisfactory quivering
motion when projected in any bit of drapery that is blown about or
flutters on a figure in action.

CYCLE OF DRAWINGS TO PRODUCE A SCREEN

ANIMATION OF A WAVING FLAG.
Flowing water, waves, and rippling on the surface of a stream, are
not difficult matters to animate if the artist keeps in mind that the
plainest unelaborated line work gives for these elusive pictorial
ingredients the most striking effects on the screen.
 It is customary, again, for artistic particulars like these to be made
in cycles of three or five drawings. The action for this class of
subjects is nearly always quick, and so drawings for the purpose
need not be numerous.
A water-splash is a detail of a screen animation rather frequently
introduced. Animators have adopted a stereotyped way of rendering
it. When it is associated with a falling of some unlucky character into
the water, it is very effective from a pictorial and a humorous point of
view. The succeeding up-rushing column of water, after the splash, is
made in the form of a huge mushroom—rather conventional but
extremely comical.
In such a particular as a jet of water, a cycle of drawings is also
used. In planning such drawings for animation care must be taken
that they give in the combined screen illusion a proper one of falling
water. The slightest misplacing of succeeding details representing
the jet may give an effect of the water going backward. A funny
touch is what is wanted in a humorous picture, but, generally, not of
this sort.
 CYCLE OF DRAWINGS FOR AN EFFECT OF
FALLING WATER.
The drawings are repeated, number 1
following number 3.

Imparting an appearance of rain over a scene is produced by

having several celluloids with lines indicating this. They would be
used in their order as designed during the photography in the usual
way.
Falling snow—that indispensable ingredient of the provincial
melodrama—is simply managed by spreading, at haphazard over
several celluloids, spots of white pigment. A general tinting, of
course, over the underlying pictorial composition would add, by
contrast of tone, to the illusion.
A blank sheet of celluloid placed over the entire drawing is often
employed to hold components of some quickly moving element of an
incident. Each separate detail of its drawing, in this case, is made on
this blank celluloid under the camera and photographed as it is
made. Supposing that it is lightning zigzagging across a dark
background. There will be drawn over this celluloid the first part of
the bolt, photographed and then another part drawn which is
photographed, and then the end of the bolt which is also separately