[R] combining mathematical notation and value substitution
Thomas Lumley
tlumley at u.washington.edu
Mon Jun 23 06:28:51 CEST 2003
On Sun, 22 Jun 2003, Faheem Mitha wrote:
> If I'm doing this correctly, R does not seem to think it is a call.
>
> > is.call("Monotonic Multigamma run (" * n == len * ", " * theta == t1
> * ").")
> Error in "Monotonic Multigamma run (" * n :
> non-numeric argument to binary operator
R is trying to *evaluate*
"Monotonic Multigamma run ("* n==len etc
which doesn't work. Remember, is.call(), like any normal function, will
be passed the *value* of its arguments.
You could try
is.call(quote("Monotonic Multigamma run("*n==len))
which is TRUE.
> It considers it a valid R expression though.
>
> > (mode(expression("Monotonic Multigamma run (" * n == len * ", " * theta
> == t1 * ").")))
> [1] "expression"
>
That's because expression() returns an expression.
>
> The clearest description I have seen of a call is in S Poetry, where it
> says
>
> "Mode call represents objects that are calls to a function. The first
> component of a call is the name (mode name) of the function being called.
> The rest of the call is the arguments given."
>
> This certainly is how calls are constructed using call(...), but I'm not
> sure how it fits in with an expression like the one above. What is the
> function being called in that case, for example?
Well, we can find out. It must be either * or ==, but it isn't immediately
obvious which one ends up at the top level
> thing <- quote("Monotonic Multigamma Run ("*n==len* ", " * theta
==t1*").")
> mode(thing)
[1] "call"
> length(thing)
[1] 3
> thing[[1]]
==
> thing[[2]]
"Monotonic Multigamma Run (" * n == len * ", " * theta
> thing[[3]]
t1 * ")."
> mode(thing[[2]])
[1] "call"
> mode(thing[[3]])
[1] "call"
> thing[[2]][[1]]
==
> thing[[3]][[1]]
*
So it is a call to ==, with two arguments, each itself a call. The first
arguemetn is also a call to == and the second is a call to *. And so on in
a tree structure.
> Maybe I'd understand this stuff better if I knew Lisp. I'm very ignorant
> about programming language paradigms. I've looked at S Poetry, and S
> Programming. While they were helpful, I don't feel I've got a clear
> picture. Further recommended reading?
>
I don't know about further reading. I think this is probably easier to
learn when you have a specific problem to solve. I learned mostly by
porting the survival package.
-thomas
More information about the R-help
mailing list