Skip to content

Funny warning message

6 messages · John Logsdon, Friedrich Leisch, Ben Bolker +2 more

John Logsdon
# 
Hi

Sometimes (and I haven't yet found out what causes it) I get a message:

Warning: ingnored non-function "t"

I think it may be either when I have done a Ctl-C to break in or I may
have inadvertently named a variable after one of the many system or other
functions.  I have seen names other than "t".

Anyway, the only way I can get rid of it is to exit and restart.  I don't
think it causes any problems but has anyone else seen it and how to avoid?

I am running 0.63.3 from the CRAN rpm on RH5.2

John

-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-help-request at stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
Friedrich Leisch
# 
JL> Hi
JL> Sometimes (and I haven't yet found out what causes it) I get a message:

JL> Warning: ingnored non-function "t"

JL> I think it may be either when I have done a Ctl-C to break in or I may
JL> have inadvertently named a variable after one of the many system or other
JL> functions.  I have seen names other than "t".

Yes, t is indeed a system function, namely the one to get the
transpose of a matrix. The above warning says that you use symbol t
where a variable is needed, hence the function is ignored and the
variable used. But in general it is safer to avoid name conflicts like
those.

An easy way to check things like that (after seeing the warning) is to
start a new R process (without restoring an old namespace) and simply
type (in yor case) `t ENTER':

	R> t
	function (x) 
	UseMethod("t")

which gives you the definition of object t (a function).

Another obvious way is checking if there's any help for the name
(``help(t)'').

Hope this helps,
Fritz

PS: Other one letter functions include c() and q()


-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-help-request at stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
Ben Bolker
#
On Tue, 6 Apr 1999, John Logsdon wrote:

            

      
      
      
    

        
As you suggest, this happens when you've named a variable after a
system function ("t" and "c" are the most common culprits).  All you have
to do is remove the offending variable using rm(t) or rm(c); of course, if
you need that variable you probably want to copy it somewhere.
  R usually does the right thing under these circumstances, it's just
warning you.

  This should probably go in a FAQ list somewhere: I get this question
from students frequently.  Or perhaps (?) the warning message could be
usefully extended to 'ignored non-function "t"; type rm(t) to remove', or
even 'ignored non-function "t"; help("conflicts") for more information'
(where this basic information was provided in a help file).

  Ben


-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-help-request at stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

  
  


  


      

    

    

      
      

        


  

        

      John Logsdon
    

    

      
      #
    

  


  

          

      
      
      
    

        
Many thanks to all who took the time to point out the blindingly obvious!

I frequently use single letters in various languages for short-term
(sometimes local to a function) variables.  In fact my Fortran
indoctrination still leads me to be uncomfortable with any loop counter
other than i-l!  This had only rarely happened and didn't appear to do any
damage.

So, as an entry to the wish-list, since R handles it correctly, wouldn't
it be better to suppress the warning message - via an option statement.
After all t() is clearly different to t[ ] or t so the context should be
able to determine what is really wanted.  (Mind you, I wouldn't go as far
as Algol68, where if I remember clearly, a legal command would be: if if
then then else else := if not then do else end!) 

Perhaps options(sloppy=TRUE)?

As a second entry to the wish-list, would it be possible to set an option
that ensured vector lengths were strictly matched?  I find that whenever I
drop a booboo and have mismatched vector length, the warning message
indicates that I have indeed done something wrong.  At the moment, I can't
conceive of a situation when an operation on two vectors where one is not
the same length as the other *or* one is effectively a scalar (vector
length 1) can be a legal statement.  Maybe some library functions do
assume this, in which case the user (or function) could store the option
an switch it off during the body.

Perhaps options(vector.match=TRUE)?

Since I don't use S+, I don't know what they do but S+ is not the oracle
anyway.

John

-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-help-request at stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

  
  


  


      

    

    

      
      

        


  

        

      Bill Venables
    

    

      
      #
    

  


  

          

      
      
      
    

        
John> So, as an entry to the wish-list, since R handles it
    John> correctly, wouldn't it be better to suppress the
    John> warning message - via an option statement.  After all
    John> t() is clearly different to t[ ] or t so the context
    John> should be able to determine what is really wanted.

As it was doing, of course.  All you were getting was a warning
message, which to my mind is not a bad idea.  If you did use t
for a function name (and if you use it as a variable name, why
not a function?) you would probably find that some vital system
function was suddenly and mysteriously broken.

    John> As a second entry to the wish-list, would it be
    John> possible to set an option that ensured vector lengths
    John> were strictly matched?  I find that whenever I drop a
    John> booboo and have mismatched vector length, the warning

(`drop' a booboo?  I think the thing to avoid is making one in
the first place... :-)

    John> message indicates that I have indeed done something
    John> wrong.  At the moment, I can't conceive of a situation
    John> when an operation on two vectors where one is not the
    John> same length as the other *or* one is effectively a
    John> scalar (vector length 1) can be a legal statement.
    John> Maybe some library functions do assume this, in which
    John> case the user (or function) could store the option an
    John> switch it off during the body.

    John> Perhaps options(vector.match=TRUE)?

There are many situations where quite sensible programming does
make use of the recycling rule to good advantage, but I agree
that there are few (if any) cases where you need it when the
lengths are not strictly proportional.  For example consider a
calculation like finding a correlation matrix (if there were not
a built-in function to do it, I know):

V <- var(X)
SD <- sqrt(diag(V))
R <- t(V/SD)/SD

Compare the last step with the operations and memory use in

R <- diag(1/SD) %*% V %*% diag(1/SD)

a style many people do adopt.  Of course if V is very large,
transpostion is not a trivial operation, either.

    John> Since I don't use S+, I don't know what they do but S+
    John> is not the oracle anyway.

The latest version of S (version 4) outlaws vector arithmetic
with vectors of non-proportional sizes.

I think S (if not S+) is a bit of an oracle, too, by the way, and
going against the fundamental design is something that should be
done with great caution.  There is a lot of occluded wisdom in S.

Bill Venables.

-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-help-request at stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

  
  


  


      

    

    

      
      

        


  

        

      Brian Ripley
    

    

      
      #
    

  


  

      
On Wed, 7 Apr 1999, Bill Venables wrote:

        

            

      
      
      
    

        
The intention in a future version of R to warn only if the object
which is masked is of the same mode ("function" here). This was decided
a couple of weeks ago, but we needed to get R-0.64 out first.

Brian