Re: [Rd] Associative array?
Hi, Just a note, if you want an exact character representation of an 8 byte IEEE float you may want to extract the exact 16 character hexidecimal equivalent of the raw binary 8 byte float. Converting possible non-integer or non 2^x float to decimal is often an approximation and may not be reversible. -- View this message in context: http://n4.nabble.com/Associative-array-tp1588978p1689897.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
Re: [Rd] print(big+small*1i) -> big + 0i
I'm not sure it's awful either, but it
is surprising -- at least to my eye.
In particular, it is using the same
amount of real estate as it would to
print the "right" value.
Pat
On 25/03/2010 01:14, William Dunlap wrote:
Should both parts of a complex number be printed
to the same precision? The imaginary part of 0
looks a bit odd when log10(real/imag)>=~ getOption("digits"),
but I'm not sure it is awful. Some people might
expect the same number of significant digits in the
two parts.
1e7+4i
[1] 1000+0i
1e7+5i
[1] 1000+0i
1e10 + 1000i
[1] 1e+10+0e+00i
getOption("digits")
[1] 7
options(digits=4)
1e4+4i
[1] 1+0i
1e7+1000i
[1] 1000+0i
version
_
platform i386-pc-mingw32
arch i386
os mingw32
system i386, mingw32
status Under development (unstable)
major 2
minor 11.0
year 2010
month 03
day07
svn rev51225
language R
version.string R version 2.11.0 Under development (unstable) (2010-03-07
r51225)
Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Patrick Burns
pbu...@pburns.seanet.com
http://www.burns-stat.com
(home of 'Some hints for the R beginner'
and 'The R Inferno')
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [patch] add is.set parameter to sample()
> "AndrewC" == Andrew Clausen > on Tue, 23 Mar 2010 08:04:12 -0400 writes: AndrewC> Hi all, AndrewC> I forgot to test my patch! I fixed a few bugs. and this time, you even forgot to attach it (in a way to pass through the list filters). Note however, that all this seems unnecessary, as we have sample.int() and a trivial definition of resample() at least in R-devel, which will be released as R 2.11.0 on April 22. Thank you anyway, for your efforts! Martin Martin Maechler, ETH Zurich AndrewC> On 22 March 2010 22:53, Andrew Clausen wrote: >> Hi all, >> >> sample() has some well-documented undesirable behaviour. >> >> sample(1:6, 1) >> sample(2:6, 1) >> ... >> sample(5:6, 1) >> >> do what you expect, but >> >> sample(6:6, 1) >> sample(1:6, 1) >> >> do the same thing. >> >> This behaviour is documented: >> >> If 'x' has length 1, is numeric (in the sense of 'is.numeric') and >> 'x >= 1', sampling _via_ 'sample' takes place from '1:x'. _Note_ >> that this convenience feature may lead to undesired behaviour when >> 'x' is of varying length 'sample(x)'. See the 'resample()' >> example below. >> >> My proposal is to add an extra parameter is.set to sample() to control >> this behaviour. If the parameter is unspecified, then we keep the old >> behaviour for compatibility. If it is TRUE, then we treat the first >> parameter x as a set. If it is FALSE, then we treat it as a set size. >> This means that >> >> sample(6:6, 1, is.set=TRUE) >> >> would return 6 with probability 1. >> >> I have attached a patch to implement this new option. >> >> Cheers, >> Andrew >> AndrewC> __ AndrewC> R-devel@r-project.org mailing list AndrewC> 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] [patch] add is.set parameter to sample()
Hi Martin,
I re-attached the patch with a filename that will hopefully get
through the filters this time.
I agree that the case that you want to specify an integer is already
well handled with sample.int(). I disagree that the resample() code
for the set case given in the example is trivial. The user has to
load the code into their program, which is annoying for such basic
functionality. Moreover, the example code doesn't work for sampling
with replacement, and is poorly documented. Finally, it isn't obvious
to new users of R what to do with resample(). (They would probably
try using resample() without cutting & pasting it into their program.
And why is it called resample()? It's a mysterious name, that
suggests some technical concept, like resampling digital audio from
one sampling rate to another.)
So, the upside of my patch is that sample() becomes more convenient,
and the documentation becomes simpler. What's the downside? It is
backwards compatible.
sample() is one of the most important functions in R... I teach it to
my undergraduate economics students in the first 20 minutes of their
first R lesson. It is the first probability/statistics function they
learn. It is important that it is easy and convenient to use.
My first R problem set that I assigned my students was to do a Monte
Carlo simulation of the Monty Hall problem. sample()'s surprise
really bites here because Monty has either one or two choices of door
to open. It's bad enough that there is a surprise, but even worse
that there is no workaround that my students can understand easily.
Cheers,
Andrew
On 25 March 2010 06:53, Martin Maechler wrote:
>> "AndrewC" == Andrew Clausen
>> on Tue, 23 Mar 2010 08:04:12 -0400 writes:
>
> AndrewC> Hi all,
> AndrewC> I forgot to test my patch! I fixed a few bugs.
>
> and this time, you even forgot to attach it (in a way to pass
> through the list filters).
>
> Note however, that all this seems unnecessary,
> as we have sample.int()
> and a trivial definition of resample()
> at least in R-devel, which will be released as R 2.11.0 on
> April 22.
>
> Thank you anyway, for your efforts!
> Martin
>
> Martin Maechler, ETH Zurich
>
> AndrewC> On 22 March 2010 22:53, Andrew Clausen
> wrote:
> >> Hi all,
> >>
> >> sample() has some well-documented undesirable behaviour.
> >>
> >> sample(1:6, 1)
> >> sample(2:6, 1)
> >> ...
> >> sample(5:6, 1)
> >>
> >> do what you expect, but
> >>
> >> sample(6:6, 1)
> >> sample(1:6, 1)
> >>
> >> do the same thing.
> >>
> >> This behaviour is documented:
> >>
> >> If 'x' has length 1, is numeric (in the sense of 'is.numeric') and
> >> 'x >= 1', sampling _via_ 'sample' takes place from '1:x'. _Note_
> >> that this convenience feature may lead to undesired behaviour when
> >> 'x' is of varying length 'sample(x)'. See the 'resample()'
> >> example below.
> >>
> >> My proposal is to add an extra parameter is.set to sample() to control
> >> this behaviour. If the parameter is unspecified, then we keep the old
> >> behaviour for compatibility. If it is TRUE, then we treat the first
> >> parameter x as a set. If it is FALSE, then we treat it as a set size.
> >> This means that
> >>
> >> sample(6:6, 1, is.set=TRUE)
> >>
> >> would return 6 with probability 1.
> >>
> >> I have attached a patch to implement this new option.
> >>
> >> Cheers,
> >> Andrew
> >>
> AndrewC> __
> AndrewC> R-devel@r-project.org mailing list
> AndrewC> https://stat.ethz.ch/mailman/listinfo/r-devel
>
diff --git a/src/library/base/R/sample.R b/src/library/base/R/sample.R
index 8d22469..01498c0 100644
--- a/src/library/base/R/sample.R
+++ b/src/library/base/R/sample.R
@@ -14,13 +14,17 @@
# A copy of the GNU General Public License is available at
# http://www.r-project.org/Licenses/
-sample <- function(x, size, replace=FALSE, prob=NULL)
+sample <- function(x, size, replace=FALSE, prob=NULL, is.set=NULL)
{
-if(length(x) == 1L && is.numeric(x) && x >= 1) {
+is.natural <- function(x) length(x) == 1L && is.numeric(x) && x >= 1
+if(is.null(is.set)) is.set <- !is.natural(x)
+if(!is.set) {
+ stopifnot(is.natural(x))
if(missing(size)) size <- x
.Internal(sample(x, size, replace, prob))
}
else {
+ stopifnot(length(x) >= 1)
if(missing(size)) size <- length(x)
x[.Internal(sample(length(x), size, replace, prob))]
}
diff --git a/src/library/base/man/sample.Rd b/src/library/base/man/sample.Rd
index 3929ff2..811fed2 100644
--- a/src/library/base/man/sample.Rd
+++ b/src/library/base/man/sample.Rd
@@ -12,26 +12,31 @@
of \code{x} using either with or without replacement.
}
\usage{
-sample(x, size, replace = FALSE, prob = NULL)
+sample(x, size, replace = FALSE, prob = NULL, is.set=NULL)
sample.int(n, size, replace = FALSE, prob = NULL)
}
\argumen
[Rd] update.packages(1)
I'm relaying a question from my institute's sysadmin:
Would it be possible to modify update.packages() and related functions so
that 'lib.loc' accepts integer values to specify a library from the
.libPaths() vector?
Many Linux users want to update all user packages (inside the R_LIBS_USER
directory, e.g. ~/r/library) and none of the system packages (inside the
/usr directory, e.g. /usr/lib64/R/library), because they don't have write
privileges to update the system packages.
Currently, this can be done by pressing 'y RET' for all the user packages
and 'RET' for all the system packages. This hard work and careful reading
when there dozens of packages. Another way is to run
update.packages(Sys.getenv("R_LIBS_USER"))
or:
update.packages(.libPaths()[1])
But it would be nicer for the user to type
update.packages(1)
using a 'pos' like notation to indicate the first element of the
.libPaths() vector.
---
A separate but related issue is that it would be nice if the R_LIBS_USER
library would be the first library by default. Currently, my sysadmin must
use Rprofile.site to shuffle the .libPaths() to make R_LIBS_USER first,
which seems like a sensible default when it comes to install.packages()
and remove.packages().
This is R version 2.10.1 (2009-12-14) on x86_64-redhat-linux-gnu (Fedora
11).
Thanks,
Arni
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R CMD install: problem quoting spaces when calling gzip?
There appears to be a quoting problem in the way R CMD install handles file
names containing spaces, more specifically, in the way the argument is passed
through to gzip.
The install.packages command
(from R)
install.packages("~/Projects/R library/bar/eyetrackR_0.13.tar.gz", repos =
NULL, type = "source")
expands to
system("R_LIBS='/Users/foo/Library/R/2.10/library'
"/Library/Frameworks/R.framework/Resources/bin/R CMD INSTALL -l
'/Users/foo/Library/R/2.10/library' '/Users/foo/Projects/R\
library/bar/eyetrackR_0.13.tar.gz'")
and gives the same error messages as the following commands from Terminal.app
on Mac OS X
(from bash)
R CMD install /Users/foo/Projects/R\ library/bar/eyetrackR_0.13.tar.gz
R CMD install "~/Projects/R library/bar/eyetrackR_0.13.tar.gz"
R CMD install '~/Projects/R library/bar/eyetrackR_0.13.tar.gz'
, namely (the error messages):
gzip: /Users/foo/Projects/R.gz: No such file or directory
gzip: library/bar/eyetrackR_0.13.tar.gz: No such file or directory
The following commands do work
(from R)
setwd("~/Projects/R library/bar/")
install.packages("eyetrackR_0.13.tar.gz", repos = NULL, type = "source")
(from bash)
cd ~/Projects/R\ library/bar/
R CMD install eyetrackR_0.13.tar.gz
Interestingly, if the file is unpacked on the command line (tar xzvf), then
both R CMD install and install.packages work fine using the quoted path name
syntax, i.e.,
R CMD install /Users/foo/Projects/R\ library/bar/eyetrackR
install.packages("~/Projects/R library/bar/eyetrackR", repos = NULL, type =
"source")
Is this a known problem? I searched the archives, but did not find a decisive
answer (only some rather old posts suggesting not to use path names containing
spaces--unfortunately this is not an option in the managed Windows environment
I need to work in next week).
Sorry for the long post and thanks for your time,
Jochen
Jochen Laubrock, Dept. of Psychology, University of Potsdam,
Karl-Liebknecht-Strasse 24-25, 14476 Potsdam, Germany
phone: +49-331-977-2346, fax: +49-331-977-2793
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
