Re: [Rd] optim CG bug w/patch proposal (PR#8786)
[Sorry for the belated reply: this came in just as I was leaving for a
trip.]
I've checked the original source, and the C code in optim does accurately
reflect the published algorithm.
Since your example is a discontinuous function, I don't see why you expect
CG to work on it. John Nash reports on his extensive experience that
method 3 is the worst, and I don't think we should let a single 2D example
of a badly-behaved function override that.
Note that no other optim method copes with the discontiuity here: had your
reported that it would have been clear that the problem was with the
example.
On Fri, 21 Apr 2006, [EMAIL PROTECTED] wrote:
Dear R team,
when using optim with method CG I got the wrong $value for the
reported $par.
Example:
f-function(p) {
if (!all(p-.7)) return(2)
if (!all(p.7)) return(2)
sin((p[1])^2)*sin(p[2])
}
optim(c(0.1,-0.1),f,method=CG,control=list(trace=0,type=1))
$par 19280.68 -10622.32
$value -0.2346207 # should be 2!
optim(c(0.1,-0.1),f,method=CG,control=list(trace=0,type=2))
$par 3834.021 -2718.958
$value -0.0009983175 # should be 2!
Fix:
--- optim.c (Revision 37878)
+++ optim.c (Arbeitskopie)
@@ -970,7 +970,8 @@
if (!accpoint) {
steplength *= stepredn;
if (trace) Rprintf(*);
- }
+ } else
+ *Fmin = f;
}
} while (!(count == n || accpoint));
if (count n) {
After fix:
optim(c(0.1,-0.1),f,method=CG,control=list(trace=0,type=1))
$par 0.6993467 -0.4900145
$value -0.2211150
optim(c(0.1,-0.1),f,method=CG,control=list(trace=0,type=2))
$par 3834.021 -2718.958
$value 2
Wishlist:
1. Please make type=3 the default in optim (it is more robust).
2. The $par reported for type=2 is still not satisfactory. I found out
that this can be improved by limiting G3 to a maximum of about 2000
(maybe even smaller). However, I'm not a CG expert and can live with a
suboptimal result.
--- optim.c (Revision 37878)
+++ optim.c (Arbeitskopie)
@@ -946,6 +946,8 @@
G3 = G1 / G2;
else
G3 = 1.0;
+ if (G3 2e3)
+ G3 = 2e3;
gradproj = 0.0;
for (i = 0; i n; i++) {
t[i] = t[i] * G3 - g[i];
Andreas
--
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] optim CG bug w/patch proposal (PR#8786)
Probably I included too much at once in my bug report. I can live with
an unfulfilled wishlist and thank you for thinking about it. The
badly-behaved function is just an example to demonstrate the bug I
reported. I think it is a bug if optim returns (without any warning) an
unmatching pair of par and value: f(par) != value. And it is easily fixed.
Andreas
Prof Brian Ripley wrote:
[Sorry for the belated reply: this came in just as I was leaving for a
trip.]
I've checked the original source, and the C code in optim does
accurately reflect the published algorithm.
Since your example is a discontinuous function, I don't see why you
expect CG to work on it. John Nash reports on his extensive
experience that method 3 is the worst, and I don't think we should let
a single 2D example of a badly-behaved function override that.
Note that no other optim method copes with the discontiuity here: had
your reported that it would have been clear that the problem was with
the example.
On Fri, 21 Apr 2006, [EMAIL PROTECTED] wrote:
Dear R team,
when using optim with method CG I got the wrong $value for the
reported $par.
Example:
f-function(p) {
if (!all(p-.7)) return(2)
if (!all(p.7)) return(2)
sin((p[1])^2)*sin(p[2])
}
optim(c(0.1,-0.1),f,method=CG,control=list(trace=0,type=1))
$par 19280.68 -10622.32
$value -0.2346207 # should be 2!
optim(c(0.1,-0.1),f,method=CG,control=list(trace=0,type=2))
$par 3834.021 -2718.958
$value -0.0009983175 # should be 2!
Fix:
--- optim.c (Revision 37878)
+++ optim.c (Arbeitskopie)
@@ -970,7 +970,8 @@
if (!accpoint) {
steplength *= stepredn;
if (trace) Rprintf(*);
- }
+ } else
+ *Fmin = f;
}
} while (!(count == n || accpoint));
if (count n) {
After fix:
optim(c(0.1,-0.1),f,method=CG,control=list(trace=0,type=1))
$par 0.6993467 -0.4900145
$value -0.2211150
optim(c(0.1,-0.1),f,method=CG,control=list(trace=0,type=2))
$par 3834.021 -2718.958
$value 2
Wishlist:
[wishlist deleted]
--
Andreas Westfeld, 0432 01CC F511 9E2B 0B57 5993 0B22 98F8 4AD8 EEEA
[EMAIL PROTECTED] http://www.inf.tu-dresden.de/~aw4
TU Dresden Fakultät Informatik, Institut für Systemarchitektur
Datenschutz und Datensicherheit, Tel. +49-351-463-37918
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] (PR#8861) Memory allocation fails in R 2.2.1 and R 2.3.0 on SGI Irix, while plenty of memory available
On a solaris 9 box here, gcc 3.4.2 defaults to build 32-bit binaries for
some unknown reason, but can be pursuaded to build 64-bit executables
by passing the -m64 switch explicitly. (this is first hand experience,
discovered while looking into a similiar anomaly with another piece
of software). I think gcc on early version of Mac OS X (10.2?) has
a similiar behavior also of defaulting to 32-bit unless told otherwise,
but can be pursuaded. Maybe gcc on IRIS can be similiarly pursuaded
too?
gcc -v
Reading specs from /usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.2/specs
Configured with: ../configure --with-as=/usr/ccs/bin/as
--with-ld=/usr/ccs/bin/ld --disable-nls
Mirjam van Vroonhoven wrote:
Prof Brian Ripley wrote on Mon, May 15, 2006 at 04:09:38PM +0100:
You can tell if you have a 64bit build of R by looking at
.Machine$sizeof.pointer in R, which should be 8.
And if this is a 32-bit build, it is working as expected given the limited
address space.
It is a 32 bit build. My R 2.0.0 is a 64bit build.
If not, then you need to set whatever C and Fortran compilation flags give
a 64bit system. It doesn't look to me as if R's configure script has any
special handling for C compiler flags on SGI.
Well, the R-admin manual says (under IRIX)
@R{} 2.1.0 has been successfully built on IRIX64 6.5 using both
@command{gcc} and the native (MipsPro 7.4) compiler. However, neither
version has passed @command{make check} due to a problem with time
zones (see below). A 64-bit executable has not been successfully
built.
so we could not use special handling for a system we have not been told
how to build in 64-bit mode.
Here we don't know the OS, the compiler, the flags used and that
definitely is a bug.
The OS is irix 6.5.27, compiler = gcc, no special flags.
But that is no different from what I recall to have done when building
R 2.0.0 a long time ago.
I'll try to find out how to build a 64 bit executable, and see wether it
works. Probably that is easier using the native mipspro compiler.
Will report back to you guys when I find out a way to build a working
64bit R 2.3.0 on SGI/irix64
Thanks for the time,
Mirjam
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] (PR#8861) Memory allocation fails in R 2.2.1 and R 2.3.0 on SGI Irix, while plenty of memory available
On Tue, 16 May 2006, Hin-Tak Leung wrote:
On a solaris 9 box here, gcc 3.4.2 defaults to build 32-bit binaries for some
unknown reason,
Actually, for a well-documented reason. (You need both a suitable CPU and
the appropriate parts of the OS installed for 64-bit binaries to be
usable, and you need to be working on large structures for them to be
desirable.)
BTW, g77 3.4.2 is broken, so please don't use it to build R.
but can be pursuaded to build 64-bit executables by passing the -m64
switch explicitly. (this is first hand experience, discovered while
looking into a similiar anomaly with another piece of software). I think
gcc on early version of Mac OS X (10.2?) has
Really? It is documented explicitly on the gcc man page and in the
R-admin manual.
However, on Solaris there is more to this than using -m64, and that too is
documented in the R-admin manual: you need to ensure that you get 64-bit
libraries.
a similiar behavior also of defaulting to 32-bit unless told otherwise,
but can be pursuaded. Maybe gcc on IRIS can be similiarly pursuaded
too?
gcc -v
Reading specs from /usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.2/specs
Configured with: ../configure --with-as=/usr/ccs/bin/as
--with-ld=/usr/ccs/bin/ld --disable-nls
Mirjam van Vroonhoven wrote:
Prof Brian Ripley wrote on Mon, May 15, 2006 at 04:09:38PM +0100:
You can tell if you have a 64bit build of R by looking at
.Machine$sizeof.pointer in R, which should be 8.
And if this is a 32-bit build, it is working as expected given the limited
address space.
It is a 32 bit build. My R 2.0.0 is a 64bit build.
If not, then you need to set whatever C and Fortran compilation flags
give
a 64bit system. It doesn't look to me as if R's configure script has any
special handling for C compiler flags on SGI.
Well, the R-admin manual says (under IRIX)
@R{} 2.1.0 has been successfully built on IRIX64 6.5 using both
@command{gcc} and the native (MipsPro 7.4) compiler. However, neither
version has passed @command{make check} due to a problem with time
zones (see below). A 64-bit executable has not been successfully
built.
so we could not use special handling for a system we have not been told
how to build in 64-bit mode.
Here we don't know the OS, the compiler, the flags used and that
definitely is a bug.
The OS is irix 6.5.27, compiler = gcc, no special flags.
But that is no different from what I recall to have done when building
R 2.0.0 a long time ago.
I'll try to find out how to build a 64 bit executable, and see wether it
works. Probably that is easier using the native mipspro compiler.
Will report back to you guys when I find out a way to build a working
64bit R 2.3.0 on SGI/irix64
Thanks for the time,
Mirjam
--
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] Truncated labels in hist (PR#8864)
[Duncan Murdoch] [François Pinard] Hi, people. Executing the following command: hist(rpois(100,5), labels=TRUE) yields a graphic in which some labels are truncated (on an X11 I don't see this on Windows using windows(), or Linux using X11(). I imagine it's a case that the device isn't reporting the size of fonts properly, and since my X server shows things properly, I would guess it's a problem with your X server, not with R. Thanks a lot, Duncan, for checking on your side, and replying. I'll try to explore if something is wrong here, that I could understand :-). -- François Pinard http://pinard.progiciels-bpi.ca __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] optim CG bug w/patch proposal (PR#8786)
On 5/16/2006 4:56 AM, [EMAIL PROTECTED] wrote:
Probably I included too much at once in my bug report. I can live with
an unfulfilled wishlist and thank you for thinking about it. The
badly-behaved function is just an example to demonstrate the bug I
reported. I think it is a bug if optim returns (without any warning) an
unmatching pair of par and value: f(par) != value. And it is easily fixed.
I agree with you that on return f(par) should be value. I agree with
Brian that changes to the underlying strategy need much more thought.
Duncan Murdoch
Andreas
Prof Brian Ripley wrote:
[Sorry for the belated reply: this came in just as I was leaving for a
trip.]
I've checked the original source, and the C code in optim does
accurately reflect the published algorithm.
Since your example is a discontinuous function, I don't see why you
expect CG to work on it. John Nash reports on his extensive
experience that method 3 is the worst, and I don't think we should let
a single 2D example of a badly-behaved function override that.
Note that no other optim method copes with the discontiuity here: had
your reported that it would have been clear that the problem was with
the example.
On Fri, 21 Apr 2006, [EMAIL PROTECTED] wrote:
Dear R team,
when using optim with method CG I got the wrong $value for the
reported $par.
Example:
f-function(p) {
if (!all(p-.7)) return(2)
if (!all(p.7)) return(2)
sin((p[1])^2)*sin(p[2])
}
optim(c(0.1,-0.1),f,method=CG,control=list(trace=0,type=1))
$par 19280.68 -10622.32
$value -0.2346207 # should be 2!
optim(c(0.1,-0.1),f,method=CG,control=list(trace=0,type=2))
$par 3834.021 -2718.958
$value -0.0009983175 # should be 2!
Fix:
--- optim.c (Revision 37878)
+++ optim.c (Arbeitskopie)
@@ -970,7 +970,8 @@
if (!accpoint) {
steplength *= stepredn;
if (trace) Rprintf(*);
- }
+ } else
+ *Fmin = f;
}
} while (!(count == n || accpoint));
if (count n) {
After fix:
optim(c(0.1,-0.1),f,method=CG,control=list(trace=0,type=1))
$par 0.6993467 -0.4900145
$value -0.2211150
optim(c(0.1,-0.1),f,method=CG,control=list(trace=0,type=2))
$par 3834.021 -2718.958
$value 2
Wishlist:
[wishlist deleted]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Cofnigure (Building) trouble
Hi, I'm trying to build R on SuSE 10.1/x86_64. I had to download fortran as it wasn't supplied by SuSE. Octave, which also uses both C and Fortran was able to compile w/o trouble. The problem I run in to with R is the following. R's configure script will complain that it can't find the fortran libraries (octave didn't give this complaint). When I specify them using LDFLAGS, for some reason this causes the C test to fail (even though I can still use gcc w/o trouble): [EMAIL PROTECTED]:~/R-2.3.0 export LDFLAGS=/usr/local/fortran/lib64 [EMAIL PROTECTED]:~/R-2.3.0 echo $LDFLAGS /usr/local/fortran/lib64 [EMAIL PROTECTED]:~/R-2.3.0 export F77=/usr/local/fortran/bin/gfortran ... checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. I've put up my config.log at http://sweb.uky.edu/~bebark2/config.log Thanks in advance for the advice. -- Brandon Barker Phone: (859) 948-5335 Email: [EMAIL PROTECTED] [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problems on SuSE 10.1 (was Cofnigure (Building) trouble)
On Tue, 16 May 2006, Brandon Barker wrote: Hi, I'm trying to build R on SuSE 10.1/x86_64. I had to download fortran as it wasn't supplied by SuSE. Octave, which also uses both C and Fortran was able to compile w/o trouble. The problem I run in to with R is the following. R's configure script will complain that it can't find the fortran libraries (octave didn't give this complaint). When I specify them using LDFLAGS, for some reason this causes the C test to fail (even though I can still use gcc w/o trouble): [EMAIL PROTECTED]:~/R-2.3.0 export LDFLAGS=/usr/local/fortran/lib64 This should be -L/usr/local/fortran/lib64, and that error causes R's build command to be invalid. Please note that this is covered in the R-admin manual which the INSTALL file asked you to read (instead of asking other people to read it for you). [EMAIL PROTECTED]:~/R-2.3.0 echo $LDFLAGS /usr/local/fortran/lib64 [EMAIL PROTECTED]:~/R-2.3.0 export F77=/usr/local/fortran/bin/gfortran ... checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. I've put up my config.log at http://sweb.uky.edu/~bebark2/config.log Thanks in advance for the advice. -- 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] R CMD SHLIB
It is possible to do things like env PKG_LIB=-L/opt/foo/lib -lbar R CMD SHLIB *.c to add libraries to the creation of a shared object, but I have from time to time wondered if we should allow R CMD SHLIB *.c -L/opt/foo/lib -lbar not least as users seems to expect it to work. It looks simple to do (at least under Unix) if we pass -L* -l* *.a directly to the link command. Would this be worthwhile? -- 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 CMD SHLIB
On Tue, 16 May 2006, Prof Brian Ripley wrote: It is possible to do things like env PKG_LIB=-L/opt/foo/lib -lbar R CMD SHLIB *.c to add libraries to the creation of a shared object, but I have from time to time wondered if we should allow R CMD SHLIB *.c -L/opt/foo/lib -lbar not least as users seems to expect it to work. It looks simple to do (at least under Unix) if we pass -L* -l* *.a directly to the link command. Would this be worthwhile? Yes. My only reservation is that users may then expect all compiler/linker flags to work, not just -L/-l -thomas Thomas Lumley Assoc. Professor, Biostatistics [EMAIL PROTECTED] University of Washington, Seattle __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] bug in rbind.data.frame with factors (PR#8868)
Full_Name: Rafal Kustra Version: 2.1.1 OS: Linux, MacOS 10.3 Submission from: (NULL) (69.195.47.62) When Rbinding two data frames with factors, strange result occur (but no error) when the order of data frame variables is different in two data frames: d1=as.data.frame(list(x=1:10,y=letters[1:10])) d2=as.data.frame(list(y=LETTERS[1:5],x=7:11)) d2 y x 1 A 7 2 B 8 3 C 9 4 D 10 5 E 11 rbind(d1,d2) xy 1 1a 2 2b 3 3c 4 4d 5 5e 6 6f 7 7g 8 8h 9 9i 10 10j 11 7 NA 21 8 NA 31 9 NA 41 10 NA 51 11 NA Warning message: invalid factor level, NAs generated in: [-.factor(`*tmp*`, ri, value = c(A, B, C, D, E)) Things work correctly when the order of variables is the same: d3=as.data.frame(list(x=7:11,y=LETTERS[1:5])) rbind(d1,d3) x y 1 1 a 2 2 b 3 3 c 4 4 d 5 5 e 6 6 f 7 7 g 8 8 h 9 9 i 10 10 j 11 7 A 21 8 B 31 9 C 41 10 D 51 11 E __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug in rbind.data.frame with factors (PR#8868)
How is this a bug? From the help page for cbind/rbind: Description Take a sequence of vector, matrix or data frames arguments and combine by _columns_ or _rows_, respectively. (emphasis added) Note that it does _not_ say combine by variable names. Peter Ehlers [EMAIL PROTECTED] wrote: Full_Name: Rafal Kustra Version: 2.1.1 OS: Linux, MacOS 10.3 Submission from: (NULL) (69.195.47.62) When Rbinding two data frames with factors, strange result occur (but no error) when the order of data frame variables is different in two data frames: d1=as.data.frame(list(x=1:10,y=letters[1:10])) d2=as.data.frame(list(y=LETTERS[1:5],x=7:11)) d2 y x 1 A 7 2 B 8 3 C 9 4 D 10 5 E 11 rbind(d1,d2) xy 1 1a 2 2b 3 3c 4 4d 5 5e 6 6f 7 7g 8 8h 9 9i 10 10j 11 7 NA 21 8 NA 31 9 NA 41 10 NA 51 11 NA Warning message: invalid factor level, NAs generated in: [-.factor(`*tmp*`, ri, value = c(A, B, C, D, E)) Things work correctly when the order of variables is the same: d3=as.data.frame(list(x=7:11,y=LETTERS[1:5])) rbind(d1,d3) x y 1 1 a 2 2 b 3 3 c 4 4 d 5 5 e 6 6 f 7 7 g 8 8 h 9 9 i 10 10 j 11 7 A 21 8 B 31 9 C 41 10 D 51 11 E __ 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] bug in rbind.data.frame with factors (PR#8868)
Agreed. Should have checked the help page. But then it should return an error msg, not try to do something and return an invalid result. rafal PS: perhaps rbind.data.frame should be more forgiving as to the order of variables, though. On 5/16/06, Peter Ehlers [EMAIL PROTECTED] wrote: How is this a bug? From the help page for cbind/rbind: Description Take a sequence of vector, matrix or data frames arguments and combine by _columns_ or _rows_, respectively. (emphasis added) Note that it does _not_ say combine by variable names. Peter Ehlers [EMAIL PROTECTED] wrote: Full_Name: Rafal Kustra Version: 2.1.1 OS: Linux, MacOS 10.3 Submission from: (NULL) (69.195.47.62) When Rbinding two data frames with factors, strange result occur (but no error) when the order of data frame variables is different in two data frames: d1=as.data.frame(list(x=1:10,y=letters[1:10])) d2=as.data.frame(list(y=LETTERS[1:5],x=7:11)) d2 y x 1 A 7 2 B 8 3 C 9 4 D 10 5 E 11 rbind(d1,d2) xy 1 1a 2 2b 3 3c 4 4d 5 5e 6 6f 7 7g 8 8h 9 9i 10 10j 11 7 NA 21 8 NA 31 9 NA 41 10 NA 51 11 NA Warning message: invalid factor level, NAs generated in: [-.factor(`*tmp*`, ri, value = c(A, B, C, D, E)) Things work correctly when the order of variables is the same: d3=as.data.frame(list(x=7:11,y=LETTERS[1:5])) rbind(d1,d3) x y 1 1 a 2 2 b 3 3 c 4 4 d 5 5 e 6 6 f 7 7 g 8 8 h 9 9 i 10 10 j 11 7 A 21 8 B 31 9 C 41 10 D 51 11 E __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug in rbind.data.frame with factors (PR#8868)
On Tue, 16 May 2006, Peter Ehlers wrote: How is this a bug? From the help page for cbind/rbind: Description Take a sequence of vector, matrix or data frames arguments and combine by _columns_ or _rows_, respectively. (emphasis added) Note that it does _not_ say combine by variable names. That was my first reaction, but in fact it does attempt to match up the colunn names. So this is a bug in an undocumented extension, the bug being that when it looks into extending the levels of a factor, it checks if the column number was a factor in the first data frame and not in the (possibly permuted) columns of the data frame under consideration. It is unclear from the S documentation what it is supposed to do, but it seems that it generates the same problematic output. Peter Ehlers [EMAIL PROTECTED] wrote: Full_Name: Rafal Kustra Version: 2.1.1 Please don't report on obselete versions of R: we do ask so quite explicitly. OS: Linux, MacOS 10.3 Submission from: (NULL) (69.195.47.62) When Rbinding two data frames with factors, strange result occur (but no error) when the order of data frame variables is different in two data frames: d1=as.data.frame(list(x=1:10,y=letters[1:10])) d2=as.data.frame(list(y=LETTERS[1:5],x=7:11)) d2 y x 1 A 7 2 B 8 3 C 9 4 D 10 5 E 11 rbind(d1,d2) xy 1 1a 2 2b 3 3c 4 4d 5 5e 6 6f 7 7g 8 8h 9 9i 10 10j 11 7 NA 21 8 NA 31 9 NA 41 10 NA 51 11 NA Warning message: invalid factor level, NAs generated in: [-.factor(`*tmp*`, ri, value = c(A, B, C, D, E)) Things work correctly when the order of variables is the same: d3=as.data.frame(list(x=7:11,y=LETTERS[1:5])) rbind(d1,d3) x y 1 1 a 2 2 b 3 3 c 4 4 d 5 5 e 6 6 f 7 7 g 8 8 h 9 9 i 10 10 j 11 7 A 21 8 B 31 9 C 41 10 D 51 11 E __ 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 -- 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] bug in rbind.data.frame with factors (PR#8868)
On 5/16/06, Prof Brian Ripley [EMAIL PROTECTED] wrote: On Tue, 16 May 2006, Peter Ehlers wrote: How is this a bug? From the help page for cbind/rbind: Description Take a sequence of vector, matrix or data frames arguments and combine by _columns_ or _rows_, respectively. (emphasis added) Note that it does _not_ say combine by variable names. That was my first reaction, but in fact it does attempt to match up the colunn names. So this is a bug in an undocumented extension, the bug being that when it looks into extending the levels of a factor, it checks if the column number was a factor in the first data frame and not in the (possibly permuted) columns of the data frame under consideration. It is unclear from the S documentation what it is supposed to do, but it seems that it generates the same problematic output. Peter Ehlers [EMAIL PROTECTED] wrote: Full_Name: Rafal Kustra Version: 2.1.1 Please don't report on obselete versions of R: we do ask so quite explicitly. I must say reporting a bug to R-devel is not for the faint of heart -:) Thanks for all you work! rafal OS: Linux, MacOS 10.3 Submission from: (NULL) (69.195.47.62) When Rbinding two data frames with factors, strange result occur (but no error) when the order of data frame variables is different in two data frames: d1=as.data.frame(list(x=1:10,y=letters[1:10])) d2=as.data.frame(list(y=LETTERS[1:5],x=7:11)) d2 y x 1 A 7 2 B 8 3 C 9 4 D 10 5 E 11 rbind(d1,d2) xy 1 1a 2 2b 3 3c 4 4d 5 5e 6 6f 7 7g 8 8h 9 9i 10 10j 11 7 NA 21 8 NA 31 9 NA 41 10 NA 51 11 NA Warning message: invalid factor level, NAs generated in: [-.factor(`*tmp*`, ri, value = c(A, B, C, D, E)) Things work correctly when the order of variables is the same: d3=as.data.frame(list(x=7:11,y=LETTERS[1:5])) rbind(d1,d3) x y 1 1 a 2 2 b 3 3 c 4 4 d 5 5 e 6 6 f 7 7 g 8 8 h 9 9 i 10 10 j 11 7 A 21 8 B 31 9 C 41 10 D 51 11 E __ 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 -- 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 [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] New probability law functions
Dear developers,
I am currently writing, for a package of mine, {d,p,q,r}dist() functions for
some probability laws not already found in base R. I was wondering if the
Core Team would see any interest in having some or all the functions
integrated in base R. I'm talking here of distributions like the Pareto,
Burr, inverted gamma and, ultimately, four parameter transformed beta and
transformed gamma (as named in Klugman, Panjer Willmot, Loss Models, Second
Edition, Wiley, 2004).
If there is interest, I will gladly contribute patches to relevant files. I'm
asking beforehand since my current implementation is simpler than what is
found in random.c and I would prefer to go one route or another.
Thanks in advance for any feedback.
--
Vincent Goulet, Associate Professor
École d'actuariat
Université Laval, Québec
[EMAIL PROTECTED] http://vgoulet.act.ulaval.ca
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
