I notice in different packages it sometimes refers to a variable, a column to sort by, an object, etc. Like in dplyr it usually refers to a variable, but in ggplot, it's not even used.
Is there any logic behind this? Is there any universality? Or can it just be anything.
It can accept an arbitrary number of formal parameters. In base R these parameters are often arguments to other functions. The Arguments description in the function's help page should indicate which subsequent functions will be getting these arguments. It can be the only argument, the first, the last, or it can be intercalated in the parameter list. The items in the list(...) generally should be named. You can access the items in the "dots" list in a couple of different ways: ...() and list(...) are two that I've seen. Generally, it is the R-cognoscenti that will be designing functions with these forms. When it is intercalated (or the first), the named parameters that follow it in the formals must be named when the function is called and cannot be assigned positionally. If you type ?'...' you will be shown the Reserved page, which in turn has a link to dotsMethods {methods}.
I found it difficult to search for [r] with "..." using a SO search panel but searching on "[r] dotsMethods" brought up 10 hits.
Related
When I'm using a new function, the documentation/vignettes give an overview of how the function works, but often do not list all of the possible options for every argument.
There must (?) be a command which lists all of the valid options for an argument? After lots of Googling there are lots of answers to the question of how to list all the possible arguments of a function (args, formals etc), but nothing I can find which lists all the possible options of an argument?
For example if I type formals(lmer) or args(lmer), it just list the functions and the defaults, not all the possible options.
How can I display all the possible options that an argument can take?
Help files call attributes() a function. Its syntax looks like a function call. Even class(attributes) calls it a function.
But I see I can assign something to attributes(myobject), which seems unusual. For example, I cannot assign anything to log(myobject).
So what is the proper name for "functions" like attributes()? Are there any other examples of it? How do you tell them apart from regular functions? (Other than trying supposedfunction(x)<-0, that is.)
Finally, I guess attributes() implementation overrides the assignment operator, in order to become a destination for assignments. Am I right? Is there any usable guide on how to do it?
Very good observation Indeed. It's an example of replacement function, if you see closely and type apropos('attributes') in your R console, It will return
"attributes"
"attributes<-"
along with other outputs.
So, basically the place where you are able to assign on the left sign of assignment operator, you are not calling attributes, you are actually calling attributes<- , There are many functions in R like that for example: names(), colnames(), length() etc. In your example log doesn't have any replacement counterpart hence it doesn't work the way you anticipated.
Definiton(from advanced R book link given below):
Replacement functions act like they modify their arguments in place,
and have the special name xxx<-. They typically have two arguments (x
and value), although they can have more, and they must return the
modified object
If you want to see the list of these functions you can do :
apropos('<-$') and you can check out similar functions, which has similar kind of properties.
You can read about it here and here
I am hopeful that this solves your problem.
Im using R for about 3 years and one of the main advantages (in my opinion) is the wide range of questions and assistance one can find on stackoverflow and similar websites.
One thing that is missing and kind of annoys me is an entire list of every single argument a function can use (plus possible values of those arguments).
For example: In R documentation all "main" arguments are listed and in many cases the documentation says "... further arguments passed to or from other methods". How can I know which arguments are meant by "..."?
When searching on stackoverflow for a way to get my desired result of an analysis I sometimes stumble about these additional arguments which can be very helpful in many cases. It still takes much time to find these arguments hidden in other users answers. Sometimes I used a workaround which would have been unnecessary if I had known some additional function arguments.
Is anyone else experiencing the same thing?
(It's difficult to mention examples but I remember having that trouble when using the leaflet functions for the first time.)
Tim
The most direct answer is that we often don't know what arguments one might want to pass to .... In fact, that is the point of ... arguments, is to not require us to know what arguments may be passed to it.
Consider, for example, the print generic in base R. It is defined as
print(x, ...)
So what are the arguments that can be passed to ...?
print.factor defines
print(x, quote = FALSE, max.levels = NULL,
width = getOption("width"), ...)
print.table defines
print(x, digits = getOption("digits"), quote = FALSE,
na.print = "", zero.print = "0", justify = "none", ...)
Notice that the print methods for factor and table objects don't share the same arguments. In fact, every print method may be defined with a different set of arguments. R then uses the class of the object to determine which set of arguments to apply to print.
When a developer creates a new print method, CRAN requires that all new methods contain at least the same arguments as the generic. So every print method has arguments x and ....
How do I know what arguments may be acceptable to ...?
First, read and follow the documentation. In glm, you find that the ... argument accepts arguments to "form the default control argument." This references the control argument, which then references the glm.control function. Opening ?glm.control shows the arguments epsilon, maxit and trace.
Another example, in ggplot2's geom_line, the documentation states that ... arguments are passed to the layer function. Use ?layer to see what arguments are available.
If the documentation simply specifies "to other methods," then you are probably looking at a method that is dispatched with different behaviors for different types of objects.
I come from a C# background and try to migrate some of my time series library to R.
One of the benefits of OOP is that I can tuck away variables in a class and pass this as reference.
I read up on R environments, lists, ... and I'm still not sure about the right approach. If I would use a list then I would need to check the function argument:
exists()
(btw: Is there also a function to test for the elements in a list)
I could create a list, pass it as an argument and then write the result back in a list. But is this the right approach?
Any comments ...
exists is seldom used. If you need it, maybe you do something wrong.
missing is sometimes used.
Functions sometimes, but not very often, receive lists as parameters, and often return lists.
To test whether a list foo has an element bar, use is.null(foo$bar). This is FALSE if the list has the element, TRUE otherwise.
What is the difference between this lines of code?
mean(some_argument)
mean(x = some_argument)
The output is the same, but has the explicit mention of x any advantages?
People typically don't add argument names for commonly used arguments, such as the x in mean, but almost always refer to the na.rm arguments when removing missing values.
While neglecting the argument name makes for compact code, here are four (related) reasons for including the names of arguments rather than relying on their position.
Re-order arguments as needed. When you refer to the arguments by name, you can arbitrarily re-order the arguments and still produce the desired result. Sometimes it is useful to re-order your arguments. For example, when running a loop over one of the arguments, you might prefer to put the looped argument in the front of the function.
It is typically safer / more future-proof. As an example, if some user-written function or package re-orders the arguments in an update, and you relied on the positions of the arguments, this would break your code. In the best scenario, you would get an error. In the worst scenario the function would run, but would an incorrect result. Including the argument names greatly reduces the chances of running into either case.
For greater code clarity. If an argument is rarely used or you want to be explicit for future readers of your code (including you 2 months from now), adding the names can make for easier reading.
Ability to skip arguments. If you want to only change the third argument, then referring to it by name is probably preferable.
See also the R Language Definition: 4.3.2 Argument matching