Skip to content

combining mathematical notation and value substitution

4 messages · Thomas Lumley, Faheem Mitha, Peter Dalgaard

Thomas Lumley
#
On Sun, 22 Jun 2003, Faheem Mitha wrote:
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.
That's because expression() returns an expression.
Well, we can find out. It must be either * or ==, but it isn't immediately
obvious which one ends up at the top level
==t1*").")
[1] "call"
[1] 3
==
"Monotonic Multigamma Run (" * n == len * ", " * theta
t1 * ")."
[1] "call"
[1] "call"
==
*

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.
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
3 days later
Faheem Mitha
#
On Sun, 22 Jun 2003, Thomas Lumley wrote:

            

      
      
      
    

        
Hmm. I'm trying to distinguish in my mind the value of an expression and
the expression itself. For some reason it reminds me of the following
exchange, from "Through the Looking-Glass".

**********************************************************************

"...The name of the song is called 'Haddocks' Eyes.'"

"Oh, that's the name of the song, is it?" Alice said, trying to feel
interested.

"No, you don't understand," the Knight said, looking a little vexed.
"That's what the name is called. The name really is 'The Aged, Aged Man.'"

"Then I ought to have said 'That's what the song is called'?" Alice
corrected herself.

"No you oughtn't: that's another thing. The song is called 'Ways and
Means' but that's only what it's called, you know!"

"Well, what is the song then?" said Alice, who was by this time completely
bewildered.

"I was coming to that," the Knight said. "The song really is 'A-sitting On
a Gate': and the tune's my own invention."
**********************************************************************

            

      
      
      
    

        
This is very interesting. I had convinced myself that an expression could
not become a call unless created explicitly by call, because it could not
know out of all the possible call structures which one to turn the
expression into. However, it appears this is not the case. So, naturally,
this makes me wonder, what rules are used to make the structure, out of
all the various possibilities. For example, the function in the call could
have corresponded to one of the *'s, and then the rest of the structure
would have been different. And is this rule part of the language
definition?

                                                            Faheem.

  
  


  


      

    

    

      
      

        


  

        

      Thomas Lumley
    

    

      
      #
    

  


  

      
On Thu, 26 Jun 2003, Faheem Mitha wrote:

        

            

      
      
      
    

        
Yes, but Carroll gets that slightly wrong: the song is not "A-sitting On a
Gate", (which is an English phrase, not a song).

            

      
      
      
    

        
The rules are defined by the R grammar, which can be found in
src/main/gram.y (if you speak bison)

Basically, == has lower precedence than *, so one of the == must be the
last function called.  This is necessarily part of the language
definition, as it tells you the meaning of eg
  2*3==6
Since * has higher precedence this is parsed as (2*3)==6, not 2*(3==6).

It doesn't actually matter which == comes first, but we can see from other
examples that the rightmost operator ends up at the root of the tree
Since

            

      
      
      
    

        
[1] TRUE
it must have been evaluated as (2<3)<4,  not 2<(3<4)



While the rules for constructing the tree are part of the language
definition, the order of evaluation might not be.  In C, for example, the
order of evaluation is not specified except to the extent that precedence
constrains it (and for a few special operators like && and ||).

FOr an R example, if you do
	f(plot(a), plot(b))

it is clear that the plot commands must be evaluated before f() returns if
their return values are actually used. It is not clear which order the
plots() appear, and I would say that it shouldn't be part of the language
definition.


	-thomas

  
  


  


      

    

    

      
      

        


  

        

      Peter Dalgaard
    

    

      
      #
    

  


  

      
Thomas Lumley <tlumley at u.washington.edu> writes:

            

      
      
      
    

        
...not to mention that lazy evaluation explicitly makes the order dependent
on the function body:

  f <- function(x,y) {x;y}
  f <- function(x,y) {y;x}

will produce the plots in different order when called as above. Notice
in particular that constructs like

  f(a<-b, a)

are playing with fire, unless you're really, really sure that the 1st
arg is evaluated before the 2nd.