## 2.10 Working with the Library

REVIEW To summarise then, when we interact with R we can usually drop the package prefix for those commands that can be found in one (or more) of the attached packages. Throughout the running text in this book we retain the package prefix to clarify where each command comes from. However, within the code we tend to drop the package name prefix.

A prefix can still be useful in larger programs to ensure we are using the correct command and to communicate to the human reader where the command comes from. Some packages do implement commands with the same names as commands defined differently and found in other packages and the prefix notation is then useful to specify which command we are referring to.

Each of the following chapters will begin with a list of packages to attach from the library into the R session. Below is an example of attaching five common packages for our work. Attaching the listed packages will allow the examples presented within the chapter to be replicated. In the code below take note of the use of the hash (#) to introduce a comment which is ignored by R—R will not attempt to understand the comments as commands. Comments are there to assist the human reader in understanding our programs.

# Load packages required for this script.

library(rattle)   # The weatherAUS dataset and normVarNames().
library(magrittr) # Pipes %>%, %<>%, %T>%, %\$%.
In starting up an R session (for example, by starting up RStudio) we can enter the above library() commands into an R script file created using the New RScript File menu option in RStudio and then ask RStudio to Run the commands. RStudio will send each command to the R Console which sends the command on to the R software. It is the R software that then runs the commands. If R responds that the package is not available then the package will need to be installed, which we can do from RStudio’s Tools menu or by directly using utils::install.packages() as we saw above.