Re: [Rd] proposed changes to RSiteSearch
From: spencerg
Thank you all for your suggestions. My goal with this
is to make
it as easy as possible for R users to find what they want in
contributed
packages. A referee for our R Journal manuscript complained that
RSiteSearch.function was too much to type, suggesting we consider
masking RSiteSearch. From the discussion, I do not see a strong
consensus for doing that. I like Romain's suggestion to shorten the
name further to, e.g., web.search or doc.search. Another
colleague
suggested RSearch.
What do you think about renaming the current
RSiteSearch.function{RSiteSearch} to RSearch{RSearch}?
I'm happy to support the consensus of this group on a name (and
even enhancements) that seems likely to maximize its utility to R
users. I ask, because a rose by any other name would smell as sweet,
but one named prettysweetsmellingthingamabob might not sell
as well.
Thanks,
Spencer
[I've removed those on cc since I believe everyone will get this through
R-devel anyway...]
I'd suggest something like findFunction() or some such, if the main goal
is to look for functions (not manuals, vignettes, mailing lists, etc.).
RSiteSearch() was named what it was because it was meant as an interface
to Jon's search site that has lots of things related to R.
It seems to me that the recent discussion has been about including other
alternative search engines, etc. Recall that when we were discussing
including RSiteSearch() into base R, Jon basically had to commit to
maintaining the site, as well as documenting how to replicate the site
if and when he could no longer maintain it, before R Core accepted the
function. I think it would be wonderful to have a search facility
that's all encompassing (Roogle?), but for inclusion into base R we
really need to have the sites being searched being basically permenant.
Perhaps a bit OT, but what would really be nice is if a search facility
can not only find functions that's related to some search phrase, but
also indicate whether the packages the functions belong to have already
been installed on the user's system. Sort of like yum info or yum
search for those on RedHat-based Linux...
Best,
Andy
Gabor Grothendieck wrote:
On Thu, Jun 4, 2009 at 12:13 PM, Duncan Murdoch
murd...@stats.uwo.ca wrote:
Gabor Grothendieck wrote:
On Thu, Jun 4, 2009 at 1:58 AM, Duncan Murdoch
murd...@stats.uwo.ca
wrote:
spencerg wrote:
Hello All:
What do you think of adding a function RSiteSeach
to the package
of
that name, masking the RSiteSearch function in
utils, trapping any
call
RSiteSearch('searchstring', 'function') to the current
RSiteSearch.function
and passing all others to utils:::RSiteSearch? This
was suggested by
a
referee to a manuscript on this new capability
submitted to R Journal.
The current version of this manuscript is available via
system.file('doc',
'RSiteSearch.pdf', package='RSiteSearch') if you have
the RSiteSearch
package installed.
I suppose this depends on your long term plans for the
function and
package.
If you think it should eventually replace the utils
function, then it
makes
sense to use the same name: users won't get used to a
new name in the
meantime. But if you think it will diverge from that
function, then you
might as well pick a separate name now.
I disagree with Gabor about this being heavy handed, at
least while it is
the only significant export in the package. If people
don't want it,
don't
attach the package.
The last sentence only gives you a choice of clobbering
the existing
function or not using it and that is not very nice.
What is wanted is
both to be able to use it and allow it to coexist in a nice way.
It is essentially a rename of the existing one to
utils::RSiteSearch. I
would only suggest this if RSiteSearch::RSiteSearch expanded on its
capabilities (which I think was Spencer's proposal),
rather than replacing
them with something different.
How about R changing its RSiteSearch to be an S3 generic with the
main functionality being placed into RSiteSearch.default? Then
RSiteSearch.function can become RsiteSearch.character and
- RSiteSearch will give the new functionality when the package is
loaded and the old functionality if not.
- RSiteSearch.character can be used in place of
RSiteSearch.function
to force only the new functionality (or an error if not present)
- RSiteSearch.default will give the old functionality
whether or not the
package is loaded
(If there is a NAMESPACE then Its assumed here that both
methods are
exported.)
How is that an improvement? Just replace your (RSiteSearch,
RSiteSearch.character, RSiteSearch.default) with (RSiteSearch,
RSiteSearch::RSiteSearch, utils::RSiteSearch) in my
Re: [Rd] Show location of workspace image on quit?
Barry Rowlingson wrote: Would something like q() Save workspace image (/home/me/workspace/.RData)? [y/n/c]: be useful to anyone else? Just thought I'd ask before I dive into internals or wrap the q function for myself. yes, it would be very useful to me. vQ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Show location of workspace image on quit?
On 05/06/2009 7:53 AM, Barry Rowlingson wrote: When I quit R, it says: q() Save workspace image? [y/n/c]: and since I've probably got 3 R sessions running in however many different directories and I might have jumped around with setwd() , I forget exactly where R wants to save its workspace image. So could q() be changed to say what file it is going to save to before it does? Currently I have to hit 'c', then do getcwd(), then quit again. Would something like q() Save workspace image (/home/me/workspace/.RData)? [y/n/c]: be useful to anyone else? Just thought I'd ask before I dive into internals or wrap the q function for myself. That sounds like a great suggestion. I might word it as Save workspace to /home/me/workspace/.RData? [y/n/c] If people are working deep in a directory tree, the path might end up too long; you might want to think about limiting it (e.g. by leaving off the root). Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Show location of workspace image on quit?
When I quit R, it says: q() Save workspace image? [y/n/c]: and since I've probably got 3 R sessions running in however many different directories and I might have jumped around with setwd() , I forget exactly where R wants to save its workspace image. So could q() be changed to say what file it is going to save to before it does? Currently I have to hit 'c', then do getcwd(), then quit again. Would something like q() Save workspace image (/home/me/workspace/.RData)? [y/n/c]: be useful to anyone else? Just thought I'd ask before I dive into internals or wrap the q function for myself. Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Show location of workspace image on quit?
I guess that having something like this q() Save workspace image (/home/me/workspace/.RData)? [y/n/c/e]: where e means Editing the path should be clear enought, isn't it? Best, Mathieu Le vendredi 05 juin 2009 à 14:36 +0200, Wacek Kusnierczyk a écrit : Duncan Murdoch wrote: On 05/06/2009 7:53 AM, Barry Rowlingson wrote: When I quit R, it says: q() Save workspace image? [y/n/c]: and since I've probably got 3 R sessions running in however many different directories and I might have jumped around with setwd() , I forget exactly where R wants to save its workspace image. So could q() be changed to say what file it is going to save to before it does? Currently I have to hit 'c', then do getcwd(), then quit again. Would something like q() Save workspace image (/home/me/workspace/.RData)? [y/n/c]: be useful to anyone else? Just thought I'd ask before I dive into internals or wrap the q function for myself. That sounds like a great suggestion. I might word it as Save workspace to /home/me/workspace/.RData? [y/n/c] but then what would happen if you choose 'n'? i'd expect a prompt for another path -- and i'd suspect this is what others would expect, too. with the message as barry suggests, exiting without saving is the most natural thing, which is what happens in the current implementation. if you insist on your version, it would be better, i think, to change the behaviour, too. vQ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Institute of Mathematics Ecole Polytechnique Fédérale de Lausanne STAT-IMA-FSB-EPFL, Station 8 CH-1015 Lausanne Switzerland http://stat.epfl.ch/ Tel: + 41 (0)21 693 7907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Show location of workspace image on quit?
Mathieu Ribatet wrote: I guess that having something like this q() Save workspace image (/home/me/workspace/.RData)? [y/n/c/e]: where e means Editing the path should be clear enought, isn't it? good idea; maybe 'o' for 'other path'; or 'a' for 'alternative path'; or 'd' for 'different path'; or 'm' for 'modify path'; or 'p' for 'path'; or... ? vQ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Show location of workspace image on quit?
I think e is better than others. Ronggui 2009/6/5 Wacek Kusnierczyk waclaw.marcin.kusnierc...@idi.ntnu.no: Mathieu Ribatet wrote: I guess that having something like this q() Save workspace image (/home/me/workspace/.RData)? [y/n/c/e]: where e means Editing the path should be clear enought, isn't it? good idea; maybe 'o' for 'other path'; or 'a' for 'alternative path'; or 'd' for 'different path'; or 'm' for 'modify path'; or 'p' for 'path'; or... ? vQ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- HUANG Ronggui, Wincent PhD Candidate Dept of Public and Social Administration City University of Hong Kong Home page: http://asrr.r-forge.r-project.org/rghuang.html __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] proposed changes to RSiteSearch
Liaw, Andy wrote:
From: spencerg
Thank you all for your suggestions. My goal with this
is to make
it as easy as possible for R users to find what they want in
contributed
packages. A referee for our R Journal manuscript complained that
RSiteSearch.function was too much to type, suggesting we consider
masking RSiteSearch. From the discussion, I do not see a strong
consensus for doing that. I like Romain's suggestion to shorten the
name further to, e.g., web.search or doc.search. Another
colleague
suggested RSearch.
What do you think about renaming the current
RSiteSearch.function{RSiteSearch} to RSearch{RSearch}?
I'm happy to support the consensus of this group on a name (and
even enhancements) that seems likely to maximize its utility to R
users. I ask, because a rose by any other name would smell as sweet,
but one named prettysweetsmellingthingamabob might not sell
as well.
Thanks,
Spencer
[I've removed those on cc since I believe everyone will get this through
R-devel anyway...]
I'd suggest something like findFunction() or some such, if the main goal
is to look for functions (not manuals, vignettes, mailing lists, etc.).
findFunction sounds to me like the best name I've heard so far.
RSiteSearch() was named what it was because it was meant as an interface
to Jon's search site that has lots of things related to R.
It seems to me that the recent discussion has been about including other
alternative search engines, etc. Recall that when we were discussing
including RSiteSearch() into base R, Jon basically had to commit to
maintaining the site, as well as documenting how to replicate the site
if and when he could no longer maintain it, before R Core accepted the
function. I think it would be wonderful to have a search facility
that's all encompassing (Roogle?), but for inclusion into base R we
really need to have the sites being searched being basically permenant.
Perhaps a bit OT, but what would really be nice is if a search facility
can not only find functions that's related to some search phrase, but
also indicate whether the packages the functions belong to have already
been installed on the user's system. Sort of like yum info or yum
search for those on RedHat-based Linux...
The current RSiteSeach package includes that adds other
information from packageDescription to the package summary, adding
(current default) Title, Version, Author, Maintainer, and (date)
Packaged. If the package is not installed, these fields are left
blank. I've used this to prioritize which packages (and then which
functions) I should consider first.
Best Wishes,
Spencer
Best,
Andy
Gabor Grothendieck wrote:
On Thu, Jun 4, 2009 at 12:13 PM, Duncan Murdoch
murd...@stats.uwo.ca wrote:
Gabor Grothendieck wrote:
On Thu, Jun 4, 2009 at 1:58 AM, Duncan Murdoch
murd...@stats.uwo.ca
wrote:
spencerg wrote:
Hello All:
What do you think of adding a function RSiteSeach
to the package
of
that name, masking the RSiteSearch function in
utils, trapping any
call
RSiteSearch('searchstring', 'function') to the current
RSiteSearch.function
and passing all others to utils:::RSiteSearch? This
was suggested by
a
referee to a manuscript on this new capability
submitted to R Journal.
The current version of this manuscript is available via
system.file('doc',
'RSiteSearch.pdf', package='RSiteSearch') if you have
the RSiteSearch
package installed.
I suppose this depends on your long term plans for the
function and
package.
If you think it should eventually replace the utils
function, then it
makes
sense to use the same name: users won't get used to a
new name in the
meantime. But if you think it will diverge from that
function, then you
might as well pick a separate name now.
I disagree with Gabor about this being heavy handed, at
least while it is
the only significant export in the package. If people
don't want it,
don't
attach the package.
The last sentence only gives you a choice of clobbering
the existing
function or not using it and that is not very nice.
What is wanted is
both to be able to use it and allow it to coexist in a nice way.
It is essentially a rename of the existing one to
utils::RSiteSearch. I
would only suggest this if RSiteSearch::RSiteSearch expanded on its
capabilities (which I think was Spencer's proposal),
rather than replacing
them with something different.
How about R changing its
Re: [Rd] Show location of workspace image on quit?
On Fri, Jun 5, 2009 at 1:46 PM, Mathieu Ribatetmathieu.riba...@epfl.ch wrote: I guess that having something like this q() Save workspace image (/home/me/workspace/.RData)? [y/n/c/e]: where e means Editing the path should be clear enought, isn't it? 'e' might be thought to mean 'exit' in English, which makes me think we also need to make sure this can all be translated. Maybe 'p' for path? Or 'e' for 'elsewhere'? This is getting tricky :) I think I'd rather leave off the 'e' option for simplicity - if the user wants to save elsewhere they can hit 'c' and do save() or setcwd() themselves, I'm not sure we need to put extra functionality into the q function. Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] proposed changes to RSiteSearch
On 6/5/2009 9:41 AM, spencerg wrote:
Liaw, Andy wrote:
From: spencerg
Thank you all for your suggestions. My goal with this
is to make
it as easy as possible for R users to find what they want in
contributed
packages. A referee for our R Journal manuscript complained that
RSiteSearch.function was too much to type, suggesting we consider
masking RSiteSearch. From the discussion, I do not see a strong
consensus for doing that. I like Romain's suggestion to shorten the
name further to, e.g., web.search or doc.search. Another
colleague
suggested RSearch.
What do you think about renaming the current
RSiteSearch.function{RSiteSearch} to RSearch{RSearch}?
I'm happy to support the consensus of this group on a name (and
even enhancements) that seems likely to maximize its utility to R
users. I ask, because a rose by any other name would smell as sweet,
but one named prettysweetsmellingthingamabob might not sell
as well.
Thanks,
Spencer
[I've removed those on cc since I believe everyone will get this through
R-devel anyway...]
I'd suggest something like findFunction() or some such, if the main goal
is to look for functions (not manuals, vignettes, mailing lists, etc.).
findFunction sounds to me like the best name I've heard so far.
But it isn't looking for functions, it's looking for help pages about
functions. Another possibility is ???, e.g.
???topic
This is done by masking the utils function `?`, and you'd have to be
careful to pass along requests with one or two (or more than three?)
question marks to the original; it also feels a bit strange to type
hits - ???topic
though I think it's syntactic and well-defined. I'm not sure how you'd
include your optional arguments, it would be really weird (but again
well defined) to say
z - ???spline(maxPages = 2)
(Your first example in ?RSiteSearch.function, translated).
Duncan Murdoch
RSiteSearch() was named what it was because it was meant as an interface
to Jon's search site that has lots of things related to R.
It seems to me that the recent discussion has been about including other
alternative search engines, etc. Recall that when we were discussing
including RSiteSearch() into base R, Jon basically had to commit to
maintaining the site, as well as documenting how to replicate the site
if and when he could no longer maintain it, before R Core accepted the
function. I think it would be wonderful to have a search facility
that's all encompassing (Roogle?), but for inclusion into base R we
really need to have the sites being searched being basically permenant.
Perhaps a bit OT, but what would really be nice is if a search facility
can not only find functions that's related to some search phrase, but
also indicate whether the packages the functions belong to have already
been installed on the user's system. Sort of like yum info or yum
search for those on RedHat-based Linux...
The current RSiteSeach package includes that adds other
information from packageDescription to the package summary, adding
(current default) Title, Version, Author, Maintainer, and (date)
Packaged. If the package is not installed, these fields are left
blank. I've used this to prioritize which packages (and then which
functions) I should consider first.
Best Wishes,
Spencer
Best,
Andy
Gabor Grothendieck wrote:
On Thu, Jun 4, 2009 at 12:13 PM, Duncan Murdoch
murd...@stats.uwo.ca wrote:
Gabor Grothendieck wrote:
On Thu, Jun 4, 2009 at 1:58 AM, Duncan Murdoch
murd...@stats.uwo.ca
wrote:
spencerg wrote:
Hello All:
What do you think of adding a function RSiteSeach
to the package
of
that name, masking the RSiteSearch function in
utils, trapping any
call
RSiteSearch('searchstring', 'function') to the current
RSiteSearch.function
and passing all others to utils:::RSiteSearch? This
was suggested by
a
referee to a manuscript on this new capability
submitted to R Journal.
The current version of this manuscript is available via
system.file('doc',
'RSiteSearch.pdf', package='RSiteSearch') if you have
the RSiteSearch
package installed.
I suppose this depends on your long term plans for the
function and
package.
If you think it should eventually replace the utils
function, then it
makes
sense to use the same name: users won't get used to a
new name in the
meantime. But if you think it will diverge from that
function, then you
might as well pick a separate name now.
I disagree with Gabor about this being heavy handed, at
least while it is
the only significant export in the package. If people
Re: [Rd] Show location of workspace image on quit?
On 6/5/2009 9:46 AM, Barry Rowlingson wrote: On Fri, Jun 5, 2009 at 1:46 PM, Mathieu Ribatetmathieu.riba...@epfl.ch wrote: I guess that having something like this q() Save workspace image (/home/me/workspace/.RData)? [y/n/c/e]: where e means Editing the path should be clear enought, isn't it? 'e' might be thought to mean 'exit' in English, which makes me think we also need to make sure this can all be translated. Maybe 'p' for path? Or 'e' for 'elsewhere'? This is getting tricky :) I think I'd rather leave off the 'e' option for simplicity - if the user wants to save elsewhere they can hit 'c' and do save() or setcwd() themselves, I'm not sure we need to put extra functionality into the q function. An alternative to think about is to report where the file was saved, rather than tease the user by suggesting s/he has a choice. This is a bit harder in the GUIs, but would be very easy in a console, just print the path after quitting: Save workspace image? [y/n/c]: y Image saved to /home/me/workspace/.RData In the Windows GUI you could pop up a dialog box to say this, with a checkbox saying don't show me this next time. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Show location of workspace image on quit?
On Fri, Jun 5, 2009 at 9:43 AM, Wacek Kusnierczykwaclaw.marcin.kusnierc...@idi.ntnu.no wrote: Mathieu Ribatet wrote: I guess that having something like this q() Save workspace image (/home/me/workspace/.RData)? [y/n/c/e]: where e means Editing the path should be clear enought, isn't it? good idea; maybe 'o' for 'other path'; or 'a' for 'alternative path'; or 'd' for 'different path'; or 'm' for 'modify path'; or 'p' for 'path'; or... ? or perhaps clearer: Save workspace to /home/me/workspace/.RData? [ y(es) / (n(o) / c(ancel) / o(ther) ]: __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Bug in print.Arima and patch
Dear List,
A posting to R-Help exposed this problem with the print method for
objects of class Arima:
set.seed(1)
x - arima.sim(n = 100, list(ar = 0.8897, ma = -0.2279))
mod - arima(x, order = c(1,0,1))
coefs - coef(mod)
mod2 - arima(x, order = c(1,0,1), fixed = coefs)
mod2
Call:
arima(x = x, order = c(1, 0, 1), fixed = coefs)
Coefficients:
Error in se nrow(x$var.coef) : invalid 'y' type in 'x y'
print(mod2, se = FALSE)
Call:
arima(x = x, order = c(1, 0, 1), fixed = coefs)
Coefficients:
ar1ma1 intercept
0.9323-0.2940-0.0353
sigma^2 estimated as 0.8339: log likelihood = -133.55, aic = 269.11
The print methods raises an error in this case, where all coefficients
are fixed, because x$var.coef is of length(0), which in turn results in
NULL being used in the comparison, resulting in the error.
A potential fix is to just include a check for length(x$var.coef) 0 in
the if statement. This fix, when applied to:
R version 2.10.0 Under development (unstable) (2009-06-05 r48712)
fixes this particular problem and passes make check-devel. A patch
against r48712 is attached, and included here in-line:
[ga...@desktop build]$ svn diff ../src/library/stats/R/arima.R
Index: ../src/library/stats/R/arima.R
===
--- ../src/library/stats/R/arima.R (revision 48712)
+++ ../src/library/stats/R/arima.R (working copy)
@@ -355,7 +355,7 @@
if (length(x$coef)) {
cat(Coefficients:\n)
coef - round(x$coef, digits = digits)
-if (se nrow(x$var.coef)) {
+if (se length(x$var.coef) 0 nrow(x$var.coef)) {
ses - rep(0, length(coef))
ses[x$mask] - round(sqrt(diag(x$var.coef)), digits = digits)
coef - matrix(coef, 1L, dimnames = list(NULL, names(coef)))
HTH
G
--
%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
Dr. Gavin Simpson [t] +44 (0)20 7679 0522
ECRC, UCL Geography, [f] +44 (0)20 7679 0565
Pearson Building, [e] gavin.simpsonATNOSPAMucl.ac.uk
Gower Street, London [w] http://www.ucl.ac.uk/~ucfagls/
UK. WC1E 6BT. [w] http://www.freshwaters.org.uk
%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
Index: ../src/library/stats/R/arima.R
===
--- ../src/library/stats/R/arima.R (revision 48712)
+++ ../src/library/stats/R/arima.R (working copy)
@@ -355,7 +355,7 @@
if (length(x$coef)) {
cat(Coefficients:\n)
coef - round(x$coef, digits = digits)
-if (se nrow(x$var.coef)) {
+if (se length(x$var.coef) 0 nrow(x$var.coef)) {
ses - rep(0, length(coef))
ses[x$mask] - round(sqrt(diag(x$var.coef)), digits = digits)
coef - matrix(coef, 1L, dimnames = list(NULL, names(coef)))
signature.asc
Description: This is a digitally signed message part
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Show location of workspace image on quit?
Any change here is not so simple to implement as to propose: this is not something in the R engine, but part of the clean-up action in the front end. That means that there are at least 3 versions to handle in the standard front ends (and that for R.app is not in the main source tarball). And at least two of them is offered for translation so there are many copies. Then there are other front-ends such as JGR and RKward I hope people proposing this will offer complete patches. On Fri, 5 Jun 2009, Duncan Murdoch wrote: On 6/5/2009 9:46 AM, Barry Rowlingson wrote: On Fri, Jun 5, 2009 at 1:46 PM, Mathieu Ribatetmathieu.riba...@epfl.ch wrote: I guess that having something like this q() Save workspace image (/home/me/workspace/.RData)? [y/n/c/e]: where e means Editing the path should be clear enought, isn't it? 'e' might be thought to mean 'exit' in English, which makes me think we also need to make sure this can all be translated. Maybe 'p' for path? Or 'e' for 'elsewhere'? This is getting tricky :) I think I'd rather leave off the 'e' option for simplicity - if the user wants to save elsewhere they can hit 'c' and do save() or setcwd() themselves, I'm not sure we need to put extra functionality into the q function. An alternative to think about is to report where the file was saved, rather than tease the user by suggesting s/he has a choice. This is a bit harder in the GUIs, but would be very easy in a console, just print the path after quitting: Save workspace image? [y/n/c]: y Image saved to /home/me/workspace/.RData In the Windows GUI you could pop up a dialog box to say this, with a checkbox saying don't show me this next time. Duncan Murdoch __ 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 in print.Arima and patch
Why not use NROW?
On Fri, 5 Jun 2009, Gavin Simpson wrote:
Dear List,
A posting to R-Help exposed this problem with the print method for
objects of class Arima:
set.seed(1)
x - arima.sim(n = 100, list(ar = 0.8897, ma = -0.2279))
mod - arima(x, order = c(1,0,1))
coefs - coef(mod)
mod2 - arima(x, order = c(1,0,1), fixed = coefs)
mod2
Call:
arima(x = x, order = c(1, 0, 1), fixed = coefs)
Coefficients:
Error in se nrow(x$var.coef) : invalid 'y' type in 'x y'
print(mod2, se = FALSE)
Call:
arima(x = x, order = c(1, 0, 1), fixed = coefs)
Coefficients:
ar1ma1 intercept
0.9323-0.2940-0.0353
sigma^2 estimated as 0.8339: log likelihood = -133.55, aic = 269.11
The print methods raises an error in this case, where all coefficients
are fixed, because x$var.coef is of length(0), which in turn results in
NULL being used in the comparison, resulting in the error.
A potential fix is to just include a check for length(x$var.coef) 0 in
the if statement. This fix, when applied to:
R version 2.10.0 Under development (unstable) (2009-06-05 r48712)
fixes this particular problem and passes make check-devel. A patch
against r48712 is attached, and included here in-line:
[ga...@desktop build]$ svn diff ../src/library/stats/R/arima.R
Index: ../src/library/stats/R/arima.R
===
--- ../src/library/stats/R/arima.R (revision 48712)
+++ ../src/library/stats/R/arima.R (working copy)
@@ -355,7 +355,7 @@
if (length(x$coef)) {
cat(Coefficients:\n)
coef - round(x$coef, digits = digits)
-if (se nrow(x$var.coef)) {
+if (se length(x$var.coef) 0 nrow(x$var.coef)) {
ses - rep(0, length(coef))
ses[x$mask] - round(sqrt(diag(x$var.coef)), digits = digits)
coef - matrix(coef, 1L, dimnames = list(NULL, names(coef)))
HTH
G
--
%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
Dr. Gavin Simpson [t] +44 (0)20 7679 0522
ECRC, UCL Geography, [f] +44 (0)20 7679 0565
Pearson Building, [e] gavin.simpsonATNOSPAMucl.ac.uk
Gower Street, London [w] http://www.ucl.ac.uk/~ucfagls/
UK. WC1E 6BT. [w] http://www.freshwaters.org.uk
%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
--
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] Show location of workspace image on quit?
On Fri, Jun 5, 2009 at 3:01 PM, Gabor Grothendieckggrothendi...@gmail.com wrote: Save workspace to /home/me/workspace/.RData? [ y(es) / (n(o) / c(ancel) / o(ther) ]: Quitting emacs produces this: Save file /foo/bar/baz.qux? (y, n, !, ., q, C-r, d or C-h) I'm not sure what any other than the first two do. I don't think I've ever used them. Plus there's no mention of the option I usually do when I hit save accidentally, which is C-g (the emacs generic 'panic' button). I don't think I'd want R's quit function to be so verbose. Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug in print.Arima and patch
On Fri, 5 Jun 2009, Gavin Simpson wrote:
On Fri, 2009-06-05 at 15:42 +0100, Prof Brian Ripley wrote:
Why not use NROW?
No reason - had forgotten this existed.
I was testing NROW after having seen the R-help message, so will go
ahead with that solution. But as I was doing so, something urgent
came up locally
Thank you for looking into the issue.
So here is another patch:
[ga...@desktop ~]$ svn diff ~/R/devel/src/
Index: /home/gavin/R/devel/src/library/stats/R/arima.R
===
--- /home/gavin/R/devel/src/library/stats/R/arima.R (revision 48712)
+++ /home/gavin/R/devel/src/library/stats/R/arima.R (working copy)
@@ -355,7 +355,7 @@
if (length(x$coef)) {
cat(Coefficients:\n)
coef - round(x$coef, digits = digits)
-if (se nrow(x$var.coef)) {
+if (se NROW(x$var.coef)) {
ses - rep(0, length(coef))
ses[x$mask] - round(sqrt(diag(x$var.coef)), digits =
digits)
coef - matrix(coef, 1L, dimnames = list(NULL,
names(coef)))
And the same is attached, that implements your suggested change rather
than the one I sent earlier.
Cheers,
G
On Fri, 5 Jun 2009, Gavin Simpson wrote:
Dear List,
A posting to R-Help exposed this problem with the print method for
objects of class Arima:
set.seed(1)
x - arima.sim(n = 100, list(ar = 0.8897, ma = -0.2279))
mod - arima(x, order = c(1,0,1))
coefs - coef(mod)
mod2 - arima(x, order = c(1,0,1), fixed = coefs)
mod2
Call:
arima(x = x, order = c(1, 0, 1), fixed = coefs)
Coefficients:
Error in se nrow(x$var.coef) : invalid 'y' type in 'x y'
print(mod2, se = FALSE)
Call:
arima(x = x, order = c(1, 0, 1), fixed = coefs)
Coefficients:
ar1ma1 intercept
0.9323-0.2940-0.0353
sigma^2 estimated as 0.8339: log likelihood = -133.55, aic = 269.11
The print methods raises an error in this case, where all coefficients
are fixed, because x$var.coef is of length(0), which in turn results in
NULL being used in the comparison, resulting in the error.
A potential fix is to just include a check for length(x$var.coef) 0 in
the if statement. This fix, when applied to:
R version 2.10.0 Under development (unstable) (2009-06-05 r48712)
fixes this particular problem and passes make check-devel. A patch
against r48712 is attached, and included here in-line:
[ga...@desktop build]$ svn diff ../src/library/stats/R/arima.R
Index: ../src/library/stats/R/arima.R
===
--- ../src/library/stats/R/arima.R (revision 48712)
+++ ../src/library/stats/R/arima.R (working copy)
@@ -355,7 +355,7 @@
if (length(x$coef)) {
cat(Coefficients:\n)
coef - round(x$coef, digits = digits)
-if (se nrow(x$var.coef)) {
+if (se length(x$var.coef) 0 nrow(x$var.coef)) {
ses - rep(0, length(coef))
ses[x$mask] - round(sqrt(diag(x$var.coef)), digits = digits)
coef - matrix(coef, 1L, dimnames = list(NULL, names(coef)))
HTH
G
--
%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
Dr. Gavin Simpson [t] +44 (0)20 7679 0522
ECRC, UCL Geography, [f] +44 (0)20 7679 0565
Pearson Building, [e] gavin.simpsonATNOSPAMucl.ac.uk
Gower Street, London [w] http://www.ucl.ac.uk/~ucfagls/
UK. WC1E 6BT. [w] http://www.freshwaters.org.uk
%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
--
%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
Dr. Gavin Simpson [t] +44 (0)20 7679 0522
ECRC, UCL Geography, [f] +44 (0)20 7679 0565
Pearson Building, [e] gavin.simpsonATNOSPAMucl.ac.uk
Gower Street, London [w] http://www.ucl.ac.uk/~ucfagls/
UK. WC1E 6BT. [w] http://www.freshwaters.org.uk
%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
--
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] Show location of workspace image on quit?
On Fri, Jun 5, 2009 at 11:52 AM, Barry Rowlingsonb.rowling...@lancaster.ac.uk wrote: On Fri, Jun 5, 2009 at 3:01 PM, Gabor Grothendieckggrothendi...@gmail.com wrote: Save workspace to /home/me/workspace/.RData? [ y(es) / (n(o) / c(ancel) / o(ther) ]: Quitting emacs produces this: Save file /foo/bar/baz.qux? (y, n, !, ., q, C-r, d or C-h) I'm not sure what any other than the first two do. I don't think I've ever used them. Plus there's no mention of the option I usually do when I hit save accidentally, which is C-g (the emacs generic 'panic' button). I don't think I'd want R's quit function to be so verbose. The problem isn't really verbosity --- the problem is that one has no idea what the options all mean. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Bug in the package RODBC (PR#13745)
Full_Name: N. Srinivasan Version: 2.8.1 OS: Linux Submission from: (NULL) (68.110.225.2) * Installing *source* package 'RODBC' ... checking for gcc... gcc -std=gnu99 checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc -std=gnu99 accepts -g... yes checking for gcc -std=gnu99 option to accept ANSI C... none needed checking how to run the C preprocessor... gcc -std=gnu99 -E checking for egrep... grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking sql.h usability... no checking sql.h presence... no checking for sql.h... no checking sqlext.h usability... no checking sqlext.h presence... no checking for sqlext.h... no configure: error: ODBC headers sql.h and sqlext.h not found ERROR: configuration failed for package 'RODBC' ** Removing '/home/user1/R-2.8.1/library/RODBC' The downloaded packages are in /tmp/RtmpmB0FH5/downloaded_packages Updating HTML index of packages in '.Library' Warning message: In install.packages(RODBC) : installation of package 'RODBC' had non-zero exit status __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] sort/partial NA handling
I am not sure if this is a documentation problem or an implementation problem: The 'partial' feature of sort works fine with all values of na.last for some values of 'partial': sort(c(3,NA,1,2),na.last=FALSE,partial=1:2) # find minimum values [1] NA 1 2 3 sort(c(3,NA,1,2),na.last=TRUE,partial=1:2) [1] 1 2 3 NA sort(c(3,NA,1,2),na.last=NA,partial=1:2) [1] 1 2 3 sort(c(3,NA,1,2),na.last=FALSE,partial=2:3) [1] NA 1 2 3 sort(c(3,NA,1,2),na.last=TRUE,partial=2:3) [1] 1 2 3 NA sort(c(3,NA,1,2),na.last=NA,partial=2:3) [1] 1 2 3 but not all: sort(c(3,NA,1,2),na.last=FALSE,partial=3:4) # find maximum values Error in sort.int(x, na.last = na.last, decreasing = decreasing, ...) : index 4 outside bounds sort(c(3,NA,1,2),na.last=TRUE,partial=3:4) Error in sort.int(x, na.last = na.last, decreasing = decreasing, ...) : index 4 outside bounds sort(c(3,NA,1,2),na.last=NA,partial=3:4) Error in sort.int(x, na.last = na.last, decreasing = decreasing, ...) : index 4 outside bounds # error is expected here, since there will be no .[4] value Thought the documentation warns that many of the options are not available for partial sorting, it does not seem to say anything about NA not being handled in some cases. The problem seems to occur when the 'partial' range would have included non-existent positions if na.last were NA, even when na.last is not NA. -s [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] need help with libtool/aclocal error
I'm trying to build an executable for a program I wrote. The compilation steps go well, but the linking step fails with a libtool version mismatch error. My linking command has this prefix: /path/to/R/bin/R CMD LINK gcc -g -std=gnu99 ... etc. The error looks like this: libtool: Version mismatch error. This is libtool 2.2, but the libtool: definition of this LT_INIT comes from libtool 2.2.6. libtool: You should recreate aclocal.m4 with macros from libtool 2.2 libtool: and run autoconf again. I have no idea what this error message is referring to. The version of libtool installed on the system is none of the ones mentioned in this error: % libtool --version ltmain.sh (GNU libtool) 1.5.22 Debian 1.5.22-4 (1.1220.2.365 2005/12/18 22:14:06) FSF disclaimer The libtool in the R directory has version 2.2: % /path/to/R/bin/libtool --version ltmain.sh (GNU libtool) 2.2 Written by Gordon Matzigkeit g...@gnu.ai.mit.edu, 1996 FSF disclaimer Strangely enough, this same libtool script has the following lines in its source code: # Which release of libtool.m4 was used? macro_version=2.2.6 macro_revision=1.3012 I don't know what to make of this. Be that as it may, does anyone know how I could get past this sticking point? TIA! G. P.S. I should point out that the R I'm using is one that I just compiled so that I could run R under valgrind. Here's the ./configure command I used before running make: % ./configure --prefix=/path/to/R --enable-R-shlib --enable-BLAS-shlib --with-valgrind-instrumentation=2 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] proposed changes to RSiteSearch
Dear Andy, Duncan, et al.
Based on comments from Andy and Duncan, I'd like to revise my
proposal as follows:
1. Rename the current RSiteSearch.function to
findFunction and the package name from RSiteSearch.function to
findFunction, with findFun being an alias for findFunction.
2. Try to write code so '???differential equation(999)'
works the same as 'RSiteSearch.function(differential equation, 999)'
does now.
What do you think? I've made this as two steps, because I can do
1 myself, but I may need help to develop 2.
Thanks again for all your suggestions.
Best Wishes,
Spencer
Duncan Murdoch wrote:
On 6/5/2009 9:41 AM, spencerg wrote:
Liaw, Andy wrote:
From: spencerg
Thank you all for your suggestions. My goal with this is to
make it as easy as possible for R users to find what they want in
contributed packages. A referee for our R Journal manuscript
complained that RSiteSearch.function was too much to type,
suggesting we consider masking RSiteSearch. From the discussion,
I do not see a strong consensus for doing that. I like Romain's
suggestion to shorten the name further to, e.g., web.search or
doc.search. Another colleague suggested RSearch.
What do you think about renaming the current
RSiteSearch.function{RSiteSearch} to RSearch{RSearch}?
I'm happy to support the consensus of this group on a name
(and even enhancements) that seems likely to maximize its utility
to R users. I ask, because a rose by any other name would smell as
sweet, but one named prettysweetsmellingthingamabob might not
sell as well.
Thanks,
Spencer
[I've removed those on cc since I believe everyone will get this
through
R-devel anyway...]
I'd suggest something like findFunction() or some such, if the main
goal
is to look for functions (not manuals, vignettes, mailing lists, etc.).
findFunction sounds to me like the best name I've heard so far.
But it isn't looking for functions, it's looking for help pages about
functions. Another possibility is ???, e.g.
???topic
This is done by masking the utils function `?`, and you'd have to be
careful to pass along requests with one or two (or more than three?)
question marks to the original; it also feels a bit strange to type
hits - ???topic
though I think it's syntactic and well-defined. I'm not sure how
you'd include your optional arguments, it would be really weird (but
again well defined) to say
z - ???spline(maxPages = 2)
(Your first example in ?RSiteSearch.function, translated).
Duncan Murdoch
RSiteSearch() was named what it was because it was meant as an
interface
to Jon's search site that has lots of things related to R.
It seems to me that the recent discussion has been about including
other
alternative search engines, etc. Recall that when we were discussing
including RSiteSearch() into base R, Jon basically had to commit to
maintaining the site, as well as documenting how to replicate the site
if and when he could no longer maintain it, before R Core accepted the
function. I think it would be wonderful to have a search facility
that's all encompassing (Roogle?), but for inclusion into base R we
really need to have the sites being searched being basically permenant.
Perhaps a bit OT, but what would really be nice is if a search facility
can not only find functions that's related to some search phrase, but
also indicate whether the packages the functions belong to have already
been installed on the user's system. Sort of like yum info or yum
search for those on RedHat-based Linux...
The current RSiteSeach package includes that adds other
information from packageDescription to the package summary, adding
(current default) Title, Version, Author, Maintainer, and
(date) Packaged. If the package is not installed, these fields are
left blank. I've used this to prioritize which packages (and then
which functions) I should consider first.
Best Wishes,
Spencer
Best,
Andy
Gabor Grothendieck wrote:
On Thu, Jun 4, 2009 at 12:13 PM, Duncan Murdoch
murd...@stats.uwo.ca wrote:
Gabor Grothendieck wrote:
On Thu, Jun 4, 2009 at 1:58 AM, Duncan Murdoch
murd...@stats.uwo.ca
wrote:
spencerg wrote:
Hello All:
What do you think of adding a function RSiteSeach
to the package
of
that name, masking the RSiteSearch function in
utils, trapping any
call
RSiteSearch('searchstring', 'function') to the current
RSiteSearch.function
and passing all others to utils:::RSiteSearch? This
was suggested by
a
referee to a manuscript on this new capability
submitted to R Journal.
The current version of this manuscript is available via
system.file('doc',
'RSiteSearch.pdf', package='RSiteSearch') if you have
