[Rd] nls fails to return correlation matrix (PR#8127)
Full_Name: Carsten Urbach Version: 2.1.1 (2005-06-20) OS: Linux Submission from: (NULL) (141.34.5.241) I observed one case where nls failed to return the correlation matrix, while the parameter estimates were computed correctly. In the follwing I include all the commands leading to this problem. R was started with 'R --vanilla': > version _ platform i686-pc-linux-gnu arch i686 os linux-gnu system i686, linux-gnu status major2 minor1.1 year 2005 month06 day 20 language R > data <- read.table(file="zp.dat", header=F) > data V1 V2 V3 V4 1 4 5.6791 0.80709 0.00094 2 6 5.8636 0.71202 0.00083 3 8 6.0219 0.67844 0.00139 4 10 6.1628 0.65797 0.00130 5 12 6.2885 0.64604 0.00119 6 16 6.4956 0.63047 0.00112 > df <- data.frame(x=data$V2-6, y=data$V3) > df x y 1 -0.3209 0.80709 2 -0.1364 0.71202 3 0.0219 0.67844 4 0.1628 0.65797 5 0.2885 0.64604 6 0.4956 0.63047 > fit4 <- nls(y ~ a+b*x+c*x^2+d*x^3+e*x^4, data = df, start = list(a = 1., b = -1., c = 1., d=-1., e=1.)) > summary(fit4) Formula: y ~ a + b * x + c * x^2 + d * x^3 + e * x^4 Parameters: Estimate Std. Error t value Pr(>|t|) a 0.680936 0.001327 513.002 0.00124 ** b -0.168167 0.010660 -15.775 0.04030 * c 0.325593 0.047433 6.864 0.09210 . d -0.860767 0.117710 -7.313 0.08652 . e 0.957177 0.319101 3.000 0.20486 --- Signif. codes: 0 *** 0.001 ** 0.01 * 0.05 . 0.1 1 Residual standard error: 0.001722 on 1 degrees of freedom Correlation of Parameter Estimates: a b c d b 1 c , , 1 d * , 1 e . , * * attr(,"legend") [1] 0 0.3 . 0.6 , 0.8 + 0.9 * 0.95 B 1 > fit4 Nonlinear regression model model: y ~ a + b * x + c * x^2 + d * x^3 + e * x^4 data: df a b c d e 0.6809363 -0.1681674 0.3255929 -0.8607670 0.9571768 residual sum-of-squares: 2.966569e-06 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wishlist: write.delim()
> "Douglas" == Douglas Grove <[EMAIL PROTECTED]>
> on Thu, 8 Sep 2005 15:33:02 -0700 (PDT) writes:
Douglas> Hi,
Douglas> It would be great if someone would add write.delim() as an
Douglas> adjunct to write.table(), just as with write.csv().
Douglas> I store a lot of data in tab-delimited files and can read
Douglas> it in easily with: read.delim("text.txt", as.is=TRUE)
Douglas> and would love to be able to write it out as easily when
Douglas> I create these files.
Douglas> The obvious setting needed for write.delim() is sep = "\t",
Douglas> but in addition I would request the setting row.names = FALSE
Douglas> i.e.
Douglas> write.delim(x, file) = write.table(x, file, sep = "\t",
row.names=FALSE)
i.e.,
write.delim <- function(x, file, ...)
write.table(x, file, sep = "\t", row.names=FALSE, ...)
So, why don't you just add that one line to your .Rprofile ?
In general, I don't think that it's worth to introduce a whole
new function just because of some frequent argument use of an
already existing function {{and I have wondered if it was worth
to provide write.csv() at all - although, there the difference to default
write.table() is quite a bit larger}}
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] nls fails to return correlation matrix (PR#8127)
[EMAIL PROTECTED] writes: > Full_Name: Carsten Urbach > Version: 2.1.1 (2005-06-20) > OS: Linux > Submission from: (NULL) (141.34.5.241) > > > I observed one case where nls failed to return the correlation matrix, while > the > parameter estimates were computed correctly. In the follwing I include all the > commands leading to this problem. R was started with 'R --vanilla': . > > Residual standard error: 0.001722 on 1 degrees of freedom > > Correlation of Parameter Estimates: > a b c d > b 1 > c , , 1 > d * , 1 > e . , * * > attr(,"legend") > [1] 0 0.3 . 0.6 , 0.8 + 0.9 * 0.95 B 1 And the problem was??? You may not like the graphical representation, but it is not a bug. Just use print(summary(fit),symbolic.cor=FALSE) to get rid of it. -- 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] [R] Debugging R/Fortran in Windows
[Moved from R-help] James Wettenhall wrote: > Hi, > > I'm trying to debug an R interface to a Fortran subroutine from Windows. > (Yes, I know I should try Unix/Linux as well, but a quick attempt > suggested that the (MinGW g77) Fortran compiler I have installed on my > Windows laptop works better on this Fortran code.) > > I'm trying to follow the instructions in the "Writing R Extensions" Manual: > > Start R under the debugger after setting a breakpoint for WinMain. > gdb .../bin/Rgui.exe > (gdb) break WinMain > (gdb) run > > But when I run gdb on Rgui.exe, I get the message: > "no debugging symbols found" > and then when I try "break WinMain", I get: > "No symbol table is loaded. use the 'file' command." You can also start R normally, load your dll by attaching the package, then click on Misc | Break to debugger. This assumes you have debugging symbols in your DLL, and have gdb set up properly; see http://www.stats.uwo.ca/faculty/murdoch/software/debuggingR for more details. Duncan Murdoch > > I'm using R 2.1.1 on Windows 2000 and gdb 5.2.1 from MSys's MinGW. > > I'm calling a Fortran function (several times) from R. And I seem to have > the basic two-way data communication working - I appear to have > succesfully passed all required data types (integer, real, double > precision) to and from Fortran with sensible results both from within R > and from using WRITE(FILENUM,*) from within Fortran. But unfortunately > there is still evidence of memory leakage. > > Any suggestions would be greatly appreciated. > > Regards, > James > > __ > R-help@stat.math.ethz.ch mailing list > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] C macros and Makevars/package building
> Kasper Daniel Hansen writes: > Hi > We are currently embedding a rather large C++ library in R (BioC), > and we want some comments on the portability of how we have approach > this. > First of, we are not really able to do much about the portability of > the basic library, which of course is the main question :) We have an > approach which seems to work, I just want a bit of feedback on it > The way we integrate it into R is simply by having a subdirectory / > src/sdk together with a Makevars file. This file basically looks like > PKG_CPPFLAGS+=\ >-imacros R_affx_constants.h\ >-Isdk/files\ > (... + a lot of other -I statements telling CPP to include > subdirectories of src/sdk) > Then we have a > SOURCES.SDK = \ >sdk/files/FileIO.cpp \ >(... + a lot of other .cpp files) > SOURCES.OURS = \ >R_affx_cdf.cpp > and then finally a > OBJS=$(SOURCES.SDK:.cpp=.o) $(SOURCES.OURS:cpp:.o) > We seem to need the last statement since it seems that .cpp is not > automatically a C++ suffix (but is it done the "right" way for > portability?). We need the -imacro statement in order to include some > macros from Rconfig.h (big endian checks) which are then translated > from the WORDS_BIGENDIAN used in R to the IS_BIG_ENDIAN used in the > library. > Comments on the portability? THings like OBJS=$(SOURCES.SDK:.cpp=.o) are portable. Not sure about the .cpp not being a C++ suffix part; the generated Makeconf files should contain a rule for .cpp.o: $(CXX) $(ALL_CPPFLAGS) $(ALL_CXXFLAGS) -c $< -o $@ and the appropriate .SUFFIXES settings. (Maybe you manipulate .SUFFIXES?) Using FOO += something in Make files is not portable. best -k __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] two almost identical packages: best practice
Hi
I have written a whole bunch of methods for objects of class "octonion".
[
an octonion is a single column of an eight-row matrix. Octonions have
their own multiplication rules and are a generalization of quaternions,
which are columns of a four-row matrix.
]
So far I've done about a dozen generic functions such as seq.octonion(),
rep.octonion(), [<-.octonion(), and so on and so on.
Very nearly all of these functions are applicable to objects of
class "quaternion".
So, for example, I have a generic function Im.octonion():
R> Im.octonion
function (x)
{
Re(x) <- 0
return(x)
}
The definition of Im.quaternion() is exactly the same.
Sometimes the return value is an octonion:
Conj.octonion
function (x)
{
x <- as.matrix(x)
x[-1, ] <- -x[-1, ]
return(as.octonion(x))
}
So the last line of Conj.quaternion() would be "return(as.quaternion
(x))"
but would be otherwise identical.
A similar story holds for each of maybe twenty generic functions.
Nearly all the Rd files are similarly identical: the word "octonion"
replaces the word "octonion". I suppose "A" changes to "An" as well.
There is a small number of functions and datasets that are specific
to octonions.
What is Best Practice in this situation? I don't want to edit two
separate
packages in tandem. Is there a mechanism for doing what I want
in the context of a bundle?
--
Robin Hankin
Uncertainty Analyst
National Oceanography Centre, Southampton
European Way, Southampton SO14 3ZH, UK
tel 023-8059-7743
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] two almost identical packages: best practice
On 9/9/05, Robin Hankin <[EMAIL PROTECTED]> wrote:
> Hi
>
> I have written a whole bunch of methods for objects of class "octonion".
>
> [
> an octonion is a single column of an eight-row matrix. Octonions have
> their own multiplication rules and are a generalization of quaternions,
> which are columns of a four-row matrix.
> ]
>
> So far I've done about a dozen generic functions such as seq.octonion(),
> rep.octonion(), [<-.octonion(), and so on and so on.
>
> Very nearly all of these functions are applicable to objects of
> class "quaternion".
> So, for example, I have a generic function Im.octonion():
>
> R> Im.octonion
> function (x)
> {
> Re(x) <- 0
> return(x)
> }
>
> The definition of Im.quaternion() is exactly the same.
> Sometimes the return value is an octonion:
>
> Conj.octonion
> function (x)
> {
> x <- as.matrix(x)
> x[-1, ] <- -x[-1, ]
> return(as.octonion(x))
> }
>
> So the last line of Conj.quaternion() would be "return(as.quaternion
> (x))"
> but would be otherwise identical.
> A similar story holds for each of maybe twenty generic functions.
> Nearly all the Rd files are similarly identical: the word "octonion"
> replaces the word "octonion". I suppose "A" changes to "An" as well.
>
> There is a small number of functions and datasets that are specific
> to octonions.
>
> What is Best Practice in this situation? I don't want to edit two
> separate
> packages in tandem. Is there a mechanism for doing what I want
> in the context of a bundle?
Not sure what is best but some possibilities are to:
- create a third S3 class and make your two classes subclasses of that or
- make one of your classes a subclass of the other or
- in some cases, you may be able to use the .default method for common code.
You can also make use of NextMethod if you like though I am not sure if it will
buy you much in this situation (see the dyn package for examples of the use
of NextMethod).
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wishlist: write.delim()
On Fri, 9 Sep 2005, Martin Maechler wrote:
> > "Douglas" == Douglas Grove <[EMAIL PROTECTED]>
> > on Thu, 8 Sep 2005 15:33:02 -0700 (PDT) writes:
>
> Douglas> Hi,
> Douglas> It would be great if someone would add write.delim() as an
> Douglas> adjunct to write.table(), just as with write.csv().
>
> Douglas> I store a lot of data in tab-delimited files and can read
> Douglas> it in easily with: read.delim("text.txt", as.is=TRUE)
> Douglas> and would love to be able to write it out as easily when
> Douglas> I create these files.
>
> Douglas> The obvious setting needed for write.delim() is sep = "\t",
> Douglas> but in addition I would request the setting row.names = FALSE
>
> Douglas> i.e.
>
> Douglas> write.delim(x, file) = write.table(x, file, sep = "\t",
> row.names=FALSE)
>
> i.e.,
>write.delim <- function(x, file, ...)
> write.table(x, file, sep = "\t", row.names=FALSE, ...)
>
> So, why don't you just add that one line to your .Rprofile ?
I would love to do this, but I have to distribute code to people who
are not only R illiterate, but also fairly computer illiterate as well.
So for simplicity I can't use a lot of little convenience functions
that I'd prefer to use.
> In general, I don't think that it's worth to introduce a whole
> new function just because of some frequent argument use of an
> already existing function {{and I have wondered if it was worth
> to provide write.csv() at all - although, there the difference to default
> write.table() is quite a bit larger}}
I agree that it's not a good idea in general. I suggested this since
there's plenty of precedent in the read and write table functions.
On the "read" sinde there's read.csv, read.csv2, read.delim and read.delim2
and on the 'write" side there are write.csv and write.csv2. So it seems
obvious (from a simplistic point of view) to balance these out and offer
write.delim and write.delim2.
Probably one would want to use the same 'qmethod' setting too, as
write.csv and write.csv2 use. So that would bring the number of changed
arguments to 3, the same as write.csv has...
Doug
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] A question on R memory management in .Fortran() calls under Windows
Dear R community,
I have a question on how R manages memory allocation in .Fortran()
calls under Windows.
In brief, apparently, it is not possible to allocate large matrices
inside a Fortran subroutine
unless you pass them as arguments. If you do not act in this way
RGUI crashes with a stack overflow error and acting on memory through
vsize nsize ppsize and memory.limit does not help at all.
Details of the configurations on which I performed testing follow:
R 2.1.1 on WinXP Pro SP2 ITA
PC1: AMD 64 3700+ 1GB RAM
PC2: AMD AthlonXP 2400+ 512Mb RAM
Compaq Visual Fortran pro 6.6C
To give an idea I attach a brief example on how to reproduce this:
Create two simple subroutines 'foo' and 'foobis' that, say, give the
sum of the elements of a matrix:
*** file foo.f90 starts
***
SUBROUTINE foo(X,M,N,S)
!DEC$ ATTRIBUTES DLLEXPORT,C,REFERENCE,ALIAS:'foo_' :: FOO
IMPLICIT NONE
integer:: M,N
real*8:: X(M,N),S
S = sum(X);
END SUBROUTINE foo
SUBROUTINE foobis(M,N,S)
!DEC$ ATTRIBUTES DLLEXPORT,C,REFERENCE,ALIAS:'foobis_' :: FOOBIS
IMPLICIT NONE
integer:: M,N
real*8:: X(M,N),S
X = 1;
S = sum(X);
END SUBROUTINE foobis
*** file foo.f90 ends
***
Notice that the matrix X is an input argument in foo and an internal
variable in foobis.
After compiling and linking turn to R:
**
> dyn.load("foo.dll");
> is.loaded(symbol.For("foo"));
[1] TRUE
> is.loaded(symbol.For("foobis"));
[1] TRUE
> M <- 10;
> N <- 10;
> X <- matrix(1,M,N);
> .Fortran("foo",X,as.integer(M),as.integer(N),S=as.double(0))$S;
[1] 100
> .Fortran("foobis",as.integer(M),as.integer(N),S=as.double(0))$S;
[1] 100
## no problem here with small matrices, let's increase the size
> M <- 3000;
> N <- 100;
> X <- matrix(1,M,N);
> .Fortran("foo",X,as.integer(M),as.integer(N),S=as.double(0))$S;
[1] 3e+05 ## OK
.Fortran("foobis",as.integer(M),as.integer(N),S=as.double(0))$S;
## *** R GUI CRASHES WITH A STACK OVERFLOW ERROR ***
Any suggestion would be greatly appreciated, I apologize if this
problem has already been addressed previously, I did not notice it.
Many thanks in advance,
Simone
__
Simone Giannerini
Dipartimento di Scienze Statistiche "Paolo Fortunati"
Universita' di Bologna
Via delle belle arti 41 - 40126 Bologna, ITALY
Tel: +39 051 2098248 Fax: +39 051 232153
E-mail: [EMAIL PROTECTED]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Issue tracking in packages [was: Re: [R] change in read.spss, package foreign?]
On 9/9/05, Thomas Lumley <[EMAIL PROTECTED]> wrote:
>
> Many packages have a NEWS or ChangeLog file describing changes. You would
> typically have to look at the source package to find them, since by Unix
> tradition they are usually in the top-level directory and so are not
> included in the binary build.
>
> The foreign package is on svn.r-project.org, so you can see its Changelog
> there. There have been suggestions to extract these files and put them in
> the CRAN listing, but one obstacle is the lack of standardisation.
Of course this has been discussed a number of times but since its being
brought up again let me just add that there is a substantial need for something
here (i.e. something to address the lack of a standard way of communicating
issues in packages including changes, outstanding bugs, wishlist items, etc.)
I personally put NEWS, WISHLIST and THANKS files in the 'inst'
directory of all my source packages. This has the effect of copying them to the
top level of the built version so that they are accessible from R via:
system.file("NEWS", package = "mypackage"))
without the burden of having the user retrieve the source and I think we
need something like that, in general.
If someone wanted to set it up it would really be nice to have sourceforge-like
facilities made available for package developers providing groupware
facilities such as svn for each package, Trac issue tracking for each package,
home page for each package, email list for each package, etc. Its probably
too much ongoing work to provide this on a package by package basis but
an automated system that made it easy for package developers to access this
all in a standard way on a self-serve basis similar to OpenSVN would
be feasible
if someone wanted to do it.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Issue tracking in packages [was: Re: [R] change in read.spss, package foreign?]
On Fri, 9 Sep 2005, Gabor Grothendieck wrote: > > I personally put NEWS, WISHLIST and THANKS files in the 'inst' > directory of all my source packages. This has the effect of copying them to > the > top level of the built version so that they are accessible from R via: > I'm not sure that WISHLIST and THANKS need to be available to people who haven't installed the package. NEWS, on the other hand, really does. One option (if it doesn't turn out to be too much work for the CRAN maintainers) would be to have an optional Changelog field in the DESCRIPTION file giving the relative path to the file. This would mean that maintainers would not all have to switch to the same format. eg for foreign Changelog: ChangeLog and for survey Changelog: inst/NEWS This might be enough to make it easy for CRAN to display these when the maintainer provides them. -thomas __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Issue tracking in packages [was: Re: [R] change in read.spss, package foreign?]
On 9/9/05, Thomas Lumley <[EMAIL PROTECTED]> wrote: > On Fri, 9 Sep 2005, Gabor Grothendieck wrote: > > > > I personally put NEWS, WISHLIST and THANKS files in the 'inst' > > directory of all my source packages. This has the effect of copying them > > to the > > top level of the built version so that they are accessible from R via: > > > > I'm not sure that WISHLIST and THANKS need to be available to people who > haven't installed the package. NEWS, on the other hand, really does. > > One option (if it doesn't turn out to be too much work for the CRAN > maintainers) would be to have an optional Changelog field in the > DESCRIPTION file giving the relative path to the file. This would mean > that maintainers would not all have to switch to the same format. > eg for foreign > Changelog: ChangeLog > and for survey > Changelog: inst/NEWS > > This might be enough to make it easy for CRAN to display these when the > maintainer provides them. How about if there were just a standard location and name such as inst/NEWS, inst/WISHLIST, inst/THANKS (which has the advantage that they are automatically made available in the built package under the current way packages are built) and then CRAN could just check if its there or not -- no need to change and document the DESCRIPTION file. The only thing package developers who want to provide these have to do is to use the indicated names and location. It would still be possible as step 2 to provide your idea since its upwardly compatible. In fact, even with no software at all there would be an advantage to this since users would definitively know where to look and would not have to download the source package just to read this. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] A question on R memory management in .Fortran() calls under Windows
On 9/9/2005 1:04 PM, Simone Giannerini wrote:
> Dear R community,
>
> I have a question on how R manages memory allocation in .Fortran()
> calls under Windows.
> In brief, apparently, it is not possible to allocate large matrices
> inside a Fortran subroutine
> unless you pass them as arguments. If you do not act in this way
> RGUI crashes with a stack overflow error and acting on memory through
> vsize nsize ppsize and memory.limit does not help at all.
It looks as though your Fortran compiler is allocating the new matrix on
the stack. R doesn't give you a huge stack, and that's causing the
overflow. When you get R to do the allocation, it does it on the heap,
which has no artificial limits. Only a pointer to the object ends up on
the stack.
I'd say your only reasonable workarounds are to tell your compiler to
use the heap for the local matrix allocation (if that's possible), or do
your allocations in R.
There might be some utility somewhere which can modify Rgui.exe to tell
it to start with a larger stack, and there is probably some linker
option to put one in place, but it's not really reasonable to increase
R's stack, because in almost all other situations, writing that much
data to the stack is a sign of an infinite recursion.
Duncan Murdoch
>
>
> Details of the configurations on which I performed testing follow:
> R 2.1.1 on WinXP Pro SP2 ITA
> PC1: AMD 64 3700+ 1GB RAM
> PC2: AMD AthlonXP 2400+ 512Mb RAM
> Compaq Visual Fortran pro 6.6C
>
>
> To give an idea I attach a brief example on how to reproduce this:
> Create two simple subroutines 'foo' and 'foobis' that, say, give the
> sum of the elements of a matrix:
>
> *** file foo.f90 starts
> ***
> SUBROUTINE foo(X,M,N,S)
> !DEC$ ATTRIBUTES DLLEXPORT,C,REFERENCE,ALIAS:'foo_' :: FOO
>
> IMPLICIT NONE
> integer:: M,N
> real*8:: X(M,N),S
>
> S = sum(X);
>
> END SUBROUTINE foo
>
> SUBROUTINE foobis(M,N,S)
> !DEC$ ATTRIBUTES DLLEXPORT,C,REFERENCE,ALIAS:'foobis_' :: FOOBIS
>
> IMPLICIT NONE
> integer:: M,N
> real*8:: X(M,N),S
> X = 1;
> S = sum(X);
>
> END SUBROUTINE foobis
>
> *** file foo.f90 ends
> ***
>
> Notice that the matrix X is an input argument in foo and an internal
> variable in foobis.
> After compiling and linking turn to R:
> **
>> dyn.load("foo.dll");
>> is.loaded(symbol.For("foo"));
> [1] TRUE
>> is.loaded(symbol.For("foobis"));
> [1] TRUE
>> M <- 10;
>> N <- 10;
>> X <- matrix(1,M,N);
>> .Fortran("foo",X,as.integer(M),as.integer(N),S=as.double(0))$S;
> [1] 100
>> .Fortran("foobis",as.integer(M),as.integer(N),S=as.double(0))$S;
> [1] 100
>
> ## no problem here with small matrices, let's increase the size
>
>> M <- 3000;
>> N <- 100;
>> X <- matrix(1,M,N);
>> .Fortran("foo",X,as.integer(M),as.integer(N),S=as.double(0))$S;
> [1] 3e+05 ## OK
>
>
> .Fortran("foobis",as.integer(M),as.integer(N),S=as.double(0))$S;
> ## *** R GUI CRASHES WITH A STACK OVERFLOW ERROR ***
>
> Any suggestion would be greatly appreciated, I apologize if this
> problem has already been addressed previously, I did not notice it.
> Many thanks in advance,
>
> Simone
> __
>
> Simone Giannerini
> Dipartimento di Scienze Statistiche "Paolo Fortunati"
> Universita' di Bologna
> Via delle belle arti 41 - 40126 Bologna, ITALY
> Tel: +39 051 2098248 Fax: +39 051 232153
> E-mail: [EMAIL PROTECTED]
>
> __
> 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] A question on R memory management in .Fortran() calls under Windows
Simone,
On Sep 9, 2005, at 1:04 PM, Simone Giannerini wrote:
> Dear R community,
>
> I have a question on how R manages memory allocation in .Fortran()
> calls under Windows.
> In brief, apparently, it is not possible to allocate large matrices
> inside a Fortran subroutine
I suspect that this is a problem of your compiler, not R, because it
works without problems for me:
> dyn.load("foo.so")
> M=10
> N=10
> X=matrix(1,M,N)
> .Fortran("foo",X,as.integer(M),as.integer(N),S=as.double(0))$S
[1] 100
> .Fortran("foobis",as.integer(M),as.integer(N),S=as.double(0))$S
[1] 100
> M=3000
> N=100
> X=matrix(1,M,N)
> .Fortran("foo",X,as.integer(M),as.integer(N),S=as.double(0))$S
[1] 3e+05
> .Fortran("foobis",as.integer(M),as.integer(N),S=as.double(0))$S
[1] 3e+05
> M=1
> N=1
> X=matrix(1,M,N)
> .Fortran("foo",X,as.integer(M),as.integer(N),S=as.double(0))$S
[1] 1e+08
> .Fortran("foobis",as.integer(M),as.integer(N),S=as.double(0))$S
[1] 1e+08
Tested on
PC1: Win XP SP2, AMD64 3000+, 1GB RAM, gfortran 4.1.0 (20050902)
PC2: OS X, G5 1.8, 1GB RAM, gfortran 4.0.1
Cheers,
Simon
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Issue tracking in packages [was: Re: [R] change in read.spss, package foreign?]
On Fri, 9 Sep 2005, Gabor Grothendieck wrote: > How about if there were just a standard location and name such as inst/NEWS, > inst/WISHLIST, inst/THANKS (which has the advantage that they are > automatically > made available in the built package under the current way packages are > built) The problem is that there *isn't* a standard location. As Robert Gentleman has pointed out, if you only maintain two or three packages it isn't too bad to change them to some new layout, but if you are the bioconductor project it gets painful quite quickly. Also, there are good reasons for having NEWS in the top level directory. Nearly everything that isn't an R package does this, because it's a useful standard. -thomas __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Issue tracking in packages [was: Re: [R] change in read.spss, package foreign?]
On 9/9/05, Thomas Lumley <[EMAIL PROTECTED]> wrote: > On Fri, 9 Sep 2005, Gabor Grothendieck wrote: > > How about if there were just a standard location and name such as inst/NEWS, > > inst/WISHLIST, inst/THANKS (which has the advantage that they are > > automatically > > made available in the built package under the current way packages are > > built) > > The problem is that there *isn't* a standard location. As Robert Gentleman Yes, I know. That was the point of my post -- declare a standard location that everyone would use (or not but if they don't then people will have a hard time finding their info but no worse than now). > has pointed out, if you only maintain two or three packages it isn't too > bad to change them to some new layout, but if you are the bioconductor > project it gets painful quite quickly. Surely there are only a few possibilities that are used and a simple script could fix that all up. Its the same problem if you have to modify every DESCRIPTION file. At any rate I don't think this should be driven by compatibility with what is there now since its not a difficult one-time transition. > > Also, there are good reasons for having NEWS in the top level directory. > Nearly everything that isn't an R package does this, because it's a useful > standard. This could be handled by having the build procedure copy NEWS, WISHLIST and THANKS files at the top level to the build rather than not copying them. That way one would not have to put them in the inst directory -- although unlike my previous suggestion this would require modifying the build software though its presumably not a big change. I agree that this would be worth it. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] two almost identical packages: best practice
On 9 Sep 2005, [EMAIL PROTECTED] wrote: > I have written a whole bunch of methods for objects of class > "octonion". > > So far I've done about a dozen generic functions such as > seq.octonion(), rep.octonion(), [<-.octonion(), and so on and so on. > > Very nearly all of these functions are applicable to objects of > class "quaternion". One solution would be to define a common base class (perhaps nionBase? ;-) and put the common methods there. So in S3 I guess you'd have an Im.nionBase function and your octonions and quaternions would be subclasses of nionBase. > (x))" but would be otherwise identical. A similar story holds for > each of maybe twenty generic functions. Nearly all the Rd files are > similarly identical: the word "octonion" replaces the word > "octonion". I suppose "A" changes to "An" as well. If you document the generics for the base class, I think that would work. Otherwise, find/replace. > There is a small number of functions and datasets that are specific > to octonions. > > What is Best Practice in this situation? I don't want to edit two > separate > packages in tandem. Is there a mechanism for doing what I want > in the context of a bundle? If they need to be in separate packages, perhaps you have three packages: nionBase quaternion (depends on nionBase) etc. HTH, + seth __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Install packages to non-default lib on Windows
On 8 Sep 2005, [EMAIL PROTECTED] wrote: >>> installing inst files installing data files installing man source >>> files installing indices cannot create >>> d:/biocbld/R-devel/doc/html/search/index.txt: permission denied > > I was also annoyed about this point a couple of times. But what are > possible solutions? > > - not updating indices at all? No idea how difficult this would be but... Perhaps there could be a system and local help indices (defined by R_LIBS). If a package is installed in a local package library, I don't really see the point of adding an entry in a global index. > - provide a switch such as --no-indices for the R CMD tools? Or perhaps making the failure to write into the index a warning and not a fatal error? Not updating the help index seems unfatal to me. > short time workaround: simply give users write access to the few > files that have to write to. Yep. Thanks, + seth __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] MikTeX will be assumed in R 2.2.0 in Windows
I've just committed some changes to allow R to be built and to use MikTeX without needing the Rd.sty files to be installed to localtexmf. Unfortunately, the changes are not compatible with other TeX packages, so if you're not using MikTeX you'll need to edit a couple of the config files (or set an environment variable). I'd appreciate hearing of any problems during the alpha or beta test period. A binary build containing the changes should be on CRAN tomorrow or the next day. Look for revision 35546 or higher. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] MikTeX will be assumed in R 2.2.0 in Windows
Great. What specifically is the change? On 9/9/05, Duncan Murdoch <[EMAIL PROTECTED]> wrote: > I've just committed some changes to allow R to be built and to use > MikTeX without needing the Rd.sty files to be installed to localtexmf. > Unfortunately, the changes are not compatible with other TeX packages, > so if you're not using MikTeX you'll need to edit a couple of the config > files (or set an environment variable). > > I'd appreciate hearing of any problems during the alpha or beta test period. > > A binary build containing the changes should be on CRAN tomorrow or the > next day. Look for revision 35546 or higher. > > Duncan Murdoch > > __ > 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] MikTeX will be assumed in R 2.2.0 in Windows
Gabor Grothendieck wrote: > Great. What specifically is the change? There are a number of changes to make use of the --include-directory command line option that Miktex supports. It needed to be done in several places because tex is called from makefiles, Perl and shell scripts. Duncan Murdoch > > On 9/9/05, Duncan Murdoch <[EMAIL PROTECTED]> wrote: > >>I've just committed some changes to allow R to be built and to use >>MikTeX without needing the Rd.sty files to be installed to localtexmf. >>Unfortunately, the changes are not compatible with other TeX packages, >>so if you're not using MikTeX you'll need to edit a couple of the config >>files (or set an environment variable). >> >>I'd appreciate hearing of any problems during the alpha or beta test period. >> >>A binary build containing the changes should be on CRAN tomorrow or the >>next day. Look for revision 35546 or higher. >> >>Duncan Murdoch >> >>__ >>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
[Rd] \dontshow
In R 2.2.0 I find that even if I use \dontshow in the examples section of an .Rd file that the code still shows. Has anyone else seen this? Are there any packages that use this facility that I could try in order to check this? I am using > R.version.string # XP "R version 2.2.0, 2005-09-03" __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R.version.string (Re: MikTeX will be assumed in R 2.2.0 in Windows)
On 9/9/05, Duncan Murdoch <[EMAIL PROTECTED]> wrote: > I've just committed some changes to allow R to be built and to use > MikTeX without needing the Rd.sty files to be installed to localtexmf. > Unfortunately, the changes are not compatible with other TeX packages, > so if you're not using MikTeX you'll need to edit a couple of the config > files (or set an environment variable). > > I'd appreciate hearing of any problems during the alpha or beta test period. > > A binary build containing the changes should be on CRAN tomorrow or the > next day. Look for revision 35546 or higher. Note that R.version.string in R 2.2.0 2005-09-03 does not give this sort of version information. If we are going to use this style I suggest we modify R.version.string accordingly. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Copying libraries from one version of R to another (was Re: MikTeX will be assumed in R 2.2.0 in Windows)
On 9/9/05, Duncan Murdoch <[EMAIL PROTECTED]> wrote: > I've just committed some changes to allow R to be built and to use > MikTeX without needing the Rd.sty files to be installed to localtexmf. > Unfortunately, the changes are not compatible with other TeX packages, > so if you're not using MikTeX you'll need to edit a couple of the config > files (or set an environment variable). > > I'd appreciate hearing of any problems during the alpha or beta test period. > > A binary build containing the changes should be on CRAN tomorrow or the > next day. Look for revision 35546 or higher. The above improvement was one of the key things one had to look out for in installing R that was not already covered in the R setup procedure. The other one is to copy the libraries from your old R version to your new one (unless you want to share libraries among versions). I have a batch file in the devel version of batchfiles to do that but if this were made part of the installation procedure I could eliminate it or if it were included it would be much less necessary. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] \dontshow
On 9/9/05, Gabor Grothendieck <[EMAIL PROTECTED]> wrote: > In R 2.2.0 I find that even if I use \dontshow in the examples section > of an .Rd file that the code still shows. > > Has anyone else seen this? > > Are there any packages that use this facility that I could > try in order to check this? > > I am using > > > R.version.string # XP > "R version 2.2.0, 2005-09-03" > I realize that this description was not clear enough. It does not show in the help file but when you run the example it shows and it was that part I was concerned about. Is that the way its supposed to work? __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] Debugging R/Fortran in Windows
Thanks very much to Uwe, Duncan and Seth (who replied off the list). Uwe - That section of the R for Windows FAQ was very useful - thanks! Sorry I posted a question involving C/Fortran to R-Help. Duncan - Thanks for all the useful info. I've bookmarked the pages you sent me. Seth - Thanks for suggesting valgrind. I tried it out, and it correctly told me that memory leakage was not the problem (although I didn't believe it at first). It turned out that the reason my variables were being overwritten was not because of memory leakage, but because of my own stupidity - using the same variable name for a function I was estimating and for my current estimate of that function. Sorry I didn't spend more time checking this myself! Thanks again for your help, James __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
