Problem fixed by R-patched, thanks; see comments below.
>On Thu, 11 Oct 2007, [EMAIL PROTECTED] wrote:
>
>> I'm encountering excruciatingly slow load times for character vectors
>> in R 2.6.0-- up to 30sec for a 15K file that contains a no-attributes
>> character vector of length ~1e4 and object
>> There was no attachment: since these are (I presume)
>> binary files, can ou
>> not put them on a website (as suggested by the posting
>> guide)?
> Sorry, I would have if I could, but can't at present. The
> attachments got through OK to me at least, though. If
I still can't reproduce this with lots of empty strings, but the way they
are handled was changed in R-patched -- but not with the intention of
avoiding a performance bottleneck, just to simplify the code.
I don't get object sizes as large as 500Kb, but it will be the case that
"" is shared in
This was a deliberate change for R 2.4.0 with SVN log:
r38145 | rgentlem | 2006-05-20 23:58:14 +0100 (Sat, 20 May 2006) | 2 lines
fixing gregexpr infelicity
So it seems the author of gregexpr believed that the bug was in 2.3.1, not
2.5.1.
On Wed, 10 Oct 2007, [EMAIL PROTECTED] wrote:
> Full_Na
This is already fixed in nlme_3.1-86!
> Sigma <- corMatrix(tmp, covariate = 1:n) # segfault
Error in corMatrix.corARMA(tmp, covariate = 1:n) :
'object' has not been Initialize()d
Please do check that things you report are not already fixed.
On Wed, 10 Oct 2007, [EMAIL PROTECTED] wrote:
> Fu
If you want all the matches (including overlaps) then you could try one
of these:
> gregexpr("(?=3Dabab)","ababab",perl=3DTRUE)
[[1]]
[1] 1 3
attr(,"match.length")
[1] 0 0
> gregexpr("ab(?=3Dab)","ababab",perl=3DTRUE)
[[1]]
[1] 1 3
attr(,"match.length")
[1] 2 2
The book "Mastering Regular Expres
Hi,
I'm trying to cross compile R260 in a ubuntu 6.06 linux. I downloaded
the Makefile for 251 and simply replaced the R version by 260. However
I'm getting an error about mingw.
[EMAIL PROTECTED]:~/ipimar/devel/R/ccompile260$ make R
export
PATH=/home/ernesto/ipimar/devel/R/ccompile260/cross-t
I don't know what you mean about 'the Makefile': the R sources contain
all the makefiles needed.
Things are different for 2.6.0 but the procedure is (still) described in
the R-admin manual (section 3.1.9 in the version I am looking at), and it
has been tested. Looks like you have the settings
On Wed, 10 Oct 2007, Duncan Murdoch wrote:>
> As Charles Berry told you when this was posted to R-help, it looks as
> though it is Mathematica that is inaccurate. For example, I would
> expect this plot to be smooth, and it is not in either R or Mathematica,
> but R is at least monotone:
I did ch
Yes, we had originally wanted it to find all matches, but user
complaints that it did not perform as Perl does were taken to prevail.
There are different ways to do this, but it seems the notion that one
not start looking for the next match until after the previous one is
more common. I did co
Yes, we had originally wanted it to find all matches, but user
complaints that it did not perform as Perl does were taken to prevail.
There are different ways to do this, but it seems the notion that one
not start looking for the next match until after the previous one is
more common. I did co
Here's a contribution from Ian Smith that got bounced from the list.
Original Message
Subject: Re: [Rd] pt inaccurate when x is close to 0 (PR#9945)
Date: Thu, 11 Oct 2007 06:02:43 -0400
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Duncan,
I tried sending the rest of this to
I have been unable to reproduce this problem but the warning I got told
me to send a bug report, so here it is.
After a fairly lengthy session, using the ape and ade4 packages,
conducted via a terminal in kate under kubuntu 6.06 linux , I found
errors claiming not to find lapply- see first sec
13 matches
Mail list logo
