search for: do_termsform

...andomForest seem to work fine, while nnet, rpart can't handle nonsyntactic names in formulae as such In particlar, rpart contains this code: lapply(m[attr(Terms, "term.labels")], tfun) which fails for the reasons given. One way to get around this, might be to modify the do_termsform code, right now we have: PROTECT(varnames = allocVector(STRSXP, nvar)); for (v = CDR(varlist), i = 0; v != R_NilValue; v = CDR(v)) SET_STRING_ELT(varnames, i++, STRING_ELT(deparse1line(CAR(v), 0), 0)); and then for term.labels, we copy over the varnames (with :, as neede...

...; 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 t...

Dear all, I had a R segmentation fault, and then invoked debug mode and ran step by step. When I reached "terms(Y~X1*X2*...*X16)", I would then have "segmentation" fault. However, if I just ran this under regular "R interactive" mode, it would be fine though taking long time. My questions are: 1. Is there a known limit of terms for a formula? 2. Why does the

Dear all, I had a R segmentation fault, and then invoked debug mode and ran step by step. When I reached "terms(Y~X1*X2*...*X16)", I would then have "segmentation" fault. However, if I just ran this under regular "R interactive" mode, it would be fine though taking long time. My questions are: 1. Is there a known limit of terms for a formula? 2. Why does the