Re: [Rd] [R] Open a file which name contains a tilde
How can expanding tildes anywhere but the beginning of a file name NOT be
considered a bug?
On Thu, 6 Jun 2019 at 23:04, Ivan Krylov wrote:
> On Wed, 5 Jun 2019 18:07:15 +0200
> Frank Schwidom wrote:
>
> > +> path.expand("a ~ b")
> > [1] "a /home/user b"
>
> > How can I switch off any file crippling activity?
>
> It doesn't seem to be possible if readline is enabled and works
> correctly.
>
> Calls to path.expand [1] end up [2] in R_ExpandFileName [3], which
> calls R_ExpandFileName_readline [4], which uses libreadline function
> tilde_expand [5]. tilde_expand seems to be designed to expand '~'
> anywhere in the string it is handed, i.e. operate on whole command
> lines, not file paths.
>
> I am taking the liberty of Cc-ing R-devel in case this can be
> considered a bug.
>
> --
> Best regards,
> Ivan
>
> [1]
>
> https://github.com/wch/r-source/blob/12d1d2d232d84aa355e48b81180a0e2c6f2f/src/main/names.c#L807
>
> [2]
>
> https://github.com/wch/r-source/blob/12d1d2d232d84aa355e48b81180a0e2c6f2f/src/main/platform.c#L1915
>
> [3]
>
> https://github.com/wch/r-source/blob/12d1d2d232d84aa355e48b81180a0e2c6f2f/src/unix/sys-unix.c#L147
>
> [4]
>
> https://github.com/wch/r-source/blob/12d1d2d232d84aa355e48b81180a0e2c6f2f/src/unix/sys-std.c#L494
>
> [5]
> https://git.savannah.gnu.org/cgit/readline.git/tree/tilde.c?h=devel#n187
>
> __
> r-h...@r-project.org mailing list -- To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide
> http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Parallel number stream: clusterSetRNGStream
Dear All, Is the following expected behaviour? set.seed(1) library(parallel) cl = makeCluster(5) clusterSetRNGStream(cl, iseed = NULL) parSapply(cl, 1:5, function(i) sample(1:10, 1)) # 7 4 2 10 10 clusterSetRNGStream(cl, iseed = NULL) # 7 4 2 10 10 parSapply(cl, 1:5, function(i) sample(1:10, 1)) stopCluster(cl) The documentation could be read either way, e.g. * iseed: An integer to be supplied to set.seed, or NULL not to set reproducible seeds. >From Details optionally setting the seed of the streams by set.seed(iseed) (otherwise they are set from the current seed of the master process: after selecting the L'Ecuyer generator). As may be guessed, this caught me out, since I was expecting the same behaviour as set.seed(NULL). Thanks Colin -- R version 3.6.0 (2019-04-26) Platform: x86_64-pc-linux-gnu (64-bit) Running under: Ubuntu 18.04.2 LTS __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Give update.formula() an option not to simplify or reorder the result -- request for comments
Trying to revive, possibly conclude a forgotten thread ... > Abby Spurdle > on Mon, 20 May 2019 14:11:47 +1200 writes: > Hi Pavel > (Back On List) > And my two cents... >> At this time, the update.formula() method always performs a number of >> transformations on the results, eliminating redundant variables and >> reordering interactions to be after the main effects. >> This the proposal is to add an option simplify= (defaulting to TRUE, >> for backwards compatibility) that if FALSE will skip the simplification >> step. >> Any thoughts? One particular question that Martin raised is whether the >> UI should be just a single logical argument, or something else. > Firstly, note that the constructor for formula objects behaves differently > to the update method, so I think any changes should be consistent between > the two functions. Not so easily: The ` ~ ` constructor does not sensibly (in my opinion) get optional arguments, whereas Pavel was suggesting a new *optional* argument to update.formula() >> #constructor - doesn't simplify >> y ~ x + x > y ~ x + x >> #update method - does simplify >> update (y ~ x, ~. + x) > y ~ x > Interestingly, this doesn't simplify. >> update (y ~ I (x), ~. + x) > y ~ I(x) + x well, I hope so: The whole point of I(.) is to *not* be identical (but close) to its argument. > I think that simplification could mean different things. Good point, I tend to agree, with the above, (whereas I'm less happy with this example : ) > So, there could be something like: >> update (y ~ x, ~. + x, strip=FALSE) > y ~ I (2 * x) > I don't know how easy that would be to implement. > (Symbolic computation on par with computer algebra systems is a discussion > in itself...). > And you could have one argument (say, method="simplify") rather than two or > more logical arguments. Yes exactly; given what we've heard till now, I'd also go for a new argument (possibly 'method') which should be a string (and keep the current behavior as default), ideally here with a match.arg() setup. > It would also be possible to allow partial forms of simplification, by > specifying which terms should be collapsed, however, I doubt any possible > usefulness of this, would justify the complexity. > However, feel free to disagree. > You made an interesting comment. >> This is not >> always the desired behavior, because formulas are increasingly used >> for purposes other than specifying linear models. > Can I ask what these purposes are? > kind regards > Abs __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Offer zip builds
Just to add to that point - it is expected that the registry is appropriately updated so the correct version of R can be located. Just unpacking a ZIP won't work in general since tools using R have no reliable way to find it. Cheers, Simon > On Jun 6, 2019, at 6:33 AM, Jeroen Ooms wrote: > > On Tue, Jun 4, 2019 at 5:40 PM Steven Penny wrote: >> >> Theres nothing nefarious here. It would allow people to use the R environment >> without running an installer. If someone is a new user they may want to try >> R out, and installers can be invasive as they commonly: >> >> - copy files to install dir >> - copy files to profile dir >> - set registry entries >> - set environment variables >> - set start menu entries >> >> and historically uninstallers have a bad record of reverting these changes. >> should not put this burden upon new users or even having them resort to >> virtual >> machine to avoid items above. having a ZIP file allows new users to run the >> R environment, then if they like it perhaps they can run the installer going >> forward. > > This is a valid suggestion, but probably impossible to do reliably. > Most installers (the R one is completely open source btw) perform > those steps for a reason. It is great if software can be installed > simply by extracting a zip file somewhere, but if this is what you > desire, you're using the wrong operating system. > > We only offer official installation options that work 100% reliably > and I don't think this can be accomplished with a zip file. For > example a zip file won't be able to set the installation location in > the registry, and hence other software such as RStudio won't be able > to find the R installation. Also a zip installation might mix up > package libraries from different R versions (which is bad), or users > might expect they can upgrade R by overwriting their installation with > a new zip (also bad). Hence I'm afraid offering such alternative > installation options would open a new can of worms with bug reports > from Windows users with broken installations, or packages that don't > work as expected. > > As for alternatives, 'rportable' and 'innoextract' have already been > mentioned if you really just want to dump the files from the > installer, if that works for you. Another popular option to install > (any) Windows software without manually running installers is using > chocolatey, for example: > > choco install miktex > choco install r.project > > This will still indirectly use official installers, but the installers > have been verified as "safe" by external folks and the installation is > completely automated. Perhaps that's another compromise you could live > with. > > __ > 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] [R] Open a file which name contains a tilde
> On Jun 6, 2019, at 2:04 PM, Richard O'Keefe wrote:
>
> How can expanding tildes anywhere but the beginning of a file name NOT be
> considered a bug?
>
>
I think that that IS what libreadline is doing if one allows a whitespace
separated list of file names.
As reported in R-help,
https://www.mail-archive.com/r-help@r-project.org/msg254116.html
path.expand seems to expand tildes beginning whitespace separated strings that
could be filenames, but not other tildes.
Thus,
> path.expand("~/.newsrc ~/.R/*") # expands both tildes
[1] "/Users/cberry/.newsrc /Users/cberry/.R/*"
> path.expand("~/.newsrc~/.R/*") # expands only the first
[1] "/Users/cberry/.newsrc~/.R/*"
>
This could be a feature if what one wanted was to pass the result to a system
command that will process multiple file arguments, e.g.
> system(paste( "wc", path.expand("~/.newsrc ~/.R/*"))) # run wc on some files
I doubt that this was intended by R-core, but perhaps the readline devs had
this in mind.
Chuck
> On Thu, 6 Jun 2019 at 23:04, Ivan Krylov wrote:
>
>> On Wed, 5 Jun 2019 18:07:15 +0200
>> Frank Schwidom wrote:
>>
>>> +> path.expand("a ~ b")
>>> [1] "a /home/user b"
>>
>>> How can I switch off any file crippling activity?
>>
>> It doesn't seem to be possible if readline is enabled and works
>> correctly.
>>
>> Calls to path.expand [1] end up [2] in R_ExpandFileName [3], which
>> calls R_ExpandFileName_readline [4], which uses libreadline function
>> tilde_expand [5]. tilde_expand seems to be designed to expand '~'
>> anywhere in the string it is handed, i.e. operate on whole command
>> lines, not file paths.
>>
>> I am taking the liberty of Cc-ing R-devel in case this can be
>> considered a bug.
>>
>> --
>> Best regards,
>> Ivan
>>
>> [1]
>>
>> https://github.com/wch/r-source/blob/12d1d2d232d84aa355e48b81180a0e2c6f2f/src/main/names.c#L807
>>
>> [2]
>>
>> https://github.com/wch/r-source/blob/12d1d2d232d84aa355e48b81180a0e2c6f2f/src/main/platform.c#L1915
>>
>> [3]
>>
>> https://github.com/wch/r-source/blob/12d1d2d232d84aa355e48b81180a0e2c6f2f/src/unix/sys-unix.c#L147
>>
>> [4]
>>
>> https://github.com/wch/r-source/blob/12d1d2d232d84aa355e48b81180a0e2c6f2f/src/unix/sys-std.c#L494
>>
>> [5]
>> https://git.savannah.gnu.org/cgit/readline.git/tree/tilde.c?h=devel#n187
>>
>> __
>> r-h...@r-project.org mailing list -- To UNSUBSCRIBE and more, see
>> https://stat.ethz.ch/mailman/listinfo/r-help
>> PLEASE do read the posting guide
>> http://www.R-project.org/posting-guide.html
>> and provide commented, minimal, self-contained, reproducible code.
>>
>
> [[alternative HTML version deleted]]
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Parallel number stream: clusterSetRNGStream
Yes, I would think this behavior is intentionally, but obviously, I
don't know for sure. Looking at the code:
> parallel::clusterSetRNGStream
function (cl = NULL, iseed = NULL)
{
cl <- defaultCluster(cl)
oldseed <- if (exists(".Random.seed", envir = .GlobalEnv,
inherits = FALSE))
get(".Random.seed", envir = .GlobalEnv, inherits = FALSE)
else NULL
RNGkind("L'Ecuyer-CMRG")
if (!is.null(iseed))
set.seed(iseed)
nc <- length(cl)
seeds <- vector("list", nc)
seeds[[1L]] <- .Random.seed
You'll find that:
1. the stream of RNG seeds, originates from .Random.seed.
2a. 'iseed' is only applied if non-NULL, which changes starting .Random.seed.
2b. If iseed = NULL, then the .Random.seed is whatever it was when you
called the function
If you use iseed = NULL, then you need to forward the RNG state
(=.Random.seed) yourself. Here's an example:
set.seed(1)
library(parallel)
cl <- parallel::makeCluster(5)
str(.Random.seed)
# int [1:626] 10403 624 -169270483 -442010614 -603558397 -222347416 ...
clusterSetRNGStream(cl, iseed = NULL)
parSapply(cl, 1:5, function(i) sample(1:10, 1))
# [1] 7 4 2 10 10
str(.Random.seed)
# int [1:626] 10403 624 -169270483 -442010614 -603558397 -222347416 ...
clusterSetRNGStream(cl, iseed = NULL)
parSapply(cl, 1:5, function(i) sample(1:10, 1))
# [1] 7 4 2 10 10
## Forward RNG state
sample.int(1)
# [1] 1
str(.Random.seed)
# int [1:626] 10403 1 1654269195 -1877109783 -961256264 1403523942 ...
clusterSetRNGStream(cl, iseed = NULL)
parSapply(cl, 1:5, function(i) sample(1:10, 1))
# [1] 8 6 1 7 5
FYI, you see a similar behavior with parallel::mclapply():
set.seed(1)
library(parallel)
RNGkind("L'Ecuyer-CMRG")
unlist(parallel::mclapply(1:2, function(n) rnorm(n), mc.set.seed = TRUE))
# [1] -1.2673735 0.9045952 1.9502072
unlist(parallel::mclapply(1:2, function(n) rnorm(n), mc.set.seed = TRUE))
# [1] -1.2673735 0.9045952 1.9502072
## Forward RNG state
sample.int(1)
# [1] 1
unlist(parallel::mclapply(1:2, function(n) rnorm(n), mc.set.seed = TRUE))
# [1] -0.09117479 -1.07803714 0.13924063
I can see pros and cons with this behavior, but I think the default is
risky. For instance, it's not hard to imagine an implementation
resampling algorithm where you have to option to run it via lapply()
or via parallel::mclapply() - there is a non-zero probability that
such an implementation produces identical samples.
Proper parallel RNG can be tricky
/Henrik
On Fri, Jun 7, 2019 at 7:09 AM Colin Gillespie wrote:
>
> Dear All,
>
> Is the following expected behaviour?
>
> set.seed(1)
> library(parallel)
> cl = makeCluster(5)
> clusterSetRNGStream(cl, iseed = NULL)
> parSapply(cl, 1:5, function(i) sample(1:10, 1))
> # 7 4 2 10 10
> clusterSetRNGStream(cl, iseed = NULL)
> # 7 4 2 10 10
> parSapply(cl, 1:5, function(i) sample(1:10, 1))
> stopCluster(cl)
>
> The documentation could be read either way, e.g.
>
> * iseed: An integer to be supplied to set.seed, or NULL not to set
> reproducible seeds.
>
> From Details
>
> optionally setting the seed of the streams by set.seed(iseed)
> (otherwise they are set from the current seed of the master process:
> after selecting the L'Ecuyer generator).
>
> As may be guessed, this caught me out, since I was expecting the same
> behaviour as set.seed(NULL).
>
> Thanks
>
> Colin
>
> --
>
> R version 3.6.0 (2019-04-26)
> Platform: x86_64-pc-linux-gnu (64-bit)
> Running under: Ubuntu 18.04.2 LTS
>
> __
> 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] Offer zip builds
> Just to add to that point - it is expected that the registry is appropriately updated so the correct version of R can be located. Just unpacking a ZIP won't work in general since tools using R have no reliable way to find it. Shouldn't it be sufficient to set the "Path" system or environment variables? [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
