Understand R’s scoping rules which determine how the language compartmentalizes object and retrieves them in a given session.
R Enforces rules with virtual environments. Think of each environment as a separate compatment where data tructures and functions are saved.
They allor R to distinguish between identical names that are associated with different scopes and therfore stored in different envirnments.
Global. Global envirnment is set aside for user-defined objects. Every object you’ve created or overwritten so far has resided in the global envirnoment of your current R session.
Use the ls() function to show th contents of the global environment
ls() [1] "bar" "baz" "char.mat" "char.vec"
[5] "ctrl" "df.world_ports" "dia.url" "diamonds"
[9] "fac.vec" "flow.jok" "flow.vat" "foo"
[13] "full_form" "Full_form" "geocodes.world_ports" "html.world_ports"
[17] "ice.river" "in_train" "int_plot" "logic.mat"
[21] "logic.vec" "mnr_impute" "mnr_tune" "mydatafile"
[25] "newobect" "num.mat1" "num.mat2" "num.vec1"
[29] "num.vec2" "opt.arg" "ordfac.vec" "prec"
[33] "predic" "ptype" "quux" "qux"
[37] "scat" "scat_orig" "small_form" "small_tr_dat"
[41] "somelist" "temp" "test_data" "test_data3"
[45] "train_data" "wls" "x" "y" Package Environment and Namespaces Refers to the items made available by each package in R. In fact, the structure of R packages in terms of scoping is a bit more complicated. Each package environment actually represnets several environments that control different aspects of a search for a given object.
A package can have visible functions that a user is able to use and invisible functions that provide internal support to the visible functions.
ls("package:graphics") [1] "abline" "arrows" "assocplot" "axis" "Axis" "axis.Date"
[7] "axis.POSIXct" "axTicks" "barplot" "barplot.default" "box" "boxplot"
[13] "boxplot.default" "boxplot.matrix" "bxp" "cdplot" "clip" "close.screen"
[19] "co.intervals" "contour" "contour.default" "coplot" "curve" "dotchart"
[25] "erase.screen" "filled.contour" "fourfoldplot" "frame" "grconvertX" "grconvertY"
[31] "grid" "hist" "hist.default" "identify" "image" "image.default"
[37] "layout" "layout.show" "lcm" "legend" "lines" "lines.default"
[43] "locator" "matlines" "matplot" "matpoints" "mosaicplot" "mtext"
[49] "pairs" "pairs.default" "panel.smooth" "par" "persp" "pie"
[55] "plot" "plot.default" "plot.design" "plot.function" "plot.new" "plot.window"
[61] "plot.xy" "points" "points.default" "polygon" "polypath" "rasterImage"
[67] "rect" "rug" "screen" "segments" "smoothScatter" "spineplot"
[73] "split.screen" "stars" "stem" "strheight" "stripchart" "strwidth"
[79] "sunflowerplot" "symbols" "text" "text.default" "title" "xinch"
[85] "xspline" "xyinch" "yinch" Local Environments Local Environment is created each time a function is called in R. Sometimes called “Lexical environment”. This contains all the objects and variables created in and avisible to the function, including any arguments you’ve supplied to the function upon execution. This allows identical argument names to co-exist in a given workspace.
For example:
youthspeak<-matrix(data=c("OMG","LOL","WTF","YOLO"),nrow=2,ncol=2)
youthspeak [,1] [,2]
[1,] "OMG" "WTF"
[2,] "LOL" "YOLO"A local environment is created containing the data vector when this function is called. It begins by looking for data in this local environment. So R isn’t confused by other objects orr functions named data in other environments.
If a required item isn’t in the local environment, only then does R begin to widen its search for that item. Once the function has completed, this local environment is automatically removed.
The path followed by R to access data structures and fucntions from environments other than the immediate global environment.
search() [1] ".GlobalEnv" "tools:rstudio" "package:stats" "package:graphics" "package:grDevices"
[6] "package:utils" "package:datasets" "package:methods" "Autoloads" "package:base" Order is read from left to right then down to the next line.
You can find out the environment by using the environment() function
environment(seq)<environment: namespace:base>environment(arrows)<environment: namespace:graphics>To find the parent or hierarchical order:
library("car")
search() [1] ".GlobalEnv" "package:car" "tools:rstudio" "package:stats" "package:graphics"
[6] "package:grDevices" "package:utils" "package:datasets" "package:methods" "Autoloads"
[11] "package:base" You can see that the parent of package:stats is package:graphics R will stop searching at the first match or when it has exhaused the entire search path and reached the empty environment.
If you try to assign a value to any of these reserved names, an error occurs
if <-c(1,2,3)Error: unexpected assignment in "if <-"NOte: since R is case sensitive, nan, na, true, false will work.
Argument matching conditions allow you to provide arguments to functions either with abbrieviated names or without names at all.
Each argument tag is written out in full. This is the most exhaustive way to call a function. Exact matching is less prone to mis-specification of arguments compared to other matching sytles. It is also useful when a function has many possible arguments but you want to specify only a few. Drawbacks: It can be cumbersome for relatively simple operations. Exact matching requires the user to remember or lookup the full, case-sensitive tags.
bar<-matrix(data=1:9,nrow=3,ncol=3,
dimnames=list(c("a","b","c"),c("d","e","f")))
bar d e f
a 1 4 7
b 2 5 8
c 3 6 9# you can switch around the arguments and it will still work bec of exact matching
bar<-matrix(ncol=3,
dimnames=list(c("a","b","c"),
c("d","e","f")),
data=1:9,nrow=3)
bar d e f
a 1 4 7
b 2 5 8
c 3 6 9Partial Matching lets you use arguments with an abbreviated tag. For partial matching there is NO set number of letters you have to provide As long as each argument is still uniquely identifiable.
This shortens your code and still lets you provide arguments in any order.
bar<-matrix(dat=1:9,nr=3,nc=3,
di=list(c("a","b","c"),c("d","e","f")))
bar d e f
a 1 4 7
b 2 5 8
c 3 6 9Positional matching is when you supply arguments without tags and R interprets them based solely on their order.
# first find out the exact order of the arguments
args(matrix)function (data = NA, nrow = 1, ncol = 1, byrow = FALSE, dimnames = NULL)
NULL# then write out the function using the arguments in order
bar <-matrix(1:9,3,3,F,list(c("a","b","c"),c("d","e","f")))
bar d e f
a 1 4 7
b 2 5 8
c 3 6 9Positional matching has shorter, cleaner code, particulary for routine tasks No need to remember specific argument tags.
You can mix and match any of the above matching styles in a single functaion call.
bar<-matrix(1:9,3,3,dim=list(c("a","b","c"),c("d","e","f")))
bar d e f
a 1 4 7
b 2 5 8
c 3 6 9Many functions exhibit variadic behavior. They can accept any number of arguments and its up to the user to decide how many to use.
The flexibility is achieved in R by use of the special dot-dot-dot designations (…) also called the ellipsis There are 2 groups of functions that use ellipsis: 1. functions such as c, data.frame and list where the ellipsis always represent the main ingredient 2. functions such as plot where the ellipsis is meant as a supplementary or potential repository of optional arguments.
# example of first group
args(data.frame)function (..., row.names = NULL, check.rows = FALSE, check.names = TRUE,
fix.empty.names = TRUE, stringsAsFactors = default.stringsAsFactors())
NULL# example of second group
args(plot)function (x, y, ...)
NULL