Re: [Rd] Add-on argument in sample()
On 6/16/2015 1:32 PM, Peter Meissner wrote:
Am .06.2015, 14:55 Uhr, schrieb Millot Gael :
Hi.
I have a problem with the default behavior of sample(), which performs
sample(1:x) when x is a single value.
This behavior is well explained in ?sample.
However, this behavior is annoying when the number of value is not
predictable. Would it be possible to add an argument
that desactivates this and perform the sampling on a single value ?
Examples:
sample(10, size = 1, replace = FALSE)
10
sample(10, size = 3, replace = TRUE)
10 10 10
sample(10, size = 3, replace = FALSE)
Error
I think the problem here is that the function actually does what you
would expect it to do given a statistic perspective. A sample of size
three from a population of one without allowing to draw elements again
that were drawn already is simply not defined. What shall the function
give back?
If I understand right, this error is exactly what the poster would like
to see, but which you dont get currently. If length(population) == 1,
you will now sample from 1:population, not the population itself. So:
> sample(8:10, 3, replace = FALSE)
[1] 10 8 9
> sample(9:10, 3, replace = FALSE)
Error in sample.int(length(x), size, replace, prob) :
cannot take a sample larger than the population when 'replace = FALSE'
> sample(10:10, 3, replace = FALSE)
[1] 8 10 2
I have to admit that I also find this behaviour inconsistent, even if it
is well described already on the first line of the details in the
documentation. It is definitely a feature which can cause some trouble,
and where the tests might end up more complicated than you would first
think.
... You can always wrap your code in a try() like this to prevent errors
to break loops or functions:
try(sample(...))
No error is given when length(population) == 1, and the result might be
perfectly valid if population is variable. So this will easily stay in
the script as an undetected bug.
... or you might check your arguments before execution:
if ( !replace & length(population) >= size ){
sample(population, size = size , replace = replace)
}else{
...
}
This test is not sufficient if length(population) == size == 1, so you
will also need to check for this special case:
if (length(population) == 1 & size == 1) {
population
} else if (!replace & length(population) >= size) {
sample(population, size = size, replace = replace)
} else {
...
}
Then the question would be if this test could be replaced with a new
argument to sample, e.g. expandSingle, which has TRUE as default for
backward compatibility, but FALSE if you dont want population to be
expanded to 1:population. It could certainly be useful in some cases,
but you still need to know about the expansion to use it. I think most
of these bugs occur because users did not think about the expansion in
the first place or did not realize that their population could be of
length 1 in some situations. These users would therefore not think about
changing the argument either.
Cheers,
Jon
Many thanks for your help.
Best wishes,
Gael Millot.
Gael Millot
UMR 3244 (IC-CNRS-UPMC) et Universite Pierre et Marie Curie
Equipe Recombinaison et instabilite genetique
Pav Trouillet Rossignol 5eme etage
Institut Curie
26 rue d'Ulm
75248 Paris Cedex 05
FRANCE
tel : 33 1 56 24 66 34
fax : 33 1 56 24 66 44
Email : gael.mil...@curie.fr
http://perso.curie.fr/Gael.Millot/index.html
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Best, Peter
--
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Jon Olav Skøien
Joint Research Centre - European Commission
Institute for Environment and Sustainability (IES)
Climate Risk Management Unit
Via Fermi 2749, TP 100-01, I-21027 Ispra (VA), ITALY
jon.sko...@jrc.ec.europa.eu
Tel: +39 0332 789205
Disclaimer: Views expressed in this email are those of the individual
and do not necessarily represent official views of the European Commission.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Add-on argument in sample()
On 6/18/2015 12:25 AM, Hervé Pagès wrote:
Hi,
Special behavior of sample(x, ...) when length(x) is 1 is of course
a bad feature. I think it pre-dates sample.int() which is what people
should use these days if they want the behavior of sample(x, ...) when
length(x) is 1. And because we now have sample.int(), this feature
could in theory be removed from sample(). Unfortunately this would
break a lot of existing code so a warning or some kind of notification
would need to be implemented.
Even if the cost is high, that still sounds better/cleaner to me than
adding an extra argument to sample() to control this (which is only
going to be used by people aware of the problem but people aware of
the problem already know how to workaround it).
I am generally skeptical to backward-incompatible changes, particularly
when no error will be thrown. On the other hand this might be one of the
few cases where quite a lot of existing code will suddenly work
correctly after a change... But unfortunately it is the ones who
actually read the documentation who will get their code broken.
Cheers,
Jon
Cheers,
H.
On 06/17/2015 01:27 AM, Jon Skoien wrote:
On 6/16/2015 1:32 PM, Peter Meissner wrote:
Am .06.2015, 14:55 Uhr, schrieb Millot Gael :
Hi.
I have a problem with the default behavior of sample(), which performs
sample(1:x) when x is a single value.
This behavior is well explained in ?sample.
However, this behavior is annoying when the number of value is not
predictable. Would it be possible to add an argument
that desactivates this and perform the sampling on a single value ?
Examples:
sample(10, size = 1, replace = FALSE)
10
sample(10, size = 3, replace = TRUE)
10 10 10
sample(10, size = 3, replace = FALSE)
Error
I think the problem here is that the function actually does what you
would expect it to do given a statistic perspective. A sample of size
three from a population of one without allowing to draw elements again
that were drawn already is simply not defined. What shall the function
give back?
If I understand right, this error is exactly what the poster would like
to see, but which you dont get currently. If length(population) == 1,
you will now sample from 1:population, not the population itself. So:
> sample(8:10, 3, replace = FALSE)
[1] 10 8 9
> sample(9:10, 3, replace = FALSE)
Error in sample.int(length(x), size, replace, prob) :
cannot take a sample larger than the population when 'replace = FALSE'
> sample(10:10, 3, replace = FALSE)
[1] 8 10 2
I have to admit that I also find this behaviour inconsistent, even if it
is well described already on the first line of the details in the
documentation. It is definitely a feature which can cause some trouble,
and where the tests might end up more complicated than you would first
think.
... You can always wrap your code in a try() like this to prevent errors
to break loops or functions:
try(sample(...))
No error is given when length(population) == 1, and the result might be
perfectly valid if population is variable. So this will easily stay in
the script as an undetected bug.
... or you might check your arguments before execution:
if ( !replace & length(population) >= size ){
sample(population, size = size , replace = replace)
}else{
...
}
This test is not sufficient if length(population) == size == 1, so you
will also need to check for this special case:
if (length(population) == 1 & size == 1) {
population
} else if (!replace & length(population) >= size) {
sample(population, size = size, replace = replace)
} else {
...
}
Then the question would be if this test could be replaced with a new
argument to sample, e.g. expandSingle, which has TRUE as default for
backward compatibility, but FALSE if you dont want population to be
expanded to 1:population. It could certainly be useful in some cases,
but you still need to know about the expansion to use it. I think most
of these bugs occur because users did not think about the expansion in
the first place or did not realize that their population could be of
length 1 in some situations. These users would therefore not think about
changing the argument either.
Cheers,
Jon
Many thanks for your help.
Best wishes,
Gael Millot.
Gael Millot
UMR 3244 (IC-CNRS-UPMC) et Universite Pierre et Marie Curie
Equipe Recombinaison et instabilite genetique
Pav Trouillet Rossignol 5eme etage
Institut Curie
26 rue d'Ulm
75248 Paris Cedex 05
FRANCE
tel : 33 1 56 24 66 34
fax : 33 1 56 24 66 44
Email : gael.mil...@curie.fr
http://perso.curie.fr/Gael.Millot/index.html
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Best, Peter
--
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Jon Olav Skøien
Joint Resea
[Rd] Strange behavior when using progress bar (Fwd: Re: [R] The code itself disappears after starting to execute the for loop)
I first answered to the email below in r-help, but as I did not see any
response, and it looks like a bug/unwanted behavior, I am also posting
here. I have observed this in RGui, whereas it seems not to happen in
RStudio.
Similar to OP, I sometimes have a problem with functions using the
progress bar. Frequently, the console is cleared after x iterations when
the progress bar is called in a function which is wrapped in a loop. In
the example below, this happened for me every ~44th iteration.
Interestingly, it seems that reduction of the sleep times in this
function increases the number of iterations before clearing. In my real
application, where the progress bar is used in a much slower function,
the console is cleared every 2-3 iteration, which means that I cannot
scroll back to check the output.
testit <- function(x = sort(runif(20)), ...)
{
pb <- txtProgressBar(...)
for(i in c(0, x, 1)) {Sys.sleep(0.2); setTxtProgressBar(pb, i)}
Sys.sleep(1)
close(pb)
}
iter = 0
while (TRUE) {testit(style = 3); iter = iter + 1; print(paste("done",
iter))}
Is this only a problem for a few, or is it reproducible? Any hints to
what the problem could be, or if it can be fixed? I have seen this in
some versions of R, and could also reproduce in 3.3.2.
Best wishes,
Jon
R version 3.3.2 (2016-10-31)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 8.1 x64 (build 9600)
locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United States.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
On 11/23/2016 5:22 PM, Maram SAlem wrote:
Thanks a lot Bert , will check out your suggestions.
I've unchecked the buffer output option in GUI but still have the same problem.
Thanks for your time and concern.
Maram Salem
Sent from my iPhone
On Nov 23, 2016, at 5:55 PM, Bert Gunter wrote:
In addition to Jim's comments, which you have not yet satisfactorily
addressed (buffering in GUI??),
1. Show your code!
2. Show ouput of sessionInfo()
3. Upgrade to the latest R version maybe
4. Perhaps write to package maintainer (see ?maintainer) if nothing or
no one helps.
Cheers,
Bert
Bert Gunter
"The trouble with having an open mind is that people keep coming along
and sticking things into it."
-- Opus (aka Berkeley Breathed in his "Bloom County" comic strip )
On Tue, Nov 22, 2016 at 10:05 AM, Maram SAlem wrote:
Thanks for helping Jim.
I'm actually using the pbapply function together with the print function within
a loop. In earlier versions, the progress bar and the output of the print
function used to appear after each iteration of the loop. But with the 3.3.1.
Version nothing appears, instead the console turns white and thecursor turns
blue ( busy) and I know nothing about the progress of the running code.
I just want to see the bar and the output of the print function as I used to,
any help?
Thanks in advance.
Maram Salem
Sent from my iPhone
On Nov 3, 2016, at 8:30 PM, jim holtman wrote:
A little more information would help. How exactly are out creating the output
to the console? Are you using 'print', 'cat' or something else? Do you have
buffered output checked on the GUI (you probably don't want it checked or you
output will be delayed till the buffer is full -- this mightbe the cause of
your problem.
Jim Holtman
Data Munger Guru
What is the problem that you are trying to solve?
Tell me what you want to do, not how you want to do it.
On Thu, Nov 3, 2016 at 1:55 PM, Maram SAlem wrote:
Hi all,
I've a question concerning the R 3.3.1 version. I have a long code that I used
to run on versions earlier to the 3.3.1 version, and when I copied the code to
the R console, I can still see the code while the loop is executing , along
with the output printed after each iteration of the loop.
Now, on the 3.3.1 version, after I copy the code to the console, it disappears
and I only see the printed output of only one iteration at a time, that is,
after the first iteration the printed output disappears ( thoughit's only 6
lines, just giving me some guidance, not a long output).
This is causing me some problems, so I don't know if there is a general option
for R that enables me to still see the code and the output of allthe iterations
till the loop is over, as was the case with earlier R versions.
I didn't include the code as it's a long one.
Thanks a lot in advance,
Maram
Sent from my iPhone
__
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-h...@r-project.
Re: [Rd] Strange behavior when using progress bar (Fwd: Re: [R] The code itself disappears after starting to execute the for loop)
I would like to ask once more if this is reproducible also for others?
If yes, should I submit it as a bug-report?
Best,
Jon
On 11/28/2016 11:26 AM, Jon Skoien wrote:
I first answered to the email below in r-help, but as I did not see
any response, and it looks like a bug/unwanted behavior, I am also
posting here. I have observed this in RGui, whereas it seems not to
happen in RStudio.
Similar to OP, I sometimes have a problem with functions using the
progress bar. Frequently, the console is cleared after x iterations
when the progress bar is called in a function which is wrapped in a
loop. In the example below, this happened for me every ~44th
iteration. Interestingly, it seems that reduction of the sleep times
in this function increases the number of iterations before clearing.
In my real application, where the progress bar is used in a much
slower function, the console is cleared every 2-3 iteration, which
means that I cannot scroll back to check the output.
testit <- function(x = sort(runif(20)), ...)
{
pb <- txtProgressBar(...)
for(i in c(0, x, 1)) {Sys.sleep(0.2); setTxtProgressBar(pb, i)}
Sys.sleep(1)
close(pb)
}
iter = 0
while (TRUE) {testit(style = 3); iter = iter + 1; print(paste("done",
iter))}
Is this only a problem for a few, or is it reproducible? Any hints to
what the problem could be, or if it can be fixed? I have seen this in
some versions of R, and could also reproduce in 3.3.2.
Best wishes,
Jon
R version 3.3.2 (2016-10-31)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 8.1 x64 (build 9600)
locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United States.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
On 11/23/2016 5:22 PM, Maram SAlem wrote:
Thanks a lot Bert , will check out your suggestions.
I've unchecked the buffer output option in GUI but still have the
same problem.
Thanks for your time and concern.
Maram Salem
Sent from my iPhone
On Nov 23, 2016, at 5:55 PM, Bert Gunter
wrote:
In addition to Jim's comments, which you have not yet satisfactorily
addressed (buffering in GUI??),
1. Show your code!
2. Show ouput of sessionInfo()
3. Upgrade to the latest R version maybe
4. Perhaps write to package maintainer (see ?maintainer) if nothing or
no one helps.
Cheers,
Bert
Bert Gunter
"The trouble with having an open mind is that people keep coming along
and sticking things into it."
-- Opus (aka Berkeley Breathed in his "Bloom County" comic strip )
On Tue, Nov 22, 2016 at 10:05 AM, Maram SAlem
wrote:
Thanks for helping Jim.
I'm actually using the pbapply function together with the print
function within a loop. In earlier versions, the progress bar and
the output of the print function used to appear after each
iteration of the loop. But with the 3.3.1. Version nothing appears,
instead the console turns white and thecursor turns blue ( busy)
and I know nothing about the progress of the running code.
I just want to see the bar and the output of the print function as
I used to, any help?
Thanks in advance.
Maram Salem
Sent from my iPhone
On Nov 3, 2016, at 8:30 PM, jim holtman wrote:
A little more information would help. How exactly are out
creating the output to the console? Are you using 'print', 'cat'
or something else? Do you have buffered output checked on the GUI
(you probably don't want it checked or you output will be delayed
till the buffer is full -- this mightbe the cause of your problem.
Jim Holtman
Data Munger Guru
What is the problem that you are trying to solve?
Tell me what you want to do, not how you want to do it.
On Thu, Nov 3, 2016 at 1:55 PM, Maram SAlem
wrote:
Hi all,
I've a question concerning the R 3.3.1 version. I have a long
code that I used to run on versions earlier to the 3.3.1 version,
and when I copied the code to the R console, I can still see the
code while the loop is executing , along with the output printed
after each iteration of the loop.
Now, on the 3.3.1 version, after I copy the code to the console,
it disappears and I only see the printed output of only one
iteration at a time, that is, after the first iteration the
printed output disappears ( thoughit's only 6 lines, just giving
me some guidance, not a long output).
This is causing me some problems, so I don't know if there is a
general option for R that enables me to still see the code and
the output of allthe iterations till the loop is over, as was the
case with earlier R versions.
I didn't include the code as it's a long one.
Thanks a lot in advance,
Maram
Sent from my iPhone
__
r-h...@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://st
Re: [Rd] Strange behavior when using progress bar (Fwd: Re: [R] The code itself disappears after starting to execute the for loop)
On 12/7/2016 11:58 AM, Martin Maechler wrote: Jon Skoien on Wed, 7 Dec 2016 11:04:04 +0100 writes: >> Is this only a problem for a few, or is it reproducible? Any hints to >> what the problem could be, or if it can be fixed? I have seen this in >> some versions of R, and could also reproduce in 3.3.2. "some versions of R" ... all on Windows ? Yes, I should have clarified, several versions of R, all running on the same Windows 8.1 computer. Jon >> >> Best wishes, >> Jon >> >> R version 3.3.2 (2016-10-31) >> Platform: x86_64-w64-mingw32/x64 (64-bit) >> Running under: Windows 8.1 x64 (build 9600) >> >> locale: >> [1] LC_COLLATE=English_United States.1252 >> [2] LC_CTYPE=English_United States.1252 >> [3] LC_MONETARY=English_United States.1252 >> [4] LC_NUMERIC=C >> [5] LC_TIME=English_United States.1252 >> >> attached base packages: >> [1] stats graphics grDevices utils datasets methods base [.] > Jon Olav Skøien > Joint Research Centre - European Commission > Institute for Space, Security & Migration > Disaster Risk Management Unit > Via E. Fermi 2749, TP 122, I-21027 Ispra (VA), ITALY > jon.sko...@jrc.ec.europa.eu > Tel: +39 0332 789205 -- Jon Olav Skøien Joint Research Centre - European Commission Institute for Space, Security & Migration Disaster Risk Management Unit Via E. Fermi 2749, TP 122, I-21027 Ispra (VA), ITALY jon.sko...@jrc.ec.europa.eu Tel: +39 0332 789205 Disclaimer: Views expressed in this email are those of the individual and do not necessarily represent official views of the European Commission. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Strange behavior when using progress bar (Fwd: Re: [R] The code itself disappears after starting to execute the for loop)
Thanks John,
As the problem can be reproduced, I would like to submit this as a bug
report. But I think someone will have to add me to Bugzilla first.
Given the few responses, I am not expecting that this will get a high
priority though...
Jon
On 12/7/2016 2:59 PM, Fox, John wrote:
Dear Martin and Jon,
I can reproduce this problem in the Windows GUI, where I observed it using
Jon's program after 75 iterations. I didn't observe the problem in a Windows
terminal or under RStudio, letting the program run for more than 200 iterations
in each case.
My system and session info:
- snip -
Sys.info()
sysname release version nodename
"Windows" "10 x64""build 14393" "JOHN-CARBON-X1"
machinelogin user effective_user
"x86-64" "John Fox" "John Fox" "John Fox"
sessionInfo()
R version 3.3.2 (2016-10-31)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 10 x64 (build 14393)
locale:
[1] LC_COLLATE=English_Canada.1252 LC_CTYPE=English_Canada.1252
[3] LC_MONETARY=English_Canada.1252 LC_NUMERIC=C
[5] LC_TIME=English_Canada.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
- snip -
I hope this helps,
John
-
John Fox, Professor
McMaster University
Hamilton, Ontario
Canada L8S 4M4
Web: socserv.mcmaster.ca/jfox
-Original Message-
From: R-devel [mailto:r-devel-boun...@r-project.org] On Behalf Of Martin
Maechler
Sent: December 7, 2016 5:58 AM
To: Jon Skoien
Cc: r-devel@r-project.org
Subject: Re: [Rd] Strange behavior when using progress bar (Fwd: Re: [R] The
code itself disappears after starting to execute the for loop)
Jon Skoien
on Wed, 7 Dec 2016 11:04:04 +0100 writes:
> I would like to ask once more if this is reproducible also for others?
> If yes, should I submit it as a bug-report?
> Best,
> Jon
Please Windows users .. this is possibly only for you!
Note that I do *not* see problems on Linux (in ESS; did not try RStudio).
Please also indicate in which form you are running R.
Here it does depend if this is inside RStudio, ESS, the "Windows GUI", the
"Windows terminal", ...
Martin Maechler,
ETH Zurich
> On 11/28/2016 11:26 AM, Jon Skoien wrote:
>> I first answered to the email below in r-help, but as I did not see
>> any response, and it looks like a bug/unwanted behavior, I am also
>> posting here. I have observed this in RGui, whereas it seems not to
>> happen in RStudio.
>>
>> Similar to OP, I sometimes have a problem with functions using the
>> progress bar. Frequently, the console is cleared after x iterations
>> when the progress bar is called in a function which is wrapped in a
>> loop. In the example below, this happened for me every ~44th
>> iteration. Interestingly, it seems that reduction of the sleep times
>> in this function increases the number of iterations before clearing.
>> In my real application, where the progress bar is used in a much
>> slower function, the console is cleared every 2-3 iteration, which
>> means that I cannot scroll back to check the output.
testit <- function(x = sort(runif(20)), ...) {
pb <- txtProgressBar(...)
for(i in c(0, x, 1)) {Sys.sleep(0.2); setTxtProgressBar(pb, i)}
Sys.sleep(1)
close(pb)
}
it <- 0
while (TRUE) {testit(style = 3); it <- it + 1; print(paste("done", it))}
>> Is this only a problem for a few, or is it reproducible? Any hints to
>> what the problem could be, or if it can be fixed? I have seen this in
>> some versions of R, and could also reproduce in 3.3.2.
"some versions of R" ... all on Windows ?
>>
>> Best wishes,
>> Jon
>>
>> R version 3.3.2 (2016-10-31)
>> Platform: x86_64-w64-mingw32/x64 (64-bit)
>> Running under: Windows 8.1 x64 (build 9600)
>>
>> locale:
>> [1] LC_COLLATE=English_United States.1252
>> [2] LC_CTYPE=English_United States.1252
>> [3] LC_MONETARY=English_United States.1252
>> [4] LC_NUMERIC=C
>> [5] LC_TIME=English_United States.1252
>>
>> attached base packages:
>> [1] stats graphics grDevices utils datasets methods base
[.]
> Jon Olav Skøien
> Joint Research Centre - European Commission
> Institute for Space, Security & Migration
> Disaster Risk Management Unit
> Via E. Fermi 2749, TP 122, I-2
