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
21 8
31 9
41 10
51 11
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
> 21 8
> 31 9
> 41 10
> 51 11
> 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
> > 21 8
> > 31 9
> > 41 10
> > 51 11
> > 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
>> 21 8
>> 31 9
>> 41 10
>> 51 11
>> 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
> >> 21 8
> >> 31 9
> >> 41 10
> >> 51 11
> >> 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
Re: [Rd] R CMD SHLIB
> "TL" == Thomas Lumley <[EMAIL PROTECTED]> > on Tue, 16 May 2006 10:15:11 -0700 (PDT) writes: TL> 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? TL> Yes. TL> My only reservation is that users may then expect all TL> compiler/linker flags to work, not just -L/-l I had exactly the same thought. Maybe Brian's proposal can be extended into "all switches that are not recognized by 'R CMD SHLIB' are passed to compiler / linker " hmm, or maybe not, since the question quickly become *which* are passed to compiler and which to linker (and which to both ?) ... Martin Maechler, ETH Zurich __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD SHLIB
On Wed, 17 May 2006, Martin Maechler wrote: >> "TL" == Thomas Lumley <[EMAIL PROTECTED]> >> on Tue, 16 May 2006 10:15:11 -0700 (PDT) writes: > >TL> 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? > >TL> Yes. > >TL> My only reservation is that users may then expect all >TL> compiler/linker flags to work, not just -L/-l > > I had exactly the same thought. > > Maybe Brian's proposal can be extended into > > "all switches that are not recognized by 'R CMD SHLIB' are > passed to compiler / linker " > > hmm, or maybe not, since the question quickly become *which* are > passed to compiler and which to linker (and which to both ?) ... On looking at the code, currently all items on the command line not recognized as flags, source files or object files are ignored, so we can just pass those to the linker. It's a little more complicated under Windows since Perl is used and -L* looks like an unknown option and so need to be preceded by --. Will commit these changes to R-devel shortly. -- 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
