[Rd] print.data.frame curiosity

2010-05-06 Thread Romain Francois 


Hello,

I made a mistake and passed stringsAsFactors to the wrong function in :

 df - as.data.frame( list( x = 1:3, y = c(a, b, c ), 
stringsAsFactors = FALSE ) )


But then :

 df
  x y
1 1 a
2 2 b
3 3 c

and :

 df[[y]]
[1] a b c
Levels: a b c
 str( df )
'data.frame':   3 obs. of  3 variables:
 $ x   : int  1 2 3
 $ y   : Factor w/ 3 levels a,b,c: 1 2 3
 $ stringsAsFactors: logi  FALSE FALSE FALSE


Somehow, print.data.frame does not want to print a column named 
stringsAsFactors. (I know this is a bad name for a column, but ...)


Apparently, this line in format.data.frame is responsible for the mismatch:

x - do.call(data.frame, rval)

Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/9aKDM9 : embed images in Rd documents
|- http://tr.im/OIXN : raster images and RImageJ
|- http://tr.im/OcQe : Rcpp 0.7.7

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Validity glitch when contains=matrix

2010-05-06 Thread John Chambers 
Re: the validity bug.  It's just as your example suggests:  the 
inherited initialize() method for matrix fails to call validObject(). 
 Should be easy to fix.  (Although it points out that the code should 
perhaps be reorganized so the initialize() method is not responsible for 
checking validity.)



Re: your other question:

On 5/6/10 4:09 AM, Martin Maechler wrote:

Daniel Murphychiefmur...@gmail.com
 on Wed, 5 May 2010 22:08:06 -0700 writes:

snip

   Should I
   1) always put matrix into the setClass representation argument 
instead of
   the contains argument, or
   2) use contains=numeric, put the matrix's dims and dimnames attributes
   into slots, and rely on a constructor to populate the instance?



Either is possible, but if you really want your new objects to inherit 
the properties of a matrix, your initial idea of contains=matrix is 
the natural choice for 2) (once the bug is fixed, but even before for 
most purposes). The choice is to inherit from matrix or have matrix as a 
slot (what Smalltalk called is a versus has a).


The choice is as always whether you want to inherit all the methods and 
then override the ones that DON'T make sense, or put the matrix in a 
slot and write all the methods that DO make sense.


Neither choice fits all examples but matrix is special, because R 
treats them in a special (perhaps weird would apply) way:  they are 
not a class (not even an S3 class) but much code recognizes them 
internally, meaning you inherit a great deal of stuff.


If your new class of objects are supposed to act like matrices most of 
the time, the contains= version may require a lot less programming. On 
the other hand, if you planned to store the data in a non-standard way 
(as the Matrix package does) then you really don't want to inherit the 
standard methods because any you failed to override could be disastrous.




Well, one can go the very long and stable way as we did in the
Matrix package...

I'm not sure I would recommend that for you in your situation.
...
not the least because you *could* use the Matrix package if you
want to use such formal matrices with its thousands of methods.

Martin Maechler,
ETH Zurich

   Option 2 seems most stable.

   Thanks,
   Dan Murphy

   Windows Vista, R version 2.11.0 (2010-04-22)

   [[alternative HTML version deleted]]

   __
   R-devel@r-project.org mailing list
   https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel