On Wed, Oct 19, 2011 at 2:34 PM, Stavros Macrakis wrote:
> I was surprised to find that df$a[1] is an order of magnitude faster than
> df[1,"a"]:
Yes. This treats a data frame as a list, and is much faster.
> I thought this might be because df[,] builds a data frame before simplifying
> it to a
`$` and `[` are primitives while `[.data.frame` is a longish R function
that does all sorts of clever things.
On 19/10/11 22:34, Stavros Macrakis wrote:
I was surprised to find that df$a[1] is an order of magnitude faster than
df[1,"a"]:
df<- data.frame(a=1:10)
system.time(replicate(10, d
On 20/10/2011 3:06 PM, Joshua Wiley wrote:
That Cygwin warning is expected on Windows.
It can be suppressed by setting an environment variable named CYGWIN
with value nodosfilewarning, e.g. by doing this at the command line:
SET CYGWIN=nodosfilewarning
Duncan Murdoch
You can still build
That. Cygwin warning is expected on Windows. You can still build the package
and it should be fine, although it looks like the documentation may need a bit
of tweaking to pass R CMD check. 2.13.2 is the latest version of R, and I
would recommend using it over 2.12.2. Both for the improvements
Dear All,
I am a beginner creating R packages. I followed the Leisch (2009) tutorial
and the document “Writing R Extensions” to write an example.
I installed R 2.12.2 (I also tried R2.13.2), the last version of Rtools and
the recommended packages in a PC with Windows 7 Home Premium.
I can run
On 20.10.2011 18:25, Geoff Jentry wrote:
On Thu, 20 Oct 2011, Hadley Wickham wrote:
The optimal solution would be if R packages could depend on a specific
version of a package, and a user could have multiple packages
You used to be able to have a versioned install of a package, and then
load
On Thu, 20 Oct 2011, Hadley Wickham wrote:
The optimal solution would be if R packages could depend on a specific
version of a package, and a user could have multiple packages
You used to be able to have a versioned install of a package, and then
load a particular version. Not sure when it wa
> We did have an attempt at that for some versions, but I don't think it ever
> achieved all of its goals, and we've dropped it.
Yes, I remembered it used to be possible to do versioned installs, but
I don't think you could ever have them loaded simultaneously.
> I'm not sure it would be "optimal
On 11-10-20 10:56 AM, Hadley Wickham wrote:
My package will have an update soon, that is not backward compatible
with the current version. It will likely break much of the existing
code. Many (~50) packages depend on 'igraph' and they, too, will most
probably break with the new version.
My inte
> My package will have an update soon, that is not backward compatible
> with the current version. It will likely break much of the existing
> code. Many (~50) packages depend on 'igraph' and they, too, will most
> probably break with the new version.
>
> My intended solution is, that I create a s
Thanks for the insight!
It is indeed true that naming the new version 'igraph1' (this is a
better name for the change it introduces), is optimal for the existing
packages.
I was a bit reluctant to do this, because of two reasons. First,
igraph exists as a Python package, and a C library as well,
On Thu, 20 Oct 2011, Rainer M Krug wrote:
On Wed, Oct 19, 2011 at 8:05 PM, G?bor Cs?rdi wrote:
Dear R developers,
I am seeking advice on some $subject matter.
If this is intended to be a CRAN update, then really you need to ask
the CRAN crew about the possible implications (and I've sent
Sorry - not iplot, but igraph.
On Thu, Oct 20, 2011 at 9:21 AM, Rainer M Krug wrote:
>
>
> On Wed, Oct 19, 2011 at 8:05 PM, Gábor Csárdi wrote:
>
>> Dear R developers,
>>
>> I am seeking advice on some $subject matter.
>>
>> My package will have an update soon, that is not backward compatible
>
On Wed, Oct 19, 2011 at 8:05 PM, Gábor Csárdi wrote:
> Dear R developers,
>
> I am seeking advice on some $subject matter.
>
> My package will have an update soon, that is not backward compatible
> with the current version. It will likely break much of the existing
> code. Many (~50) packages dep
14 matches
Mail list logo