[Rd] read.table with ":" in column names (PR#8511)
Full_Name: emiel ver loren
Version: 2.2.0
OS: Windows XP
Submission from: (NULL) (145.117.31.248)
Dear R-community and developers,
I have been trying to read in a tab delimeted file where the column names and
the row names are of the form "GO:051" (gene ontology IDs). When using:
> gomat<-read.table("test.txt")
> colnames(gomat)[1]
[1] "GO.051"
> rownames(gomat)[1]
[1] "GO:002"
Which means that ":" is transformed into a "." !! This seems like Excel when it
is trying to guess what I am really ment (and turning 1/1/1 into 1-1-2001).
Furthermore, I found the following quite strange as well:
> gomat2<-read.delim2("test.txt",header=FALSE)
> gomat2[1,1:2]
V1 V2
1 GO:051 GO:280
> as.character(gomat2[1,1:2])
[1] "8" "2"
> as.character(gomat2[1,1])
[1] "GO:051"
I have found a way to work around it, but I am wandering what's happening
The tab-delimited file look like:
GO:051 GO:280 GO:740
GO:002 0 0 0
GO:004 0 0 0
GO:012 0 0 0
GO:014 0 0 0
GO:015 0 0 0
GO:018 0 0 0
GO:019 0 0 0
Thanks for helping, and
Emiel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] read.table with ":" in column names (PR#8511)
Please do not report documented behaviour as a bug!
See the 'check.names' argument to read.table.
In your second example you are applying as.character to a data frame, and
you seem not to realize that. We specifically ask you NOT to use R-bugs
to ask questions. (What is happening is that you got the internal codes
of the factor columns, which is not what you intended. If you want
character columns, read them as such.)
On Fri, 20 Jan 2006 [EMAIL PROTECTED] wrote:
> Full_Name: emiel ver loren
> Version: 2.2.0
We do ask you not to send reports on obselete versions of R.
> OS: Windows XP
> Submission from: (NULL) (145.117.31.248)
>
>
> Dear R-community and developers,
>
> I have been trying to read in a tab delimeted file where the column names and
> the row names are of the form "GO:051" (gene ontology IDs). When using:
>
>> gomat<-read.table("test.txt")
>> colnames(gomat)[1]
> [1] "GO.051"
>> rownames(gomat)[1]
> [1] "GO:002"
>
> Which means that ":" is transformed into a "." !! This seems like Excel when
> it
> is trying to guess what I am really ment (and turning 1/1/1 into 1-1-2001).
>
> Furthermore, I found the following quite strange as well:
>
>> gomat2<-read.delim2("test.txt",header=FALSE)
>> gomat2[1,1:2]
> V1 V2
> 1 GO:051 GO:280
>> as.character(gomat2[1,1:2])
> [1] "8" "2"
>> as.character(gomat2[1,1])
> [1] "GO:051"
>
> I have found a way to work around it, but I am wandering what's happening
>
> The tab-delimited file look like:
>
> GO:051GO:280 GO:740
> GO:0020 0 0
> GO:0040 0 0
> GO:0120 0 0
> GO:0140 0 0
> GO:0150 0 0
> GO:0180 0 0
> GO:0190 0 0
>
> Thanks for helping, and
>
> Emiel
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] read.table with ":" in column names (PR#8511)
[EMAIL PROTECTED] writes:
> Full_Name: emiel ver loren
> Version: 2.2.0
> OS: Windows XP
> Submission from: (NULL) (145.117.31.248)
>
>
> Dear R-community and developers,
>
> I have been trying to read in a tab delimeted file where the column names and
> the row names are of the form "GO:051" (gene ontology IDs). When using:
>
> > gomat<-read.table("test.txt")
> > colnames(gomat)[1]
> [1] "GO.051"
> > rownames(gomat)[1]
> [1] "GO:002"
>
> Which means that ":" is transformed into a "." !! This seems like Excel when
> it
> is trying to guess what I am really ment (and turning 1/1/1 into 1-1-2001).
This is what check.names=FALSE is for... (and NOT a bug, please don't
abuse the bug repository, use the mailing lists)
> Furthermore, I found the following quite strange as well:
>
> > gomat2<-read.delim2("test.txt",header=FALSE)
> > gomat2[1,1:2]
> V1 V2
> 1 GO:051 GO:280
> > as.character(gomat2[1,1:2])
> [1] "8" "2"
> > as.character(gomat2[1,1])
> [1] "GO:051"
>
> I have found a way to work around it, but I am wandering what's happening
Yes, this is a bit nasty, but... What is happening is similar to this:
> d <- data.frame(a=factor(LETTERS), b=factor(letters))
> d[1,]
a b
1 A a
> as.character(d[1,])
[1] "1" "1"
> as.character(d[1,1])
[1] "A"
> as.character(d[1,1,drop=F])
[1] "1"
or this:
> l <- list(a=factor("x"),b=factor("y"))
> l
$a
[1] x
Levels: x
$b
[1] y
Levels: y
> as.character(l)
[1] "1" "1"
The thing is that as.character on a list will first coerce factors to
numeric, then numeric to character. I'm not sure whether there could
be a rationale for it, but it isn't S-PLUS compatible (not 6.2.1
anyway, which is the most recent one that I have access to).
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] read.table with ":" in column names (PR#8511)
On Fri, 20 Jan 2006 [EMAIL PROTECTED] wrote:
> Full_Name: emiel ver loren
> Version: 2.2.0
> OS: Windows XP
> Submission from: (NULL) (145.117.31.248)
>
>
> Dear R-community and developers,
>
> I have been trying to read in a tab delimeted file where the column names and
> the row names are of the form "GO:051" (gene ontology IDs). When using:
>
> > gomat<-read.table("test.txt")
> > colnames(gomat)[1]
> [1] "GO.051"
> > rownames(gomat)[1]
> [1] "GO:002"
>
> Which means that ":" is transformed into a "." !! This seems like Excel when
> it
> is trying to guess what I am really ment (and turning 1/1/1 into 1-1-2001).
Wrong.
?read.table says with reference to the check.names = TRUE argument that:
"check.names: logical. If 'TRUE' then the names of the variables in the
data frame are checked to ensure that they are syntactically
valid variable names. If necessary they are adjusted (by
'make.names') so that they are, and also to ensure that there
are no duplicates."
> make.names("GO:051")
[1] "GO.051"
You can use "GO:051" as a column name if quoted, otherwise ":" is an
operator, so the default value of the check.names argument is sound.
If you "ment" to do what you say, you should have set check.names=FALSE.
>
> Furthermore, I found the following quite strange as well:
>
> > gomat2<-read.delim2("test.txt",header=FALSE)
> > gomat2[1,1:2]
> V1 V2
> 1 GO:051 GO:280
> > as.character(gomat2[1,1:2])
> [1] "8" "2"
> > as.character(gomat2[1,1])
> [1] "GO:051"
>
> I have found a way to work around it, but I am wandering what's happening
>
> The tab-delimited file look like:
>
> GO:051GO:280 GO:740
> GO:0020 0 0
> GO:0040 0 0
> GO:0120 0 0
> GO:0140 0 0
> GO:0150 0 0
> GO:0180 0 0
> GO:0190 0 0
>
> Thanks for helping, and
>
> Emiel
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: [EMAIL PROTECTED]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] read.table with ":" in column names (PR#8511)
[EMAIL PROTECTED] writes: > On Fri, 20 Jan 2006 [EMAIL PROTECTED] wrote: > > > Full_Name: emiel ver loren > > Version: 2.2.0 > > We do ask you not to send reports on obselete versions of R. Well, we might forgive that (please at least check against the current NEWS file), but USING FAKE EMAIL ADDRESSES ON BUG REPORTS IS BLOODY UNFORGIVEABLE! G -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] as.character on list (was read.table with ":" in column names)
On Fri, 20 Jan 2006, Peter Dalgaard wrote:
[...]
> Yes, this is a bit nasty, but... What is happening is similar to this:
>
>> d <- data.frame(a=factor(LETTERS), b=factor(letters))
>> d[1,]
> a b
> 1 A a
>> as.character(d[1,])
> [1] "1" "1"
>> as.character(d[1,1])
> [1] "A"
>> as.character(d[1,1,drop=F])
> [1] "1"
>
> or this:
>
>> l <- list(a=factor("x"),b=factor("y"))
>> l
> $a
> [1] x
> Levels: x
>
> $b
> [1] y
> Levels: y
>
>> as.character(l)
> [1] "1" "1"
>
> The thing is that as.character on a list will first coerce factors to
> numeric, then numeric to character.
Nope. It just coerces an INTSXP to a STRSXP. as.character (and all other
forms of coercion that I can think of quickly) ignores classes except when
initially dispatching.
Note that these examples are special cases:
> as.character(d[1:2,])
[1] "c(1, 2)" "c(1, 2)"
may also be unexpected but follows from the general (undocumented, I
dare say) rules.
> I'm not sure whether there could be a rationale for it, but it isn't
> S-PLUS compatible (not 6.2.1 anyway, which is the most recent one that I
> have access to).
My S-PLUS deparses:
> l <- list(a=factor("x"),b=factor("y"))
> as.character(l)
[1] "structure(.Data = 1, .Label = \"x\", class = \"factor\")"
[2] "structure(.Data = 1, .Label = \"y\", class = \"factor\")"
which seems no better (and probably worse).
The only other consistent option I can see is for all coercion methods to
dispatch at each element of a recursive object, which I suspect introduces
a considerable overhead for very little gain.
One could perhaps argue for a data.frame method, since coercion operations
on dataframes are rare and that is a case where people get factors where
they wanted character columns.
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] as.character on list (was read.table with ":" in column names)
Prof Brian Ripley <[EMAIL PROTECTED]> writes:
> > The thing is that as.character on a list will first coerce factors to
> > numeric, then numeric to character.
>
> Nope. It just coerces an INTSXP to a STRSXP. as.character (and all
> other forms of coercion that I can think of quickly) ignores classes
> except when initially dispatching.
OK. I just meant that "de facto" it is like as.character(as.integer(f))
> Note that these examples are special cases:
>
> > as.character(d[1:2,])
> [1] "c(1, 2)" "c(1, 2)"
>
> may also be unexpected but follows from the general (undocumented, I
> dare say) rules.
and unlike as.character(as.integer(f)), so I do stand corrected
> > I'm not sure whether there could be a rationale for it, but it isn't
> > S-PLUS compatible (not 6.2.1 anyway, which is the most recent one
> > that I have access to).
>
> My S-PLUS deparses:
>
> > l <- list(a=factor("x"),b=factor("y"))
> > as.character(l)
> [1] "structure(.Data = 1, .Label = \"x\", class = \"factor\")"
> [2] "structure(.Data = 1, .Label = \"y\", class = \"factor\")"
>
> which seems no better (and probably worse).
Same here. Arguably, we deparse too, we just discard attributes first.
Both S-PLUS and R will do
> as.character(list(a=1:5,b=3))
[1] "c(1, 2, 3, 4, 5)" "3"
> The only other consistent option I can see is for all coercion methods
> to dispatch at each element of a recursive object, which I suspect
> introduces a considerable overhead for very little gain.
Then again maybe not, but it is one of those things which have the
potential to break things in unexpected places if you change it.
> One could perhaps argue for a data.frame method, since coercion
> operations on dataframes are rare and that is a case where people get
> factors where they wanted character columns.
Agreed.
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] par(mfg=) and postscript and pdf
On Fri, 2006-01-20 at 07:47 +, Prof Brian Ripley wrote: > This is related to the incorrect bug report PR#7820. Marc Schwartz > pointed out in > > https://stat.ethz.ch/pipermail/r-devel/2005-April/033016.html > > an example of a real problem. If you call par(mfg=) after par(mfrow) (or > mfcol) and before you have done any plotting, NewPage is not called on the > device at the start of the first page. That causes the DSC comments to be > incorrect on postscript() and much worse on pdf(). > > You would get the same effect by calling par(new=T) before plot.new() is > called, except that is disallowed. par(mfg=) does set new=T internally, > and also sets the plot number to a valid one, both of which inhibit > calling NewPage. I've managed to overcome this by ensuring that > GNewPage always calls NewPage on an unused device (there is an internal > 'state' variable which records the latter). > > This is safe in the sense that the worst it could do is to produce an > unwanted new page. I can't see how this could happen but the design of > the internals of base graphics is very complicated and undocumented, so I > am only putting the change in R-devel (along with fixes to the > long-standing graphics bugs PR#1235 and PR#2630). Prof. Ripley, Thanks for your follow up on this issue. Your efforts in resolution are greatly appreciated. Best regards, Marc Schwartz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] read.table with ":" in column names (PR#8511)
in my view it's not always good to get this answer, but your "problem" is not too deeply hidden in the manpages, so simply read the documentation of read.table: ?read.table (and look out for the "check.names" flag) regards, joerg __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check, NAMESPACE, import: bad error?
On 19 Jan 2006, [EMAIL PROTECTED] wrote: > We do recommend you try INSTALLing and loading the package before R > CMD check. The most common problem I have found is that the DSO/DLL > cannot be loaded, and there loading will give a more extensive error > message. Yes, the package INSTALLs and loads just fine. Actually, one sees the same error message for a package without a DSO/DLL... But DSO/DLL loading does seem to be related. I'm only seeing the issue when the package that is imported contains a DSO/DLL. I've created two versions of a very simple 'hello world' package. The first imports RUnit and passes check. The second imports Biobase and does not pass check. http://bioconductor.fhcrc.org/developers/examples/ Perhaps someone can see if they see the same thing and/or point out an error in my package setup. R.version _ platform powerpc-apple-darwin8.4.0 arch powerpc os darwin8.4.0 system powerpc, darwin8.4.0 status Under development (unstable) major 2 minor 3.0 year 2006 month 01 day15 svn rev37092 language R version.string Version 2.3.0 Under development (unstable) (2006-01-15 r37092) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Troubles with the function rmultinom.c of the R's Random Number Generator
Hi,
I'm simulating a Markov chain in Fortran interfaced with R-2.2.1 in order
to generate data according to a Markov Random Field called the Potts model.
R Version:
platform i686-pc-linux-gnu
arch i686
os linux-gnu
system i686, linux-gnu
status
major2
minor2.1
year 2005
month12
day 20
svn rev 36812
Each loop of my Fortran calls the function rmultinom.c of the R's Random
Number Generator through the wrapper:
#include
#include
void F77_SUB(sarmultinom)(int n,
double* prob,
int K,
int* rN){
rmultinom(n, prob, K, rN);}
My fortran program is:
subroutine testsarmultinom(n,prob,K,rN)
implicit none
integer n,K,rN(K)
double precision prob(K)
call rndstart()
call sarmultinom(n,prob,K,rN)
call rndend()
end
In order to understand better how the function rmultinom.c works, I have
written an R code which calls this fortran subroutine as follows:
system("R CMD SHLIB test-multinom.f wrapper.c")
dyn.load("~/Package/test/test-multinom.so")
n=1
prob=c(0.6,0.1,0.3)
K=3
rN=c(1,0,0)
res<- .Fortran("testsarmultinom",
as.integer(n),
as.double(prob),
as.integer(K),
as.integer(rN))
Unfortunately, I have some trouble with the results. First, this command
always returns 0 values. In other words, I always get:
>res[[4]]
[1] 0 0 0
Moreover, if I run this R code a second time, an error message appears:
Segmentation fault.
Has somebody ever used rmultinom.c and encountered these problems? My code
must be wrong but I don't know where. In this case, what is the correct way
to call the C function rmultinom.c?
Thanks in advance,
Sophie.
Sophie Ancelet
ENGREF
Laboratoire Grese
19 avenue du Maine
75 732 Paris Cedex 15
France
tel: 33 1 45 49 89 27
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Troubles with Fortran and C (was with the function rmultinom.c of the R's Random Number Generator)
All arguments to functions called from C by Fortran are pointers
(or should be: yours are not). The error is within your own code.
You don't want to call rndstart and rndend around every call, only before
the first and after the last.
This is not the list for advice om mixed Fortran/C programming, though.
On Fri, 20 Jan 2006, Sophie Ancelet wrote:
>
> Hi,
>
> I'm simulating a Markov chain in Fortran interfaced with R-2.2.1 in order
> to generate data according to a Markov Random Field called the Potts model.
>
> R Version:
> platform i686-pc-linux-gnu
> arch i686
> os linux-gnu
> system i686, linux-gnu
> status
> major2
> minor2.1
> year 2005
> month12
> day 20
> svn rev 36812
>
>
>
>
> Each loop of my Fortran calls the function rmultinom.c of the R's Random
> Number Generator through the wrapper:
>
> #include
> #include
> void F77_SUB(sarmultinom)(int n,
> double* prob,
> int K,
> int* rN){
> rmultinom(n, prob, K, rN);}
>
>
>
> My fortran program is:
>
> subroutine testsarmultinom(n,prob,K,rN)
> implicit none
> integer n,K,rN(K)
> double precision prob(K)
>
> call rndstart()
> call sarmultinom(n,prob,K,rN)
> call rndend()
> end
>
>
> In order to understand better how the function rmultinom.c works, I have
> written an R code which calls this fortran subroutine as follows:
>
> system("R CMD SHLIB test-multinom.f wrapper.c")
> dyn.load("~/Package/test/test-multinom.so")
>
> n=1
> prob=c(0.6,0.1,0.3)
> K=3
> rN=c(1,0,0)
> res<- .Fortran("testsarmultinom",
> as.integer(n),
> as.double(prob),
> as.integer(K),
> as.integer(rN))
>
>
> Unfortunately, I have some trouble with the results. First, this command
> always returns 0 values. In other words, I always get:
>
>> res[[4]]
> [1] 0 0 0
>
>
> Moreover, if I run this R code a second time, an error message appears:
> Segmentation fault.
>
> Has somebody ever used rmultinom.c and encountered these problems? My code
> must be wrong but I don't know where. In this case, what is the correct way
> to call the C function rmultinom.c?
>
> Thanks in advance,
>
> Sophie.
>
>
>
>
> Sophie Ancelet
> ENGREF
> Laboratoire Grese
> 19 avenue du Maine
> 75 732 Paris Cedex 15
> France
> tel: 33 1 45 49 89 27
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] cron job install/update problems: tcltk can't find display (installing e.g., pbatR)
This really is an R-devel question, so moved there. (Just what would you use R-devel for?) On Fri, 20 Jan 2006, Paul Johnson wrote: > On Fedora Core Linux 4, I have a cron job that causes R to update all > packages and install new ones. Lately, I notice in the log that some > packages fail to install. These are ones that assume X is running. > For example, the pbatR install requires tcltk to be loaded, and then > the install fails because in a cron job, there is no DISPLAY > environment. I suppose the same happens if you try to install R > packages in the console, without X running? Yes. At least for tcltk this is solved in R-devel, so it will start without X11. Some of your `black list' will work if you update your gcc to the current version (4.0.2). > Error output is pasted here. I wonder if you can advise me whether > this is the kind of thing that can be fixed in the cron job or not. Yes, if you run an X server (e.g. Xvfb) to which a cron job has access. > I've verified that pbatR does install interactively (because tcltk > does start). If you think this is a pbatR-specific problem, i will > contact the author directly. When I have the repos option set, the > interactive install does not cause any tcltk widgets to pop up, so I > wonder if it is really necessary. It is unreasonable that some packages expect X11 to be running to be installed or checked. So if the issue is not tcltk, please complain to the maintainer(s). -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Problem loading package with version, S4 classes and NAMESPACE
I've run into a problem that I hope has an obvious solution. The sp
package uses S4 classes and has a NAMESPACE, and when installed without
package versions, runs OK, passes R CMD check, and so on.
A user reported that he installed it --with-package-versions, and that
from then on it would fail at first use of a class defined in the package.
I've reconstructed the problem in a skeletal package:
http://reclus.nhh.no/R/etc/S4nswv_0.1-1.tar.gz
which when installed without versions works:
$ R CMD INSTALL S4nswv
$ R
...
> library(S4nswv)
> sessionInfo()
R version 2.2.1, 2005-12-20, i686-pc-linux-gnu
attached base packages:
[1] "methods" "stats" "graphics" "grDevices" "utils" "datasets"
[7] "base"
other attached packages:
S4nswv
"0.1-1"
> xyd <- new("xyloc", x=runif(20), y=runif(20))
> xyd
x y res
[1,] 0.01589694 0.935594239 -0.91969730
[2,] 0.56974225 0.120906481 0.44883577
...
but fails after INSTALL --with-package-versions S4nswv
> library(S4nswv)
> sessionInfo()
R version 2.2.1, 2005-12-20, i686-pc-linux-gnu
attached base packages:
[1] "methods" "stats" "graphics" "grDevices" "utils"
"datasets"
[7] "base"
other attached packages:
S4nswv_0.1-1
"0.1-1"
> xyd <- new("xyloc", x=runif(20), y=runif(20))
Error in as.environment(pkg) : no item called "package:S4nswv" on the
search list
Error in initialize(value, ...) : S language method selection got an error
when called from internal dispatch for function 'initialize'
> traceback()
2: initialize(value, ...)
1: new("xyloc", x = runif(20), y = runif(20))
This suggests that "package:S4nswv" and its versioned equivalent are not
being associated, and I'd be grateful for pointers about how to do this.
Removing the NAMESPACE, and uncommenting .First.lib() in R/zzz.R removes
the problem, that is the skeletal package works --with-package-versions,
but this isn't an option.
At present, the methods package is invoked in DESCRIPTION in the Depends:
field, by "import(methods)" in NAMESPACE, and by
.onLoad <- function(lib, pkg) require(methods)
in zzz.R, which feels like overkill, but removing them one-by-one doesn't
seem to affect the problem.
(I don't think this is the same problem as Seth's)
Roger
--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: [EMAIL PROTECTED]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem loading package with version, S4 classes and NAMESPACE
On Fri, 20 Jan 2006, Roger Bivand wrote:
> I've run into a problem that I hope has an obvious solution. The sp
> package uses S4 classes and has a NAMESPACE, and when installed without
> package versions, runs OK, passes R CMD check, and so on.
>
> A user reported that he installed it --with-package-versions, and that
> from then on it would fail at first use of a class defined in the package.
Further to my question, hardcoding the package= argument to the versioned
package name string in setClass() removes the problem when installing with
versions (for that version), but creates the reverse problem if installed
(by default) without versions:
> library(S4nswv)
> xyd <- new("xyloc", x=runif(20), y=runif(20))
Loading required package: S4nswv_0.1-1
Error in .requirePackage(package) : unable to find required package
'S4nswv_0.1-1'
In addition: Warning message:
there is no package called 'S4nswv', version 0.1-1 in: library(package,
character.only = TRUE, logical = TRUE, warn.conflicts = warn.conflicts,
Error in initialize(value, ...) : S language method selection got an error
when called from internal dispatch for function 'initialize'
The default for the package argument is getPackageName(where), and where =
topenv(parent.frame()). There are comments in methods/R/packageName.R
suggesting that the hidden object .packageName is being made invisible by
NAMESPACE.
It looks as though R_PACKAGE_NAME as a shell variable could be used to
smuggle the correct string in, but I'm not sure what order things happen
in.
>
> I've reconstructed the problem in a skeletal package:
>
> http://reclus.nhh.no/R/etc/S4nswv_0.1-1.tar.gz
>
> which when installed without versions works:
>
> $ R CMD INSTALL S4nswv
> $ R
> ...
> > library(S4nswv)
> > sessionInfo()
> R version 2.2.1, 2005-12-20, i686-pc-linux-gnu
>
> attached base packages:
> [1] "methods" "stats" "graphics" "grDevices" "utils" "datasets"
> [7] "base"
>
> other attached packages:
> S4nswv
> "0.1-1"
> > xyd <- new("xyloc", x=runif(20), y=runif(20))
> > xyd
>x y res
> [1,] 0.01589694 0.935594239 -0.91969730
> [2,] 0.56974225 0.120906481 0.44883577
> ...
>
> but fails after INSTALL --with-package-versions S4nswv
>
> > library(S4nswv)
> > sessionInfo()
> R version 2.2.1, 2005-12-20, i686-pc-linux-gnu
>
> attached base packages:
> [1] "methods" "stats" "graphics" "grDevices" "utils"
> "datasets"
> [7] "base"
>
> other attached packages:
> S4nswv_0.1-1
> "0.1-1"
> > xyd <- new("xyloc", x=runif(20), y=runif(20))
> Error in as.environment(pkg) : no item called "package:S4nswv" on the
> search list
> Error in initialize(value, ...) : S language method selection got an error
> when called from internal dispatch for function 'initialize'
> > traceback()
> 2: initialize(value, ...)
> 1: new("xyloc", x = runif(20), y = runif(20))
>
> This suggests that "package:S4nswv" and its versioned equivalent are not
> being associated, and I'd be grateful for pointers about how to do this.
>
> Removing the NAMESPACE, and uncommenting .First.lib() in R/zzz.R removes
> the problem, that is the skeletal package works --with-package-versions,
> but this isn't an option.
>
> At present, the methods package is invoked in DESCRIPTION in the Depends:
> field, by "import(methods)" in NAMESPACE, and by
>
> .onLoad <- function(lib, pkg) require(methods)
>
> in zzz.R, which feels like overkill, but removing them one-by-one doesn't
> seem to affect the problem.
>
> (I don't think this is the same problem as Seth's)
>
> Roger
>
>
--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: [EMAIL PROTECTED]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Minumum memory requirements to run R.
Prof Brian Ripley wrote: > Quite a while back we set the goal of running R in 16Mb RAM, as people (I > think Kjetil) had teaching labs that small. It's a while since I actually har R used on such small machines, I think 64 MB is quite acceptable now. Kjetil > > Since then R has grown, and we has recently started to optimize R for > speed rather than size. I recently tested R-devel on my ancient Win98 > notebook with 64Mb RAM -- it ran but startup was rather slow on what I > think is a 233MHz processor and very slow disc. > > R still runs in 16Mb, but that is getting tight. Does anyone have any > need to run on a smaller machine than my 64Mb notebook? > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] nls profiling with algorithm="port" may violate bounds (PR#8508)
Hi, Ben, et al.:
The issue Ben identified with confint(nls(... )) generates a hard
failure for me. Specifically the command "confint(m1)" in his script
below under Rgui 2.2.1 first says, "Waiting for profiling to be done..."
then forces a screen to pop up with heading "R for Windows GUI
front-end" reading, "R for Windows GUI front-end has encountered a
problem and needs to close. We are sorry for the inconvenience. If you
were in the middle of something, the information you were working on
might be lost... ." When I try the same thing running R under XEmacs
with ESS, I get essentially the same response, exceppt "R for Windows
GUI" is replaced by "R for Windows terminal". In both cases, it kills
R. In both cases, sessionInfo() before this command is as follows:
> sessionInfo()
R version 2.2.1, 2005-12-20, i386-pc-mingw32
attached base packages:
[1] "stats4""methods" "stats" "graphics" "grDevices" "utils"
[7] "datasets" "base"
I'm running Windows XP professional version 5.1 on an IBM T30
notebook computer.
Thanks to all of the R Core team for all your hard work to make R
what it is today, with these kinds of unpleasant surprises to rare.
Best Wishes,
spencer graves
[EMAIL PROTECTED] wrote:
> [posted to R-devel, no discussion:
> resubmitting it as a bug, just so it gets
> logged appropriately]
>
>Sorry to report further difficulties with
> nls and profiling and constraints ... the problem
> this time (which I didn't check for in my last
> round of testing) is that the nls profiler doesn't
> seem to respect constraints that have been
> set when using the port algorithm.
> See test code below ...
> If I can I will try to hack the code, but I will
> probably start by redefining my function with
> some workarounds to make the fit quadratically "bad" (but well-defined)
> when the parameters are negative ...
> As always, please don't hesitate to correct me
> if I'm being an idiot ...
>
> cheers
> Ben Bolker
>
> ---
> rm(list=ls())
>
> npts=10
> set.seed(1001)
>
> a =2
> b =0.5
> x= runif(npts)
> y = a*x/(1+a*b*x)+rnorm(npts,sd=0.2)
>
> gfun <- function(a,b,x) {
> if (a<0 || b<0) stop("bounds violated")
> a*x/(1+a*b*x)
> }
>
> m1 = nls(y~gfun(a,b,x),algorithm="port",
> lower=c(0,0),start=c(a=1,b=1))
>
> try(confint(m1))
>
>
> for what it's worth, the logic appears to be OK in mle in the stats4
> library:
> --
> library(stats4)
>
> mfun <- function(a,b,s) {
> if (a<0 || b<0 || s<0) stop("bounds violated")
> -sum(dnorm(y,a*x/(1+a*b*x),sd=s,log=TRUE))
> }
>
> m2 = mle(minuslogl=mfun,
> start=list(a=1,b=1,s=0.1),
> method="L-BFGS-B",lower=c(0.002,0.002,0.002))
>
> confint(m2)
>
> m2b = mle(minuslogl=mfun,
> fixed=list(b=0),start=list(a=1,s=0.1),
> method="L-BFGS-B",lower=c(0.002,0.002,0.002))
> ## set boundary slightly above zero to avoid
> ## boundary cases
>
> dev <- 2*(-logLik(m2b)+logLik(m2))
> as.numeric(pchisq(dev,lower.tail=FALSE,df=1))
>
> __
> 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
Re: [Rd] Minumum memory requirements to run R.
From: Kjetil Brinchmann Halvorsen > > Prof Brian Ripley wrote: > > Quite a while back we set the goal of running R in 16Mb > RAM, as people (I > > think Kjetil) had teaching labs that small. > > It's a while since I actually har R used on such small > machines, I think > 64 MB is quite acceptable now. > > Kjetil > > > > > Since then R has grown, and we has recently started to > optimize R for > > speed rather than size. I recently tested R-devel on my > ancient Win98 > > notebook with 64Mb RAM -- it ran but startup was rather > slow on what I > > think is a 233MHz processor and very slow disc. > > > > R still runs in 16Mb, but that is getting tight. Does > anyone have any > > need to run on a smaller machine than my 64Mb notebook? I sure don't, but I wouldn't be surprised if one of these days someone figures out how to get R to run on a video card... (I recall that there was a tutorial session at some datamining conference last year that showed people how to use the GPU for numerical computation, so this may not be too far fetched.) Andy __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
