Re: [Rd] repeat bug report: as.factor argument to row / col fails if NULL dimnames
I have never seen the report in the repository. There were problems with R-bugs at around that time (most email submission was stalled for a month or so). However, I think the problems are far more serious: the help page says Returns a matrix of integers indicating their column number in a matrix-like object. ... as.factor: a logical value indicating whether the value should be returned as a factor rather than as numeric. Value: An integer matrix with the same dimensions as 'x' and whose 'ij'-th element is equal to 'j'. There is no mention of using the column labels as the values and the result was not even a matrix. I certainly expected the factor levels to be numeric. I presume that the intention is to use the column labels (default seq_len(nrow(x)) ) in place of the numbers, and to return a factor matrix, so I have implemented that for col() and row(). However, I do wonder that anyone was using as.factor=TRUE given that it did not do anything like what it was documented to. On Mon, 8 Dec 2008, Dan Davison wrote: This bug was reported to r-devel by Martin Morgan on 13th May 2008 (original email pasted below). However I couldn't locate it in the bug tracker (with searches for row, col, as\.factor) It is still present in today's svn version (rev 47115). I hope I'm doing something useful by bringing it up again. I have not sent this to r-bugs, as I'm concerned that not locating it in the bug tracker could be my failing. Dan original report: -- col(matrix(0, 5, 5), as.factor=TRUE) fails col(matrix(0, 5, 5), as.factor=TRUE) Error in factor(.Internal(col(dim(x))), labels = colnames(x)) : invalid labels; length 0 should be 1 or 5 when the matrix has no dimnames. This is not as advertised. I would have expected the equivalent of factor(.Internal(col(dim(x))), labels=colnames(x, do.NULL=FALSE, prefix=)) sessionInfo() R version 2.8.0 Under development (unstable) (2008-05-13 r45682) x86_64-unknown-linux-gnu Martin -- Martin Morgan Computational Biology / Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109 Location: Arnold Building M2 B169 Phone: (206) 667-2793 -- -- http://www.stats.ox.ac.uk/~davison __ 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] repeat bug report: as.factor argument to row / col fails if NULL dimnames
Prof Brian Ripley wrote: I have never seen the report in the repository. There were problems with R-bugs at around that time (most email submission was stalled for a month or so). Maybe, but I don't see a PR# on _any_ of Martin Morgan's posts... However, I think the problems are far more serious: the help page says Returns a matrix of integers indicating their column number in a matrix-like object. ... as.factor: a logical value indicating whether the value should be returned as a factor rather than as numeric. Value: An integer matrix with the same dimensions as 'x' and whose 'ij'-th element is equal to 'j'. There is no mention of using the column labels as the values and the result was not even a matrix. I certainly expected the factor levels to be numeric. I presume that the intention is to use the column labels (default seq_len(nrow(x)) ) in place of the numbers, and to return a factor matrix, so I have implemented that for col() and row(). However, I do wonder that anyone was using as.factor=TRUE given that it did not do anything like what it was documented to. There could, I suppose, be applications of the style library(ISwR) dd - data.frame(count=c(caesar.shoe), caesar=row(caesar.shoe,as.factor=TRUE), size=col(caesar.shoe,as.factor=TRUE)) anova(glm(count~caesar*size,family=poisson,data=dd)) (as.data.frame.table is better in this case, I know). Notice that this will break if you change the value to a factor matrix. It is not clear that a matrix is desired -- an alternative point of view is that when you request a factor, it is intended to be used along with long-format data. On Mon, 8 Dec 2008, Dan Davison wrote: This bug was reported to r-devel by Martin Morgan on 13th May 2008 (original email pasted below). However I couldn't locate it in the bug tracker (with searches for row, col, as\.factor) It is still present in today's svn version (rev 47115). I hope I'm doing something useful by bringing it up again. I have not sent this to r-bugs, as I'm concerned that not locating it in the bug tracker could be my failing. D -- 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] repeat bug report: as.factor argument to row / col fails if NULL dimnames
On Fri, 12 Dec 2008, Peter Dalgaard wrote: Prof Brian Ripley wrote: I have never seen the report in the repository. There were problems with R-bugs at around that time (most email submission was stalled for a month or so). Maybe, but I don't see a PR# on _any_ of Martin Morgan's posts... However, I think the problems are far more serious: the help page says Returns a matrix of integers indicating their column number in a matrix-like object. ... as.factor: a logical value indicating whether the value should be returned as a factor rather than as numeric. Value: An integer matrix with the same dimensions as 'x' and whose 'ij'-th element is equal to 'j'. There is no mention of using the column labels as the values and the result was not even a matrix. I certainly expected the factor levels to be numeric. I presume that the intention is to use the column labels (default seq_len(nrow(x)) ) in place of the numbers, and to return a factor matrix, so I have implemented that for col() and row(). However, I do wonder that anyone was using as.factor=TRUE given that it did not do anything like what it was documented to. There could, I suppose, be applications of the style library(ISwR) dd - data.frame(count=c(caesar.shoe), caesar=row(caesar.shoe,as.factor=TRUE), size=col(caesar.shoe,as.factor=TRUE)) anova(glm(count~caesar*size,family=poisson,data=dd)) (as.data.frame.table is better in this case, I know). Notice that this will break if you change the value to a factor matrix. It is not clear that a matrix is desired -- an alternative point of view is that when you request a factor, it is intended to be used along with long-format data. Yes, it is not clear (and I had given it some thought), but a) a matrix result was documented and b) it is easier to remove dims than add them (impossible without the original matrix to hand). On Mon, 8 Dec 2008, Dan Davison wrote: This bug was reported to r-devel by Martin Morgan on 13th May 2008 (original email pasted below). However I couldn't locate it in the bug tracker (with searches for row, col, as\.factor) It is still present in today's svn version (rev 47115). I hope I'm doing something useful by bringing it up again. I have not sent this to r-bugs, as I'm concerned that not locating it in the bug tracker could be my failing. -- 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] package development
Using parse() is better for syntax errors; pathnames - list.files(path=pkg/R, pattern=[.](r|R|s|S)$, full.names=TRUE); for (pathname in pathnames) parse(pathname) /Henrik On Thu, Dec 11, 2008 at 4:00 PM, Duncan Murdoch murd...@stats.uwo.ca wrote: On 11/12/2008 6:04 PM, Terry Therneau wrote: I'm making the move of the survival package from my own environment to, and have stumbled into a vacuum. The R Extensions manual has really nice instructions about how to lay out the directories, order the files, and run tests for DISTRIBUTION of a product, but I can't find anything on how to set up a reasonable DEVELOPMENT environment. In my local world, I had the .c and .s files in a common directory, with a Makefile that I had created, and the test suite in a subdirectory. Debugging and development was quite nice. make cd test R attach(..) try something and perhaps it fails q() cd .. Fix and repeat. The Makefile took some time to create, but paid for itself a hundred times over. So, I've now rearranged everything into standard R order. Then I did the only thing I could find R CMD INSTALL ~/myRlib survival where survival is said directory. This turns out to be not useful at all. The survival package is large, and I rather suspected that I would goof something up, and I did, resulting in the following message Error in parse(n = -1, file = file) : unexpected end of input at 14450: } 14451: It is not exactly obvious which of the 132 files in my R/ directory is the culprit here. That's something I would like to fix too. There are (at least) two possible ways: stop concatenating the files (which is not really needed nowadays, most packages install saved images), or add some markup to the concatenated file so that the parser can report on the original filename and line number (like the #LINE directives output by the C preprocessor). In general: 1. The library is large, and recompiling/reparsing everything is very far from instantaneous. It is not the edit/load cycle I desire. If you install from the directory, the compiling should only be done once (unless you change a file, of course). (The alternative is installing from the tarball, which is recommended for later stages of testing before distribution, because it's possible something could go wrong in building the tarball. But it won't include any object files, so you'll recompile every time.) You can also use option --docs=none to skip building the help system; this will save a bit of time. 2. I take testing seriously: the test suite takes on the order of 15 minutes to run on a fast machine. I most certainly don't want to run it in the mid cycle. I don't quite follow this. If you want to run all your tests, you would use R CMD check. If you only want to run some of them, then you can source things out of the tests directory while running interactively. Someone must have tackled this. I'm hoping that there is some documentation that I have managed to overlook which discussess a good setup for this middle ground between concieving of a library and packaging it for delivery; the build, test, make sure it acually works part of development. I find the process I follow is to organize the files in the distribution structure from the beginning. When adding new functions, I'll generally use source() a few times to get the syntax right, and perhaps run simple tests. (But remember, if you use a NAMESPACE, the functions may not behave the same when they're sourced into the global environment.) In the early stages, I'll do a lot of installs of the packages. If I was porting a big package and wanted to find syntax errors, to work around the not-very-helpful error message you saw I'd do something like for (f in list.files(pkg/R, full=TRUE)) source(f) which will report the error more informatively. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] package development
Thanks to all for the replys. I've learned several things First -- I didn't miss anything obvious in the documentation. This is good in one sense at least: I wasn't being blind. I had one misunderstanding pointed out, which is that I need not worry about my test suite being run with each INSTALL; that happens with CHECK. Second, I heard several good ideas for attacking the problem. Terry T. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] package development
Duncan Murdoch wrote: On 11/12/2008 6:04 PM, Terry Therneau wrote: I'm making the move of the survival package from my own environment to, and have stumbled into a vacuum. The R Extensions manual has really nice instructions about how to lay out the directories, order the files, and run tests for DISTRIBUTION of a product, but I can't find anything on how to set up a reasonable DEVELOPMENT environment. In my local world, I had the .c and .s files in a common directory, with a Makefile that I had created, and the test suite in a subdirectory. Debugging and development was quite nice. make cd test R attach(..) try something and perhaps it fails q() cd .. Fix and repeat. The Makefile took some time to create, but paid for itself a hundred times over. So, I've now rearranged everything into standard R order. Then I did the only thing I could find R CMD INSTALL ~/myRlib survival where survival is said directory. This turns out to be not useful at all. The survival package is large, and I rather suspected that I would goof something up, and I did, resulting in the following message Error in parse(n = -1, file = file) : unexpected end of input at 14450: } 14451: It is not exactly obvious which of the 132 files in my R/ directory is the culprit here. That's something I would like to fix too. There are (at least) two possible ways: stop concatenating the files (which is not really needed nowadays, most packages install saved images), or add some markup to the concatenated file so that the parser can report on the original filename and line number (like the #LINE directives output by the C preprocessor). I would certainly appreciate a fix for this. When this has happened to me, I usually end up just sourcing the individual files into an R session until I find the bad file, and get a report with the right line number. It always seems like a lot of work for something that should be trivial. In general: 1. The library is large, and recompiling/reparsing everything is very far from instantaneous. It is not the edit/load cycle I desire. If you install from the directory, the compiling should only be done once (unless you change a file, of course). (The alternative is installing from the tarball, which is recommended for later stages of testing before distribution, because it's possible something could go wrong in building the tarball. But it won't include any object files, so you'll recompile every time.) You can also use option --docs=none to skip building the help system; this will save a bit of time. 2. I take testing seriously: the test suite takes on the order of 15 minutes to run on a fast machine. I most certainly don't want to run it in the mid cycle. I don't quite follow this. If you want to run all your tests, you would use R CMD check. If you only want to run some of them, then you can source things out of the tests directory while running interactively. Someone must have tackled this. I'm hoping that there is some documentation that I have managed to overlook which discussess a good setup for this middle ground between concieving of a library and packaging it for delivery; the build, test, make sure it acually works part of development. In my experience there are two differ sorts of problems that I think could benefit from some improvement. The first is that there should be a standard way to have extra tests, that do not get run in the normal CRAN testing cycle, or by developers when using a quick R CMD check, but can be run with a standard mechanism. I do this by putting the tests in a separate package, and I have seen reports of different mechanisms, but I think they are all somewhat ad hoc. Currently, if you put too much testing in your package then all the testing gets omitted on some CRAN testing platforms. Just a common directory like extraTests/ would be a good start. The second problem is that a developer usually needs to run tests/ when code in R/ has been changed, but probably not run tests/ when the changes are only in man/, demos/, or inst/doc/. The checking that needs to be done in those cases is reduced from the full R CMD check. A common way to attack this is with a good Makefile. I wrote an article in R News a few years ago about my attempts to do this, and my Makefiles are available, but there is some customization necessary, and there is lots of room for improvement. It does (mostly) work with make -j, so days of testing on a single processor machine can be accomplished in a few hours on multicore machines (for me, mileage may vary). I have not addressed the idea of trying to specialize files in tests/ to specific code files in R/. (I think others have tried to do this with a unit testing approach.) Paul Gilbert I find the process I follow is to organize the files in the distribution structure from the
Re: [Rd] package development
A quick comment on two subjects: First to get the line # from the command line: cat pkg/R/* all.R wc all.R vim +LINE all.R (or pick you favorite method here...) From there it should be easy enough to get context. At least enough to grep back into the R directory. Also, the use of unit-tests is IMO the best answer for managing a separate test suite that you can selectively run (all of part of) during the build phase. Simply editing/adding an .Rbuildignore is all you need to turn it off or on. This makes it easy not to distribute the tests as well, if you choose not too. RUnit is a good tool to look into. HTH Jeff On Fri, Dec 12, 2008 at 8:12 AM, Paul Gilbert pgilb...@bank-banque-canada.ca wrote: Duncan Murdoch wrote: On 11/12/2008 6:04 PM, Terry Therneau wrote: I'm making the move of the survival package from my own environment to, and have stumbled into a vacuum. The R Extensions manual has really nice instructions about how to lay out the directories, order the files, and run tests for DISTRIBUTION of a product, but I can't find anything on how to set up a reasonable DEVELOPMENT environment. In my local world, I had the .c and .s files in a common directory, with a Makefile that I had created, and the test suite in a subdirectory. Debugging and development was quite nice. make cd test R attach(..) try something and perhaps it fails q() cd .. Fix and repeat. The Makefile took some time to create, but paid for itself a hundred times over. So, I've now rearranged everything into standard R order. Then I did the only thing I could find R CMD INSTALL ~/myRlib survival where survival is said directory. This turns out to be not useful at all. The survival package is large, and I rather suspected that I would goof something up, and I did, resulting in the following message Error in parse(n = -1, file = file) : unexpected end of input at 14450: } 14451: It is not exactly obvious which of the 132 files in my R/ directory is the culprit here. That's something I would like to fix too. There are (at least) two possible ways: stop concatenating the files (which is not really needed nowadays, most packages install saved images), or add some markup to the concatenated file so that the parser can report on the original filename and line number (like the #LINE directives output by the C preprocessor). I would certainly appreciate a fix for this. When this has happened to me, I usually end up just sourcing the individual files into an R session until I find the bad file, and get a report with the right line number. It always seems like a lot of work for something that should be trivial. In general: 1. The library is large, and recompiling/reparsing everything is very far from instantaneous. It is not the edit/load cycle I desire. If you install from the directory, the compiling should only be done once (unless you change a file, of course). (The alternative is installing from the tarball, which is recommended for later stages of testing before distribution, because it's possible something could go wrong in building the tarball. But it won't include any object files, so you'll recompile every time.) You can also use option --docs=none to skip building the help system; this will save a bit of time. 2. I take testing seriously: the test suite takes on the order of 15 minutes to run on a fast machine. I most certainly don't want to run it in the mid cycle. I don't quite follow this. If you want to run all your tests, you would use R CMD check. If you only want to run some of them, then you can source things out of the tests directory while running interactively. Someone must have tackled this. I'm hoping that there is some documentation that I have managed to overlook which discussess a good setup for this middle ground between concieving of a library and packaging it for delivery; the build, test, make sure it acually works part of development. In my experience there are two differ sorts of problems that I think could benefit from some improvement. The first is that there should be a standard way to have extra tests, that do not get run in the normal CRAN testing cycle, or by developers when using a quick R CMD check, but can be run with a standard mechanism. I do this by putting the tests in a separate package, and I have seen reports of different mechanisms, but I think they are all somewhat ad hoc. Currently, if you put too much testing in your package then all the testing gets omitted on some CRAN testing platforms. Just a common directory like extraTests/ would be a good start. The second problem is that a developer usually needs to run tests/ when code in R/ has been changed, but probably not run tests/ when the changes are only in man/, demos/, or inst/doc/. The checking that needs to be done in those cases is reduced from the full R
Re: [Rd] package development
Jeff Ryan wrote: A quick comment on two subjects: First to get the line # from the command line: cat pkg/R/* all.R wc all.R vim +LINE all.R (or pick you favorite method here...) The tmp file is also indicated in error message, so you can edit that, go to the line number, find context, grep the files in R/, and then go directly to the line that needs to be fixed in the source file. Couldn't be simpler? From there it should be easy enough to get context. At least enough to grep back into the R directory. Also, the use of unit-tests is IMO the best answer for managing a separate test suite that you can selectively run (all of part of) during the build phase. Simply editing/adding an .Rbuildignore is all you need to turn it off or on. This makes it easy not to distribute the tests as well, if you choose not too. Yes, there are several options for not distributing tests. I was thinking more about how to distribute them with a simple mechanism for anyone to run them, but in a way that they are not run by the usual R CMD check. Paul RUnit is a good tool to look into. HTH Jeff On Fri, Dec 12, 2008 at 8:12 AM, Paul Gilbert pgilb...@bank-banque-canada.ca wrote: Duncan Murdoch wrote: On 11/12/2008 6:04 PM, Terry Therneau wrote: I'm making the move of the survival package from my own environment to, and have stumbled into a vacuum. The R Extensions manual has really nice instructions about how to lay out the directories, order the files, and run tests for DISTRIBUTION of a product, but I can't find anything on how to set up a reasonable DEVELOPMENT environment. In my local world, I had the .c and .s files in a common directory, with a Makefile that I had created, and the test suite in a subdirectory. Debugging and development was quite nice. make cd test R attach(..) try something and perhaps it fails q() cd .. Fix and repeat. The Makefile took some time to create, but paid for itself a hundred times over. So, I've now rearranged everything into standard R order. Then I did the only thing I could find R CMD INSTALL ~/myRlib survival where survival is said directory. This turns out to be not useful at all. The survival package is large, and I rather suspected that I would goof something up, and I did, resulting in the following message Error in parse(n = -1, file = file) : unexpected end of input at 14450: } 14451: It is not exactly obvious which of the 132 files in my R/ directory is the culprit here. That's something I would like to fix too. There are (at least) two possible ways: stop concatenating the files (which is not really needed nowadays, most packages install saved images), or add some markup to the concatenated file so that the parser can report on the original filename and line number (like the #LINE directives output by the C preprocessor). I would certainly appreciate a fix for this. When this has happened to me, I usually end up just sourcing the individual files into an R session until I find the bad file, and get a report with the right line number. It always seems like a lot of work for something that should be trivial. In general: 1. The library is large, and recompiling/reparsing everything is very far from instantaneous. It is not the edit/load cycle I desire. If you install from the directory, the compiling should only be done once (unless you change a file, of course). (The alternative is installing from the tarball, which is recommended for later stages of testing before distribution, because it's possible something could go wrong in building the tarball. But it won't include any object files, so you'll recompile every time.) You can also use option --docs=none to skip building the help system; this will save a bit of time. 2. I take testing seriously: the test suite takes on the order of 15 minutes to run on a fast machine. I most certainly don't want to run it in the mid cycle. I don't quite follow this. If you want to run all your tests, you would use R CMD check. If you only want to run some of them, then you can source things out of the tests directory while running interactively. Someone must have tackled this. I'm hoping that there is some documentation that I have managed to overlook which discussess a good setup for this middle ground between concieving of a library and packaging it for delivery; the build, test, make sure it acually works part of development. In my experience there are two differ sorts of problems that I think could benefit from some improvement. The first is that there should be a standard way to have extra tests, that do not get run in the normal CRAN testing cycle, or by developers when using a quick R CMD check, but can be run with a standard mechanism. I do this by putting the tests in a separate package, and I have seen reports of different mechanisms, but I think they are all somewhat ad hoc. Currently, if you put too much testing in your package
Re: [Rd] function qt can fails if ndf 1 (PR#13364)
You have missed the following item in NEWS for R-patched.
NEW FEATURES
o qt() now works for 0 df 1.
Please review what the FAQ has to say about checkiong your facts and not
reporting things which are already fixed.
Fortunately this example had some use: it showed someone had replaced a
working method in R-devel by one that infinite-looped, and I've reverted
it.
On Wed, 3 Dec 2008, ger...@mail.generacio.com wrote:
Full_Name: Gerard Torrent
Version: R version 2.8.0 (2008-10-20)
OS: Linux 2.6.27.5-41.fc9.x86_64 #1 SMP
Submission from: (NULL) (85.52.227.233)
In some cases qt complains about NaNs and don't gives the correct result:
qt(0.1,, 0.1)
That gives a syntax error
[1] NaN
Warning message:
In qt(p, df, lower.tail, log.p) : NaNs produced
But the result can be found:
pt(-1.60443e+06, 0.1)
[1] 0.0997
It actually was documented so in 2.8.0
df: degrees of freedom ( 0, maybe non-integer). 'df = Inf' is
allowed. For 'qt' only values of at least one are currently
supported unless 'ncp' is supplied.
!
If I replace the current method by bisection method in file file src/nmath/qt.c
the result is computed fine.
int cont=0;
do {
cont++;
nx = lx + (ux - lx)/2.0;
if ((pp = pt(nx, ndf, TRUE, FALSE)) p) {
ux = nx; pu = pp;
} else {
lx = nx; pl = pp;
}
}
while ((ux - lx) / fabs(nx) accu cont 100);
__
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] package development
I think the /tmp file gets removed: ERROR: lazy loading failed for package 'xts' ** Removing '/private/tmp/Rinst625532301/xts' ERROR Installation failed. Removing '/tmp/Rinst625532301' At least it seems to when I run R CMD from the shell. Yes, there are several options for not distributing tests. I was thinking more about how to distribute them with a simple mechanism for anyone to run them, but in a way that they are not run by the usual R CMD check. You can still distribute the tests in the inst/unitTests directory, you would just have to make sure that the calling script in the /tests directory is commented out. Alternately you could have that /tests/doRUnit.R script (or whatever you call it/them) check for some environment variable to be set before running the full suite. Jeff __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Warning: missing text for item ... in \describe?
Hello:
For the record, I found the source of this warning: I had an
extraneous space in \item{fd} {text}: When I changed to
\item{fd}{text}, this warning disappeared.
Best Wishes,
Spencer
#
What might be the problem generating messages like Warning:
missing text for item ... in \describe with R CMD check and R CMD
install?
With the current version of fda on R-Forge, I get the following:
Warning: missing text for item 'fd' in \describe
Warning: missing text for item 'fdPar' in \describe
I found a where someone else asked about essentially this warning
message, but I didn't find a reply. I also found that
https://svn.r-project.org/R/trunk/share/perl/R/Rdconv.pm; is coded to
issue such messages. However, I still don't know what I'm doing to
generate it.
Thanks in advance for any suggestions.
Best Wishes,
Spencer
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Warning: missing text for item ... in \describe?
On Fri, 12 Dec 2008, Spencer Graves wrote:
Hello:
For the record, I found the source of this warning: I had an
extraneous space in \item{fd} {text}: When I changed to \item{fd}{text},
this warning disappeared.
And while you've been away you missed
https://stat.ethz.ch/pipermail/r-devel/2008-December/051559.html
and of course
http://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64/fda-00check.html
Best Wishes,
Spencer
#
What might be the problem generating messages like Warning:
missing text for item ... in \describe with R CMD check and R CMD
install?
With the current version of fda on R-Forge, I get the following:
Warning: missing text for item 'fd' in \describe
Warning: missing text for item 'fdPar' in \describe
I found a where someone else asked about essentially this warning
message, but I didn't find a reply. I also found that
https://svn.r-project.org/R/trunk/share/perl/R/Rdconv.pm; is coded to
issue such messages. However, I still don't know what I'm doing to
generate it.
Thanks in advance for any suggestions.
Best Wishes,
Spencer
__
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
[Rd] gregexpr - match overlap mishandled (PR#13391)
Full_Name: Reid Thompson Version: 2.8.0 RC (2008-10-12 r46696) OS: darwin9.5.0 Submission from: (NULL) (129.98.107.177) the gregexpr() function does NOT return a complete list of global matches as it should. this occurs when a pattern matches two overlapping portions of a string, only the first match is returned. the following function call demonstrates this error (although this is not how I initially discovered the problem): gregexpr(11221122, paste(rep(1122, 10), collapse=)) instead of returning 9 matches as one would expect, only 5 matches are returned . . . [[1]] [1] 1 9 17 25 33 attr(,match.length) [1] 8 8 8 8 8 you will note, essentially, that the entire first match is then excluded from subsequent matching __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] gregexpr - match overlap mishandled (PR#13391)
Please do your own homework: the help page says For 'gregexpr' a list of the same length as 'text' each element of which is an integer vector as in 'regexpr', except that the starting positions of every (disjoint) match are given. If that is still not clear enough for you, please ask your supervisor for remedial help. On Fri, 12 Dec 2008, rthom...@aecom.yu.edu wrote: Full_Name: Reid Thompson Version: 2.8.0 RC (2008-10-12 r46696) OS: darwin9.5.0 Submission from: (NULL) (129.98.107.177) the gregexpr() function does NOT return a complete list of global matches as it should. this occurs when a pattern matches two overlapping portions of a string, only the first match is returned. the following function call demonstrates this error (although this is not how I initially discovered the problem): gregexpr(11221122, paste(rep(1122, 10), collapse=)) instead of returning 9 matches as one would expect, only 5 matches are returned . . . [[1]] [1] 1 9 17 25 33 attr(,match.length) [1] 8 8 8 8 8 you will note, essentially, that the entire first match is then excluded from subsequent matching __ 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] package development
Mathieu Ribatet mathieu.ribatet at epfl.ch writes: Dear Terry, One way to locate which file is wrong - surely not the most brillant way! You could do an R script that sources each of your .R files within a for (file in file.names) loop. When R will stop, it will indicate which file has a wrong syntax and more info. Yes, I also use this approach, however making use of the sourceDir() utility function that you get by example(source). I had contemplated on and off, it was worth of making sourceDir() an official function and had found that I could not reasonably see the case for it.. Martin Maechler, ETH Zurich __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] gregexpr - match overlap mishandled (PR#13391)
Where do you get should and expect from? All the regular expression tools that I am familiar with only match non-overlapping patterns unless you do extra to specify otherwise. One of the standard references for regular expressions if you really want to understand what is going on is Mastering Regular Expressions by Jeffrey Friedl. You should really read through that book before passing judgment on the correctness of an implementation. If you want the overlaps, you need to come up with a regular expression that will match without consuming all of the string. Here is one way to do it with your example: gregexpr(1122(?=1122), paste(rep(1122, 10), collapse=), perl=TRUE) [[1]] [1] 1 5 9 13 17 21 25 29 33 attr(,match.length) [1] 4 4 4 4 4 4 4 4 4 -- 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 rthom...@aecom.yu.edu Sent: Friday, December 12, 2008 10:05 AM To: r-de...@stat.math.ethz.ch Cc: r-b...@r-project.org Subject: [Rd] gregexpr - match overlap mishandled (PR#13391) Full_Name: Reid Thompson Version: 2.8.0 RC (2008-10-12 r46696) OS: darwin9.5.0 Submission from: (NULL) (129.98.107.177) the gregexpr() function does NOT return a complete list of global matches as it should. this occurs when a pattern matches two overlapping portions of a string, only the first match is returned. the following function call demonstrates this error (although this is not how I initially discovered the problem): gregexpr(11221122, paste(rep(1122, 10), collapse=)) instead of returning 9 matches as one would expect, only 5 matches are returned . . . [[1]] [1] 1 9 17 25 33 attr(,match.length) [1] 8 8 8 8 8 you will note, essentially, that the entire first match is then excluded from subsequent matching __ 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] gregexpr - match overlap mishandled (PR#13391)
Where do you get should and expect from? All the regular expression to= ols that I am familiar with only match non-overlapping patterns unless you = do extra to specify otherwise. One of the standard references for regular = expressions if you really want to understand what is going on is Mastering= Regular Expressions by Jeffrey Friedl. You should really read through th= at book before passing judgment on the correctness of an implementation. If you want the overlaps, you need to come up with a regular expression tha= t will match without consuming all of the string. Here is one way to do it= with your example: gregexpr(1122(?=3D1122), paste(rep(1122, 10), collapse=3D), perl= =3DTRUE) [[1]] [1] 1 5 9 13 17 21 25 29 33 attr(,match.length) [1] 4 4 4 4 4 4 4 4 4 -- 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 rthom...@aecom.yu.edu Sent: Friday, December 12, 2008 10:05 AM To: r-de...@stat.math.ethz.ch Cc: r-b...@r-project.org Subject: [Rd] gregexpr - match overlap mishandled (PR#13391) Full_Name: Reid Thompson Version: 2.8.0 RC (2008-10-12 r46696) OS: darwin9.5.0 Submission from: (NULL) (129.98.107.177) the gregexpr() function does NOT return a complete list of global matches as it should. this occurs when a pattern matches two overlapping portions of a string, only the first match is returned. the following function call demonstrates this error (although this is not how I initially discovered the problem): gregexpr(11221122, paste(rep(1122, 10), collapse=3D)) instead of returning 9 matches as one would expect, only 5 matches are returned . . . [[1]] [1] 1 9 17 25 33 attr(,match.length) [1] 8 8 8 8 8 you will note, essentially, that the entire first match is then excluded from subsequent matching __ 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] gregexpr - match overlap mishandled (PR#13391)
On Fri, Dec 12, 2008 at 4:35 PM, greg.s...@imail.org wrote: do extra to specify otherwise. One of the standard references for regular = expressions if you really want to understand what is going on is Mastering= Regular Expressions by Jeffrey Friedl. You should really read through th= There are also regular expression links in the Links box of the gsubfn home page: http://gsubfn.googlecode.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
