[Rd] Unattended Windows installation of R modified with v2.1.1
FYI, I just noticed that an unattended Windows installation of R v2.1.1 patched (2005-06-22), that is, rw2011pat.exe /silent /sp- /norestart no longer installs the perl scripts INSTALL, build check and so on (I think this is the flag "Source Package Installation Files" in InnoSetup. It used to do this as I can remember. I have not tried /COMPONENTS="comma separated list of component names" set the initial list of components: Components are named main, chtml, html, latex, manuals, refman, libdocs, devel, tcl, mbcs, Rd and trans. from the rw-FAQ.html, which will probably do what I want. If this modification was not intended, I just want to make the maintainer of the R Windows InnoSetup script (Duncan M and Brian R?) aware of it. Cheers Henrik __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Unattended Windows installation of R modified with v2.1.1
Well, rw2011.exe does install the default set of components for me, and nothing has changed in the last few days. Note that Inno Setup does pick up default options from a previously installed version of R, so that might be the explanation. (It might even do so if one had already been uninstalled: the docs are not clear about this.) Specifying /COMPONENTS is probably what you want to do to be sure. On Thu, 23 Jun 2005, Henrik Bengtsson wrote: > FYI, I just noticed that an unattended Windows installation of R v2.1.1 > patched (2005-06-22), that is, > > rw2011pat.exe /silent /sp- /norestart > > no longer installs the perl scripts INSTALL, build check and so on (I > think this is the flag "Source Package Installation Files" in InnoSetup. > It used to do this as I can remember. I have not tried > > /COMPONENTS="comma separated list of component names" > set the initial list of components: Components are named main, chtml, > html, latex, manuals, refman, libdocs, devel, tcl, mbcs, Rd and trans. > > from the rw-FAQ.html, which will probably do what I want. > > If this modification was not intended, I just want to make the > maintainer of the R Windows InnoSetup script (Duncan M and Brian R?) > aware of it. > > Cheers > > Henrik > > __ > 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
Re: [Rd] Rgui bug in Windows: leftover download dialog (PR#7964)
On 6/22/2005 4:15 PM, [EMAIL PROTECTED] wrote: > In Windows, if a download is interrupted (by switching to the console > window and hitting ESC), the download status dialog can be left > onscreen, with no apparent way to get rid of it (other than stopping and > restarting R). > > To duplicate: > > Run this: > > a <- available.packages() > download.packages(a, 'c:/temp') > > Then, during a particularly long download, switch to the console window > and hit ESC. > > This affects R-devel, as well as 2.1.1. Now fixed in R-devel and R-patched. I also set it so the dialog retains its position if you move it out of the way; it was pretty irritating to have it pop up in the middle of the screen every time in a multiple file download. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rgui bug in Windows: leftover download dialog (PR#7964)
On Thu, 23 Jun 2005 [EMAIL PROTECTED] wrote: > On 6/22/2005 4:15 PM, [EMAIL PROTECTED] wrote: >> In Windows, if a download is interrupted (by switching to the console >> window and hitting ESC), the download status dialog can be left >> onscreen, with no apparent way to get rid of it (other than stopping and >> restarting R). >> >> To duplicate: >> >> Run this: >> >> a <- available.packages() >> download.packages(a, 'c:/temp') >> >> Then, during a particularly long download, switch to the console window >> and hit ESC. >> >> This affects R-devel, as well as 2.1.1. > > Now fixed in R-devel and R-patched. I also set it so the dialog retains > its position if you move it out of the way; it was pretty irritating to > have it pop up in the middle of the screen every time in a multiple file > download. I don't think you can do simultaneous downloads, and is not the `it' different progress bar windows? Do you mean that the next instance of a progress bar will come up where the last one was? That seems not the standard ergonomics on GUI systems, in which a new window is treated as a new window and not the same as an old one. I hate it when Windows puts Firefox up where I dragged the last Firefox window (or even where another user dragged it). -- 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
Re: [Rd] Rgui bug in Windows: leftover download dialog (PR#7964)
On 6/23/2005 1:23 PM, Prof Brian Ripley wrote: > On Thu, 23 Jun 2005 [EMAIL PROTECTED] wrote: > >> On 6/22/2005 4:15 PM, [EMAIL PROTECTED] wrote: >>> In Windows, if a download is interrupted (by switching to the console >>> window and hitting ESC), the download status dialog can be left >>> onscreen, with no apparent way to get rid of it (other than stopping and >>> restarting R). >>> >>> To duplicate: >>> >>> Run this: >>> >>> a <- available.packages() >>> download.packages(a, 'c:/temp') >>> >>> Then, during a particularly long download, switch to the console window >>> and hit ESC. >>> >>> This affects R-devel, as well as 2.1.1. >> >> Now fixed in R-devel and R-patched. I also set it so the dialog retains >> its position if you move it out of the way; it was pretty irritating to >> have it pop up in the middle of the screen every time in a multiple file >> download. > > I don't think you can do simultaneous downloads, and is not the `it' > different progress bar windows? Right, simultaneous downloads are not possible. > Do you mean that the next instance of a progress bar will come up where > the last one was? Yes, but see below. > That seems not the standard ergonomics on GUI systems, > in which a new window is treated as a new window and not the same as an > old one. It would be good ergonomics if there was just one progress bar window when multiple files were selected for download, but I think that's too much trouble to do, since the C function called by download.file doesn't get told it's part of a multiple download sequence. The changes I made make just one progress bar window for the whole session, and make it visible when downloading and invisible otherwise. It's a change to the UI (one long-lived window instead of many short-lived ones). > I hate it when Windows puts Firefox up where I dragged the last > Firefox window (or even where another user dragged it). I think that's really Firefox moving itself to where it last was when you closed it; as far as I know Windows doesn't remember such things unless asked. There's probably some Mozilla option to control that behaviour. The retention I put in is entirely within an R session. Each download just makes the same progress window visible where you last left it, instead of creating a new one. This way if you're doing something like installing all of CRAN, you can push the progress bar out of the way while the downloads are going on, and it will stay out of the way. It does seem to have an annoying habit of grabbing the focus away from some programs, but not all; I'm not sure what's going on there or whether this can be fixed. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] typo in dev2bitmap.R (PR#7966)
Full_Name: Stephen Weigand
Version: 2.0.1
OS: solaris2.9
Submission from: (NULL) (129.176.151.21)
R> bitmap("")
produces the following error message as of the June 23 download of R-devel:
Error in bitmap("") : 'file' is must be a non-empty character string
The word "is" should deleted.
This appears to be a typo in dev2bitmap.R (appearing twice in unix/dev2bitmap.R
and twice in windows/dev2bitmap.R).
Other affected files include
grDevices/po/R-grDevices.pot
grDevices/po/R-it.po
grDevices/po/[EMAIL PROTECTED]
grDevices/po/[EMAIL PROTECTED]
grDevices/po/R-ja.po
grDevices/po/R-ko.po
Thank you,
Stephen Weigand
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Unattended Windows installation of R modified with v2.1.1
Prof Brian Ripley wrote: > Well, rw2011.exe does install the default set of components for me, and > nothing has changed in the last few days. > > Note that Inno Setup does pick up default options from a previously > installed version of R, so that might be the explanation. (It might even > do so if one had already been uninstalled: the docs are not clear about > this.) > > Specifying /COMPONENTS is probably what you want to do to be sure. Thanks for this. All good to know. It could be that I actually installed a patch version (over an previous patch version) and that I did this "attended" without selecting "devel", but I cannot remember. I'll keep an eye on it for the next time. Henrik > On Thu, 23 Jun 2005, Henrik Bengtsson wrote: > >> FYI, I just noticed that an unattended Windows installation of R v2.1.1 >> patched (2005-06-22), that is, >> >> rw2011pat.exe /silent /sp- /norestart >> >> no longer installs the perl scripts INSTALL, build check and so on (I >> think this is the flag "Source Package Installation Files" in InnoSetup. >> It used to do this as I can remember. I have not tried >> >> /COMPONENTS="comma separated list of component names" >> set the initial list of components: Components are named main, chtml, >> html, latex, manuals, refman, libdocs, devel, tcl, mbcs, Rd and trans. >> >> from the rw-FAQ.html, which will probably do what I want. >> >> If this modification was not intended, I just want to make the >> maintainer of the R Windows InnoSetup script (Duncan M and Brian R?) >> aware of it. >> >> Cheers >> >> Henrik >> >> __ >> 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
[Rd] list.files() reorders files in R CMD INSALL
Hi,
The list.files() function seems to order its result vector differently
when is run during R CMD INSTALL. Here is an example:
~% mkdir ~/FOO
~% cd ~/FOO/
~/FOO% touch a A b B
~/FOO% ls
a A b B
Put foo.R in the vor package. The foo.R just prints the files in ~/FOO:
print(list.files("~/FOO"))
Now install the package:
~/FOO% R CMD INSTALL -l ~/R/library/ ~/src/vor/
* Installing *source* package 'vor' ...
** libs
make: `vor.so' is up to date.
** R
** preparing package for lazy loading
[1] "A" "B" "a" "b"
** help
>>> Building/Updating help pages for package 'vor'
Formats: text html latex example
* DONE (vor)
Note that the files are listed as: [1] "A" "B" "a" "b"
Now start an R session
> list.files("~/FOO")
[1] "a" "A" "b" "B"
which differs in order from that in R CMD INSTALL.
> version
_
platform x86_64-unknown-linux-gnu
arch x86_64
os linux-gnu
system x86_64, linux-gnu
status
major2
minor0.1
year 2004
month11
day 15
language R
Thanks,
Vadim
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] list.files() reorders files in R CMD INSALL
On 6/23/2005 4:18 PM, Vadim Ogranovich wrote:
> Hi,
>
> The list.files() function seems to order its result vector differently
> when is run during R CMD INSTALL. Here is an example:
>
> ~% mkdir ~/FOO
> ~% cd ~/FOO/
> ~/FOO% touch a A b B
> ~/FOO% ls
> a A b B
>
>
> Put foo.R in the vor package. The foo.R just prints the files in ~/FOO:
> print(list.files("~/FOO"))
>
> Now install the package:
> ~/FOO% R CMD INSTALL -l ~/R/library/ ~/src/vor/
> * Installing *source* package 'vor' ...
> ** libs
> make: `vor.so' is up to date.
> ** R
> ** preparing package for lazy loading
> [1] "A" "B" "a" "b"
>
> ** help
> >>> Building/Updating help pages for package 'vor'
> Formats: text html latex example
> * DONE (vor)
>
>
> Note that the files are listed as: [1] "A" "B" "a" "b"
>
> Now start an R session
>> list.files("~/FOO")
> [1] "a" "A" "b" "B"
>
> which differs in order from that in R CMD INSTALL.
Looks like the sorting is being done in the C locale in the first case,
and in a different one in the second. See ?locales for how to set the
locale to what you want.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] list.files() reorders files in R CMD INSALL
On 6/23/2005 4:38 PM, Duncan Murdoch wrote:
> On 6/23/2005 4:18 PM, Vadim Ogranovich wrote:
>> Hi,
>>
>> The list.files() function seems to order its result vector differently
>> when is run during R CMD INSTALL. Here is an example:
>>
>> ~% mkdir ~/FOO
>> ~% cd ~/FOO/
>> ~/FOO% touch a A b B
>> ~/FOO% ls
>> a A b B
>>
>>
>> Put foo.R in the vor package. The foo.R just prints the files in ~/FOO:
>> print(list.files("~/FOO"))
>>
>> Now install the package:
>> ~/FOO% R CMD INSTALL -l ~/R/library/ ~/src/vor/
>> * Installing *source* package 'vor' ...
>> ** libs
>> make: `vor.so' is up to date.
>> ** R
>> ** preparing package for lazy loading
>> [1] "A" "B" "a" "b"
>>
>> ** help
>> >>> Building/Updating help pages for package 'vor'
>> Formats: text html latex example
>> * DONE (vor)
>>
>>
>> Note that the files are listed as: [1] "A" "B" "a" "b"
>>
>> Now start an R session
>>> list.files("~/FOO")
>> [1] "a" "A" "b" "B"
>>
>> which differs in order from that in R CMD INSTALL.
>
> Looks like the sorting is being done in the C locale in the first case,
> and in a different one in the second. See ?locales for how to set the
> locale to what you want.
... when in R, and see the R Extensions manual for setting it during the
INSTALL.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] list.files() reorders files in R CMD INSALL
Duncan Murdoch <[EMAIL PROTECTED]> writes: > >> [1] "a" "A" "b" "B" > >> > >> which differs in order from that in R CMD INSTALL. > > > > Looks like the sorting is being done in the C locale in the first case, > > and in a different one in the second. See ?locales for how to set the > > locale to what you want. > > ... when in R, and see the R Extensions manual for setting it during the > INSTALL. However, notice that the C locale is generally enforced for a reason: Sometimes the order of files matter, e.g. the file zzz.R is designed to come last, but in en_GB it actually comes before Zeke.R and in Estonian z comes between s and t... -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] efficiency of sample() with prob.
> We suggest that you take up your own suggestion, research this area and
> offer the R project the results of your research for consideration as your
> contribution.
I implemented Walker's alias method and re-compiled R. Here is what
I did:
1. replace function ProcSampleReplace in R-2.1.0/src/main/random.c
with the following one
static void ProbSampleReplace(int n, double *p, int *perm, int nans, int *ans)
{
/* allocate memory for a, p and HL */
double * q = Calloc(n, double);
int * a = Calloc(n, int);
int * HL = Calloc(n, int);
int * H = HL;
int * L = HL+n-1;
int i, j, k;
double rU; /* U[0,1)*n */
/* set up alias table */
/* initialize q with n*p0,...n*p_n-1 */
for(i=0; i= 1.)
*H++ = i;
else
*L-- = i;
}
while( H != HL && L != HL+n-1) {
j = *(L+1);
k = *(H-1);
a[j] = k;
q[k] += q[j] - 1;
L++; /* remove j from L */
if( q[k] < 1. ) {
*L-- = k; /* add k to L */
--H; /* remove k */
}
}
/* generate sample */
for (i = 0; i < nans; ++i) {
rU = unif_rand() * n;
k = (int)(rU);
rU -= k; /* rU becomes rU-[rU] */
if( rU < q[k] )
ans[i] = k+1;
else
ans[i] = a[k]+1;
}
Free(HL);
Free(a);
Free(q);
}
2. make and make install
3. test the new sample function by code like
> b=sample(seq(1,100), prob=seq(1,100), replace=TRUE, size=100)
> table(b)/100*sum(seq(1,100))
4. run the following code in current R 2.1.0 and updated R.
for(prob in seq(1,4)){
for(sample in seq(1,4)){
x = seq(1:(10^prob)) # short to long x
p = abs(rnorm(length(x))) # prob vector
times = 10^(6-prob) # run shorter cases more times
Rprof(paste("sample_", prob, "_", sample, ".prof", sep=''))
for(t in seq(1,times)){
sample(x, prob=p, size=10^sample, replace=TRUE )
}
Rprof(NULL)
}
}
Basically, I tried to test the performance of sample(replace=TRUE, prob=..)
with different length of x and size.
5. process the profiles and here is the result.
p: length of prob and x
size: size of sample
cell: execution time of old/updated sample()
size\p10 10^210^3 10^4
10 2.4/1.6 0.32/0.22 0.20/0.08 0.24/0.06
10^2 3.1/2.6 0.48/0.28 0.28/0.06 0.30/0.06
10^3 11.8/11.11.84/1.14 0.94/0.18 0.96/0.08
10^4 96.8/96.615.34/9.68 7.54/1.06 7.48/0.16
run: 1100010010 times
We can see that the alias method is quicker than the linear search
method in all cases. The performance difference is greatest (>50 times)
when the original algorithm need to search in a long prob vector.
I have not thoroughly tested the new function. I will do so if you
(the developers) think that this has the potential to be incorporated
into R.
Thanks.
Bo Peng
Department of Statistics
Rice University
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] efficiency of sample() with prob.
`Research' involves looking at all the competitor methods, devising a
near-optimal strategy and selecting amongst methods according to that
strategy. It is not a quick fix we are looking for but something that
will be good for the long term.
On Thu, 23 Jun 2005, Bo Peng wrote:
>> We suggest that you take up your own suggestion, research this area and
>> offer the R project the results of your research for consideration as your
>> contribution.
>
> I implemented Walker's alias method and re-compiled R. Here is what
> I did:
>
> 1. replace function ProcSampleReplace in R-2.1.0/src/main/random.c
> with the following one
>
> static void ProbSampleReplace(int n, double *p, int *perm, int nans, int *ans)
> {
>/* allocate memory for a, p and HL */
>double * q = Calloc(n, double);
>int * a = Calloc(n, int);
>int * HL = Calloc(n, int);
>int * H = HL;
>int * L = HL+n-1;
>int i, j, k;
>double rU; /* U[0,1)*n */
>
>/* set up alias table */
>/* initialize q with n*p0,...n*p_n-1 */
>for(i=0; iq[i] = p[i]*n;
>
>/* initialize a with indices */
>for(i=0; ia[i] = i;
>
>/* set up H and L */
>for(i=0; iif( q[i] >= 1.)
>*H++ = i;
>else
>*L-- = i;
>}
>
>while( H != HL && L != HL+n-1) {
>j = *(L+1);
>k = *(H-1);
>a[j] = k;
>q[k] += q[j] - 1;
>L++; /* remove j from L */
>if( q[k] < 1. ) {
>*L-- = k; /* add k to L */
>--H; /* remove k */
>}
>}
>
>/* generate sample */
>for (i = 0; i < nans; ++i) {
> rU = unif_rand() * n;
>
>k = (int)(rU);
>rU -= k; /* rU becomes rU-[rU] */
>
>if( rU < q[k] )
>ans[i] = k+1;
>else
>ans[i] = a[k]+1;
>}
>Free(HL);
>Free(a);
>Free(q);
> }
>
> 2. make and make install
>
> 3. test the new sample function by code like
>
>> b=sample(seq(1,100), prob=seq(1,100), replace=TRUE, size=100)
>> table(b)/100*sum(seq(1,100))
>
> 4. run the following code in current R 2.1.0 and updated R.
>
> for(prob in seq(1,4)){
> for(sample in seq(1,4)){
>x = seq(1:(10^prob)) # short to long x
>p = abs(rnorm(length(x))) # prob vector
>times = 10^(6-prob) # run shorter cases more times
>Rprof(paste("sample_", prob, "_", sample, ".prof", sep=''))
>for(t in seq(1,times)){
> sample(x, prob=p, size=10^sample, replace=TRUE )
>}
>Rprof(NULL)
> }
> }
>
> Basically, I tried to test the performance of sample(replace=TRUE, prob=..)
> with different length of x and size.
>
> 5. process the profiles and here is the result.
> p: length of prob and x
> size: size of sample
> cell: execution time of old/updated sample()
>
> size\p10 10^210^3 10^4
> 10 2.4/1.6 0.32/0.22 0.20/0.08 0.24/0.06
> 10^2 3.1/2.6 0.48/0.28 0.28/0.06 0.30/0.06
> 10^3 11.8/11.11.84/1.14 0.94/0.18 0.96/0.08
> 10^4 96.8/96.615.34/9.68 7.54/1.06 7.48/0.16
> run: 1100010010 times
>
> We can see that the alias method is quicker than the linear search
> method in all cases. The performance difference is greatest (>50 times)
> when the original algorithm need to search in a long prob vector.
>
> I have not thoroughly tested the new function. I will do so if you
> (the developers) think that this has the potential to be incorporated
> into R.
>
> Thanks.
>
> Bo Peng
> Department of Statistics
> Rice University
>
>
--
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
