On 8/31/07, Uwe Ligges <[EMAIL PROTECTED]> wrote:
>
>
> Johanna Hasmats wrote:
> > Hi!
> >
> >
> >
> > How can I get around in R 2.5.1 in Windows:
> >
> >
> >
> > Error in strsplit(linebuffer, "") : object "linebuffer" not found
>
>
> Why should this be a bug in R, if you have no object named "line
Johanna Hasmats wrote:
> Hi!
>
>
>
> How can I get around in R 2.5.1 in Windows:
>
>
>
> Error in strsplit(linebuffer, "") : object "linebuffer" not found
Why should this be a bug in R, if you have no object named "linebuffer"
in the environments that are on the search path.
Uwe Lig
Hi!
How can I get around in R 2.5.1 in Windows:
Error in strsplit(linebuffer, "") : object "linebuffer" not found
It comes a few lines after the actual strsplit, and yesterday everything was
fine
Thank you in advance
Kindest regards,
(the same mail was sent to the author)
When I called the function DEoptim with control=list(strategy=1) or
control=list(strategy=2)
I got the error:
Error in mui[rtd + 1, i] : incorrect number of dimensions
Analysis of the source code of the DEoptim reveals the following fragment
if (con$
Greetings. This seemed like a bug to me, but I wanted to see if this
was in fact intended before reporting.
Before I start, i want to first extend thanks for the big improvements
in integration of command completion for the windows version. Really
nice to have now. But i believe there are some
Hello,
I think I found a bug when creating graphics on a PDF device using
transparency. I'm using ggplots2 like this:
comp <- ggplot(data, aes(x=Problemsize, y=Fitness)) +
geom_smooth(fill=alpha("blue", 0.2), aes(colour=factor(Clustersize)),
size=2)
Which gives me a curve for each "Clus
Note that the use of read.table() does make a difference. If you did
x <- scan(gzfile("xxx.gz"), list("","",""))
you would leave an unused connection, and showConnections(all=TRUE) would
show this. There is a finite pool of connections, and in general the
correct way to use them is
con <- gz
On 03/07/2007 1:37 PM, David Reiss wrote:
> Hi,
> I am making multiple calls to gzfile() via read.table(), e.g.
>
>> x <- read.table( gzfile( "xxx.gz" ) )
>
> After i do this many times (I haven't counted, but probably between 50 and
> 100 times) I get the error message:
>
> Error in open.connec
Hi,
I am making multiple calls to gzfile() via read.table(), e.g.
> x <- read.table( gzfile( "xxx.gz" ) )
After i do this many times (I haven't counted, but probably between 50 and
100 times) I get the error message:
Error in open.connection(file, "r") : unable to open connection
In addition: Wa
On 6/4/07, Don MacQueen <[EMAIL PROTECTED]> wrote:
> I think you can easily get the last days of the months by creating a
> series starting on the first days, and subtracting one from each.
>
> seq(as.Date("2000-2-1"), as.Date("2001-2-1"), "months") -1
Thanks for the suggestion, but for my problem
I think you can easily get the last days of the months by creating a
series starting on the first days, and subtracting one from each.
seq(as.Date("2000-2-1"), as.Date("2001-2-1"), "months") -1
-Don
At 2:01 PM +0200 6/4/07, hadley wickham wrote:
>On 6/4/07, Gabor Grothendieck <[EMAIL PROTECTED]
On 6/4/07, Gabor Grothendieck <[EMAIL PROTECTED]> wrote:
> Note that chron does give the last day of the month:
>
> > library(chron)
> > seq(chron("1/31/2000"), chron("1/31/2001"), "month")
> [1] 01/31/00 02/29/00 03/31/00 04/30/00 05/31/00 06/30/00 07/31/00 08/31/00
> [9] 09/30/00 10/31/00 11/30
Note that chron does give the last day of the month:
> library(chron)
> seq(chron("1/31/2000"), chron("1/31/2001"), "month")
[1] 01/31/00 02/29/00 03/31/00 04/30/00 05/31/00 06/30/00 07/31/00 08/31/00
[9] 09/30/00 10/31/00 11/30/00 12/31/00 01/31/01
The zoo package has a "yearmon" class whose a
No, it's not a bug, it matches with the documentation.
see:
?seq.POSIXt
Using '"month"' first advances the month without changing the day:
if this results in an invalid day of the month, it is counted
forward into the next month: see the examples.
So, it increases the month firs
> seq(as.Date("2000-1-1"), as.Date("2001-1-1"), "months")
[1] "2000-01-01" "2000-02-01" "2000-03-01" "2000-04-01" "2000-05-01"
[6] "2000-06-01" "2000-07-01" "2000-08-01" "2000-09-01" "2000-10-01"
[11] "2000-11-01" "2000-12-01" "2001-01-01"
> seq(as.Date("2000-1-31"), as.Date("2001-1-31"), "mont
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of ivo welch
> Sent: Thursday, May 17, 2007 11:53 AM
> To: jim holtman
> Cc: r-help
> Subject: Re: [R] bug or feature?
>
> ahh...it is the silent substitution of the data frame
onclinical Statistics
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of ivo welch
Sent: Thursday, May 17, 2007 11:53 AM
To: jim holtman
Cc: r-help
Subject: Re: [R] bug or feature?
ahh...it is the silent substitution of the data frame in the subset
statement.
ahh...it is the silent substitution of the data frame in the subset
statement. I should have known this. (PS: this may not be desirable
behavior; maybe it would be useful to issue a warning if the same name
is defined in an upper data frame. just an opinion...)
mea misunderstanding.
/iaw
___
In the 'subset' function, the 'select' parameter can contain the names of
the columns (without the df$ qualifier). So in your 'for' loop you
basically have
subset(d, d$y ==d$y)
which selects all the data since you have a column name of 'y' which is the
same as your variable.
On 5/17/07, ivo we
R version 2.5.0, under gentoo linux. This may be just my ignorance
about naming conventions inside loops and subsets, but the following
appears like a bug to me.
y = c( 1963, 1963, 1964, 1964, 1965, 1965 );
r1= rnorm(6);
d= data.frame ( y=y, r1=r1 );
## note: I am not attach()ing anything anywh
Dear r-helpers,
I have been bitten by a cryptic comment in the help page for xYplot().
Here is some code from Madeline Bauer, one of the authors, which is
essentailly the code on the help page for xYplot():
# This example uses the summarize function in Hmisc to
# compute the median and outer q
lable at cran works again as I want it to.
So cancel this R bug and and account it for a user bug :-).
Greetings,
Sebastian
On Mon, 2007-04-23 at 11:20 -0400, Duncan Murdoch wrote:
> On 4/23/2007 10:56 AM, Sebastian Weber wrote:
> > Hello everybody,
> >
> > I'm using h
On 4/23/2007 10:56 AM, Sebastian Weber wrote:
> Hello everybody,
>
> I'm using hdf5 files to store results from intermediate calculations.
> These are usually part of a list, called "res". As I want the hdf-files
> to contain all the members of res in its top "directory", I used to do
>
> attach(
Hello everybody,
I'm using hdf5 files to store results from intermediate calculations.
These are usually part of a list, called "res". As I want the hdf-files
to contain all the members of res in its top "directory", I used to do
attach(res)
do.call("hdf5save", args=c(fileout=file.path(dir, ofile
As the help page says:
'&' and '&&' indicate logical AND and '|' and '||' indicate
logical OR. The shorter form performs elementwise comparisons in
much the same way as arithmetic operators. The longer form
evaluates left to right examining only the first element of each
"&&" seems to behave strangely and gives different results from "&" e.g. in a
data frame selection (regardless whether terms are bracketed)?
===Script===
test=data.frame(gender=c("F","M","M","F","F"),side=c("R","L","R","L","R"))
test
test[test$gender=="F" & test$side=
Hi all,
Sorry to report that there is a minor bug in the floating.pie function
in the new version of plotrix. I inadvertantly changed the bouyancy
constant and some users may find that they are farther down the ordinate
than they should be. This will be fixed in version 2.2-1.
Jim
___
I've verified this bug and will be releasing a new version shortly.
Max
-Original Message-
From: Abhijit Dasgupta [mailto:[EMAIL PROTECTED]
Sent: Saturday, December 23, 2006 12:03 AM
To: r-help@stat.math.ethz.ch; Kuhn, Max
Subject: bug in odfWeave
Hi,
I think there is a minor bug in o
Hi,
I think there is a minor bug in odfWeave. In the function odfStyleGen,
the following line has an extra "=":
if(length(grep("italic", thisStyle$fontType)))
fontText <- c(fontText, tagattr("fo:font-style=", "italic"))
This is creating an error if some text needs to
outh San Francisco, CA 94404
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Frank E Harrell Jr
Sent: Friday, October 13, 2006 5:51 AM
To: Prof Brian Ripley
Cc: [EMAIL PROTECTED]
Subject: Re: [R] Bug in lowess
Prof Brian Ripley wrote:
> Frank Harrell wrote:
Prof Brian Ripley wrote:
> Frank Harrell wrote:
>
> [...]
>
>> Thank you Brian. It seems that no matter what is the right answer, the
>> answer currently returned on my system is clearly wrong. lowess()$y
>> should be constrained to be within range(y).
>
> Really? That assertion is offered wi
If you are just modifying an S3 method in a package you may not need to reinsert
the method into the package since UseMethod first looks into the
caller environment
for methods anyways and only second does it look for methods in the
package. Thus:
HTML.data.frame <- R2HTML:::HTML.data.frame
Frank Harrell wrote:
[...]
> Thank you Brian. It seems that no matter what is the right answer, the
> answer currently returned on my system is clearly wrong. lowess()$y
> should be constrained to be within range(y).
Really? That assertion is offered without proof and I am pretty sure is
inc
Ah, it's fixed in 2.4.0. I'll work around it.
-Alex
On 13 Oct 2006, at 11:19, Alex Brown wrote:
> First, here's the specific bug I have. Later I'll say why I care.
>
>> ls(zappo)
> Error in try(name) : object "zappo" not found
> # good.
>> f = function(zappo) { function(y) zappo + y }
>> g = f
First, here's the specific bug I have. Later I'll say why I care.
> ls(zappo)
Error in try(name) : object "zappo" not found
# good.
> f = function(zappo) { function(y) zappo + y }
> g = f(1)
> g(1)
[1] 2
> formals(g)
$y
> formals(g)$y
> formals(g)$y = 2
> g
function (y = 2)
zappo + y
>
Prof Brian Ripley wrote:
> You sent this earlier to R-devel. Please do see the posting guide!
> Since you (incorrectly) thought this was a bug in MASS, you should have
> contacted the maintainer.
Thanks, but I did try emailing both you and Prof. Venables directly a
month ago. After not receiv
Prof Brian Ripley wrote:
> On Thu, 12 Oct 2006, Gavin Simpson wrote:
>
>> On Wed, 2006-10-11 at 22:29 -0500, Frank E Harrell Jr wrote:
>>> x <- c(0,7,8,14,15,120,242)
>>> y <- c(122,128,130,158,110,110,92)
>>>
>>> lowess(x,y)
>>>
>>> $x
>>> [1] 0 7 8 14 15 120 242
>>>
>>> $y
>>> [1] 122.
You sent this earlier to R-devel. Please do see the posting guide!
Since you (incorrectly) thought this was a bug in MASS, you should have
contacted the maintainer.
On Wed, 11 Oct 2006, Martin C. Martin wrote:
> Hi,
>
> First of all, thanks for the great work on R in general, and MASS in
> par
On Thu, 12 Oct 2006, Gavin Simpson wrote:
> On Wed, 2006-10-11 at 22:29 -0500, Frank E Harrell Jr wrote:
>> x <- c(0,7,8,14,15,120,242)
>> y <- c(122,128,130,158,110,110,92)
>>
>> lowess(x,y)
>>
>> $x
>> [1] 0 7 8 14 15 120 242
>>
>> $y
>> [1] 122. 128. 132.2857 158.
On Wed, 2006-10-11 at 22:29 -0500, Frank E Harrell Jr wrote:
> x <- c(0,7,8,14,15,120,242)
> y <- c(122,128,130,158,110,110,92)
>
> lowess(x,y)
>
> $x
> [1] 0 7 8 14 15 120 242
>
> $y
> [1] 122. 128. 132.2857 158. 110. -4930.
> 110.
Same behaviour here
x <- c(0,7,8,14,15,120,242)
y <- c(122,128,130,158,110,110,92)
lowess(x,y)
$x
[1] 0 7 8 14 15 120 242
$y
[1] 122. 128. 132.2857 158. 110. -4930.
110.
R version 2.2.1, 2005-12-20, i486-pc-linux-gnu
attached base packages:
[1] "methods" "stats"
Hi,
First of all, thanks for the great work on R in general, and MASS in
particular. It's been a life saver for me many times.
However, I think I've discovered a bug. It seems that, when I use
weights during an initial least-squares regression fit, and later try to
add terms using stepAIC(),
I've tracked down where this is occurring, but I don't know how to fix
it. Here's a summary:
If the language in Windows is set to simplified Chinese (i.e. Chinese
(PRC)) and message translations are installed, then on startup Rgui
crashes when it tries to install the console popup menu. The c
Frank E Harrell Jr <[EMAIL PROTECTED]> writes:
> Deepayan Sarkar wrote:
> > On 9/26/06, Frank E Harrell Jr <[EMAIL PROTECTED]> wrote:
> >> I think this is new since a previous version of R:
> >>
> >> > h <- function(x, trantab) trantab[x]
> >> > w <- 6:4
> >> > names(w) <- c('cat','dog','giraff
This seems to be related to using c to define transtab.
If we use list in place of c then it displays ok:
> h <- function(x, trantab) transtab[x]
> formals(h) <- list(x = numeric(0), transtab = c(cat = 6, dog = 5))
> print(h) # bad display
function (x = numeric(0), transtab = c(6, 5))
transtab[x]
Deepayan Sarkar wrote:
> On 9/26/06, Frank E Harrell Jr <[EMAIL PROTECTED]> wrote:
>> I think this is new since a previous version of R:
>>
>> > h <- function(x, trantab) trantab[x]
>> > w <- 6:4
>> > names(w) <- c('cat','dog','giraffe')
>> > w
>> cat dog giraffe
>>6 5
On 9/26/06, Frank E Harrell Jr <[EMAIL PROTECTED]> wrote:
> I think this is new since a previous version of R:
>
> > h <- function(x, trantab) trantab[x]
> > w <- 6:4
> > names(w) <- c('cat','dog','giraffe')
> > w
> cat dog giraffe
>6 5 4
> >
> > formals(h) <- lis
I think this is new since a previous version of R:
> h <- function(x, trantab) trantab[x]
> w <- 6:4
> names(w) <- c('cat','dog','giraffe')
> w
cat dog giraffe
6 5 4
>
> formals(h) <- list(x=numeric(0), trantab=w)
> h
function (x = numeric(0), trantab = c(6, 5, 4
Hi,
I guess the question often comes down to whether it is a bug report,
or a question. If you know it is a bug, and have a complete and correct
example where the obviously incorrect behavior occurs and you are
positive that the problem is the package then sending it to the
maintainer is app
If users post a bug or problem issue to an R-based news group
(R-devel, R-help, BioC - though BioC is far more forgiving)
they get yelled at for not reading the posting guide
and FAQ.
"Please *_do_* read the FAQ, the posting guide, ..."
the yellers do say. So I read the BioC FAQ and it says...
z.ch
Subject: Re: [R] bug in interaction order when using drop?
> On Thu, 10 Aug 2006, Petr Pikal wrote:
>
> > Ooops, my first suggestion reorders factor itself but
> >
> > if (drop) factor(ans) else ans
> >
> > instead of whole drop construction shall pre
gt; levels(interaction(c("A", "A", "B"), letters[1:3], drop=T))
[1] "A.a" "A.b" "B.c"
looks more sensible in this case.
>
> Petr
>
> On 10 Aug 2006 at 16:32, Petr Pikal wrote:
>
> From: "Petr
ROTECTED]>
To: r-help@stat.math.ethz.ch
Date sent: Thu, 10 Aug 2006 16:32:54 +0200
Priority: normal
Subject: [R] bug in interaction order when using drop?
> Hallo all
>
> > version
>_
Hallo all
> version
_
platform i386-pc-mingw32
arch i386
os mingw32
system i386, mingw32
status
On Wed, 26 Jul 2006, Patrick Jahn wrote:
> Dear All,
> if you generate a sequence with small latitude like:
>
> x<-seq(0,1,0.005)
>
> and you ask for all points of this lattice how many points are in a
> neighbourhood with radius 0.01
> of each point:
>
> v <- rep( 0 , length( x ) ) ;
> for (i in
Dear All,
if you generate a sequence with small latitude like:
x<-seq(0,1,0.005)
and you ask for all points of this lattice how many points are in a
neighbourhood with radius 0.01
of each point:
v <- rep( 0 , length( x ) ) ;
for (i in 1:length(x) )
{ v[i] <- length(x[ abs(x-x[i]) < 0.01
On Sat, 27 May 2006, P Ehlers wrote:
> Looks like a bug (in mvt()?). Note that
>
> pmvnorm(lower = c(-Inf, -Inf), upper = c(Inf, 10))
>
> works as expected, as does replacing any of the 4 Infs with a finite
> value.
>
> Function sadmvn() in pkg:mnormt does give 1 with Inf lower/uppers.
>
yes, lo
Looks like a bug (in mvt()?). Note that
pmvnorm(lower = c(-Inf, -Inf), upper = c(Inf, 10))
works as expected, as does replacing any of the 4 Infs with a finite
value.
Function sadmvn() in pkg:mnormt does give 1 with Inf lower/uppers.
Peter Ehlers
Daniel Yang wrote:
> Dear R-help,
>
> Is t
Dear R-help,
Is the following a bug of pmvnorm?
R<-matrix(c(1,.5,.5,1),2,2)
pmvnorm(lower=c(-Inf,-Inf),upper=c(Inf,Inf),corr=R)
It returns,
[1] 0
attr(,"error")
[1] 0
attr(,"msg")
[1] "Normal Completion"
But I think it should return 1.
Yung-jui
__
running
pictex()
plot(1:11,(-5:5)^2, type='b', main="Simple_Example_Plot")
dev.off()
(as in the pictex example, but with underscores instead of spaces).
the TeX file contains
\put {Simple_Example_Plot} [lB] <0.00pt,0.00pt> at 124.00 275.33
the underscores have a special meaning in
> From: Joerg van den Hoff <[EMAIL PROTECTED]>
>
> hi,
>
> did'nt see anything in the archive:
>
> map('world',pro='rectangular',para=0)
>
> yields a strange artifact (horizontal bar) extending over the whole map
> at a certain latitude range (approx 65 deg. north), whereas
>
> map('world',pr
Intermountain Healthcare
[EMAIL PROTECTED]
(801) 408-8111
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Ray Brownrigg
> Sent: Wednesday, March 08, 2006 12:40 PM
> To: [EMAIL PROTECTED]; r-help@stat.math.ethz.ch
> Subject: Re: [R]
I seem to recall I came across something similar recently (well,
relatively recently, perhaps a couple of years ago). The problem is
related to how the code handles polygons that are split across the map
boundaries. As I recall, the fix was to modify the polygons that
straddle the date line. I'l
hi,
did'nt see anything in the archive:
map('world',pro='rectangular',para=0)
yields a strange artifact (horizontal bar) extending over the whole map
at a certain latitude range (approx 65 deg. north), whereas
map('world',pro='rectangular',para=180)
(which should be the same) does not show th
Woops!
RTFM for me :(
Thanks everyone for your help.
Mick
-Original Message-
From: Liaw, Andy [mailto:[EMAIL PROTECTED]
Sent: 23 February 2006 13:57
To: michael watson (IAH-C); r-help@stat.math.ethz.ch
Subject: RE: [R] Bug in setting GUI to SDI mode?
The file needs to be in R_HOME
The file needs to be in R_HOME\etc. See ?Rconsole.
Andy
From: michael watson (IAH-C)
>
> Hi
>
> I did a google search on this and came up with nothing.
>
> OK, in the latest release of R for windows, I want to change
> the gui to
> SDI mode.
>
> Edit -> GUI preferences
> Choose SDI
> Appl
michael watson (IAH-C) wrote:
> Hi
>
> I did a google search on this and came up with nothing.
>
> OK, in the latest release of R for windows, I want to change the gui to
> SDI mode.
>
> Edit -> GUI preferences
> Choose SDI
> Apply
>
> I get the message about properties not being able to be
michael watson (IAH-C) wrote:
> Hi
>
> I did a google search on this and came up with nothing.
>
> OK, in the latest release of R for windows, I want to change the gui to
> SDI mode.
>
> Edit -> GUI preferences
> Choose SDI
> Apply
>
> I get the message about properties not being able to be
On 2/23/2006 8:33 AM, michael watson (IAH-C) wrote:
> Hi
>
> I did a google search on this and came up with nothing.
>
> OK, in the latest release of R for windows, I want to change the gui to
> SDI mode.
>
> Edit -> GUI preferences
> Choose SDI
> Apply
>
> I get the message about properties
You should save it to
C:\Program File\R\2.2.1\etc
Best,
Ales Ziberna
michael watson (IAH-C) pravi:
> Hi
>
> I did a google search on this and came up with nothing.
>
> OK, in the latest release of R for windows, I want to change the gui to
> SDI mode.
>
> Edit -> GUI preferences
> Choose SDI
Hi
I did a google search on this and came up with nothing.
OK, in the latest release of R for windows, I want to change the gui to
SDI mode.
Edit -> GUI preferences
Choose SDI
Apply
I get the message about properties not being able to be changed on a
running console, and that I need to save.
z.ch
Subject: Re: [R] ?bug? strange factors produced by chron
> On Mon, 13 Feb 2006, Petr Pikal wrote:
>
> > Thank you very much.
> >
> > On 13 Feb 2006 at 10:54, Prof Brian Ripley wrote:
> >
> > Date sent: Mon, 13 Feb 2006 10:54:21 + (GMT)
&
etr Pikal <[EMAIL PROTECTED]>
> Copies to:r-help@stat.math.ethz.ch
> Subject: Re: [R] ?bug? strange factors produced by chron
>
>> 1) The obvious test is via is.factor(), and you have not used that.
>
> I used it with TRUE result but did not use in
r-help@stat.math.ethz.ch
Subject: Re: [R] ?bug? strange factors produced by chron
> 1) The obvious test is via is.factor(), and you have not used that.
I used it with TRUE result but did not use in my post (mea culpa)
> is.factor(kvartaly)
[1] TRUE
> 2) Your example works for me,
1) The obvious test is via is.factor(), and you have not used that.
2) Your example works for me, so what versions of R and chron is this?
3) Here's my guess. split is using the C-level test isFactor. That tests
that the factor is of type integer, so please try
> typeof(kvartaly)
I suspect y
Hallo all
Please help me. I am lost and do not know what is the problem. I have
a factor called kvartaly.
> attributes(kvartaly)
$levels
[1] "1Q.04" "2Q.04" "3Q.04" "4Q.04" "1Q.05" "2Q.05" "3Q.05" "4Q.05"
$class
[1] "factor"
> mode(kvartaly)
[1] "numeric"
> str(kvartaly)
Factor w/ 8 levels "1Q.
Ken Termiso wrote:
> Hi all,
>
> When using heatmap() with a pdf driver, and specifying parameters for
> mai in heatmap, I get a printout of the mai parameters at the top of the
> pdf...see attachment.
>
> This is on win2k pro with R2.2.1
>
> Thanks,
> Ken
>
>
Not a bug since ?heatmap has
Hi all,
When using heatmap() with a pdf driver, and specifying parameters for mai in
heatmap, I get a printout of the mai parameters at the top of the pdf...see
attachment.
This is on win2k pro with R2.2.1
Thanks,
Ken
__
R-help@stat.math.ethz.ch m
I know it's conventional to report bugs to the maintainer, but I'm not sure
which package actually contains this bug(s), so I apologize for sending this
to the list at large. I see the bug under both R 2.1.1, and R 2.2.1. (I sent
a related message a while ago, but this one has more detail.)
lib
I see that I need to send my bug report to the package maintainer.
Apologies for sending it to this list. There's a lot to absorb from various
online pages when reporting a bug & I missed the part about sending to the
maintainer.
Peter
__
R-help@stat.m
There's a bug in my version of bootcov. I'm not sure whether to report it
here or in r-bugs, because it is in a contributed package. The bug is
straightforward, so perhaps it has been reported, tho I found no reference
in a search of the archive.
Any attempt to run bootcov with both cluster and
I suppose it is a bug in the documentation that it doesn't say it doesn't
work with dates (or Surv objects, or )
It works with factors and numbers.
-thomas
On Thu, 15 Dec 2005, ronggui wrote:
library(foreign)
da<-read.dta(file.choose())
da
startdat starttimenddate endt
> library(foreign)
> da<-read.dta(file.choose())
> da
startdat starttimenddate endtime days hoursmin secused
1 2005-01-112 2005-12-15 20.19 NA NA 9
> attributes(da)
$datalabel
[1] "Example of use of date and time functions"
$time.stamp
[1] "15 十二月 2005 20"
$names
IL PROTECTED]
Cc: R-help@stat.math.ethz.ch
Subject: [R] bug in geoR (?)
I've enconuntered this problem with the last cran version of geoR:
library(geoR)
day <- rep(1:2, each=5)
coords <- matrix(rep(runif(10),2), 10, 2)
data <- rnorm(10)
data[1] <- NA
as.geodata(cbind(coords, data,
I've enconuntered this problem with the last cran version of geoR:
> library(geoR)
> day <- rep(1:2, each=5)
> coords <- matrix(rep(runif(10),2), 10, 2)
> data <- rnorm(10)
> data[1] <- NA
> as.geodata(cbind(coords, data, day), realisations=4)
as.geodata: 1 points removed due to NA in the data
Err
On Mon, 2005-11-14 at 15:55 +0100, Karin Lagesen wrote:
> I have found a bug/feature with barplot that at least to me shows
> undesireable behaviour. When using barplot and plotting fewer
> groups/levels/factors(I am unsure what they are called) than the number
> of colors stated in a col statement
I have found a bug/feature with barplot that at least to me shows
undesireable behaviour. When using barplot and plotting fewer
groups/levels/factors(I am unsure what they are called) than the number
of colors stated in a col statement, the colors wrap around such that
the colors are not fixed to
>
>
>get.hist.quote(instrument="INR/USD", provider="oanda", start="2005-10-20")
>
>
>trying URL
>'http://www.oanda.com/convert/fxhistory?lang=en&date1=10%2F20%2F2005&date=11%2F01%2F2005&date_fmt=us&exch=INR&exch2=&expr=USD&expr2=&margin_fixed=0&&SUBMIT=Get+Table&format=ASCII&redirected=1'
>Conte
t; [EMAIL PROTECTED] On Behalf Of Ajay Shah
> Sent: Wednesday, November 02, 2005 5:09 AM
> To: r-help@stat.math.ethz.ch
> Subject: [R] Bug report on get.hist.quote
>
>
> > get.hist.quote(instrument="INR/USD", provider="oanda",
start="2005-10-
> 20&qu
> get.hist.quote(instrument="INR/USD", provider="oanda", start="2005-10-20")
trying URL
'http://www.oanda.com/convert/fxhistory?lang=en&date1=10%2F20%2F2005&date=11%2F01%2F2005&date_fmt=us&exch=INR&exch2=&expr=USD&expr2=&margin_fixed=0&&SUBMIT=Get+Table&format=ASCII&redirected=1'
Content type 'te
Yes, its a bug. The calls to axis.times in plot.times use the same
col variable as the points do. This shows it more compactly:
library(chron)
x <- seq.dates(from="09/30/2005", len = 10)
plot(x, 1:10, col = "red")
A workaround would be to plot the X axis separately:
plot(x, 1:10, col = "red",
kage would be to contact the
author/maintainer (Kurt) and not to file a bug in the main R bug
tracking system.
3. The problem with 'col.main' is I believe a result of this argument
being passed as part of the "..." arguments to plot.times(). Hence you
end up with partial mat
Thanks all for following up. I'll consider the bug "filed."
I should note for the record that if 'col="red"' is replaced in my
code by 'col.main="red"' the x axis is still made red.
I'll use the workaround for now (for which thanks). Even with little
things like this, plotting from the comm
Thanks for the code and the clarifications, including the PDF file.
Yes, I can replicate the behavior here (R 2.2.0 on FC4) and I am cc:ing
Kurt Hornik, who ported chron to R and is the chron package maintainer.
It appears that the "culprit" is the argument 'col = "red"', which
towards the end of
## Code was long, so I simplified it by creating vectors from scratch
so it would run as is. Putative "bug" is still evidenced on the x axis
discount.factors.dates <- seq.dates(from="09/30/2005", to="09/30/2035")
rates<-seq(4.4, 5.2, by=0.0025);
plot(discount.factors.dates[1:length(rates)], ra
On Tue, 2005-10-11 at 16:07 -1000, Parlamis Franklin wrote:
> I have observed the following behavior, wondering if it is a bug
> before I submit a report.
>
> I am using the plot function with call: plot(X, Y,
> col="red", . . . ) where X is an object that inherits from classes
> 'dates' an
I have observed the following behavior, wondering if it is a bug
before I submit a report.
I am using the plot function with call: plot(X, Y,
col="red", . . . ) where X is an object that inherits from classes
'dates' and 'times' (created with the 'dates' function from package
'chron') and
It is indeed a bug and I will address it.
On 9/30/05, Horacio Montenegro <[EMAIL PROTECTED]> wrote:
>
> Just to add more info:
>
> I've got the same error with both lme4 0.95-10 &
> Matrix 0.95-13 and lme4 0.98-1 & Matrix 0.98-7, always
> running on Win98SE, R 2.1.1. So it seems to occur w
Just to add more info:
I've got the same error with both lme4 0.95-10 &
Matrix 0.95-13 and lme4 0.98-1 & Matrix 0.98-7, always
running on Win98SE, R 2.1.1. So it seems to occur with
any Windows version.
cheers,
Horacio
>
> I'm putting the data and an R script up for FTP,
>
I am using version 0.98-7 of the Matrix package. I used the RGui
"Install Packages..." menu option to get the lme4 package from CRAN and
this version of the Matrix was automatically downloaded as well.
Martin Maechler wrote:
>>"Mark" == Mark Lyman <[EMAIL PROTECTED]>
>>on Thu, 29 Se
1 - 100 of 215 matches
Mail list logo
