Dear Steve, Since this relates as well to the message I posted a couple of minutes before yours, I agree that it’s possible to phrase “best practices” too categorically. In the current case, I believe that it’s reasonable to say that specifying the data argument is “generally” or “usually” the best option. That doesn’t rule out exceptions.
Best, John ------------------------------------------------- John Fox, Professor Emeritus McMaster University Hamilton, Ontario, Canada Web: http::/socserv.mcmaster.ca/jfox > On Dec 17, 2018, at 7:49 AM, S Ellison <s.elli...@lgcgroup.com> wrote: > > > >> From: Thomas Yee [mailto:t....@auckland.ac.nz] >> >> Thanks for the discussion. I do feel quite strongly that >> the variables should always be a part of a data frame. > > This seems pretty much a decision for R core, and I think it's useful to have > raised the issue. > > But I, er, feel strongly that strong feelings and 'always' are unsafe in a > best practice argument. > > First, other folk with different use-cases or work practice may see 'best > practice' quite differently. So I would pretty much always expect exceptions. > > Second, for examples of capability, there are too many exceptions in this > instance. For example: > glm() can take a two-column matrix as a single response variable. > lm() can take a matrix as a response variable. > lm() can take a complete data frame as a predictor (see ?stackloss) > > None of these work naturally if everything is in a data frame, and some won’t > work at all. > > Steve E > > > > > ******************************************************************* > This email and any attachments are confidential. Any use, copying or > disclosure other than by the intended recipient is unauthorised. If > you have received this message in error, please notify the sender > immediately via +44(0)20 8943 7000 or notify postmas...@lgcgroup.com > and delete this message and any copies from your computer and network. > LGC Limited. Registered in England 2991879. > Registered office: Queens Road, Teddington, Middlesex, TW11 0LY, UK > ______________________________________________ > 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
