nice report generator?

2. It's more flexible to construct the language object as a language object,
rather than pasting something together and parsing it.  For one thing, that
allows non-syntactic variable names; I think it's also easier to read.  So
your code

txt<- paste("tabular(value*v*", LEFT , "~" ,RIGHT ,", data = m_xx,
suppressLabels  = 2,...)", sep = "")
eval(parse(text = txt ))

could be rewritten as

formula<- substitute( value*v*LEFT ~ RIGHT, list(LEFT=LEFT, RIGHT=RIGHT))
tabular(formula, data = m_xx, suppressLabels = 2, ...)

To be strictly correct, shouldn't that be:

formula<- eval(substitute( value*v*LEFT ~ RIGHT, list(LEFT=LEFT, RIGHT=RIGHT)))

?

It might make sense to put something like this into the tables package, but
I don't want to have a dependency on reshape.

Would you consider making tabular generic?

To be strictly correct, shouldn't that be:

formula<- eval(substitute( value*v*LEFT ~ RIGHT, list(LEFT=LEFT,
RIGHT=RIGHT)))

?

I think it probably doesn't matter. ?The difference is that mine gives a
pure language object, whereas yours gives a formula object. ?The formula
object has a class which means some methods will work differently, and it
also has an environment attached, which defines where the variables in it
should be resolved. ?I suspect the variables shouldn't be resolved in the
environment where "formula" was being created, so it's probably better not
to attach an environment at all, but the tabular function ignores the
environment of the formula (it uses its data argument for that), so it
doesn't make a big difference.

 2. It's more flexible to construct the language object as a language object,
 rather than pasting something together and parsing it.  For one thing, that
 allows non-syntactic variable names; I think it's also easier to read.  So
 your code

 txt<- paste("tabular(value*v*", LEFT , "~" ,RIGHT ,", data = m_xx,
 suppressLabels  = 2,...)", sep = "")
 eval(parse(text = txt ))

 could be rewritten as

 formula<- substitute( value*v*LEFT ~ RIGHT, list(LEFT=LEFT, RIGHT=RIGHT))
 tabular(formula, data = m_xx, suppressLabels = 2, ...)

To be strictly correct, shouldn't that be:

formula<- eval(substitute( value*v*LEFT ~ RIGHT, list(LEFT=LEFT, RIGHT=RIGHT)))

?

 It might make sense to put something like this into the tables package, but
 I don't want to have a dependency on reshape.

Would you consider making tabular generic?

On 06/02/2012 4:12 PM, Hadley Wickham wrote:

  2. It's more flexible to construct the language object as a language object,
  rather than pasting something together and parsing it.  For one thing, that
  allows non-syntactic variable names; I think it's also easier to read.  So
  your code

  txt<- paste("tabular(value*v*", LEFT , "~" ,RIGHT ,", data = m_xx,
  suppressLabels  = 2,...)", sep = "")
  eval(parse(text = txt ))

  could be rewritten as

  formula<- substitute( value*v*LEFT ~ RIGHT, list(LEFT=LEFT, RIGHT=RIGHT))
  tabular(formula, data = m_xx, suppressLabels = 2, ...)

To be strictly correct, shouldn't that be:

formula<- eval(substitute( value*v*LEFT ~ RIGHT, list(LEFT=LEFT, RIGHT=RIGHT)))

?

  It might make sense to put something like this into the tables package, but
  I don't want to have a dependency on reshape.

Would you consider making tabular generic?

I have now made tabular() into a generic function, but because of the
problems at R-forge, can't commit the changes immediately.   The old
tabular() function is now the tabular.formula() method; the default
method tries to coerce the object to a formula to call that.  I think
both my suggestion and yours would likely have problems in the new
system (as they did in the old one) because the environment associated
with the formula would be wrong.  It's a little tricky, but now
tabular() works a lot more like model.frame(), which I think has to be
considered to be the standard way to do this.