[Rd] mean (PR#10864)
Full_Name: Paul PONCET Version: 2.6.0 OS: Windows 2000 Submission from: (NULL) (83.137.240.218) Function 'mean.default' calls function 'stats::median' if 'trim = 0.5'. In that case the call should be 'stats::median(x, na.rm = na.rm)' instead of 'stats::median(x, na.rm = FALSE)'. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug in help(). (PR#10859)
On Wed, 27 Feb 2008, [EMAIL PROTECTED] wrote:
There appears to be a bug in help() when there are multiple packages
attached
containing functions with the same name, and offline=TRUE.
It's in utils:::print.help_files_with_topic, now fixed in R-devel.
The simple workaround is to supply the package name in the help call.
Example:
library(mgcv)
library(gam)
If one simply does:
help(gam) # No ``offline=TRUE''
then the following message appears:
Help on topic 'gam' was found in the following packages:
Package Library
mgcv /Library/Frameworks/R.framework/Resources/
library
gam /Users/rturner/Rlib
and a small chooser-menu window pops up to permit one to select the
package to be referred to.
However if one does
help(gam,offline=TRUE)
then the message about multiple packages appears, immediately
followed by
Error in titles[i] - if (inherits(tmp, try-error)) unknown title
else tmp[tools::file_path_sans_ext(tmp$File) == :
nothing to replace with
(and no chooser-menu window pops up).
Session info:
R version 2.6.2 (2008-02-08)
i386-apple-darwin8.10.1
locale:
C
attached base packages:
[1] splines stats graphics grDevices utils datasets methods
[8] base
other attached packages:
[1] mgcv_1.3-29 gam_0.98misc_0.0-2
loaded via a namespace (and not attached):
[1] rcompgen_0.1-17 tcltk_2.6.2 tools_2.6.2
cheers,
Rolf Turner
##
Attention:\ This e-mail message is privileged and confid...{{dropped:9}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] looking for R_approx in 2.6
Hi there. I was wondering what happened to R_approx from R_ext/Applic.h ... it seems to have dissapeared in 2.6.x, and I can't seem to find it simply listed in some other header file. thanks, -peter. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] looking for R_approx in 2.6
Looks like it was removed in r42551 and from the comment it appears it was not part of the R API anyway. -roger Peter Kharchenko wrote: Hi there. I was wondering what happened to R_approx from R_ext/Applic.h ... it seems to have dissapeared in 2.6.x, and I can't seem to find it simply listed in some other header file. thanks, -peter. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Roger D. Peng | http://www.biostat.jhsph.edu/~rpeng/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Unix-like touch to update modification timestamp of file?
Wow, this has to win the prize for some of the most obscure documentation ever. Kudos on your M$-archaeology. Nicholas Message: 9 Date: Wed, 27 Feb 2008 15:23:51 -0500 From: Gabor Grothendieck [EMAIL PROTECTED] Subject: Re: [Rd] Unix-like touch to update modification timestamp of file? To: Henrik Bengtsson [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1 On Wed, Feb 27, 2008 at 1:27 PM, Henrik Bengtsson [EMAIL PROTECTED] wrote: On Wed, Feb 27, 2008 at 8:24 AM, Gabor Grothendieck [EMAIL PROTECTED] wrote: If you only need Windows then this will do it even without RTools: shell(copy /b /v myfile +,,nul) Interesting. Show I figured out that '+' is for append, but how to interpret the two commas? Commas generally have various undocumented effects in Windows batch and sometimes Microsoft mentions one: http://support.microsoft.com/kb/69581 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Warnings generated by log2()/log10() are really large/takes a long time to display
Changing deparse (and internal uses) to only deparse as many lines as
are needed solves this and seems to give a noticeable performance post
(5-10% or more) on quite a few packages.
On Wed, 27 Feb 2008, Prof Brian Ripley wrote:
On Wed, 27 Feb 2008, Martin Maechler wrote:
Thank you Henrik,
HenrikB == Henrik Bengtsson [EMAIL PROTECTED]
on Tue, 26 Feb 2008 22:03:24 -0800 writes:
{with many superfluous empty statements ( i.e., trailing ; ):
Indeed!
HenrikB x - rnorm(1e6);
[]
HenrikB y - log2(x); # or log10(x)
HenrikB w - warnings();
HenrikB print(object.size(w));
HenrikB ## [1] 8000536
HenrikB str(w);
HenrikB ## List of 1
HenrikB ## $ NaNs produced: language log(c(2.12082478659910,
HenrikB 1.40263187453398, 1.574125429
HenrikB ## 83486, -0.816399069824751, 0.215940065840533,
1.20975177084379,
HenrikB -0.340287874362
HenrikB ## 813, 0.117151537611550, ...
HenrikB ## - attr(*, dots)= list()
HenrikB ## - attr(*, class)= chr warnings
HenrikB Note also how long it takes to display and str() the warning.
Yes, indeed.
It's a subtle problem and happens
because in do_log1arg() a new call is constructed in which 'x'
has already been evaluated.
A subtle fix to the subtle problem
is to replace CAR(args) by CADR(call) in there
--- arithmetic.c (Revision 44626)
+++ arithmetic.c (working copy)
@@ -1372,7 +1372,9 @@
if(PRIMVAL(op) == 10) tmp = ScalarReal(10.0);
if(PRIMVAL(op) == 2) tmp = ScalarReal(2.0);
-PROTECT(Call = lang3(install(log), CAR(args), tmp));
+/* CADR(call) instead of CAR(args), since 'args' have been
+ * evaluated in Dispatch*(..) above : */
+PROTECT(Call = lang3(install(log), CADR(call), tmp));
res = eval(Call, env);
UNPROTECT(1);
return res;
-
That does fix the problem you've reported (and passes make check)
but I'm not quite at ease with it, since it will lead to
effectively evaluate the argument *twice*.
A different approach that I'd find cleaner
would be to *not* construct and eval() a
new Call inside do_log1arg, but I assume there had been a good
reason for doing things they way they are now...
There was (although possibly no longer -- there was a bug in S4 dispatch
of primitives that failed to re-promise args).
The real issue is somewhere else entirely, the complete deparse in
print.warnings.
Martin Maechler, ETH Zurich
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
