Re: [Rd] bug (PR#13570)
On Thu, 5 Mar 2009, Benjamin Tyner wrote: Hi Nice to hear from you Ryan. I also do not have the capability to debug on windows; however, there is a chance that the behavior you are seeing is caused by the following bug noted in my thesis (available on ProQuest; email me if you don't have access): "When lambda = 0 there are no local slopes to aid the blending algorithm, yet the interpolator would still assume they were available, and thus use arbitrary values from memory. This had implications for both fit and tr[L] computation. In the updated code these are set equal to zero which seems the best automatic rule when lambda = 0." [lambda refers to degree] I submitted a bug fix to Eric Grosse, the maintainer of the netlib routines; the fixed lines of fortran are identified in the comments at (just search for my email address): http://www.netlib.org/a/loess These fixes would be relatively simple to incorporate into R's version of loessf.f The fixes from dloess even more simply, since R's code is based on dloess. Thank you for the suggestion. Given how tricky this is to reproduce, I went back to my example under valgrind. If I use the latest dloess code, it crashes, but by selectively importing some of the differences I can get it to work. So it looks as if we are on the road to a solution, but something in the current version (not necessarily in these changes) is incompatible with the current R code and I need to dig further (not for a few days). Alternatively, a quick check would be for someone to compile the source package at https://centauri.stat.purdue.edu:98/loess/loess_0.4-1.tar.gz and test it on windows. Though this package incorporates this and a few other fixes, please be aware that it the routines are converted to C and thus there is a slight performance hit compared to the fortran. Hope this helps, Ben [...] -- Brian D. Ripley, rip...@stats.ox.ac.uk 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] array subsetting of S4 object that inherits from "array"
Hi,
I have an S4 class that inherits from "array" but does not add generic
implementations of the "[" method.
A simplified example is:
setClass("fooarray", contains="array")
If I create a "fooarray" object and subset it with a one-dimensional
index vector, the return value is of class "fooarray". Other variants
(see below), however, return primitive values consistent with
"ordinary" array subsetting.
x <- new("fooarray", array(0,c(10,10,10)))
class(x[1,1,1])# prints "numeric"
class(x[1,,]) # prints "matrix"
class(x[1]) # prints "fooarray"
class(x[1:10])# prints "fooarray"
This behavior seems to have been introduced in R2.8.1 as I have not
encountered it before. I tested it on R.2.7.0 and confirmed that
class(x[1]) returned "numeric".
In my case, the desired behavior is for array subsetting in all cases
to return primitive data structures, so if there is a way to override
the new behavior I would opt for that.
Regards,
Brad Buchsbaum
R version 2.8.1 (2008-12-22)
i386-pc-mingw32
locale:
LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
States.1252;LC_MONETARY=English_United
States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
--
Bradley R. Buchsbaum
Rotman Research Institute
3560 Bathurst St.
Toronto, ON Canada M6A 2E1
email: bbuchsb...@rotman-baycrest.on.ca
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug (PR#13570)
Hi
Nice to hear from you Ryan. I also do not have the capability to debug
on windows; however, there is a chance that the behavior you are seeing
is caused by the following bug noted in my thesis (available on
ProQuest; email me if you don't have access):
"When lambda = 0 there are no local slopes to aid the blending
algorithm, yet the
interpolator would still assume they were available, and thus use
arbitrary values
from memory. This had implications for both fit and tr[L] computation.
In the
updated code these are set equal to zero which seems the best automatic
rule when
lambda = 0." [lambda refers to degree]
I submitted a bug fix to Eric Grosse, the maintainer of the netlib
routines; the fixed lines of fortran are identified in the comments at
(just search for my email address):
http://www.netlib.org/a/loess
These fixes would be relatively simple to incorporate into R's version
of loessf.f
Alternatively, a quick check would be for someone to compile the source
package at https://centauri.stat.purdue.edu:98/loess/loess_0.4-1.tar.gz
and test it on windows. Though this package incorporates this and a few
other fixes, please be aware that it the routines are converted to C and
thus there is a slight performance hit compared to the fortran.
Hope this helps,
Ben
Ryan Hafen wrote:
That is true - good point.
lp1 <- predict(loess(y ~ x, degree=0))
lp2 <- predict(loess(y ~ x, degree=0,
control=loess.control(surface="direct")))
sort(abs(lp1-lp2))
It appears that the interpolating fit is correct at the vertices. I
know when degree>=1, the interpolation uses the slopes of the local
fits to get a better approximation. Perhaps it's still trying to do
this with degree=0 but the slopes aren't available. And we have just
been lucky in the past with uninitialized values? If this is the
problem it would probably be very simple to fix and I'd love to see
degree=0 stay. I will see if I can figure it out.
On Mar 5, 2009, at 6:01 PM, Greg Snow wrote:
I see the same problem on Windows XP.
But if I run loess with surface='direct' then the results are
correct. So it looks like the problem comes from the
smoothing/interpolating, not the main loess algorithm.
--
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
greg.s...@imail.org
801.408.8111
-Original Message-
From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-
project.org] On Behalf Of Ryan Hafen
Sent: Thursday, March 05, 2009 7:43 AM
To: Prof Brian Ripley
Cc: Uwe Ligges; Berwin A Turlach; r-de...@stat.math.ethz.ch; Peter
Dalgaard
Subject: Re: [Rd] bug (PR#13570)
On Mar 5, 2009, at 7:59 AM, Prof Brian Ripley wrote:
On Thu, 5 Mar 2009, Peter Dalgaard wrote:
Prof Brian Ripley wrote:
Undortunately the example is random, so not really reproducible
(and I
see nothing wrong on my Mac). However, Linux valgrind on R-devel is
showing a problem:
==3973== Conditional jump or move depends on uninitialised value(s)
==3973==at 0xD76017B: ehg141_ (loessf.f:532)
==3973==by 0xD761600: lowesa_ (loessf.f:769)
==3973==by 0xD736E47: loess_raw (loessc.c:117)
(The uninitiialized value is in someone else's code and I suspect
it was
either never intended to work or never tested.) No essential
change has
been made to the loess code for many years.
I would not have read the documentation to say that degree = 0 was
a
reasonable value. It is not to my mind 'a polynomial surface', and
loess() is described as a 'local regression' for degree 1 or 2 in
the
reference. So unless anyone wants to bury their heads in that
code I
think a perfectly adequate fix would be to disallow degree = 0.
(I vaguely recall debating allowing in the code ca 10 years ago.)
The code itself has
if (!match(degree, 0:2, 0))
stop("'degree' must be 0, 1 or 2")
though. "Local fitting of a constant" essentially becomes kernel
smoothing, right?
I do know the R code allows it: the question is whether it is worth
the effort of finding the problem(s) in the underlying c/dloess
code, whose manual (and our reference) is entirely about 1 or 2. I
am concerned that there may be other things lurking in the degree=0
case if it was never tested (in the netlib version: I am sure it was
only minmally tested through my R interface).
I checked the original documentation on netlib and that says
29 DIM dimension of local regression
1 constant
d+1 linear (default)
(d+2)(d+1)/2quadratic
Modified by ehg127 if cdeg
True. There are plenty of reasons why one wouldn't want to use
degree=0 anyway. And I'm sure there are plenty of other simple ways
to achieve the same effect.
I ran into the problem because some code I'm planning on distributing
as part of a paper submission "blends" partway down to degree 0
smoothing at the endpoints to reduce the variance. The only bad
effect of disallowing degree 0 is for anyone with cod
Re: [Rd] bug (PR#13570)
Excellent, Ben! Thanks!!
On Mar 5, 2009, at 8:24 PM, Benjamin Tyner wrote:
Hi
Nice to hear from you Ryan. I also do not have the capability to
debug on windows; however, there is a chance that the behavior you
are seeing is caused by the following bug noted in my thesis
(available on ProQuest; email me if you don't have access):
"When lambda = 0 there are no local slopes to aid the blending
algorithm, yet the
interpolator would still assume they were available, and thus use
arbitrary values
from memory. This had implications for both fit and tr[L]
computation. In the
updated code these are set equal to zero which seems the best
automatic rule when
lambda = 0." [lambda refers to degree]
I submitted a bug fix to Eric Grosse, the maintainer of the netlib
routines; the fixed lines of fortran are identified in the comments
at (just search for my email address):
http://www.netlib.org/a/loess
These fixes would be relatively simple to incorporate into R's
version of loessf.f
Alternatively, a quick check would be for someone to compile the
source package at https://centauri.stat.purdue.edu:98/loess/loess_0.4-1.tar.gz
and test it on windows. Though this package incorporates this and a
few other fixes, please be aware that it the routines are converted
to C and thus there is a slight performance hit compared to the
fortran.
Hope this helps,
Ben
Ryan Hafen wrote:
That is true - good point.
lp1 <- predict(loess(y ~ x, degree=0))
lp2 <- predict(loess(y ~ x, degree=0,
control=loess.control(surface="direct")))
sort(abs(lp1-lp2))
It appears that the interpolating fit is correct at the vertices.
I know when degree>=1, the interpolation uses the slopes of the
local fits to get a better approximation. Perhaps it's still
trying to do this with degree=0 but the slopes aren't available.
And we have just been lucky in the past with uninitialized values?
If this is the problem it would probably be very simple to fix and
I'd love to see degree=0 stay. I will see if I can figure it out.
On Mar 5, 2009, at 6:01 PM, Greg Snow wrote:
I see the same problem on Windows XP.
But if I run loess with surface='direct' then the results are
correct. So it looks like the problem comes from the smoothing/
interpolating, not the main loess algorithm.
--
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
greg.s...@imail.org
801.408.8111
-Original Message-
From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-
project.org] On Behalf Of Ryan Hafen
Sent: Thursday, March 05, 2009 7:43 AM
To: Prof Brian Ripley
Cc: Uwe Ligges; Berwin A Turlach; r-de...@stat.math.ethz.ch; Peter
Dalgaard
Subject: Re: [Rd] bug (PR#13570)
On Mar 5, 2009, at 7:59 AM, Prof Brian Ripley wrote:
On Thu, 5 Mar 2009, Peter Dalgaard wrote:
Prof Brian Ripley wrote:
Undortunately the example is random, so not really reproducible
(and I
see nothing wrong on my Mac). However, Linux valgrind on R-
devel is
showing a problem:
==3973== Conditional jump or move depends on uninitialised
value(s)
==3973==at 0xD76017B: ehg141_ (loessf.f:532)
==3973==by 0xD761600: lowesa_ (loessf.f:769)
==3973==by 0xD736E47: loess_raw (loessc.c:117)
(The uninitiialized value is in someone else's code and I
suspect
it was
either never intended to work or never tested.) No essential
change has
been made to the loess code for many years.
I would not have read the documentation to say that degree = 0
was
a
reasonable value. It is not to my mind 'a polynomial surface',
and
loess() is described as a 'local regression' for degree 1 or 2
in
the
reference. So unless anyone wants to bury their heads in that
code I
think a perfectly adequate fix would be to disallow degree = 0.
(I vaguely recall debating allowing in the code ca 10 years
ago.)
The code itself has
if (!match(degree, 0:2, 0))
stop("'degree' must be 0, 1 or 2")
though. "Local fitting of a constant" essentially becomes kernel
smoothing, right?
I do know the R code allows it: the question is whether it is
worth
the effort of finding the problem(s) in the underlying c/dloess
code, whose manual (and our reference) is entirely about 1 or
2. I
am concerned that there may be other things lurking in the
degree=0
case if it was never tested (in the netlib version: I am sure it
was
only minmally tested through my R interface).
I checked the original documentation on netlib and that says
29 DIM dimension of local regression
1 constant
d+1 linear (default)
(d+2)(d+1)/2quadratic
Modified by ehg127 if cdegand what I dimly recall from ca 1998 is debating whether the R
code
should allow that or not.
If left to me I would say I did not wish to continue to support
degree = 0.
True. There are plenty of reasons why one wouldn't want to use
degree=0 anyway. And I'm sure there are plenty of
Re: [Rd] bug (PR#13570)
That is true - good point.
lp1 <- predict(loess(y ~ x, degree=0))
lp2 <- predict(loess(y ~ x, degree=0,
control=loess.control(surface="direct")))
sort(abs(lp1-lp2))
It appears that the interpolating fit is correct at the vertices. I
know when degree>=1, the interpolation uses the slopes of the local
fits to get a better approximation. Perhaps it's still trying to do
this with degree=0 but the slopes aren't available. And we have just
been lucky in the past with uninitialized values? If this is the
problem it would probably be very simple to fix and I'd love to see
degree=0 stay. I will see if I can figure it out.
On Mar 5, 2009, at 6:01 PM, Greg Snow wrote:
I see the same problem on Windows XP.
But if I run loess with surface='direct' then the results are
correct. So it looks like the problem comes from the smoothing/
interpolating, not the main loess algorithm.
--
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
greg.s...@imail.org
801.408.8111
-Original Message-
From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-
project.org] On Behalf Of Ryan Hafen
Sent: Thursday, March 05, 2009 7:43 AM
To: Prof Brian Ripley
Cc: Uwe Ligges; Berwin A Turlach; r-de...@stat.math.ethz.ch; Peter
Dalgaard
Subject: Re: [Rd] bug (PR#13570)
On Mar 5, 2009, at 7:59 AM, Prof Brian Ripley wrote:
On Thu, 5 Mar 2009, Peter Dalgaard wrote:
Prof Brian Ripley wrote:
Undortunately the example is random, so not really reproducible
(and I
see nothing wrong on my Mac). However, Linux valgrind on R-devel
is
showing a problem:
==3973== Conditional jump or move depends on uninitialised
value(s)
==3973==at 0xD76017B: ehg141_ (loessf.f:532)
==3973==by 0xD761600: lowesa_ (loessf.f:769)
==3973==by 0xD736E47: loess_raw (loessc.c:117)
(The uninitiialized value is in someone else's code and I suspect
it was
either never intended to work or never tested.) No essential
change has
been made to the loess code for many years.
I would not have read the documentation to say that degree = 0 was
a
reasonable value. It is not to my mind 'a polynomial surface', and
loess() is described as a 'local regression' for degree 1 or 2 in
the
reference. So unless anyone wants to bury their heads in that
code I
think a perfectly adequate fix would be to disallow degree = 0.
(I vaguely recall debating allowing in the code ca 10 years ago.)
The code itself has
if (!match(degree, 0:2, 0))
stop("'degree' must be 0, 1 or 2")
though. "Local fitting of a constant" essentially becomes kernel
smoothing, right?
I do know the R code allows it: the question is whether it is worth
the effort of finding the problem(s) in the underlying c/dloess
code, whose manual (and our reference) is entirely about 1 or 2. I
am concerned that there may be other things lurking in the degree=0
case if it was never tested (in the netlib version: I am sure it was
only minmally tested through my R interface).
I checked the original documentation on netlib and that says
29 DIM dimension of local regression
1 constant
d+1 linear (default)
(d+2)(d+1)/2quadratic
Modified by ehg127 if cdeg
True. There are plenty of reasons why one wouldn't want to use
degree=0 anyway. And I'm sure there are plenty of other simple ways
to achieve the same effect.
I ran into the problem because some code I'm planning on distributing
as part of a paper submission "blends" partway down to degree 0
smoothing at the endpoints to reduce the variance. The only bad
effect of disallowing degree 0 is for anyone with code depending on
it, although there are probably few that use it and better to
disallow
than to give an incorrect computation. I got around the problem by
installing a modified loess by one of Cleveland's former students:
https://centauri.stat.purdue.edu:98/loess/
(but don't want to require others who use my code to do so as well).
What is very strange to me is that it has been working fine in
previous R versions (tested on 2.7.1 and 2.6.1) and nothing has
changed in the loess source but yet it is having problems on 2.8.1.
Would this suggest it not being a problem with the netlib code?
Also strange that it reportedly works on Linux but not on Mac or
Windows. On the mac, the effect was much smaller. With windows, it
was predicting values like 2e215 whereas on the mac, you would almost
believe the results were legitimate if you didn't think about the
fact
that a weighted moving average involving half the data shouldn't
oscillate so much.
If the consensus is to keep degree=0, I'd be happy to help try to
find
the problem or provide a test case or something. Thanks for looking
into this.
Ryan
On Thu, 5 Mar 2009, Uwe Ligges wrote:
Berwin A Turlach wrote:
G'day Peter,
On Thu, 05 Mar 2009 09:09:27 +0100
Peter Dalgaard wrote:
rha...@stat.purdue.edu wrote:
<>
This is a C
Re: [Rd] bug (PR#13570)
On 05/03/2009 9:42 AM, Ryan Hafen wrote:
On Mar 5, 2009, at 7:59 AM, Prof Brian Ripley wrote:
On Thu, 5 Mar 2009, Peter Dalgaard wrote:
Prof Brian Ripley wrote:
Undortunately the example is random, so not really reproducible
(and I
see nothing wrong on my Mac). However, Linux valgrind on R-devel is
showing a problem:
==3973== Conditional jump or move depends on uninitialised value(s)
==3973==at 0xD76017B: ehg141_ (loessf.f:532)
==3973==by 0xD761600: lowesa_ (loessf.f:769)
==3973==by 0xD736E47: loess_raw (loessc.c:117)
(The uninitiialized value is in someone else's code and I suspect
it was
either never intended to work or never tested.) No essential
change has
been made to the loess code for many years.
I would not have read the documentation to say that degree = 0 was a
reasonable value. It is not to my mind 'a polynomial surface', and
loess() is described as a 'local regression' for degree 1 or 2 in
the
reference. So unless anyone wants to bury their heads in that
code I
think a perfectly adequate fix would be to disallow degree = 0.
(I vaguely recall debating allowing in the code ca 10 years ago.)
The code itself has
if (!match(degree, 0:2, 0))
stop("'degree' must be 0, 1 or 2")
though. "Local fitting of a constant" essentially becomes kernel
smoothing, right?
I do know the R code allows it: the question is whether it is worth
the effort of finding the problem(s) in the underlying c/dloess
code, whose manual (and our reference) is entirely about 1 or 2. I
am concerned that there may be other things lurking in the degree=0
case if it was never tested (in the netlib version: I am sure it was
only minmally tested through my R interface).
I checked the original documentation on netlib and that says
29 DIM dimension of local regression
1 constant
d+1 linear (default)
(d+2)(d+1)/2quadratic
Modified by ehg127 if cdegwhich seems to confirm that degree = 0 was intended to be allowed,
and what I dimly recall from ca 1998 is debating whether the R code
should allow that or not.
If left to me I would say I did not wish to continue to support
degree = 0.
True. There are plenty of reasons why one wouldn't want to use
degree=0 anyway. And I'm sure there are plenty of other simple ways
to achieve the same effect.
I ran into the problem because some code I'm planning on distributing
as part of a paper submission "blends" partway down to degree 0
smoothing at the endpoints to reduce the variance. The only bad
effect of disallowing degree 0 is for anyone with code depending on
it, although there are probably few that use it and better to disallow
than to give an incorrect computation. I got around the problem by
installing a modified loess by one of Cleveland's former students: https://centauri.stat.purdue.edu:98/loess/
(but don't want to require others who use my code to do so as well).
What is very strange to me is that it has been working fine in
previous R versions (tested on 2.7.1 and 2.6.1) and nothing has
changed in the loess source but yet it is having problems on 2.8.1.
Would this suggest it not being a problem with the netlib code?
Also strange that it reportedly works on Linux but not on Mac or
Windows. On the mac, the effect was much smaller. With windows, it
was predicting values like 2e215 whereas on the mac, you would almost
believe the results were legitimate if you didn't think about the fact
that a weighted moving average involving half the data shouldn't
oscillate so much.
I think it's pretty clear that it's using an uninitialized value. On
other systems (and previous versions) we've just been lucky, and those
locations held values like 0.0 that didn't matter.
If the consensus is to keep degree=0, I'd be happy to help try to find
the problem or provide a test case or something. Thanks for looking
into this.
I'd say right now the consensus among R core members is that nobody
wants to support degree=0, but if you're volunteering, the consensus
could change.
Duncan Murdoch
Ryan
On Thu, 5 Mar 2009, Uwe Ligges wrote:
Berwin A Turlach wrote:
G'day Peter,
On Thu, 05 Mar 2009 09:09:27 +0100
Peter Dalgaard wrote:
rha...@stat.purdue.edu wrote:
<>
This is a CRITICAL bug!!! I have verified it in R 2.8.1 for mac
and for windows. The problem is with loess degree=0 smoothing.
For example, try the following:
x <- 1:100
y <- rnorm(100)
plot(x, y)
lines(predict(loess(y ~ x, degree=0, span=0.5)))
This is obviously wrong.
Obvious? How? I don't see anything particularly odd (on Linux).
Neither did I on linux; but the OP mentioned mac and windows. On
windows, on running that code, the lines() command added a lot of
vertical lines; most spanning the complete window but some only
part.
Executing the code a second time (or in steps) gave sensible
results. My guess woul
Re: [Rd] problem building a package with C code (PR#13572)
On 05/03/2009 9:55 AM, pfar...@mat.puc.cl wrote: Hi, my name is Paula. Im trying to learn how to build an R package in Windows XP using a simple example which includes a C source code. The foo.c file is located in mypkg/src/foo.c. I used the command Rcmd build --force --binary [pkgpath]. The problem is when I install the zip file in R the function foo doesn´t exist. The result a recieved during the building process is copied below. I really appreciate some helpI very new on it and I have spent a lot of time trying to solve the problem alone without success. I'd guess you didn't load the dll. See my useR2008 talk for the steps needed to produce a package containing C code. It looks as though you're close. Duncan Murdoch Thanks a lot Paula Fariña C:\>cd C:\Archivos de programa\R\R-2.7.2\bin C:\Archivos de programa\R\R-2.7.2\bin>Rcmd build --force --binary D:\2009\c2r\my pkg * checking for file 'D:\2009\c2r\mypkg/DESCRIPTION' ... OK * preparing 'D:\2009\c2r\mypkg': * checking DESCRIPTION meta-information ... OK * cleaning src * removing junk files * checking for LF line-endings in source and make files file 'mypkg/src/foo.c' had non-LF line endings * checking for empty or unneeded directories * building binary distribution WARNING: some HTML links may not be found installing R.css in C:/DOCUME~1/Lir/CONFIG~1/Temp/Rinst96073413 Using auto-selected zip options '' -- Making package mypkg adding build stamp to DESCRIPTION making DLL ... making foo.d from foo.c gcc -std=gnu99 -Ic:/ARCHIV~1/R/R-27~1.2/include -O3 -Wall -c foo.c -o foo .o windres --preprocessor="gcc -E -xc -DRC_INVOKED" -I c:/ARCHIV~1/R/R-27~1.2/inclu de -i mypkg_res.rc -o mypkg_res.o gcc -std=gnu99 -shared -s -o mypkg.dll mypkg.def foo.o mypkg_res.o -Lc:/ARCH IV~1/R/R-27~1.2/bin-lR ... DLL made installing DLL installing R files installing data files installing man source files installing indices not zipping data installing help >>> Building/Updating help pages for package 'mypkg' Formats: text html latex example chm d texthtmllatex example chm e texthtmllatex example chm f texthtmllatex example chm g texthtmllatex example chm mypkg-package texthtmllatex example chm Microsoft HTML Help Compiler 4.74.8702 Compiling c:\DOCUME~1\Lir\CONFIG~1\Temp\Rbuild96033789\mypkg\chm\mypkg.chm Compile time: 0 minutes, 2 seconds 6 Topics 11 Local links 0 Internet links 1 Graphic Created c:\DOCUME~1\Lir\CONFIG~1\Temp\Rbuild96033789\mypkg\chm\mypkg.chm, 18,792 bytes Compression increased file by 2,040 bytes. adding MD5 sums packaged installation of package 'mypkg' as mypkg_1.0.zip * DONE (mypkg) C:\Archivos de programa\R\R-2.7.2\bin> __ 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] Chunk of text won't show up when compiling Rd file
On 05/03/2009 12:29 PM, Ben Bryant wrote:
Greetings -
I am trying to document the "value" section of a function. The function
returns a list, but the list itself also has attributes. I would like to
itemize the list entries, and itemize the attributes, but in between I would
like to have a sentence or two about the attributes in general. However,
for some reason this intermediate sentence won't show up in the compiled
version, so that it appears the attributes are all just elements in the
returned list. Something is making the assumption that the itemized list
must be uninterrupted, and I don't know the code to tell it not to do that.
I presume it is a very easy fix, but I haven't been able to get at it.
I pasted some example explanatory Rd code below.
Thanks!
-Ben Bryant
Could you give your example a try in R-devel, with one of the new
conversion functions, e.g. tools::Rd2HTML? I don't think these new
functions are used by default even in R-devel, but if they solve your
problem, there will be less motivation to fix the legacy functions.
Duncan Murdoch
% Just the Value Section:
\value{
Here I have a paragraph giving the general description of the output form.
Then I have an itemized list describing the elements.
\item{listobject1}{Description of list object 1}
\item{listobject2}{Description of list object 2}
%... etc
\item{lastlistobject}{Description of the last list object}
THEN, here I have a general description of the attributes, and the text
represented by this sentence is what doesn't show up, because it's in
between more of an itemized list.
\item{attribute1}{details of attribute 1}
\item{attribute 2}{details of attribute 2}
Then I have text here, and this text does show up.
}
[[alternative HTML version deleted]]
__
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] quantile(), IQR() and median() for factors
Dear all, from the help page of quantile: "x numeric vectors whose sample quantiles are wanted. Missing values are ignored." from the help page of IQR: "x a numeric vector." as a matter of facts it seems that both quantile() and IQR() do not check for the presence of a numeric input. See the following: set.seed(11) x <- rbinom(n=11,size=2,prob=.5) x <- factor(x,ordered=TRUE) x [1] 1 0 1 0 0 2 0 1 2 0 0 Levels: 0 < 1 < 2 > quantile(x) 0% 25% 50% 75% 100% 0 0 2 Levels: 0 < 1 < 2 Warning messages: 1: In Ops.ordered((1 - h), qs[i]) : '*' is not meaningful for ordered factors 2: In Ops.ordered(h, x[hi[i]]) : '*' is not meaningful for ordered factors > IQR(x) [1] 1 whereas median has the check: > median(x) Error in median.default(x) : need numeric data I also take the opportunity to ask your comments on the following related subject: In my opinion it would be convenient that median() and the like (quantile(), IQR()) be implemented for ordered factors for which in fact they can be well defined. For instance, in this way functions like apply(x,FUN=median,...) could be used without the need of further processing for data frames that contain both numeric variables and ordered factors. If on the one hand, to my limited knowledge, in English introductory statistics textbooks the fact that the median is well defined for ordered categorical variables is only mentioned marginally, on the other hand, in the Italian Statistics literature this is often discussed in detail and this could mislead students and practitioners that might expect median() to work for ordered factors. In this message https://stat.ethz.ch/pipermail/r-help/2003-November/042684.html Martin Maechler considers the possibility of doing such a job by allowing for extra arguments "low" and "high" as it is done for mad(). I am willing to give a contribution if requested, and comments are welcome. Thank you for the attention, kind regards, Simone > R.version _ platform i386-pc-mingw32 arch i386 os mingw32 system i386, mingw32 status major 2 minor 8.1 year 2008 month 12 day 22 svn rev 47281 language R version.string R version 2.8.1 (2008-12-22) LC_COLLATE=Italian_Italy.1252;LC_CTYPE=Italian_Italy.1252;LC_MONETARY=Italian_Italy.1252;LC_NUMERIC=C;LC_TIME=Italian_Italy.1252 -- __ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: +39 051 232153 http://www2.stat.unibo.it/giannerini/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug (PR#13570)
I see the same problem on Windows XP.
But if I run loess with surface='direct' then the results are correct. So it
looks like the problem comes from the smoothing/interpolating, not the main
loess algorithm.
--
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
greg.s...@imail.org
801.408.8111
> -Original Message-
> From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-
> project.org] On Behalf Of Ryan Hafen
> Sent: Thursday, March 05, 2009 7:43 AM
> To: Prof Brian Ripley
> Cc: Uwe Ligges; Berwin A Turlach; r-de...@stat.math.ethz.ch; Peter
> Dalgaard
> Subject: Re: [Rd] bug (PR#13570)
>
>
> On Mar 5, 2009, at 7:59 AM, Prof Brian Ripley wrote:
>
> > On Thu, 5 Mar 2009, Peter Dalgaard wrote:
> >
> >> Prof Brian Ripley wrote:
> >>> Undortunately the example is random, so not really reproducible
> >>> (and I
> >>> see nothing wrong on my Mac). However, Linux valgrind on R-devel is
> >>> showing a problem:
> >>>
> >>> ==3973== Conditional jump or move depends on uninitialised value(s)
> >>> ==3973==at 0xD76017B: ehg141_ (loessf.f:532)
> >>> ==3973==by 0xD761600: lowesa_ (loessf.f:769)
> >>> ==3973==by 0xD736E47: loess_raw (loessc.c:117)
> >>>
> >>> (The uninitiialized value is in someone else's code and I suspect
> >>> it was
> >>> either never intended to work or never tested.) No essential
> >>> change has
> >>> been made to the loess code for many years.
> >>>
> >>> I would not have read the documentation to say that degree = 0 was
> a
> >>> reasonable value. It is not to my mind 'a polynomial surface', and
> >>> loess() is described as a 'local regression' for degree 1 or 2 in
> >>> the
> >>> reference. So unless anyone wants to bury their heads in that
> >>> code I
> >>> think a perfectly adequate fix would be to disallow degree = 0.
> >>> (I vaguely recall debating allowing in the code ca 10 years ago.)
> >>
> >> The code itself has
> >>
> >> if (!match(degree, 0:2, 0))
> >> stop("'degree' must be 0, 1 or 2")
> >>
> >> though. "Local fitting of a constant" essentially becomes kernel
> >> smoothing, right?
> >
> > I do know the R code allows it: the question is whether it is worth
> > the effort of finding the problem(s) in the underlying c/dloess
> > code, whose manual (and our reference) is entirely about 1 or 2. I
> > am concerned that there may be other things lurking in the degree=0
> > case if it was never tested (in the netlib version: I am sure it was
> > only minmally tested through my R interface).
> >
> > I checked the original documentation on netlib and that says
> >
> > 29 DIM dimension of local regression
> >1 constant
> >d+1 linear (default)
> >(d+2)(d+1)/2quadratic
> >Modified by ehg127 if cdeg >
> > which seems to confirm that degree = 0 was intended to be allowed,
> > and what I dimly recall from ca 1998 is debating whether the R code
> > should allow that or not.
> >
> > If left to me I would say I did not wish to continue to support
> > degree = 0.
>
> True. There are plenty of reasons why one wouldn't want to use
> degree=0 anyway. And I'm sure there are plenty of other simple ways
> to achieve the same effect.
>
> I ran into the problem because some code I'm planning on distributing
> as part of a paper submission "blends" partway down to degree 0
> smoothing at the endpoints to reduce the variance. The only bad
> effect of disallowing degree 0 is for anyone with code depending on
> it, although there are probably few that use it and better to disallow
> than to give an incorrect computation. I got around the problem by
> installing a modified loess by one of Cleveland's former students:
> https://centauri.stat.purdue.edu:98/loess/
> (but don't want to require others who use my code to do so as well).
>
> What is very strange to me is that it has been working fine in
> previous R versions (tested on 2.7.1 and 2.6.1) and nothing has
> changed in the loess source but yet it is having problems on 2.8.1.
> Would this suggest it not being a problem with the netlib code?
>
> Also strange that it reportedly works on Linux but not on Mac or
> Windows. On the mac, the effect was much smaller. With windows, it
> was predicting values like 2e215 whereas on the mac, you would almost
> believe the results were legitimate if you didn't think about the fact
> that a weighted moving average involving half the data shouldn't
> oscillate so much.
>
> If the consensus is to keep degree=0, I'd be happy to help try to find
> the problem or provide a test case or something. Thanks for looking
> into this.
>
> Ryan
>
>
>
> >>
> >>
> >>> On Thu, 5 Mar 2009, Uwe Ligges wrote:
> >>>
> Berwin A Turlach wrote:
> > G'day Peter,
> >
> > On Thu, 05 Mar 2009 09:09:27 +0100
> > Peter Dalgaard wrote:
> >
> >> rha...@stat.purdue.edu wrote:
> >>> <>
> >>>
> >>> This is a CRITICAL bu
Re: [Rd] bug (PR#13570)
Mark Difford wrote: Hi Uwe, This is not a problem under Vista, using "a" development version (mine now somewhat outdated). Mark, as others have reported and debugged so far and you can see on the lists, the problem is more serious than I thought it is and it is probably also a problem under R-devel and here are just some nice lucky circumstances that we do not observe obvious miscalculations any more. Best, Uwe Regards, Mark. sessionInfo() R version 2.9.0 Under development (unstable) (2009-01-22 r47686) i386-pc-mingw32 locale: LC_COLLATE=English_South Africa.1252;LC_CTYPE=English_South Africa.1252;LC_MONETARY=English_South Africa.1252;LC_NUMERIC=C;LC_TIME=English_South Africa.1252 attached base packages: [1] splines stats graphics grDevices utils datasets methods base other attached packages: [1] ade4_1.4-10 Design_2.1-2survival_2.34-1 Hmisc_3.5-2 loaded via a namespace (and not attached): [1] cluster_1.11.12gamlss_1.9-4 grid_2.9.0 lattice_0.17-20 latticeExtra_0.5-4 [6] MASS_7.2-45tools_2.9.0 Uwe Ligges-3 wrote: Berwin A Turlach wrote: G'day Peter, On Thu, 05 Mar 2009 09:09:27 +0100 Peter Dalgaard wrote: rha...@stat.purdue.edu wrote: <> This is a CRITICAL bug!!! I have verified it in R 2.8.1 for mac and for windows. The problem is with loess degree=0 smoothing. For example, try the following: x <- 1:100 y <- rnorm(100) plot(x, y) lines(predict(loess(y ~ x, degree=0, span=0.5))) This is obviously wrong. Obvious? How? I don't see anything particularly odd (on Linux). Neither did I on linux; but the OP mentioned mac and windows. On windows, on running that code, the lines() command added a lot of vertical lines; most spanning the complete window but some only part. Executing the code a second time (or in steps) gave sensible results. My guess would be that some memory is not correctly allocated or initialised. Or is it something like an object with storage mode "integer" being passed to a double? But then, why doesn't it show on linux? Happy bug hunting. If my guess is correct, then I have no idea how to track down such things under windows. Cheers, Berwin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel Please can you folks try under R-devel (to be R-2.9.0 in a couple of weeks) and report if you still see it. I do not under R-devel (but do under R-release), so my guess is that something called by loess() has been fixed in the meantime. Moreover it is not the plot stuff that was wrong under R-2.8.1 (release) but the loess computations. Uwe Ligges __ 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] question
I posted this a few years ago (but found I never really had a
need for it):
http://tolstoy.newcastle.edu.au/R/help/04/06/1430.html
On Thu, Mar 5, 2009 at 9:22 AM, ivo welch wrote:
> dear R developers: it is of course easy for a third party to make
> suggestions if this third party is both clueless and does not put in
> any work. with these caveats, let me suggest something.
>
> The syntax for returning multiple arguments does not strike me as
> particularly appealing. would it not possible to allow syntax like:
>
> f= function() { return( rnorm(10), rnorm(20) ) }
> (a,d$b) = f()
>
> this would just hide the list conversion and unconversion. yes, I
> know how to accomplish this with lists, but it does not seem pretty or
> natural.
>
> regards,
>
> /ivo
>
> __
> 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] Package issue
Terry,
1. R CMD build on your package reports at least two warnings for me.
2. R CMD check gives dozens of warnings even before the test cases where
it already stops in gtest.R rather than anaything called gchol2.R.
3. There is no tests/gchol2.R !!!
Perhaps you want to clean up some other issues or update the svn
repository before you post again?
Best wishes,
Uwe
Terry Therneau wrote:
I've converted the bdsmatrix package (used by coxme) to the newer style of
S4, and uploaded it. It is in the pkg directory of survival, on r-forge.
I'm stuck on something that is almost certainly a namespace issue. I've
borrowed liberally from Matrix (a big help) and read the documentation, and
just upgraded to 2.8.1 - but still stuck.
All the tests work when I run them "by hand", but tests/gchol2.R fails
when run from R CMD check. The failure looks a lot like a method for
setMethod('diag', 'gchol')
is not being found.
The NAMESPACE file exports diag, along with several other methods that
do work. Any help would be appreciated.
Terry Therneau
__
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 (PR#13570)
On Mar 5, 2009, at 7:59 AM, Prof Brian Ripley wrote:
On Thu, 5 Mar 2009, Peter Dalgaard wrote:
Prof Brian Ripley wrote:
Undortunately the example is random, so not really reproducible
(and I
see nothing wrong on my Mac). However, Linux valgrind on R-devel is
showing a problem:
==3973== Conditional jump or move depends on uninitialised value(s)
==3973==at 0xD76017B: ehg141_ (loessf.f:532)
==3973==by 0xD761600: lowesa_ (loessf.f:769)
==3973==by 0xD736E47: loess_raw (loessc.c:117)
(The uninitiialized value is in someone else's code and I suspect
it was
either never intended to work or never tested.) No essential
change has
been made to the loess code for many years.
I would not have read the documentation to say that degree = 0 was a
reasonable value. It is not to my mind 'a polynomial surface', and
loess() is described as a 'local regression' for degree 1 or 2 in
the
reference. So unless anyone wants to bury their heads in that
code I
think a perfectly adequate fix would be to disallow degree = 0.
(I vaguely recall debating allowing in the code ca 10 years ago.)
The code itself has
if (!match(degree, 0:2, 0))
stop("'degree' must be 0, 1 or 2")
though. "Local fitting of a constant" essentially becomes kernel
smoothing, right?
I do know the R code allows it: the question is whether it is worth
the effort of finding the problem(s) in the underlying c/dloess
code, whose manual (and our reference) is entirely about 1 or 2. I
am concerned that there may be other things lurking in the degree=0
case if it was never tested (in the netlib version: I am sure it was
only minmally tested through my R interface).
I checked the original documentation on netlib and that says
29 DIM dimension of local regression
1 constant
d+1 linear (default)
(d+2)(d+1)/2quadratic
Modified by ehg127 if cdegwhich seems to confirm that degree = 0 was intended to be allowed,
and what I dimly recall from ca 1998 is debating whether the R code
should allow that or not.
If left to me I would say I did not wish to continue to support
degree = 0.
True. There are plenty of reasons why one wouldn't want to use
degree=0 anyway. And I'm sure there are plenty of other simple ways
to achieve the same effect.
I ran into the problem because some code I'm planning on distributing
as part of a paper submission "blends" partway down to degree 0
smoothing at the endpoints to reduce the variance. The only bad
effect of disallowing degree 0 is for anyone with code depending on
it, although there are probably few that use it and better to disallow
than to give an incorrect computation. I got around the problem by
installing a modified loess by one of Cleveland's former students: https://centauri.stat.purdue.edu:98/loess/
(but don't want to require others who use my code to do so as well).
What is very strange to me is that it has been working fine in
previous R versions (tested on 2.7.1 and 2.6.1) and nothing has
changed in the loess source but yet it is having problems on 2.8.1.
Would this suggest it not being a problem with the netlib code?
Also strange that it reportedly works on Linux but not on Mac or
Windows. On the mac, the effect was much smaller. With windows, it
was predicting values like 2e215 whereas on the mac, you would almost
believe the results were legitimate if you didn't think about the fact
that a weighted moving average involving half the data shouldn't
oscillate so much.
If the consensus is to keep degree=0, I'd be happy to help try to find
the problem or provide a test case or something. Thanks for looking
into this.
Ryan
On Thu, 5 Mar 2009, Uwe Ligges wrote:
Berwin A Turlach wrote:
G'day Peter,
On Thu, 05 Mar 2009 09:09:27 +0100
Peter Dalgaard wrote:
rha...@stat.purdue.edu wrote:
<>
This is a CRITICAL bug!!! I have verified it in R 2.8.1 for mac
and for windows. The problem is with loess degree=0 smoothing.
For example, try the following:
x <- 1:100
y <- rnorm(100)
plot(x, y)
lines(predict(loess(y ~ x, degree=0, span=0.5)))
This is obviously wrong.
Obvious? How? I don't see anything particularly odd (on Linux).
Neither did I on linux; but the OP mentioned mac and windows. On
windows, on running that code, the lines() command added a lot of
vertical lines; most spanning the complete window but some only
part.
Executing the code a second time (or in steps) gave sensible
results. My guess would be that some memory is not correctly
allocated or
initialised. Or is it something like an object with storage mode
"integer" being passed to a double? But then, why doesn't it
show on
linux?
Happy bug hunting. If my guess is correct, then I have no idea
how to
track down such things under windows.
Cheers,
Berwin
__
R-devel@r-project.org m
[Rd] question
dear R developers: it is of course easy for a third party to make
suggestions if this third party is both clueless and does not put in
any work. with these caveats, let me suggest something.
The syntax for returning multiple arguments does not strike me as
particularly appealing. would it not possible to allow syntax like:
f= function() { return( rnorm(10), rnorm(20) ) }
(a,d$b) = f()
this would just hide the list conversion and unconversion. yes, I
know how to accomplish this with lists, but it does not seem pretty or
natural.
regards,
/ivo
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug (PR#13570)
Hi Uwe, This is not a problem under Vista, using "a" development version (mine now somewhat outdated). Regards, Mark. sessionInfo() R version 2.9.0 Under development (unstable) (2009-01-22 r47686) i386-pc-mingw32 locale: LC_COLLATE=English_South Africa.1252;LC_CTYPE=English_South Africa.1252;LC_MONETARY=English_South Africa.1252;LC_NUMERIC=C;LC_TIME=English_South Africa.1252 attached base packages: [1] splines stats graphics grDevices utils datasets methods base other attached packages: [1] ade4_1.4-10 Design_2.1-2survival_2.34-1 Hmisc_3.5-2 loaded via a namespace (and not attached): [1] cluster_1.11.12gamlss_1.9-4 grid_2.9.0 lattice_0.17-20 latticeExtra_0.5-4 [6] MASS_7.2-45tools_2.9.0 Uwe Ligges-3 wrote: > > Berwin A Turlach wrote: >> G'day Peter, >> >> On Thu, 05 Mar 2009 09:09:27 +0100 >> Peter Dalgaard wrote: >> >>> rha...@stat.purdue.edu wrote: <> This is a CRITICAL bug!!! I have verified it in R 2.8.1 for mac and for windows. The problem is with loess degree=0 smoothing. For example, try the following: x <- 1:100 y <- rnorm(100) plot(x, y) lines(predict(loess(y ~ x, degree=0, span=0.5))) This is obviously wrong. >>> Obvious? How? I don't see anything particularly odd (on Linux). >> >> Neither did I on linux; but the OP mentioned mac and windows. >> >> On windows, on running that code, the lines() command added a lot of >> vertical lines; most spanning the complete window but some only part. >> >> Executing the code a second time (or in steps) gave sensible >> results. >> >> My guess would be that some memory is not correctly allocated or >> initialised. Or is it something like an object with storage mode >> "integer" being passed to a double? But then, why doesn't it show on >> linux? >> >> Happy bug hunting. If my guess is correct, then I have no idea how to >> track down such things under windows. >> >> Cheers, >> >> Berwin >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel > > > Please can you folks try under R-devel (to be R-2.9.0 in a couple of > weeks) and report if you still see it. I do not under R-devel (but do > under R-release), so my guess is that something called by loess() has > been fixed in the meantime. > > Moreover it is not the plot stuff that was wrong under R-2.8.1 (release) > but the loess computations. > > Uwe Ligges > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > -- View this message in context: http://www.nabble.com/bug-%28PR-13570%29-tp22346406p22350779.html Sent from the R devel mailing list archive at Nabble.com. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Chunk of text won't show up when compiling Rd file
Greetings -
I am trying to document the "value" section of a function. The function
returns a list, but the list itself also has attributes. I would like to
itemize the list entries, and itemize the attributes, but in between I would
like to have a sentence or two about the attributes in general. However,
for some reason this intermediate sentence won't show up in the compiled
version, so that it appears the attributes are all just elements in the
returned list. Something is making the assumption that the itemized list
must be uninterrupted, and I don't know the code to tell it not to do that.
I presume it is a very easy fix, but I haven't been able to get at it.
I pasted some example explanatory Rd code below.
Thanks!
-Ben Bryant
% Just the Value Section:
\value{
Here I have a paragraph giving the general description of the output form.
Then I have an itemized list describing the elements.
\item{listobject1}{Description of list object 1}
\item{listobject2}{Description of list object 2}
%... etc
\item{lastlistobject}{Description of the last list object}
THEN, here I have a general description of the attributes, and the text
represented by this sentence is what doesn't show up, because it's in
between more of an itemized list.
\item{attribute1}{details of attribute 1}
\item{attribute 2}{details of attribute 2}
Then I have text here, and this text does show up.
}
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] problem building a package with C code (PR#13572)
Hi, my name is Paula. Im trying to learn how to build an R package in Windows XP using a simple example which includes a C source code. The foo.c file is located in mypkg/src/foo.c. I used the command Rcmd build --force --binary [pkgpath]. The problem is when I install the zip file in R the function foo doesn´t exist. The result a recieved during the building process is copied below. I really appreciate some helpI very new on it and I have spent a lot of time trying to solve the problem alone without success. Thanks a lot Paula Fariña C:\>cd C:\Archivos de programa\R\R-2.7.2\bin C:\Archivos de programa\R\R-2.7.2\bin>Rcmd build --force --binary D:\2009\c2r\my pkg * checking for file 'D:\2009\c2r\mypkg/DESCRIPTION' ... OK * preparing 'D:\2009\c2r\mypkg': * checking DESCRIPTION meta-information ... OK * cleaning src * removing junk files * checking for LF line-endings in source and make files file 'mypkg/src/foo.c' had non-LF line endings * checking for empty or unneeded directories * building binary distribution WARNING: some HTML links may not be found installing R.css in C:/DOCUME~1/Lir/CONFIG~1/Temp/Rinst96073413 Using auto-selected zip options '' -- Making package mypkg adding build stamp to DESCRIPTION making DLL ... making foo.d from foo.c gcc -std=gnu99 -Ic:/ARCHIV~1/R/R-27~1.2/include -O3 -Wall -c foo.c -o foo .o windres --preprocessor="gcc -E -xc -DRC_INVOKED" -I c:/ARCHIV~1/R/R-27~1.2/inclu de -i mypkg_res.rc -o mypkg_res.o gcc -std=gnu99 -shared -s -o mypkg.dll mypkg.def foo.o mypkg_res.o -Lc:/ARCH IV~1/R/R-27~1.2/bin-lR ... DLL made installing DLL installing R files installing data files installing man source files installing indices not zipping data installing help >>> Building/Updating help pages for package 'mypkg' Formats: text html latex example chm d texthtmllatex example chm e texthtmllatex example chm f texthtmllatex example chm g texthtmllatex example chm mypkg-package texthtmllatex example chm Microsoft HTML Help Compiler 4.74.8702 Compiling c:\DOCUME~1\Lir\CONFIG~1\Temp\Rbuild96033789\mypkg\chm\mypkg.chm Compile time: 0 minutes, 2 seconds 6 Topics 11 Local links 0 Internet links 1 Graphic Created c:\DOCUME~1\Lir\CONFIG~1\Temp\Rbuild96033789\mypkg\chm\mypkg.chm, 18,792 bytes Compression increased file by 2,040 bytes. adding MD5 sums packaged installation of package 'mypkg' as mypkg_1.0.zip * DONE (mypkg) C:\Archivos de programa\R\R-2.7.2\bin> __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Package issue
I've converted the bdsmatrix package (used by coxme) to the newer style of
S4, and uploaded it. It is in the pkg directory of survival, on r-forge.
I'm stuck on something that is almost certainly a namespace issue. I've
borrowed liberally from Matrix (a big help) and read the documentation, and
just upgraded to 2.8.1 - but still stuck.
All the tests work when I run them "by hand", but tests/gchol2.R fails
when run from R CMD check. The failure looks a lot like a method for
setMethod('diag', 'gchol')
is not being found.
The NAMESPACE file exports diag, along with several other methods that
do work. Any help would be appreciated.
Terry Therneau
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] heatmap without dendrogams (PR#13512)
Thanks Uwe, I've added your patch to R-devel (2.9.0 to be).
On Thu, 19 Feb 2009, lig...@statistik.tu-dortmund.de wrote:
j.j.goe...@lumc.nl wrote:
Full_Name: Jelle Goeman
Version: 2.8.1
OS: Win XP
Submission from: (NULL) (87.212.67.197)
I get the following error message when I try to make a heatmap (package stats),
without the associated dendrograms.
X <- matrix(rnorm(200),20,10)
XX <- crossprod(X)
heatmap(XX, Rowv= NA, revC=TRUE)
Error in rev(ddr) : object "ddr" not found
heatmap(XX, Rowv= NA, sym=TRUE)
Error in heatmap(XX, Rowv = NA, sym = TRUE) : object "ddr" not found
According to the help file, this should work; indeed it does if I set revC or
sym to FALSE. Seems like ddr should be initialized to something like 1:ncol(X)
for the no-dendrogram case.
Kind regards,
Jelle
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Since it looks like nobody answered so far, let me suggest a patch:
D:\RCompile\recent\R\src\library\stats\R>diff -u dendrogram.R
dendrogram.R-new
--- dendrogram.R2009-02-19 18:54:18.832062400 +0100
+++ dendrogram.R-new2009-02-19 18:52:29.612961900 +0100
@@ -699,7 +699,7 @@
x <- t(x)
if(revC) { # x columns reversed
iy <- nr:1
-ddr <- rev(ddr)
+if(doRdend) ddr <- rev(ddr)
x <- x[,iy]
} else iy <- 1L:nr
Best wishes,
Uwe Ligges
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Brian D. Ripley, rip...@stats.ox.ac.uk
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] (PR#13553) wishlist boxplot
No objections from Martin or elsewhere, so I have now committed this. Thanks, Uwe. On Tue, 24 Feb 2009, Uwe Ligges wrote: > [CCing Martin and Brian who had both done most svn commits of boxplot.R so > far] > > > A very minor wishlist item that I should have already reported years ago: > > All the time when I need presentation/publication quality boxplots, I add > par(lend=1) in my code in order to suppress the ugly median line that does > not stop at the end of the box given the rounded line endings. > > Ugly example: > > boxplot(1:10, lwd=30) > > > > I'd like the following very minor change for boxplots: > > D:\Rcompile\recent\R\src\library\graphics\R>diff -u boxplot.R boxplot-new.R > --- boxplot.R 2009-02-24 18:04:47.265625000 +0100 > +++ boxplot-new.R 2009-02-24 18:10:02.0 +0100 > @@ -148,7 +148,7 @@ > ## Median > xysegments(xP(x, -wntch), stats[3L], >xP(x, +wntch), stats[3L], > - lty = medlty[i], lwd = medlwd[i], col = medcol[i]) > + lty = medlty[i], lwd = medlwd[i], col = medcol[i], lend=1) > xypoints(x, stats[3L], > pch = medpch[i], cex = medcex[i], col= medcol[i], bg = > medbg[i]) > ## Whiskers > > > > Best wishes, > Uwe Ligges > -- Brian D. Ripley, rip...@stats.ox.ac.uk 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 Rdconv(.pm) (PR#13575)
The problem is that \pkg gets included (unescaped) in a Perl
substitution, and in modern Perl \p has a meaning (Unicode property).
Needs to be escaped/quoted, or the code to work a different way (which
is probably preferable).
On Thu, 5 Mar 2009, lig...@statistik.tu-dortmund.de wrote:
For the record (and as privately discussed with Brian Ripley), happens
with all recent versions of R including R-devel from today:
Consider a simple a.Rd file containing the lines
==
\name{a}
\title{a}
\value{\code{a} \code{\link[a]{a}} \pkg{a}
\item{a}{a}
}
==
with these lines, I get, e.g.:
==
R CMD Rdconv --type="txt" a.Rd
a package:unknown R Documentation
a
Value:
'a' 'a' 'a'
Can't find Unicode property definition "k" at
d:/Rcompile/recent/R/share/perl/R/Rdconv.pm line 2173,
<$rdfile> line 5.
==
Version:
platform = i386-pc-mingw32
arch = i386
os = mingw32
system = i386, mingw32
status = Under development (unstable)
major = 2
minor = 9.0
year = 2009
month = 03
day = 03
svn rev = 48046
language = R
version.string = R version 2.9.0 Under development (unstable)
(2009-03-03 r48046)
Windows Server 2008 x64 (build 6001) Service Pack 1
Locale:
LC_COLLATE=C;LC_CTYPE=German_Germany.1252;LC_MONETARY=C;LC_NUMERIC=C;LC_TIME=C
Search Path:
.GlobalEnv, package:stats, package:graphics, package:grDevices,
package:utils, package:datasets, package:methods, Autoloads, package:base
Uwe Ligges
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Brian D. Ripley, rip...@stats.ox.ac.uk
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] methods package
John, > the 2008 book ... I suspected that I had overlooked something simple. This fits the bill. > R 2.8.1 I have been using 2.7. I will update. Thanks for the help. Terry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Bug in Rdconv(.pm) (PR#13575)
For the record (and as privately discussed with Brian Ripley), happens
with all recent versions of R including R-devel from today:
Consider a simple a.Rd file containing the lines
==
\name{a}
\title{a}
\value{\code{a} \code{\link[a]{a}} \pkg{a}
\item{a}{a}
}
==
with these lines, I get, e.g.:
==
R CMD Rdconv --type="txt" a.Rd
a package:unknown R Documentation
a
Value:
'a' 'a' 'a'
Can't find Unicode property definition "k" at
d:/Rcompile/recent/R/share/perl/R/Rdconv.pm line 2173,
<$rdfile> line 5.
==
Version:
platform = i386-pc-mingw32
arch = i386
os = mingw32
system = i386, mingw32
status = Under development (unstable)
major = 2
minor = 9.0
year = 2009
month = 03
day = 03
svn rev = 48046
language = R
version.string = R version 2.9.0 Under development (unstable)
(2009-03-03 r48046)
Windows Server 2008 x64 (build 6001) Service Pack 1
Locale:
LC_COLLATE=C;LC_CTYPE=German_Germany.1252;LC_MONETARY=C;LC_NUMERIC=C;LC_TIME=C
Search Path:
.GlobalEnv, package:stats, package:graphics, package:grDevices,
package:utils, package:datasets, package:methods, Autoloads, package:base
Uwe Ligges
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] methods package
Hi Terry,
Terry Therneau wrote:
I'm working on the next version of coxme, one step of which is converting
the bdsmatrix library from Splus to R. Actually, it is a conversion from
S4 methods as first described in the Green book to S4 methods as they
currently exist. Mostly it's going ok, but not entirely.
1. The biggest issue is lack of documentation. The online help pages have
not been a help; they keep saying it's "as found in the green book - almost".
I've looked for the package on CRAN in the hopes for more there, but can't
find it. Perchance there is something obvious that I am missing?
Well, one is that there is a 2008 book, "Software for Data Analysis",
that I wrote partly to describe this and other topics from an R
perspective. It's a reference on most pages of documentation related to
methods (in R version 2.8.1; you should be using that and/or the r-devel
version if you're revising a package).
John
2. The changes are small but numerous. The current one that has me puzzled
is a method for addition:
setMethod(Ops, signature=c('numeric', 'bdsmatrix'),
Let xmat be ordinary and bmat be a bdsmatrix. In the old code "xmat + bmat"
fell to this method (which knows what to do), in the current R I get
failure due to no method found. is.numeric(xmat) is TRUE.
What is the fix?
3. In the green book the examples used .Dim and .Dimnames slots, the Matrix
library uses Dim and Dimnames. Is there a good reason to choose one or the
other?
I'll be out of town for the next few days (son's wedding) so instant response
is not necessary.
Terry Therneau
__
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] Spearman's rank correlation test (PR#13574)
Full_Name: Petr Savicky
Version: 2.7.2, 2.8.1, 2.9.0
OS: Linux
Submission from: (NULL) (147.231.6.9)
The p-value of Spearman's rank correlation test is calculated in
cor.test(x, y, method="spearman")
using algorithm AS 89. However, the way how AS 89 is used incures error,
which may be an order of magnitude larger than the error of the original
algorithm.
The paper, which introduced AS 89, provides error bounds, which are larger
than the actual error. The reason may be, that current implementation of
AS 89 uses more acurate estimate of the distribution function of the normal
distribution. The error of the R implementation of cor.test() for positive
correlation and n = 11 is larger than this pessimistic upper bound.
The problem is discussed in more detail in R-devel postings
https://stat.ethz.ch/pipermail/r-devel/2009-January/051936.html
https://stat.ethz.ch/pipermail/r-devel/2009-February/052112.html
A patch correcting the problem in the current development version
R version 2.9.0 Under development (unstable) (2009-03-03 r48046)
is as follows.
--- R-devel/src/library/stats/R/cor.test.R 2008-12-14 17:51:56.0 +0100
+++ R-cor.test/src/library/stats/R/cor.test.R 2009-03-05 10:39:07.383841736
+0100
@@ -151,9 +151,9 @@
pspearman <- function(q, n, lower.tail = TRUE) {
if(n <= 1290 && exact) # n*(n^2 - 1) does not overflow
.C("prho",
as.integer(n),
- as.double(round(q) + lower.tail),
+ as.double(round(q) + 2*lower.tail),
p = double(1L),
integer(1L),
as.logical(lower.tail),
PACKAGE = "stats")$p
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] persistence of data
Hello, I am developing a package that needs data to persist between sessions of R (For example a sqlite database file, or simple dumps of R data with save/load). What I am using so far is : file.path( Sys.getenv( "HOME"), ".R", "myPackage" ) but I was wondering if I am missing an "official" way to do this, similar to system.file does for installed packages. I am aware of the inst directory but this does not solve the problem in cases where the library is read only. Romain -- Romain Francois Independent R Consultant +33(0) 6 28 91 30 30 http://romainfrancois.blog.free.fr __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Firefox 3 and HTML Search
Firefox 3.0.7 has been released, and it fixes the bug described below. Duncan Murdoch On 1/12/2009 8:22 AM, Duncan Murdoch wrote: On 1/9/2009 11:59 AM, Duncan Murdoch wrote: I finally upgraded to Firefox 3.05 from 2.x, and now I can reproduce a bug a colleague has been complaining about but which I hadn't been able to reproduce before. In Windows, set Firefox as the default browser. Then in Rgui (seems to affect all versions up to R-devel), use the menu to open HTML Help, and choose "Search Engine and Keywords". Enter a keyword (e.g. plot), and click on "Search". Things are a lot slower than they used to be with Firefox 2, but eventually I get a result, starting out Search Results The search string was "plot" base-defunct Defunct Functions in Base Package expression Unevaluated Expressions However, the current URL is not the same as it was before: it is now listed as file:doc/html/index.html so the links don't work: they are entered as "../../../library/base/html/base-defunct.html", etc. in the source, and the expect the current directory to be file:doc/html/search/ If I set Internet Explorer as my default browser (yuck), things are fine, so this is a Firefox 3 bug, or a new Java bug, or an R bug that was masked before. Any suggestions of workarounds? As Brian and Marc pointed out, this is a Firefox 3.0 bug. As it turns out, it was repaired in November, but not approved for release in 3.0.5 or 3.0.6 (due this month??). I've been told it will make it into 3.0.7. For more on this, see https://bugzilla.mozilla.org/show_bug.cgi?id=445004 Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug (PR#13570)
On 3/5/2009 7:10 AM, Prof Brian Ripley wrote: Undortunately the example is random, so not really reproducible (and I see nothing wrong on my Mac). However, Linux valgrind on R-devel is showing a problem: I can reproduce it using y <- sin(x) instead of rnorm(100), on R-patched (not R-devel). ==3973== Conditional jump or move depends on uninitialised value(s) ==3973==at 0xD76017B: ehg141_ (loessf.f:532) ==3973==by 0xD761600: lowesa_ (loessf.f:769) ==3973==by 0xD736E47: loess_raw (loessc.c:117) I don't see why there would be errors at those spots, but I did try tracing into loessf.f, and it's really a maze of code. In case someone wants to follow up, it looks as though the ehg128 function returns a garbage value on the first call. Working backwards through it, this is because the local variable s is garbage, because g(0,1) (an array, not a function call) is garbage at line 957, which is because it got set as garbage somewhere between being initialized at line 918, and line 957. I think the problem happened at lines 950/951, but I didn't follow up to see why. (The uninitiialized value is in someone else's code and I suspect it was either never intended to work or never tested.) No essential change has been made to the loess code for many years. I would not have read the documentation to say that degree = 0 was a reasonable value. It is not to my mind 'a polynomial surface', and loess() is described as a 'local regression' for degree 1 or 2 in the reference. So unless anyone wants to bury their heads in that code I think a perfectly adequate fix would be to disallow degree = 0. (I vaguely recall debating allowing in the code ca 10 years ago.) I agree that's the best solution. Duncan Murdoch On Thu, 5 Mar 2009, Uwe Ligges wrote: Berwin A Turlach wrote: G'day Peter, On Thu, 05 Mar 2009 09:09:27 +0100 Peter Dalgaard wrote: rha...@stat.purdue.edu wrote: <> This is a CRITICAL bug!!! I have verified it in R 2.8.1 for mac and for windows. The problem is with loess degree=0 smoothing. For example, try the following: x <- 1:100 y <- rnorm(100) plot(x, y) lines(predict(loess(y ~ x, degree=0, span=0.5))) This is obviously wrong. Obvious? How? I don't see anything particularly odd (on Linux). Neither did I on linux; but the OP mentioned mac and windows. On windows, on running that code, the lines() command added a lot of vertical lines; most spanning the complete window but some only part. Executing the code a second time (or in steps) gave sensible results. My guess would be that some memory is not correctly allocated or initialised. Or is it something like an object with storage mode "integer" being passed to a double? But then, why doesn't it show on linux? Happy bug hunting. If my guess is correct, then I have no idea how to track down such things under windows. Cheers, Berwin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel Please can you folks try under R-devel (to be R-2.9.0 in a couple of weeks) and report if you still see it. I do not under R-devel (but do under R-release), so my guess is that something called by loess() has been fixed in the meantime. Moreover it is not the plot stuff that was wrong under R-2.8.1 (release) but the loess computations. Uwe Ligges __ 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] Typo in extensions manual (PR#13573)
http://streaming.stat.iastate.edu/CRAN/ Writing R extensions Online html version, 3/5/09 Section 1.6.6, second sentence "For instance, the stats package has..." From the context of sentences in the next paragraph I think it should say stats4. Terry T. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Two documentation questions
Prof Brian Ripley wrote:
On Wed, 4 Mar 2009, Terry Therneau wrote:
[SNIP]
2. In the pdf for the survival package, or at least the one generated
by R CMD check, the entries are in a random order. Can I fix this?
It makes reading the document to look for errors rather challenging.
(That is, when I'm looking at a particular Rd file, and want to see
what it turned out to be.)
They should not be 'random'. E.g.
http://cran.r-project.org/web/packages/survival/survival.pdf is not:
it is in alphabetical order (C locale), and that is what I see for R
CMD check in 2.8.1 (but in the collation order of the locale; this is
done by Perl so depends on what it thinks is appropriate).
This is one of the things that is changing for R 2.9.0, and hence in
current R-devel. R CMD check will always uses R CMD Rd2dvi, and that
produces PDF manuals in alphabetic order of the Rd files, in the
current locale (I think Rd2dvi was always in C collation in earlier
versions).
I think the key point here is "alphabetical order of the .Rd files". If
you do not choose the names of those files carefully, the PDF file
produced by R CMD check may indeed appear to be random
-- Kevin
R CMD check was more a check of the latex conversion of the files, not
a final manual (it got bundles wrong, for example, omitted the
DESCRIPTIOM and did not check that the index worked). R-devel it does
produce a standard package manual, and the collation is by R.
Collation is a messy area with lots of OS-dependent errors. That's
why in R-devel we have moved almost all this to R code, where we can
control it (and can replace the OS's collation services by ICU if
available). And relevant to you is
sort(c("Surv", "surv", "survdiff"))
[1] "surv" "Surv" "survdiff"
which is what ICU thinks is right in English (and for one set of
English rules, it is -- further it allows you to tune them).
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 2.9.0 devel: package installation with configure-args option
I think this should now work (one of several 'FIXME' issues addressed in the latest commit -- there are still some to go, but 2.9.0 is not due for 6 weeks). It is always useful to have a real test example, though. (I used rgl in relation to some discussion about paths on r-sig-mac.) On Tue, 3 Mar 2009, Prof Brian Ripley wrote: That version of R is 'under development' and the INSTALL file says ## FIXME: this loses quotes, so filepaths with spaces in get broken up so it is I think the same as a known issue. The whole package installation process has been completely reconstructed for R-devel, and the process is not quite finished. And this is a low priority as there are effective workarounds. On Tue, 3 Mar 2009, ml-it-r-de...@epigenomics.com wrote: Hi, trying to install a package containing C code and requiring non-default configure argument settings the incantation (this has worked for R <= 2.8.1 on the same architectures) R CMD INSTALL --configure-args="--with-opt1 --with-opt2" packname does always result in a warning Warning: unknown option '--with-opt2' and consequently the option is ignored. Reverting the order of options results in the now last option to be ignored. Alternative quoting has not provided a solution. Using R CMD INSTALL --configure-args=--with-opt1 --configure-args=--with-opt2 packname does provide a workaround, though. Is this the (new to me) and only intended way to provide more than one configure argument? I checked ?INSTALL and the referenced R-admin sec. 'Configuration variables' but still am not clear on this. Regards, Matthias R version 2.9.0 Under development (unstable) (2009-03-02 r48041) on Ubuntu 8.04, 8.10 -- Matthias Burger Project Manager/ Biostatistician Epigenomics AGKleine Praesidentenstr. 110178 Berlin, Germany phone:+49-30-24345-0fax:+49-30-24345-555 http://www.epigenomics.com matthias.bur...@epigenomics.com -- Epigenomics AG Berlin Amtsgericht Charlottenburg HRB 75861 Vorstand: Geert Nygaard (CEO/Vorsitzender) Oliver Schacht PhD (CFO) Aufsichtsrat: Prof. Dr. Dr. hc. Rolf Krebs (Chairman/Vorsitzender) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, rip...@stats.ox.ac.uk 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 -- Brian D. Ripley, rip...@stats.ox.ac.uk 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] documentation questions
I read For printing \dontrun should be a no-op. to mean that it should produce no output, but I suspect you meant you wanted it to pass its argument through verbatim. If we were continuing with the Rdconv.pm I would be suggesting adding some markup for that job (e.g. \verbdontrun), but as we are transitioning to another system adding anything right now is a lot of extra work. To change Rdconv.pm for latex, the line is (in code2latex, l.2639 in R-devel) $text = replace_addnl_command($text, "dontrun", "## Not run: ", "## End(Not run)"); and AFAICS it would need to be $text = undefine_command($text, "dontrun"); On Thu, 5 Mar 2009, Terry Therneau wrote: You've answered my question 2 about why the manual was in odd order R CMD check was more of a check of the latex version of the files, not the final manual. I was looking at the result of R CMD check, and it was in random order (perhaps file date?), not just a different collation choice. Very odd. I will cease worrying about what I might have "done wrong". I omitted the important version information: R version 2.7.1 (2008-06-23) on Linux. Looking more closely, it all depends how Perl lists directories: that could be in almost any order but I am seeing collated orders. My other question was apparently unclear. looking at the pdf output (because it is nicest to read) I refer to it as "printed" because that's what I very often do for any substantial chunk of reading (>2 pages). Easier on my eyes. Talking only about the example section The question is what the result of \dontrun should be when producing a product that is meant to be read by a human, and I will assume that this is the primary target of the latex process. I oject to the comment that it adds. I would much prefer that it not add extraneous comments to my examples. I do want the items bracketed by \dontrun to appear -- if I didn't think the lines were useful I wouldn't have put them there. Perhaps because I like printed versions I like examples to show not just legal input, but give feedback on what the code does; thus make it to the extent possible look like a shapshot of a session and not just a set of legal input. It is most often output that I will have bracketed. (wrt Gabor's comment, I would rather not turn it into a comment block; it would not look at all like that on the screen). There will be two levels to the response: argue that I really shouldn't want to do this, and suggestions on how or how not to accomplish it. Wrt the first -- I need to consider this more. You may convince me. Wrt th second: I don't know perl, but looked at Rdconv.pm. It looks like changing the line to $text= undefine_command($text, "dontrun") would do what I want; but that's a guess, and it would only change the local behavior I'll have to pull down R-devel to understand the tools::: comment. Yes, verbatim sections in Tex are subtle. Thanks for the input. -- Brian D. Ripley, rip...@stats.ox.ac.uk 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] documentation questions
You've answered my question 2 about why the manual was in odd order > R CMD check was more of a check of the latex version of the files, not > the final manual. I was looking at the result of R CMD check, and it was in random order (perhaps file date?), not just a different collation choice. Very odd. I will cease worrying about what I might have "done wrong". I omitted the important version information: R version 2.7.1 (2008-06-23) on Linux. My other question was apparently unclear. looking at the pdf output (because it is nicest to read) I refer to it as "printed" because that's what I very often do for any substantial chunk of reading (>2 pages). Easier on my eyes. Talking only about the example section The question is what the result of \dontrun should be when producing a product that is meant to be read by a human, and I will assume that this is the primary target of the latex process. I oject to the comment that it adds. I would much prefer that it not add extraneous comments to my examples. I do want the items bracketed by \dontrun to appear -- if I didn't think the lines were useful I wouldn't have put them there. Perhaps because I like printed versions I like examples to show not just legal input, but give feedback on what the code does; thus make it to the extent possible look like a shapshot of a session and not just a set of legal input. It is most often output that I will have bracketed. (wrt Gabor's comment, I would rather not turn it into a comment block; it would not look at all like that on the screen). There will be two levels to the response: argue that I really shouldn't want to do this, and suggestions on how or how not to accomplish it. Wrt the first -- I need to consider this more. You may convince me. Wrt th second: I don't know perl, but looked at Rdconv.pm. It looks like changing the line to $text= undefine_command($text, "dontrun") would do what I want; but that's a guess, and it would only change the local behavior I'll have to pull down R-devel to understand the tools::: comment. Yes, verbatim sections in Tex are subtle. Thanks for the input. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug (PR#13570)
On Thu, 5 Mar 2009, Peter Dalgaard wrote:
Prof Brian Ripley wrote:
Undortunately the example is random, so not really reproducible (and I
see nothing wrong on my Mac). However, Linux valgrind on R-devel is
showing a problem:
==3973== Conditional jump or move depends on uninitialised value(s)
==3973==at 0xD76017B: ehg141_ (loessf.f:532)
==3973==by 0xD761600: lowesa_ (loessf.f:769)
==3973==by 0xD736E47: loess_raw (loessc.c:117)
(The uninitiialized value is in someone else's code and I suspect it was
either never intended to work or never tested.) No essential change has
been made to the loess code for many years.
I would not have read the documentation to say that degree = 0 was a
reasonable value. It is not to my mind 'a polynomial surface', and
loess() is described as a 'local regression' for degree 1 or 2 in the
reference. So unless anyone wants to bury their heads in that code I
think a perfectly adequate fix would be to disallow degree = 0.
(I vaguely recall debating allowing in the code ca 10 years ago.)
The code itself has
if (!match(degree, 0:2, 0))
stop("'degree' must be 0, 1 or 2")
though. "Local fitting of a constant" essentially becomes kernel
smoothing, right?
I do know the R code allows it: the question is whether it is worth
the effort of finding the problem(s) in the underlying c/dloess code,
whose manual (and our reference) is entirely about 1 or 2. I am
concerned that there may be other things lurking in the degree=0 case
if it was never tested (in the netlib version: I am sure it was only
minmally tested through my R interface).
I checked the original documentation on netlib and that says
29 DIM dimension of local regression
1 constant
d+1 linear (default)
(d+2)(d+1)/2quadratic
Modified by ehg127 if cdegwhich seems to confirm that degree = 0 was intended to be allowed, and
what I dimly recall from ca 1998 is debating whether the R code should
allow that or not.
If left to me I would say I did not wish to continue to support degree
= 0.
On Thu, 5 Mar 2009, Uwe Ligges wrote:
Berwin A Turlach wrote:
G'day Peter,
On Thu, 05 Mar 2009 09:09:27 +0100
Peter Dalgaard wrote:
rha...@stat.purdue.edu wrote:
<>
This is a CRITICAL bug!!! I have verified it in R 2.8.1 for mac
and for windows. The problem is with loess degree=0 smoothing.
For example, try the following:
x <- 1:100
y <- rnorm(100)
plot(x, y)
lines(predict(loess(y ~ x, degree=0, span=0.5)))
This is obviously wrong.
Obvious? How? I don't see anything particularly odd (on Linux).
Neither did I on linux; but the OP mentioned mac and windows. On
windows, on running that code, the lines() command added a lot of
vertical lines; most spanning the complete window but some only part.
Executing the code a second time (or in steps) gave sensible
results. My guess would be that some memory is not correctly
allocated or
initialised. Or is it something like an object with storage mode
"integer" being passed to a double? But then, why doesn't it show on
linux?
Happy bug hunting. If my guess is correct, then I have no idea how to
track down such things under windows.
Cheers,
Berwin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Please can you folks try under R-devel (to be R-2.9.0 in a couple of
weeks) and report if you still see it. I do not under R-devel (but do
under R-release), so my guess is that something called by loess() has
been fixed in the meantime.
Moreover it is not the plot stuff that was wrong under R-2.8.1
(release) but the loess computations.
Uwe Ligges
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
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
~~ - (p.dalga...@biostat.ku.dk) FAX: (+45) 35327907
--
Brian D. Ripley, rip...@stats.ox.ac.uk
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 (PR#13570)
Prof Brian Ripley wrote:
> Undortunately the example is random, so not really reproducible (and I
> see nothing wrong on my Mac). However, Linux valgrind on R-devel is
> showing a problem:
>
> ==3973== Conditional jump or move depends on uninitialised value(s)
> ==3973==at 0xD76017B: ehg141_ (loessf.f:532)
> ==3973==by 0xD761600: lowesa_ (loessf.f:769)
> ==3973==by 0xD736E47: loess_raw (loessc.c:117)
>
> (The uninitiialized value is in someone else's code and I suspect it was
> either never intended to work or never tested.) No essential change has
> been made to the loess code for many years.
>
> I would not have read the documentation to say that degree = 0 was a
> reasonable value. It is not to my mind 'a polynomial surface', and
> loess() is described as a 'local regression' for degree 1 or 2 in the
> reference. So unless anyone wants to bury their heads in that code I
> think a perfectly adequate fix would be to disallow degree = 0.
> (I vaguely recall debating allowing in the code ca 10 years ago.)
The code itself has
if (!match(degree, 0:2, 0))
stop("'degree' must be 0, 1 or 2")
though. "Local fitting of a constant" essentially becomes kernel
smoothing, right?
> On Thu, 5 Mar 2009, Uwe Ligges wrote:
>
>> Berwin A Turlach wrote:
>>> G'day Peter,
>>>
>>> On Thu, 05 Mar 2009 09:09:27 +0100
>>> Peter Dalgaard wrote:
>>>
rha...@stat.purdue.edu wrote:
> <>
>
> This is a CRITICAL bug!!! I have verified it in R 2.8.1 for mac
> and for windows. The problem is with loess degree=0 smoothing.
> For example, try the following:
>
> x <- 1:100
> y <- rnorm(100)
> plot(x, y)
> lines(predict(loess(y ~ x, degree=0, span=0.5)))
>
> This is obviously wrong.
Obvious? How? I don't see anything particularly odd (on Linux).
>>>
>>> Neither did I on linux; but the OP mentioned mac and windows. On
>>> windows, on running that code, the lines() command added a lot of
>>> vertical lines; most spanning the complete window but some only part.
>>> Executing the code a second time (or in steps) gave sensible
>>> results. My guess would be that some memory is not correctly
>>> allocated or
>>> initialised. Or is it something like an object with storage mode
>>> "integer" being passed to a double? But then, why doesn't it show on
>>> linux?
>>>
>>> Happy bug hunting. If my guess is correct, then I have no idea how to
>>> track down such things under windows.
>>>
>>> Cheers,
>>>
>>> Berwin
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>> Please can you folks try under R-devel (to be R-2.9.0 in a couple of
>> weeks) and report if you still see it. I do not under R-devel (but do
>> under R-release), so my guess is that something called by loess() has
>> been fixed in the meantime.
>>
>> Moreover it is not the plot stuff that was wrong under R-2.8.1
>> (release) but the loess computations.
>>
>> Uwe Ligges
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
--
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
~~ - (p.dalga...@biostat.ku.dk) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug (PR#13570)
Undortunately the example is random, so not really reproducible (and I see nothing wrong on my Mac). However, Linux valgrind on R-devel is showing a problem: ==3973== Conditional jump or move depends on uninitialised value(s) ==3973==at 0xD76017B: ehg141_ (loessf.f:532) ==3973==by 0xD761600: lowesa_ (loessf.f:769) ==3973==by 0xD736E47: loess_raw (loessc.c:117) (The uninitiialized value is in someone else's code and I suspect it was either never intended to work or never tested.) No essential change has been made to the loess code for many years. I would not have read the documentation to say that degree = 0 was a reasonable value. It is not to my mind 'a polynomial surface', and loess() is described as a 'local regression' for degree 1 or 2 in the reference. So unless anyone wants to bury their heads in that code I think a perfectly adequate fix would be to disallow degree = 0. (I vaguely recall debating allowing in the code ca 10 years ago.) On Thu, 5 Mar 2009, Uwe Ligges wrote: Berwin A Turlach wrote: G'day Peter, On Thu, 05 Mar 2009 09:09:27 +0100 Peter Dalgaard wrote: rha...@stat.purdue.edu wrote: <> This is a CRITICAL bug!!! I have verified it in R 2.8.1 for mac and for windows. The problem is with loess degree=0 smoothing. For example, try the following: x <- 1:100 y <- rnorm(100) plot(x, y) lines(predict(loess(y ~ x, degree=0, span=0.5))) This is obviously wrong. Obvious? How? I don't see anything particularly odd (on Linux). Neither did I on linux; but the OP mentioned mac and windows. On windows, on running that code, the lines() command added a lot of vertical lines; most spanning the complete window but some only part. Executing the code a second time (or in steps) gave sensible results. My guess would be that some memory is not correctly allocated or initialised. Or is it something like an object with storage mode "integer" being passed to a double? But then, why doesn't it show on linux? Happy bug hunting. If my guess is correct, then I have no idea how to track down such things under windows. Cheers, Berwin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel Please can you folks try under R-devel (to be R-2.9.0 in a couple of weeks) and report if you still see it. I do not under R-devel (but do under R-release), so my guess is that something called by loess() has been fixed in the meantime. Moreover it is not the plot stuff that was wrong under R-2.8.1 (release) but the loess computations. Uwe Ligges __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, rip...@stats.ox.ac.uk 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 (PR#13570)
Uwe Ligges wrote: > Berwin A Turlach wrote: > >> G'day Peter, >> >> On Thu, 05 Mar 2009 09:09:27 +0100 >> Peter Dalgaard wrote: >> >> >>> rha...@stat.purdue.edu wrote: >>> <> This is a CRITICAL bug!!! I have verified it in R 2.8.1 for mac and for windows. The problem is with loess degree=0 smoothing. For example, try the following: x <- 1:100 y <- rnorm(100) plot(x, y) lines(predict(loess(y ~ x, degree=0, span=0.5))) This is obviously wrong. >>> Obvious? How? I don't see anything particularly odd (on Linux). >>> >> Neither did I on linux; but the OP mentioned mac and windows. >> >> On windows, on running that code, the lines() command added a lot of >> vertical lines; most spanning the complete window but some only part. >> >> Executing the code a second time (or in steps) gave sensible >> results. >> >> My guess would be that some memory is not correctly allocated or >> initialised. Or is it something like an object with storage mode >> "integer" being passed to a double? But then, why doesn't it show on >> linux? >> >> Happy bug hunting. If my guess is correct, then I have no idea how to >> track down such things under windows. >> >> Cheers, >> >> Berwin >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > > Please can you folks try under R-devel (to be R-2.9.0 in a couple of > weeks) and report if you still see it. I do not under R-devel (but do > under R-release), so my guess is that something called by loess() has > been fixed in the meantime. > > Moreover it is not the plot stuff that was wrong under R-2.8.1 (release) > but the loess computations. I still see it in R-patched (haven't tried R-devel yet). So I think it is worth tracking down and fixing; I'll do it later today. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug (PR#13570)
Uwe Ligges wrote: Berwin A Turlach wrote: G'day Peter, On Thu, 05 Mar 2009 09:09:27 +0100 Peter Dalgaard wrote: rha...@stat.purdue.edu wrote: <> This is a CRITICAL bug!!! I have verified it in R 2.8.1 for mac and for windows. The problem is with loess degree=0 smoothing. For example, try the following: x <- 1:100 y <- rnorm(100) plot(x, y) lines(predict(loess(y ~ x, degree=0, span=0.5))) This is obviously wrong. Obvious? How? I don't see anything particularly odd (on Linux). Neither did I on linux; but the OP mentioned mac and windows. On windows, on running that code, the lines() command added a lot of vertical lines; most spanning the complete window but some only part. Executing the code a second time (or in steps) gave sensible results. My guess would be that some memory is not correctly allocated or initialised. Or is it something like an object with storage mode "integer" being passed to a double? But then, why doesn't it show on linux? Happy bug hunting. If my guess is correct, then I have no idea how to track down such things under windows. Cheers, Berwin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel Please can you folks try under R-devel (to be R-2.9.0 in a couple of weeks) and report if you still see it. I do not under R-devel (but do under R-release), so my guess is that something called by loess() has been fixed in the meantime. Moreover it is not the plot stuff that was wrong under R-2.8.1 (release) but the loess computations. I still see it in R-patched (haven't tried R-devel yet). So I think it is worth tracking down and fixing; I'll do it later today. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Two documentation questions
On Wed, 4 Mar 2009, Terry Therneau wrote:
1. I often like to put bits of the output into the manual pages. (We can
have a discussion of the value of this elsewhere -- I think it is sometimes
a good thing.)
I presume you mean in the \examples section of the .Rd files, not
elsewhere in the help.
In R I need to surround these with \dontrun{} for the sake of the tester,
which is fine. But the printed output contains
## Not run
and
## End (not run)
'printed output'? We have conversion to text, HTML, latex and .R, and
they are all done separately. I guess you are only concerned with
conversion to latex?
comments, which defeats the purpose of the lines by breaking them off from
the their context. How do I turn these off? For printing \dontrun should
be a no-op.
I'm not sure why it 'should'. Conversion to latex is not just for
printing, nor is \dontrun primarily for output. Indeed, at one point
a couple of months ago the parseRd function required what was in
\dontrun to be valid R code.
I certainly find having the \dontrun material in the package PDF
manual helpful on occasion.
Or at least I should have the option of making it so -- I'm rather
opinionated about the format of things I prepare for teaching purposes.
You can assume medium Tex skills in answering; my book is in Latex but I
don't create my own formats.
If you mean conversion to latex, you could either alter Rdconv.pm
or post-process the output: this is in a verbatim-like section so it
would not be easy to do so in LaTeX. If I did this often I would be
adding some markup for this purpose, but post-processing in R should
be easy (and tools:::massageExamples (in R-devel) does so).
2. In the pdf for the survival package, or at least the one
generated by R CMD check, the entries are in a random order. Can I
fix this? It makes reading the document to look for errors rather
challenging. (That is, when I'm looking at a particular Rd file,
and want to see what it turned out to be.)
They should not be 'random'. E.g.
http://cran.r-project.org/web/packages/survival/survival.pdf is not:
it is in alphabetical order (C locale), and that is what I see for R
CMD check in 2.8.1 (but in the collation order of the locale; this is
done by Perl so depends on what it thinks is appropriate).
This is one of the things that is changing for R 2.9.0, and hence in
current R-devel. R CMD check will always uses R CMD Rd2dvi, and that
produces PDF manuals in alphabetic order of the Rd files, in the
current locale (I think Rd2dvi was always in C collation in earlier
versions).
R CMD check was more a check of the latex conversion of the files, not
a final manual (it got bundles wrong, for example, omitted the
DESCRIPTIOM and did not check that the index worked). R-devel it does
produce a standard package manual, and the collation is by R.
Collation is a messy area with lots of OS-dependent errors. That's
why in R-devel we have moved almost all this to R code, where we can
control it (and can replace the OS's collation services by ICU if
available). And relevant to you is
sort(c("Surv", "surv", "survdiff"))
[1] "surv" "Surv" "survdiff"
which is what ICU thinks is right in English (and for one set of
English rules, it is -- further it allows you to tune them).
--
Brian D. Ripley, rip...@stats.ox.ac.uk
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 (PR#13570)
Berwin A Turlach wrote: > G'day Peter, > > On Thu, 05 Mar 2009 09:09:27 +0100 > Peter Dalgaard wrote: > >> rha...@stat.purdue.edu wrote: >>> <> >>> >>> This is a CRITICAL bug!!! I have verified it in R 2.8.1 for mac >>> and for windows. The problem is with loess degree=0 smoothing. >>> For example, try the following: >>> >>> x <- 1:100 >>> y <- rnorm(100) >>> plot(x, y) >>> lines(predict(loess(y ~ x, degree=0, span=0.5))) >>> >>> This is obviously wrong. >> Obvious? How? I don't see anything particularly odd (on Linux). > > Neither did I on linux; but the OP mentioned mac and windows. > > On windows, on running that code, the lines() command added a lot of > vertical lines; most spanning the complete window but some only part. > > Executing the code a second time (or in steps) gave sensible > results. > > My guess would be that some memory is not correctly allocated or > initialised. Or is it something like an object with storage mode > "integer" being passed to a double? But then, why doesn't it show on > linux? > > Happy bug hunting. If my guess is correct, then I have no idea how to > track down such things under windows. > > Cheers, > > Berwin > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel Please can you folks try under R-devel (to be R-2.9.0 in a couple of weeks) and report if you still see it. I do not under R-devel (but do under R-release), so my guess is that something called by loess() has been fixed in the meantime. Moreover it is not the plot stuff that was wrong under R-2.8.1 (release) but the loess computations. Uwe Ligges __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug (PR#13570)
Berwin A Turlach wrote: G'day Peter, On Thu, 05 Mar 2009 09:09:27 +0100 Peter Dalgaard wrote: rha...@stat.purdue.edu wrote: <> This is a CRITICAL bug!!! I have verified it in R 2.8.1 for mac and for windows. The problem is with loess degree=0 smoothing. For example, try the following: x <- 1:100 y <- rnorm(100) plot(x, y) lines(predict(loess(y ~ x, degree=0, span=0.5))) This is obviously wrong. Obvious? How? I don't see anything particularly odd (on Linux). Neither did I on linux; but the OP mentioned mac and windows. On windows, on running that code, the lines() command added a lot of vertical lines; most spanning the complete window but some only part. Executing the code a second time (or in steps) gave sensible results. My guess would be that some memory is not correctly allocated or initialised. Or is it something like an object with storage mode "integer" being passed to a double? But then, why doesn't it show on linux? Happy bug hunting. If my guess is correct, then I have no idea how to track down such things under windows. Cheers, Berwin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel Please can you folks try under R-devel (to be R-2.9.0 in a couple of weeks) and report if you still see it. I do not under R-devel (but do under R-release), so my guess is that something called by loess() has been fixed in the meantime. Moreover it is not the plot stuff that was wrong under R-2.8.1 (release) but the loess computations. Uwe Ligges __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] methods package
Terry Therneau wrote:
> I'm working on the next version of coxme, one step of which is converting
> the bdsmatrix library from Splus to R. Actually, it is a conversion from
> S4 methods as first described in the Green book to S4 methods as they
> currently exist. Mostly it's going ok, but not entirely.
>
> 1. The biggest issue is lack of documentation. The online help pages have
> not been a help; they keep saying it's "as found in the green book - almost".
> I've looked for the package on CRAN in the hopes for more there, but can't
> find it. Perchance there is something obvious that I am missing?
>
> 2. The changes are small but numerous. The current one that has me puzzled
> is a method for addition:
>setMethod(Ops, signature=c('numeric', 'bdsmatrix'),
>
> Let xmat be ordinary and bmat be a bdsmatrix. In the old code "xmat + bmat"
> fell to this method (which knows what to do), in the current R I get
> failure due to no method found. is.numeric(xmat) is TRUE.
>What is the fix?
Assuming xmat to be a numeric matrix e.g. diag(n).
S4 inheritance will be determined by is() and
is(xmat, "numeric") will be FALSE
So one solution is to provide explicit methods for signature 'matrix' i.e.
setMethod(Ops, signature=c('matrix', 'bdsmatrix'),
setMethod(Ops, signature=c('bdsmatrix', 'matrix'),
Matthias
> 3. In the green book the examples used .Dim and .Dimnames slots, the Matrix
> library uses Dim and Dimnames. Is there a good reason to choose one or the
> other?
>
> I'll be out of town for the next few days (son's wedding) so instant
> response
> is not necessary.
>
> Terry Therneau
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Matthias Burger Project Manager/ Biostatistician
Epigenomics AGKleine Praesidentenstr. 110178 Berlin, Germany
phone:+49-30-24345-0fax:+49-30-24345-555
http://www.epigenomics.com matthias.bur...@epigenomics.com
--
Epigenomics AG Berlin Amtsgericht Charlottenburg HRB 75861
Vorstand: Geert Nygaard (CEO/Vorsitzender)
Oliver Schacht PhD (CFO)
Aufsichtsrat: Prof. Dr. Dr. hc. Rolf Krebs (Chairman/Vorsitzender)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug (PR#13570)
G'day Peter, On Thu, 05 Mar 2009 09:09:27 +0100 Peter Dalgaard wrote: > rha...@stat.purdue.edu wrote: > > <> > > > > This is a CRITICAL bug!!! I have verified it in R 2.8.1 for mac > > and for windows. The problem is with loess degree=0 smoothing. > > For example, try the following: > > > > x <- 1:100 > > y <- rnorm(100) > > plot(x, y) > > lines(predict(loess(y ~ x, degree=0, span=0.5))) > > > > This is obviously wrong. > > Obvious? How? I don't see anything particularly odd (on Linux). Neither did I on linux; but the OP mentioned mac and windows. On windows, on running that code, the lines() command added a lot of vertical lines; most spanning the complete window but some only part. Executing the code a second time (or in steps) gave sensible results. My guess would be that some memory is not correctly allocated or initialised. Or is it something like an object with storage mode "integer" being passed to a double? But then, why doesn't it show on linux? Happy bug hunting. If my guess is correct, then I have no idea how to track down such things under windows. Cheers, Berwin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] problems with nls?
I don't see why this is relevant to R-devel rather than R-help.
Your script must be very old: the NEWS for R 1.9.0 said
Packages ctest, eda, modreg, mva, nls, stepfun and ts have been
merged into stats, and lqs has been returned to MASS.
That's 5 years ago now.
Function nls() still exists, and is in the 'stats' package which is
loaded in a default R session.
On Wed, 4 Mar 2009, per243 wrote:
I need to make nonlinear regression with the posterior script, but how is the
problem? I have error in library (nls), package 'nls' has been merged into
'stats'.
It was _not_ an error:
library(nls)
Warning message:
package 'nls' has been merged into 'stats'
so if your script did not run something else was the error. (We don't
have the dataset, so cannot reproduce what you did.)
I need help?
What other forms I have to make nonlinear regression? and how I find to
calculate statistics y residuals, scatterplot.
Please read 'An Introduction to R' and then a basic book on
statistics with R.
thanks
SCRIPT
ros<-read.table("Dataset.csv",header=T,sep=",")
ros
attach(ros)
# preliminaries
options(width=44)
options(digits=3)
## Nonlinear Regression
par(mfrow=c(1,2))
attach(ros)
plot(U1.7km, R, main="(a)")
library(nls)
mod1<-nls(R ~
beta1*(U1.7km^beta2)+(Hm^beta3)),start=list(beta1=2.031,beta2=0.800,beta3=-0.255),
trace = TRUE)
summary(mod1)
coef(mod1)
coef(summary(mod1))
lines(R, fitted.values(mod1), lwd=2)
plot(R, residuals(mod1), type="b", main="(b)")
abline(h=0, lty=2)
--
Brian D. Ripley, rip...@stats.ox.ac.uk
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] besselI inaccurate for negative integer order (PR#13556)
> "JL" == Jerry Lewis > on Thu, 26 Feb 2009 16:15:11 +0100 (CET) writes: JL> Full_Name: Jerry W. Lewis JL> Version: 2.8.1 JL> OS: Windows XP Professional JL> Submission from: (NULL) (198.180.131.16) JL> It should be the case that JL> besselI(x,-nu) == besselI(x,nu) == besselI(x,abs(nu)) JL> for integer nu, yet R currently can return ridiculous values when nu is a JL> negative integer. JL> For instance, besselI(9.6,-44) returns -234626490 instead of the correct value JL> of 5.9041042646307223e-25, while besselI(9.6,44) gives essentially machine JL> accuracy. Yes. I have committed a bug-fix to both R-patched and R-devel. Thank you for the report! Martin Maechler, ETH Zurich JL> This is more than an idle mathematical curiosity, since JL> one consequence is that dskellam in the VGAM package can JL> return values <0 or >1. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] calling Rf_initEmbeddedR twice gives an error
Dear all,
I've written a R to python/octave/r translator that (so you can call
python from R etc and vice versa) enabling you to e.g. call matplotlib
which just runs fine on the first command
when I do
Rf_initEmbeddedR(2, argv);
Rf_endEmbeddedR(0);
Rf_initEmbeddedR(2, argv);
Rf_endEmbeddedR(0);
I get this error
Error in .Call("R_isMethodsDispatchOn", onOff, PACKAGE = "base") :
Incorrect number of arguments (2), expecting 1 for R_isMethodsDispatchOn
Error in gzfile(file) : invalid 'encoding' argument
Fatal error: unable to restore saved data in .RData
I've recognized that there were others with that problem - which is
marked user error here
http://bugs.r-project.org/cgi-bin/R/trashcan?id=12644;user=guest;selectid=12644
Unfortunately it is nowhere stated what one should have called... Any
of
R_dot_Last();
R_RunExitFinalizers();
R_gc();
does not help either...
However I can trigger the problem on the R cmdline when I do:
.Call("R_isMethodsDispatchOn", 1,2, PACKAGE = "base") :
also looking at src/main/registration.c I don't see a reason why it
should be wrong:CALLDEF(R_isMethodsDispatchOn, 1)...
Any ideas?
Soeren
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug (PR#13570)
rha...@stat.purdue.edu wrote: <> This is a CRITICAL bug!!! I have verified it in R 2.8.1 for mac and for windows. The problem is with loess degree=0 smoothing. For example, try the following: x <- 1:100 y <- rnorm(100) plot(x, y) lines(predict(loess(y ~ x, degree=0, span=0.5))) This is obviously wrong. Obvious? How? I don't see anything particularly odd (on Linux). R 2.8 --please do not edit the information below-- Version: platform = i386-apple-darwin8.11.1 arch = i386 os = darwin8.11.1 system = i386, darwin8.11.1 status = major = 2 minor = 8.1 year = 2008 month = 12 day = 22 svn rev = 47281 language = R version.string = R version 2.8.1 (2008-12-22) GUI: R-GUI 1.27 (5301) Locale: en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8 Search Path: .GlobalEnv, tools:RGUI, package:stats, package:graphics, package:grDevices, package:utils, package:datasets, package:Rutils, package:methods, Autoloads, package:base __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- 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 ~~ - (p.dalga...@biostat.ku.dk) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug (PR#13570)
Could you explain what you are seeing that is wrong? In R 2.7.2, which is what I have here, it looks ok, and the NEWS file doesn't list any changes since 2.7.1. -thomas On Wed, 4 Mar 2009 rha...@stat.purdue.edu wrote: <> This is a CRITICAL bug!!! I have verified it in R 2.8.1 for mac and for windows. The problem is with loess degree=0 smoothing. For example, try the following: x <- 1:100 y <- rnorm(100) plot(x, y) lines(predict(loess(y ~ x, degree=0, span=0.5))) This is obviously wrong. R 2.8 --please do not edit the information below-- Version: platform = i386-apple-darwin8.11.1 arch = i386 os = darwin8.11.1 system = i386, darwin8.11.1 status = major = 2 minor = 8.1 year = 2008 month = 12 day = 22 svn rev = 47281 language = R version.string = R version 2.8.1 (2008-12-22) GUI: R-GUI 1.27 (5301) Locale: en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8 Search Path: .GlobalEnv, tools:RGUI, package:stats, package:graphics, package:grDevices, package:utils, package:datasets, package:Rutils, package:methods, Autoloads, package:base __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel Thomas Lumley Assoc. Professor, Biostatistics tlum...@u.washington.eduUniversity of Washington, Seattle __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
