I just noticed the following in update.formula and I'm wondering if this behavior is the intention of the developers. Here's an example: update(`a: b` ~ x, ~ . + y) Note now that the response has no backticks and is interpreted as a:b (i.e. ":" is now an operator). This is because in update.formula the call to terms.formula uses simplify = TRUE. I'm working with data that has a lot of colons in their names and for reporting purposes I don't want to use make.names to avoid this situation. I do have a solution which simply avoids using update.formula, but I wonder if the developers would consider removing the "simplify" argument and allow it to be passed through "...", which is currently ignored by update.formula. Alternatively, add a simplify=TRUE to the update.formula call, which can manually be set to FALSE by the user. I would love to hear any comments or criticisms of my findings. Thanks, --sundar
On Thu, Jul 30, 2009 at 2:28 PM, Sundar Dorai-Raj<sdorairaj at gmail.com> wrote:> I just noticed the following in update.formula and I'm wondering if > this behavior is the intention of the developers. Here's an example: > > update(`a: b` ~ x, ~ . + y) > > Note now that the response has no backticks and is interpreted as a:b > (i.e. ":" is now an operator). This is because in update.formula the > call to terms.formula uses simplify = TRUE. I'm working with data that > has a lot of colons in their names and for reporting purposes I don't > want to use make.names to avoid this situation. I do have a solution > which simply avoids using update.formula, but I wonder if the > developers would consider removing the "simplify" argument and allow > it to be passed through "...", which is currently ignored by > update.formula. Alternatively, add a simplify=TRUE to the > update.formula call, which can manually be set to FALSE by the user. > > I would love to hear any comments or criticisms of my findings. > > Thanks, > > --sundar >Forgot my version info> version_ platform x86_64-unknown-linux-gnu arch x86_64 os linux-gnu system x86_64, linux-gnu status major 2 minor 9.1 year 2009 month 06 day 26 svn rev 48839 language R version.string R version 2.9.1 (2009-06-26)
> -----Original Message----- > From: r-devel-bounces at r-project.org > [mailto:r-devel-bounces at r-project.org] On Behalf Of Sundar Dorai-Raj > Sent: Thursday, July 30, 2009 2:28 PM > To: r-devel at stat.math.ethz.ch > Subject: [Rd] update.formula and backticked colons > > I just noticed the following in update.formula and I'm wondering if > this behavior is the intention of the developers. Here's an example: > > update(`a: b` ~ x, ~ . + y) > > Note now that the response has no backticks and is interpreted as a:b > (i.e. ":" is now an operator). This is because in update.formula the > call to terms.formula uses simplify = TRUE. I'm working with data that > has a lot of colons in their names and for reporting purposes I don't > want to use make.names to avoid this situation. I do have a solution > which simply avoids using update.formula, but I wonder if the > developers would consider removing the "simplify" argument and allow > it to be passed through "...", which is currently ignored by > update.formula. Alternatively, add a simplify=TRUE to the > update.formula call, which can manually be set to FALSE by the user. > > I would love to hear any comments or criticisms of my findings. > > Thanks, > > --sundarIt would be nice to get right of the deparse/parse cycle in terms.formula, since that often causes problems. However, I think that adding backticks=TRUE to terms.formula:fixFormulaObject's call to deparse(form[[2L]]) would fix the immediate problem. (I haven't spent much time looking for bad side effects of this change to terms.formula, which gets called in a lot of other situations.) Bill Dunlap TIBCO Software Inc - Spotfire Division wdunlap tibco.com
> -----Original Message----- > From: William Dunlap > Sent: Friday, July 31, 2009 10:15 AM > To: 'Sundar Dorai-Raj'; r-devel at stat.math.ethz.ch > Subject: RE: [Rd] update.formula and backticked colons > > > -----Original Message----- > > From: r-devel-bounces at r-project.org > > [mailto:r-devel-bounces at r-project.org] On Behalf Of Sundar Dorai-Raj > > Sent: Thursday, July 30, 2009 2:28 PM > > To: r-devel at stat.math.ethz.ch > > Subject: [Rd] update.formula and backticked colons > > > > I just noticed the following in update.formula and I'm wondering if > > this behavior is the intention of the developers. Here's an example: > > > > update(`a: b` ~ x, ~ . + y) > > > > Note now that the response has no backticks and is > interpreted as a:b > > (i.e. ":" is now an operator). This is because in update.formula the > > call to terms.formula uses simplify = TRUE. I'm working > with data that > > has a lot of colons in their names and for reporting > purposes I don't > > want to use make.names to avoid this situation. I do have a solution > > which simply avoids using update.formula, but I wonder if the > > developers would consider removing the "simplify" argument and allow > > it to be passed through "...", which is currently ignored by > > update.formula. Alternatively, add a simplify=TRUE to the > > update.formula call, which can manually be set to FALSE by the user. > > > > I would love to hear any comments or criticisms of my findings. > > > > Thanks, > > > > --sundar > > It would be nice to get right of the deparse/parse cycle in > terms.formula, > since that often causes problems. However, I think that > adding backticks=TRUETypo above: backtick should be singular.> to terms.formula:fixFormulaObject's call to > deparse(form[[2L]]) would fix the > immediate problem. (I haven't spent much time looking for > bad side effects > of this change to terms.formula, which gets called in a lot > of other situations.) > > Bill Dunlap > TIBCO Software Inc - Spotfire Division > wdunlap tibco.com