R-beta: Re: "as.numeric" `mode' and `cast' should be kept separate.

Ross Ihaka (ihaka@stat.auckland.ac.nz)
Wed, 3 Jun 1998 13:18:04 +1200 (NZST)


Date: Wed, 3 Jun 1998 13:18:04 +1200 (NZST)
Message-Id: <199806030118.NAA14602@stat1.stat.auckland.ac.nz>
From: Ross Ihaka <ihaka@stat.auckland.ac.nz>
To: Bill Venables <wvenable@attunga.stats.adelaide.edu.au>
Subject: R-beta: Re: "as.numeric" `mode' and `cast' should be kept separate.
In-Reply-To: <9806030006.AA16033@attunga.stats.adelaide.edu.au>

Bill Venables writes:
 > I don't say this will appeal to everyone straight away, but I
 > would even favour using a binary operator syntax for the
 > assignment function form of the above replacement function, for
 > example
 > 
 > "%cast.as%" <- function(x, form) {
 > 	storage.mode(x) <- deparse(substitute(form))
 > 	x
 > }
 > 
 > Calls to .C would then take on such a striking form that it would
 > be immediately noticed if something had been missed:
 > 
 > 	result <- .C("some_flashy_C_thing",
 > 		     x = my.x %cast.as% double,
 > 		     i = my.eye %cast.as% integer,
 > 		     oops = forgot.this.one,
 > 		     value = z %cast.as% single)$value
 > 
 > Nothing to do with mode.  If "%cast.as%" is too much typing, well
 > it's not too difficult to redefine your own shorter version:
 > 
 > "%as%" <- get("%cast.as%")

This certainly appeals to me straight away!  A very nice suggestion.

 > -----------------------------------------------------------------
 > 
 > There is a semi-related but much larger issue that also deserves
 > to be fully regularised: which classes of functions strip off
 > attributes and which retain them in the result, and if there is a
 > conflict, how is it resolved?  (storage.mode<- guarantees
 > attributes will be retained; as.numeric guarantees they won't.)
 > 
 > In S it seems very illogical to me that if M is a matrix, then
 > sqrt(M) is a matrix like M in all respects but with square-root
 > entries but pnorm(M) is a naked vector of probabilities.
 > 
 > This is a very large issue, but one that really does deserve to
 > be handled in a rigorously consistent and well docuented way.  S
 > and S-PLUS are a long way from that and getting further all the
 > time.  Perhaps R can still be nudged back onto a better track.

I'm certainly not claiming consistency, but in R, most builtin
functions try to retain (at least some) attributes.  E.g.

	> x <- matrix(1:4,nc=2)
	> pchisq(x,2)
	          [,1]      [,2]
	[1,] 0.3934693 0.7768698
	[2,] 0.6321206 0.8646647
	> pchisq(2,x)
	          [,1]      [,2]
	[1,] 0.8427008 0.4275933
	[2,] 0.6321206 0.2642411

Handling this in general is hard though.

	Ross
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._