R devel - Jun 1998 - aov

R developers,

  Last week I asked several questions which I think I can now answer
myself in large part.
>
> Q 1)  Is aov supposed to avoid qr decomposition and matrix inversion?
>       In S it is claimed to be faster than lm() for large datasets.  Is
>       that due to avoidance of qr()? 
>       (My main goal is to get the Error strata working.)
   My use of matrix manipulation to avoid qr decompositon takes more
time than the complied solver build into lm.fit. It seems that the real
reason for doing aov differently would be if the determination of Error
strata and which factors to evaluate in any given error statum requires
a different approach from lm.fit.  I'm not going to worry about speed of
lm.fit anymore, so that avoids most of the other questions I had posed.

  Douglas Bates has suggested:
DB> I think that a general approach via maximum likelihood or REML to
DB> anova models with random effects in them will eventually be superior
DB> to approaches based on sum-of-squares decompositions.

  Perhaps one could make an aov function which fit using lme and then
repackaged the output a bit.  I intend to look into that possibility.

    In pursuit of a sum-of-squares decomp, I have looked at the C code
in  model.c, particularly the  do_termsform definition. I see
these comments (line 821 in June 2 snapshot)
		/* Step 2: Recode the model terms in binary form */
		/* and at the same time, expand the model formula. */

		/* FIXME: this includes specials in the model */
		/* There perhaps needs to be a an extra pass */
		/* through the model to delete any terms which */
		/* contain specials.  Actually, specials should */
		/* only enter additively so this should also be */
		/* checked and abort forced if not. */

		/* FIXME: this is also the point where nesting */
		/* needs to be taken care of. */

To continue on this approach, and follow up on these FIXMEs, I need to
understand some of the internal functions like CAR, CDR, and
combinations thereof.  I found the definition of CAR in
src/include/Defn.h as:

#define CAR(e)          ((e)->u.listsxp.carval)

But where is u.listsxp.carval defined?  For that matter, where is the
Scheme/LISP interpreter?
Is there a roadmap? list of where the different pieces of R reside?


Jim Robison-Cox                 ____________            
Department of Math Sciences    |            |           phone: (406)994-5340
2-214 Wilson Hall               \   BZN, MT |           FAX:   (406)994-1789
Montana State University         |  *_______|
Bozeman, MT 59717                 \_|         e-mail: jimrc@math.montana.edu 



-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel 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-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

> To continue on this approach, and follow up on these FIXMEs, I need to
> understand some of the internal functions like CAR, CDR, and
> combinations thereof.  I found the definition of CAR in
> src/include/Defn.h as:
> 
> #define CAR(e)          ((e)->u.listsxp.carval)
> 
> But where is u.listsxp.carval defined?  For that matter, where is the
> Scheme/LISP interpreter?
> Is there a roadmap? list of where the different pieces of R reside?
> 
> 
  Well there isn't a road map but there probably oughta be.
  Everything (almost) in R is a SEXPREC, and one of the mor common of these
  is the LISTSXP,
  
  it is basically a triple- the car, the cdr and the tag
  
   a list is a connected group of LISTSXP's,
    the car is a pointer to the "value" in that element of the list,
    the cdr is a pointer to the next LISTSXP (in the list)
    the tag is a place to keep things like the name associated with the
    list element.
    
    the first element of a list l is obtained by CAR(l)
    the second element by CADR(l) (CAR(CDR(l)))
    in the lisp world one cdr's down the list;
    
    the name for the first element is TAG(l)
    for the second TAG(CDR(l))
    and so on
    
    SEXPREC's (our basic building block) can be one of 20 different types,
    but they are all similar enough to be contained in one C union.
    First in the union is the info slot (32 bits), this is used for all sorts
    of nasty things
    
    then comes a slot for an SEXPREC that contains the attributes (this is 
    where the S-style attributes are stuck)
    
    then the actual data structures - notice that most of these are triples
    (vectors, primitives and environments are exceptions).
    
    hope this helps....
    robert
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel 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-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._