[Rd] package load altering RNG state
Hello When loading a package, I'm wondering if it's frowned upon for the package to alter the state of the random number generator? I guess not, since the parallel package does it? > set.seed(6860) > old.seed <- .GlobalEnv$.Random.seed > library(parallel) > new.seed <- .GlobalEnv$.Random.seed > identical(old.seed, new.seed) [1] FALSE I ask because, I found myself writing a custom wrapper around library() to restore the original RNG state, in order to increase reproducibility. But now wondering if others would welcome such a feature to be added to base R? Either something very general like preserveRNGstate(library(parallel)) or perhaps an specific enhancement to library itself? Regards Ben __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] buggy ANSI escape sequences in R prompt
When R is run interactively in a terminal which supports colors, it is
possible to use ANSI escape sequences in order to put colors in the prompt,
such as
options(prompt = "\033[0;31mThis is red\033[0m> ")
Unfortunately, something goes wrong because for long command lines, the
line continuation override the prompt instead of being written in the next
line. The problem gets worse when using several colors, because somehow
each escape sequence "takes up some space" in the command line, *up to the
point that the end of the prompt might overwrite the beginning*. On my
configuration this happens with for instance
options(prompt = paste("\033[0;31m With \033[0;32m multiple",
"\033[0;33m colors \033[0;34m this",
"\033[0;35m gets \033[0;36m really",
"\033[0;37m wrong! \033[0m"))
Why is it so? Is there a workaround?
PS: This rather old post seems related
http://r.789695.n4.nabble.com/Xterm-escape-sequences-in-Prompt-td906375.html
PPS: I posted this question on [R] section of stack overflow
http://stackoverflow.com/questions/42072092/buggy-ansi-escape-sequences-in-r-prompt
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] package load altering RNG state
Hi, On 2017-02-07 13:12, Benjamin Tyner wrote: Hello When loading a package, I'm wondering if it's frowned upon for the package to alter the state of the random number generator? I guess not, since the parallel package does it? Surprisingly it is not frowned upon, but it *is* a nuisance. I brought it up a couple of years ago http://r.789695.n4.nabble.com/parallel-package-changes-Random-seed-td4686321.html along with a patch, but was told off... > set.seed(6860) > old.seed <- .GlobalEnv$.Random.seed > library(parallel) > new.seed <- .GlobalEnv$.Random.seed > identical(old.seed, new.seed) [1] FALSE I ask because, I found myself writing a custom wrapper around library() to restore the original RNG state, in order to increase reproducibility. But now wondering if others would welcome such a feature to be added to base R? Either something very general like preserveRNGstate(library(parallel)) or perhaps an specific enhancement to library itself? I would very much welcome a change, but in the light of things it doesn't seem likely. Henric Winell Regards Ben __ 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] buggy ANSI escape sequences in R prompt
I guess that R does not know about ANSI sequences, and it calculates the
width of the prompt including the characters in the sequences. You cannot
do much about this, except maybe use a prompt that has two lines. You can
put the colored text and whatever you like in the first line, and the
second line can be non-ANSI.
Note that this works in the terminal, but does not work in RStudio. RStudio
does not support multi-line prompt currently.
Maybe this is also interesting for you, if you want a dynamic R prompt:
https://github.com/gaborcsardi/prompt#readme (Self-ad, sorry.)
Gabor
On Tue, Feb 7, 2017 at 8:59 AM, Hugo Raguet
wrote:
> When R is run interactively in a terminal which supports colors, it is
> possible to use ANSI escape sequences in order to put colors in the prompt,
> such as
>
> options(prompt = "\033[0;31mThis is red\033[0m> ")
>
> Unfortunately, something goes wrong because for long command lines, the
> line continuation override the prompt instead of being written in the next
> line. The problem gets worse when using several colors, because somehow
> each escape sequence "takes up some space" in the command line, *up to the
> point that the end of the prompt might overwrite the beginning*. On my
> configuration this happens with for instance
>
> options(prompt = paste("\033[0;31m With \033[0;32m multiple",
>"\033[0;33m colors \033[0;34m this",
>"\033[0;35m gets \033[0;36m really",
>"\033[0;37m wrong! \033[0m"))
>
> Why is it so? Is there a workaround?
>
> PS: This rather old post seems related
>
> http://r.789695.n4.nabble.com/Xterm-escape-sequences-in-
> Prompt-td906375.html
>
> PPS: I posted this question on [R] section of stack overflow
>
> http://stackoverflow.com/questions/42072092/buggy-ansi-
> escape-sequences-in-r-prompt
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] buggy ANSI escape sequences in R prompt
Thanks for the hint. I agree with your analysis, but that still would not
explain why the continuation overrides the begining of the same line
instead of going to the next line.
I think I'll go for the two-lines prompt. If you have a Stack Overflow
account, you can post your answer and I will accept it in a couple of days.
That would also make some ad for your dynamic R prompt! It's really cool,
but overkill for my use.
Hugo
2017-02-07 14:44 GMT+01:00 Gábor Csárdi :
> I guess that R does not know about ANSI sequences, and it calculates the
> width of the prompt including the characters in the sequences. You cannot
> do much about this, except maybe use a prompt that has two lines. You can
> put the colored text and whatever you like in the first line, and the
> second line can be non-ANSI.
>
> Note that this works in the terminal, but does not work in RStudio.
> RStudio does not support multi-line prompt currently.
>
> Maybe this is also interesting for you, if you want a dynamic R prompt:
> https://github.com/gaborcsardi/prompt#readme (Self-ad, sorry.)
>
> Gabor
>
> On Tue, Feb 7, 2017 at 8:59 AM, Hugo Raguet
> wrote:
>
>> When R is run interactively in a terminal which supports colors, it is
>> possible to use ANSI escape sequences in order to put colors in the
>> prompt,
>> such as
>>
>> options(prompt = "\033[0;31mThis is red\033[0m> ")
>>
>> Unfortunately, something goes wrong because for long command lines, the
>> line continuation override the prompt instead of being written in the next
>> line. The problem gets worse when using several colors, because somehow
>> each escape sequence "takes up some space" in the command line, *up to the
>> point that the end of the prompt might overwrite the beginning*. On my
>> configuration this happens with for instance
>>
>> options(prompt = paste("\033[0;31m With \033[0;32m multiple",
>>"\033[0;33m colors \033[0;34m this",
>>"\033[0;35m gets \033[0;36m really",
>>"\033[0;37m wrong! \033[0m"))
>>
>> Why is it so? Is there a workaround?
>>
>> PS: This rather old post seems related
>>
>> http://r.789695.n4.nabble.com/Xterm-escape-sequences-in-Prom
>> pt-td906375.html
>>
>> PPS: I posted this question on [R] section of stack overflow
>>
>> http://stackoverflow.com/questions/42072092/buggy-ansi-escap
>> e-sequences-in-r-prompt
>>
>> [[alternative HTML version deleted]]
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] package load altering RNG state
> Henric Winell
> on Tue, 7 Feb 2017 13:37:42 +0100 writes:
> Hi, On 2017-02-07 13:12, Benjamin Tyner wrote:
>> Hello
>>
>> When loading a package, I'm wondering if it's frowned
>> upon for the package to alter the state of the random
>> number generator? I guess not, since the parallel package
>> does it?
> Surprisingly it is not frowned upon, but it *is* a
> nuisance. I brought it up a couple of years ago
>
http://r.789695.n4.nabble.com/parallel-package-changes-Random-seed-td4686321.html
> along with a patch, but was told off...
>>
>> > set.seed(6860) > old.seed <- .GlobalEnv$.Random.seed >
>> library(parallel) > new.seed <- .GlobalEnv$.Random.seed >
>> identical(old.seed, new.seed) [1] FALSE
>>
>> I ask because, I found myself writing a custom wrapper
>> around library() to restore the original RNG state, in
>> order to increase reproducibility. But now wondering if
>> others would welcome such a feature to be added to base
>> R? Either something very general like
>>
>> preserveRNGstate(library(parallel))
>>
>> or perhaps an specific enhancement to library itself?
> I would very much welcome a change, but in the light of
> things it doesn't seem likely.
> Henric Winell
Sometimes things change ... and not always for the worse. I've
found a version of your original patch idea which is very
efficient nice (in my eyes) and still leaves
system.time(loadNamespace("parallel"))
to round to 0, i.e. needing less than 1 ms.
--> in R-devel svn rev 72136
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] package load altering RNG state
On 2017-02-07 15:59, Martin Maechler wrote:
Henric Winell
on Tue, 7 Feb 2017 13:37:42 +0100 writes:
> Hi, On 2017-02-07 13:12, Benjamin Tyner wrote:
>> Hello
>>
>> When loading a package, I'm wondering if it's frowned
>> upon for the package to alter the state of the random
>> number generator? I guess not, since the parallel package
>> does it?
> Surprisingly it is not frowned upon, but it *is* a
> nuisance. I brought it up a couple of years ago
>
http://r.789695.n4.nabble.com/parallel-package-changes-Random-seed-td4686321.html
> along with a patch, but was told off...
>>
>> > set.seed(6860) > old.seed <- .GlobalEnv$.Random.seed >
>> library(parallel) > new.seed <- .GlobalEnv$.Random.seed >
>> identical(old.seed, new.seed) [1] FALSE
>>
>> I ask because, I found myself writing a custom wrapper
>> around library() to restore the original RNG state, in
>> order to increase reproducibility. But now wondering if
>> others would welcome such a feature to be added to base
>> R? Either something very general like
>>
>> preserveRNGstate(library(parallel))
>>
>> or perhaps an specific enhancement to library itself?
> I would very much welcome a change, but in the light of
> things it doesn't seem likely.
> Henric Winell
Sometimes things change ... and not always for the worse. I've
found a version of your original patch idea which is very
efficient nice (in my eyes) and still leaves
system.time(loadNamespace("parallel"))
to round to 0, i.e. needing less than 1 ms.
--> in R-devel svn rev 72136
Many thanks for this, Martin!
Henric
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: tapply(*, ..., init.value = NA)
Function 'tapply' in R devel r72137 uses if(!is.null(ans) && is.na(default) && is.atomic(ans)) . Problems: - It is possible that user-specified 'default' is not of length 1. If the length is zero, the 'if' gives an error. - It is possible that is.na(default) is TRUE and user-specified 'default' is NaN. On Sat, 4/2/17, Martin Maechler wrote: Subject: Re: [Rd] RFC: tapply(*, ..., init.value = NA) Cc: R-devel@r-project.org Date: Saturday, 4 February, 2017, 10:48 PM > Suharto Anggono Suharto Anggono via R-devel > on Wed, 1 Feb 2017 16:17:06 + writes: [snip] > vector(typeof(ans)) (or vector(storage.mode(ans))) has > length zero and can be used to initialize array. Yes,.. unless in the case where ans is NULL. You have convinced me, that is nicer. > Instead of if(missing(default)) , if(identical(default, > NA)) could be used. The documentation could then say, for > example: "If default = NA (the default), NA of appropriate > storage mode (0 for raw) is automatically used." After some thought (and experiments), I have reverted and no longer use if(missing). You are right that it is not needed (and even potentially confusing) here. Changes are in svn c72106. Martin Maechler __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] package load altering RNG state
Martin,
Outstanding! This is a most welcome enhancement.
Regards
Ben
On 02/07/2017 09:59 AM, Martin Maechler wrote:
Henric Winell
on Tue, 7 Feb 2017 13:37:42 +0100 writes:
> Hi, On 2017-02-07 13:12, Benjamin Tyner wrote:
>> Hello
>>
>> When loading a package, I'm wondering if it's frowned
>> upon for the package to alter the state of the random
>> number generator? I guess not, since the parallel package
>> does it?
> Surprisingly it is not frowned upon, but it *is* a
> nuisance. I brought it up a couple of years ago
>
http://r.789695.n4.nabble.com/parallel-package-changes-Random-seed-td4686321.html
> along with a patch, but was told off...
>>
>> > set.seed(6860) > old.seed <- .GlobalEnv$.Random.seed >
>> library(parallel) > new.seed <- .GlobalEnv$.Random.seed >
>> identical(old.seed, new.seed) [1] FALSE
>>
>> I ask because, I found myself writing a custom wrapper
>> around library() to restore the original RNG state, in
>> order to increase reproducibility. But now wondering if
>> others would welcome such a feature to be added to base
>> R? Either something very general like
>>
>> preserveRNGstate(library(parallel))
>>
>> or perhaps an specific enhancement to library itself?
> I would very much welcome a change, but in the light of
> things it doesn't seem likely.
> Henric Winell
Sometimes things change ... and not always for the worse. I've
found a version of your original patch idea which is very
efficient nice (in my eyes) and still leaves
system.time(loadNamespace("parallel"))
to round to 0, i.e. needing less than 1 ms.
--> in R-devel svn rev 72136
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
