Skip to content

Problem with lm

12 messages · Eva Prieto Castro, Jorge I Velez, Greg Snow +4 more

Greg Snow
# 
Yes, it is most likely due to scoping.  It is safest to create a data
frame with all the data in it, then pass that to the data argument of
lm.
On Thu, Nov 1, 2012 at 2:25 AM, Eva Prieto Castro <evapcastro at yahoo.es> wrote:

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Mick Cooney
    

    

      
      #
    

  


  

      
But the 'y' is a parameter to the function, so does this mean that the
error is occurring when the function is invoked without that
parameter?

        
On 1 November 2012 16:02, Greg Snow <538280 at gmail.com> wrote:

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Greg Snow
    

    

      
      #
    

  


  

      
This error can still occur even if something is passed as the y
parameter to the function.  There are several things that can
complicate the process (and I don't remember exactly which one causes
the problem in this case).  Here are a couple:

In the original function, y is a parameter, but it is never actually
used before the call to lm, which means that y is really a promise to
evaluate whatever was passed to the function, but does not yet contain
the actual y values.

The lm function calls the model.frame function which calls the
model.frame.default function, which may call another function, which
of all those function environments should it look for the variable y
in?  (it seems obvious to us, but the computer is not as smart), there
is also the environment that the formula was defined in that is used
for some things.

Possibly others as well.

In either case if an explicit data frame is created (which will force
the evaluation of the promise for y) and passed to the data argument
of lm, then all these functions know exactly where to look to find the
variables in the formula and don't need to worry about parent frames
and parent environments.

This document: http://developer.r-project.org/nonstandard-eval.pdf
gives more detail.

        
On Thu, Nov 1, 2012 at 10:23 AM, Mick Cooney <mickcooney at gmail.com> wrote:

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Nordlund, Dan (DSHS/RDA)
    

    

      
      #
    

  


  

      
See comments inline

            

      
      
      
    

        
We haven't seen the actual call to the function, singleCosinor(), in your code so we can't say for sure what the problem is.  However, the confusion may be that while there is a formal parameter named y, it does not refer to any variable named y in the global environment. If you have a variables t and y in the global environment, then the call would need to be

singleCosinor(t=t, y=y)

hope this is helpful,

Dan

Daniel J. Nordlund
Washington State Department of Social and Health Services
Planning, Performance, and Accountability
Research and Data Analysis Division
Olympia, WA 98504-5204

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

  
  


  


      

    

    

      
      

        
      

    

    

      
      

        


  

        

      William Dunlap
    

    

      
      #
    

  


  

      
Did you ever show us the call to your function that made it fail
on one machine and succeed on two others?  In addition, seeing
the output of traceback() after the failure and the output of
sessionInfo() and conflicts() would help track down the problem.  

Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

  
  


  


      

    

    

      
      

        
      

    

    
3 days later

    

      
      

        
      

    

    

      
      

        


  

        

      Rolf Turner
    

    

      
      #
    

  


  

      
On 06/11/12 05:20, Eva Prieto Castro wrote:

            

      
      
      
    

        
Well, if you are happy with the result, I guess that can't be argued with.

However the fact that your previous attempts worked on some machines
and not on others indicates to me that something fundamentally wrong
is going on somewhere.  If it were *my* package I'd want to track it down,
figure out exactly why this anomaly was happening, and fix it from an
informed point of view.  Just trying things more or less at random until
something works is not a good strategy for writing robust and reliable
code.

It seems to me that resorting to the use of do.call() should not be 
necessary,
and it is not at all clear to me why this should help with the "no 
encontrado"
problem anyway.

     cheers,

         Rolf