Re: [Rd] suggested addition to model.matrix

2016-10-03 Thread Fox, John
Dear Spencer, I don't think that the problem of "converting a data frame into a model matrix" is well-defined, because there isn't a unique mapping from one to the other. In your example, you build the model matrix for the additive formula ~ a + b from the data frame matrix containing a and b

[Rd] suggested addition to model.matrix

2016-10-03 Thread Spencer Graves
Hello, All: What's the simplest way to convert a data.frame into a model.matrix? One way is given by the following example, modified from the examples in help(model.matrix): dd <- data.frame(a = gl(3,4), b = gl(4,1,12)) ab <- model.matrix(~ a + b, dd) ab0 <- model.matrix(~., dd

Re: [Rd] On implementing zero-overhead code reuse

2016-10-03 Thread Kynn Jones
Martin, thanks for that example. It's definitely eye-opening, and very good to know. The installation business, however, is still a killer for me. Of course, it's a trivial step in a simple example like the one you showed. But consider this scenario: suppose I perform an analysis that I may pu

Re: [Rd] On implementing zero-overhead code reuse

2016-10-03 Thread Martin Morgan
On 10/03/2016 01:51 PM, Kynn Jones wrote: Thank you all for your comments and suggestions. @Frederik, my reason for mucking with environments is that I want to minimize the number of names that import adds to my current environment. For instance, if module foo defines a function bar, I want my

Re: [Rd] On implementing zero-overhead code reuse

2016-10-03 Thread Dirk Eddelbuettel
Kynn, You appear confused by the meaning of the word "optional". All the things I listed for packages are additional features you _may_ use, not onces that are imposed on you so that they _must_ be used. Lastly, I forgot to mention NAMESPACE support. Which gives pretty much exactly what you ou

Re: [Rd] On implementing zero-overhead code reuse

2016-10-03 Thread Kynn Jones
Thank you all for your comments and suggestions. @Frederik, my reason for mucking with environments is that I want to minimize the number of names that import adds to my current environment. For instance, if module foo defines a function bar, I want my client code to look like this: import("fo

Re: [Rd] grep

2016-10-03 Thread Prof Brian Ripley
On 02/10/2016 17:54, Pi wrote: Hello. It would be great if the grep function in R had the option to use the -m parameter as the linux command does. I guess you mean the non-standard flag of the GNU version of grep (probably but not necessarily as used by Linux). That the POSIX standard for

Re: [Rd] On implementing zero-overhead code reuse

2016-10-03 Thread Kasper Daniel Hansen
On Mon, Oct 3, 2016 at 10:18 AM, wrote: > Hi Kynn, > > Thanks for expanding. > > I wrote a function like yours when I first started using R. It's > basically the same up to your "new.env()" line, I don't do anything > with environmentns. I just called my function "mysource" and it's > essentially

Re: [Rd] On implementing zero-overhead code reuse

2016-10-03 Thread Gabor Grothendieck
Have a look at the CRAN modules package and the import package. On Sun, Oct 2, 2016 at 1:29 PM, Kynn Jones wrote: > I'm looking for a way to approximate the "zero-overhead" model of code > reuse available in languages like Python, Perl, etc. > > I've described this idea in more detail, and the mo

Re: [Rd] On implementing zero-overhead code reuse

2016-10-03 Thread frederik
Hi Kynn, Thanks for expanding. I wrote a function like yours when I first started using R. It's basically the same up to your "new.env()" line, I don't do anything with environmentns. I just called my function "mysource" and it's essentially a "source with path". That allows me to find code I reu