[Rd] Question about match.fun()
Dear all, I was recently contacted by a user about an alledged problem/bug in the latest version of lasso2. After some investigation, we found out that it was a user error which boils down to the following: > x <- matrix(rnorm(200), ncol=2) > var <- "fred" > apply(x, 2, var) Error in get(x, envir, mode, inherits) : variable "fred" of mode "function" was not found only that the "offending" apply() command happened inside the gl1ce() function of lasso2. I was under the impression that R can now distinguish between variables and functions with the same name and, indeed, the following works: > var <- 2 > apply(x, 2, var) [1] 1.053002 1.250875 Poking a bit around, I guess that the ability to distinguish between variables and functions with the same name comes from the introduction of the function match.fun() and, after reading its help page, the reasons why an error is triggered the first time but not the second time is perfectly clear to me. I wonder whether it would make sense to change match.fun() such that the first case does not result in an error? I was thinking along the line that if the argument to match.fun() is a variable that contains a character vector of length one then, using get(), match.fun() attemps to find a function with that name. If the get() command does not succeed, then a second try is made using the name of the variable passed by the caller to match.fun(). So before trying to modify match.fun() and submitting a patch, I wanted to ask whether such a change would be accepted? Is there an argument that I don't see that the first case should always result in an error and not be silently resolved? Cheers, Berwin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Efficient Merging of two huge sorted data frames?---Use merge()?
merge() is not optimized for large data frames. To do things on this
scale you really want to be using a DBMS not R. See the `R Data
Import/Export Manual'.
Sorting is not really relevant, especially as merge is not assuming that
the match is unique. Hashing could be used, but is not.
As R is open source, you have the source code and it would be kinder to
read it yourself rather than expect this list to read it for you. A
useful contribution to the R project would be to contribute a more
efficient version, and we look forwards to seeing your contribution.
On Mon, 8 May 2006, Charles Cheung wrote:
> Hello all,
>
> A problem I encounter today is the speed which takes to sort two huge data
> frames...
>
> I wish to sort by (X,Y)
>
> Dataframe One consists of variables:
> X, Y, sequence, position
> having ~700 000 records
>
> another dataframe consists of
> X,Y, intensities
> having ~900 000 records
>
>
> Every (X,Y) pair in dataframe One is included in dataframe Two,
> however, the reverse is not true.
> Furthermore, (X,Y, position) in data frame One makes the record unique.
> (That means there can be multiple records with the same (X,Y) records!)
>
> Added together, it makes it hard to just combine the two data frames
> together by simply going
> data.frame(dataFrameOne, dataFrameTwo) because the mapping won't correspond
> even in sorted records by X and Y.
>
>
> Intuitive, it should only require very little time after
> the data records are sorted.
> However, it takes so long (I haven't finished the process in 20 minutes.. it
> should only take <1 min) to merge the list by X and Y using
>
> merge(dataFrameOne, dataFrameTwo, by=c("X","Y") , which leads me to suspect
> this process is not optimized for already sorted list.
>
> * assuming the two frames have been sorted, I would be able to do the
> following:
>
>
> X Y seq Pos
> 1 1 AA 32
> 1 2 AG 44
> 1 3 GC 65
>
>
> X Y intensities
> 1 1 0.4
> 1 3 0.552
>
>>> Cursor at beginning (1,1) (1,1) -->merge the (1,1) pair.. then cursor
>>> moves to (1,2) (1,3) --> can't find.. cursor moves to (1,3) (1,3) ..
>>> merge that pair
>
> Is the merge function doing that already?
>
>
> Is there an efficient way to merge the data frames? (What do you suggest I
> should do?)
>
>
> (to produce)
> X Y seq pos intensities
> 1 1 AA 32 0.4
> 1 3 GC 65 0.552
>
> Thank you in advance!
>
>
> Charles Cheung
>
> __
> 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
[Rd] Seg fault when installing package from bad repository
> install.packages("rggobi", repos="http://ggobi.org/r/";)
Warning in install.packages("rggobi", repos = "http://ggobi.org/r/";) :
argument 'lib' is missing: using /Users/hadley/Library/R/library/
Reading symbols for shared libraries . done
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x5f4d4550
0x90002f48 in strlen ()
(gdb) where
#0 0x90002f48 in strlen ()
#1 0x9000d7d0 in __vfprintf$LDBL128 ()
#2 0x900273cc in vsnprintf$LDBL128 ()
#3 0x0108ea1c in Rvsnprintf (buf=0xbfff35f4 "B", size=1000,
format=0x3 , ap=0x34 ) at ../../../../R-2.3.0/src/main/errors.c:211
#4 0x01092e68 in Rf_warning (format=0x3 )
at ../../../../R-2.3.0/src/main/errors.c:223
#5 0x023c39a8 in in_R_HTTPOpen (url=0x212c930
"/Library/Frameworks/R.framework/Resources/share/locale/en/LC_MESSAGES/R.mo",
cacheOK=404) at
../../../../../R-2.3.0/src/modules/internet/internet.c:490
#6 0x023c3f00 in in_do_download (call=0x5f4d4553, op=0xbfff2a03,
args=0x195d300, env=0x34) at
../../../../../R-2.3.0/src/modules/internet/internet.c:320
#7 0x010b6290 in do_download (call=0x18d0078, op=0x181c2a8,
args=0x18c3b50, env=0x18cfd64) at
../../../../R-2.3.0/src/main/internet.c:99
#8 0x010cefc4 in do_internal (call=0x18c3b50, op=0xbfff2a03,
args=0x0, env=0x18cfd64) at ../../../../R-2.3.0/src/main/names.c:1089
#9 0x0109d798 in Rf_eval (e=0x18d0040, rho=0x18cfd64) at
../../../../R-2.3.0/src/main/eval.c:391
#10 0x0109f87c in do_set (call=0x18d17b0, op=0x180a190,
args=0x18d0008, rho=0x18cfd64) at
../../../../R-2.3.0/src/main/eval.c:1303
#11 0x0109d798 in Rf_eval (e=0x18d17b0, rho=0x18cfd64) at
../../../../R-2.3.0/src/main/eval.c:391
#12 0x0109d798 in Rf_eval (e=0x18d16b4, rho=0x18cfd64) at
../../../../R-2.3.0/src/main/eval.c:391
#13 0x0109f93c in do_begin (call=0x18d1920, op=0x180a0cc,
args=0x18d1628, rho=0x18cfd64) at
../../../../R-2.3.0/src/main/eval.c:1067
#14 0x0109d798 in Rf_eval (e=0x18d1920, rho=0x18cfd64) at
../../../../R-2.3.0/src/main/eval.c:391
#15 0x010a0d34 in Rf_applyClosure (call=0x18f8cf4, op=0x18d2580,
arglist=0x18cfb50, rho=0x18f61ac, suppliedenv=0x181d200) at
../../../../R-2.3.0/src/main/eval.c:581
#16 0x0109d634 in Rf_eval (e=0x18f8cf4, rho=0x18f61ac) at
../../../../R-2.3.0/src/main/eval.c:422
#17 0x0109d66c in Rf_eval (e=0x18d2894, rho=0x18d293c) at
../../../../R-2.3.0/src/main/eval.c:370
#18 0x0109d938 in Rf_eval (e=0x1826b18, rho=0x18d293c) at
../../../../R-2.3.0/src/main/eval.c:357
#19 0x0109f93c in do_begin (call=0x1a37720, op=0x180a0cc,
args=0x1a38f2c, rho=0x18d293c) at
../../../../R-2.3.0/src/main/eval.c:1067
#20 0x0109d798 in Rf_eval (e=0x1a37720, rho=0x18d293c) at
../../../../R-2.3.0/src/main/eval.c:391
#21 0x0109d798 in Rf_eval (e=0x1a37800, rho=0x18d293c) at
../../../../R-2.3.0/src/main/eval.c:391
#22 0x0109f93c in do_begin (call=0x1a37838, op=0x180a0cc,
args=0x1a3781c, rho=0x18d293c) at
../../../../R-2.3.0/src/main/eval.c:1067
#23 0x0109d798 in Rf_eval (e=0x1a37838, rho=0x18d293c) at
../../../../R-2.3.0/src/main/eval.c:391
#24 0x010a0d34 in Rf_applyClosure (call=0x18f8cbc, op=0x1a378c4,
arglist=0x18d28b0, rho=0x18f61ac, suppliedenv=0x181d200) at
../../../../R-2.3.0/src/main/eval.c:581
#25 0x0109d634 in Rf_eval (e=0x18f8cbc, rho=0x18f61ac) at
../../../../R-2.3.0/src/main/eval.c:422
#26 0x0109f87c in do_set (call=0x18f8c68, op=0x180a190,
args=0x18f8c84, rho=0x18f61ac) at
../../../../R-2.3.0/src/main/eval.c:1303
#27 0x0109d798 in Rf_eval (e=0x18f8c68, rho=0x18f61ac) at
../../../../R-2.3.0/src/main/eval.c:391
#28 0x0109f93c in do_begin (call=0x18f88e8, op=0x180a0cc,
args=0x18f8c4c, rho=0x18f61ac) at
../../../../R-2.3.0/src/main/eval.c:1067
#29 0x0109d798 in Rf_eval (e=0x18f88e8, rho=0x18f61ac) at
../../../../R-2.3.0/src/main/eval.c:391
#30 0x0109d798 in Rf_eval (e=0x18f9724, rho=0x18f61ac) at
../../../../R-2.3.0/src/main/eval.c:391
#31 0x0109f93c in do_begin (call=0x18f94d8, op=0x180a0cc,
args=0x18f9708, rho=0x18f61ac) at
../../../../R-2.3.0/src/main/eval.c:1067
#32 0x0109d798 in Rf_eval (e=0x18f94d8, rho=0x18f61ac) at
../../../../R-2.3.0/src/main/eval.c:391
#33 0x0109d798 in Rf_eval (e=0x18fa350, rho=0x18f61ac) at
../../../../R-2.3.0/src/main/eval.c:391
#34 0x0109f93c in do_begin (call=0x18fa174, op=0x180a0cc,
args=0x18fa334, rho=0x18f61ac) at
../../../../R-2.3.0/src/main/eval.c:1067
#35 0x0109d798 in Rf_eval (e=0x18fa174, rho=0x18f61ac) at
../../../../R-2.3.0/src/main/eval.c:391
#36 0x010a0074 in do_for (call=0x18fa104, op=0x1808958,
args=0x18fa120, rho=0x18f61ac) at
../../../../R-2.3.0/src/main/eval.c:963
#37 0x0109d798 in Rf_eval (e=0x18fa104, rho=0x18f61ac) at
../../../../R-2.3.0/src/main/eval.c:391
#38 0x0109f93c in do_begin (call=0x18fb2fc, op=0x180a0cc,
args=0x18fa0e8, rho=0x18f61ac) at
../../../../R-2.3.0/src/main/eval.c:1067
#39 0x0109d798 in Rf_eval (e=0x18fb2fc, rho=0x18f61ac) at
../../../../R-2.3.0/src/main/eval.c:391
#40 0x010a0d34 in Rf_applyClosure (call=0x1910b18, op=0x18fbf5c,
arglist=0x18f6120, rho=0x190c0cc, suppliedenv=0x181d200) at
../../.
[Rd] combn(n, k, ...) and all its re-inventions
It seems people are reinventing the wheel here:
The goal is to generate all combinations of 1:n of size k.
This (typically) results in a matrix of size k * choose(n,k)
i.e. needs O(n ^ k) space, hence is only applicable to
relatively small k.
Then alternatives have been devised to generate the combinations
"one by one", and I think I remember there has been a
quiz/challenge about 20 years ago, at an S user's conference in
Australia(?), on this topic.
Anyway, AFAIK, the first nice and efficient function for this
has been provided by Scott Chasalow for S (not R) and he made
his S code available at the University of Wageningen as
"combinat" module. Later this became into an R package which is
now maintained by Vince Carey. The source of 'combinat' still
shows
# DATE WRITTEN: 14 April 1994 LAST REVISED: 10 July 1995
# AUTHOR: Scott Chasalow
OTOH, people have since reinvented the wheel quite prolifically:
There's combinations() in gtools {based on Bill Venables' code from R News 1/1},
combs() in CAtools, subsets() in BHH2, and nchoosek() in vsn (bioconductor);
then 'fwd.combn' in package "forward" which states explicitly
that it is Scott's combn() renamed..
I stopped searching for more, and I've made sure all
these 6 functions compute the same thing, at least in the most simple case.
After simply replacing nCm() by choose(), and some other minor
tweaks, I have now a version of combn() that is faster than all
the other implementations {only slightly faster than
combinations()}, and I plan to add this to R's standard package
'utils'.
Hopefully, the reinventing can be stopped by this, once people
can rely on a relatively fast implementation of the
functionality.
One might also consider to include a version of the ``one by
one'' combination generators {as mentioned above} which is
needed for larger k.
Opinions ?
Martin Maechler, ETH Zurich
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Seg fault when installing package from bad repository
It still segfaults even now that I've fixed the access error. Ah,
but if I specify type="source", so it must be a problem with having a
mac binary path but no packages in it. Is there anyway to fall back
to source automatically?
Thanks,
Hadley
On 5/9/06, hadley wickham <[EMAIL PROTECTED]> wrote:
> > install.packages("rggobi", repos="http://ggobi.org/r/";)
> Warning in install.packages("rggobi", repos = "http://ggobi.org/r/";) :
> argument 'lib' is missing: using /Users/hadley/Library/R/library/
> Reading symbols for shared libraries . done
>
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_INVALID_ADDRESS at address: 0x5f4d4550
> 0x90002f48 in strlen ()
> (gdb) where
> #0 0x90002f48 in strlen ()
> #1 0x9000d7d0 in __vfprintf$LDBL128 ()
> #2 0x900273cc in vsnprintf$LDBL128 ()
> #3 0x0108ea1c in Rvsnprintf (buf=0xbfff35f4 "B", size=1000,
> format=0x3 , ap=0x34 bounds>) at ../../../../R-2.3.0/src/main/errors.c:211
> #4 0x01092e68 in Rf_warning (format=0x3 )
> at ../../../../R-2.3.0/src/main/errors.c:223
> #5 0x023c39a8 in in_R_HTTPOpen (url=0x212c930
> "/Library/Frameworks/R.framework/Resources/share/locale/en/LC_MESSAGES/R.mo",
> cacheOK=404) at
> ../../../../../R-2.3.0/src/modules/internet/internet.c:490
> #6 0x023c3f00 in in_do_download (call=0x5f4d4553, op=0xbfff2a03,
> args=0x195d300, env=0x34) at
> ../../../../../R-2.3.0/src/modules/internet/internet.c:320
> #7 0x010b6290 in do_download (call=0x18d0078, op=0x181c2a8,
> args=0x18c3b50, env=0x18cfd64) at
> ../../../../R-2.3.0/src/main/internet.c:99
> #8 0x010cefc4 in do_internal (call=0x18c3b50, op=0xbfff2a03,
> args=0x0, env=0x18cfd64) at ../../../../R-2.3.0/src/main/names.c:1089
> #9 0x0109d798 in Rf_eval (e=0x18d0040, rho=0x18cfd64) at
> ../../../../R-2.3.0/src/main/eval.c:391
> #10 0x0109f87c in do_set (call=0x18d17b0, op=0x180a190,
> args=0x18d0008, rho=0x18cfd64) at
> ../../../../R-2.3.0/src/main/eval.c:1303
> #11 0x0109d798 in Rf_eval (e=0x18d17b0, rho=0x18cfd64) at
> ../../../../R-2.3.0/src/main/eval.c:391
> #12 0x0109d798 in Rf_eval (e=0x18d16b4, rho=0x18cfd64) at
> ../../../../R-2.3.0/src/main/eval.c:391
> #13 0x0109f93c in do_begin (call=0x18d1920, op=0x180a0cc,
> args=0x18d1628, rho=0x18cfd64) at
> ../../../../R-2.3.0/src/main/eval.c:1067
> #14 0x0109d798 in Rf_eval (e=0x18d1920, rho=0x18cfd64) at
> ../../../../R-2.3.0/src/main/eval.c:391
> #15 0x010a0d34 in Rf_applyClosure (call=0x18f8cf4, op=0x18d2580,
> arglist=0x18cfb50, rho=0x18f61ac, suppliedenv=0x181d200) at
> ../../../../R-2.3.0/src/main/eval.c:581
> #16 0x0109d634 in Rf_eval (e=0x18f8cf4, rho=0x18f61ac) at
> ../../../../R-2.3.0/src/main/eval.c:422
> #17 0x0109d66c in Rf_eval (e=0x18d2894, rho=0x18d293c) at
> ../../../../R-2.3.0/src/main/eval.c:370
> #18 0x0109d938 in Rf_eval (e=0x1826b18, rho=0x18d293c) at
> ../../../../R-2.3.0/src/main/eval.c:357
> #19 0x0109f93c in do_begin (call=0x1a37720, op=0x180a0cc,
> args=0x1a38f2c, rho=0x18d293c) at
> ../../../../R-2.3.0/src/main/eval.c:1067
> #20 0x0109d798 in Rf_eval (e=0x1a37720, rho=0x18d293c) at
> ../../../../R-2.3.0/src/main/eval.c:391
> #21 0x0109d798 in Rf_eval (e=0x1a37800, rho=0x18d293c) at
> ../../../../R-2.3.0/src/main/eval.c:391
> #22 0x0109f93c in do_begin (call=0x1a37838, op=0x180a0cc,
> args=0x1a3781c, rho=0x18d293c) at
> ../../../../R-2.3.0/src/main/eval.c:1067
> #23 0x0109d798 in Rf_eval (e=0x1a37838, rho=0x18d293c) at
> ../../../../R-2.3.0/src/main/eval.c:391
> #24 0x010a0d34 in Rf_applyClosure (call=0x18f8cbc, op=0x1a378c4,
> arglist=0x18d28b0, rho=0x18f61ac, suppliedenv=0x181d200) at
> ../../../../R-2.3.0/src/main/eval.c:581
> #25 0x0109d634 in Rf_eval (e=0x18f8cbc, rho=0x18f61ac) at
> ../../../../R-2.3.0/src/main/eval.c:422
> #26 0x0109f87c in do_set (call=0x18f8c68, op=0x180a190,
> args=0x18f8c84, rho=0x18f61ac) at
> ../../../../R-2.3.0/src/main/eval.c:1303
> #27 0x0109d798 in Rf_eval (e=0x18f8c68, rho=0x18f61ac) at
> ../../../../R-2.3.0/src/main/eval.c:391
> #28 0x0109f93c in do_begin (call=0x18f88e8, op=0x180a0cc,
> args=0x18f8c4c, rho=0x18f61ac) at
> ../../../../R-2.3.0/src/main/eval.c:1067
> #29 0x0109d798 in Rf_eval (e=0x18f88e8, rho=0x18f61ac) at
> ../../../../R-2.3.0/src/main/eval.c:391
> #30 0x0109d798 in Rf_eval (e=0x18f9724, rho=0x18f61ac) at
> ../../../../R-2.3.0/src/main/eval.c:391
> #31 0x0109f93c in do_begin (call=0x18f94d8, op=0x180a0cc,
> args=0x18f9708, rho=0x18f61ac) at
> ../../../../R-2.3.0/src/main/eval.c:1067
> #32 0x0109d798 in Rf_eval (e=0x18f94d8, rho=0x18f61ac) at
> ../../../../R-2.3.0/src/main/eval.c:391
> #33 0x0109d798 in Rf_eval (e=0x18fa350, rho=0x18f61ac) at
> ../../../../R-2.3.0/src/main/eval.c:391
> #34 0x0109f93c in do_begin (call=0x18fa174, op=0x180a0cc,
> args=0x18fa334, rho=0x18f61ac) at
> ../../../../R-2.3.0/src/main/eval.c:1067
> #35 0x0109d798 in Rf_eval (e=0x18fa174, rho=0x18f61ac) at
> ../../../../R-2.3.0/src/main/eval.c:391
> #36 0x010a0074 in do_for (call=0x18fa104, op=0x1808958,
> args=0x18fa120, rho=0x18f61ac) at
> .
[Rd] Rmpi instlation problem (PR#8846)
Ive tryed this: R CMD INSTALL Rmpi_0.5-2.tar.gz But occurred this error: gcc -shared -L/usr/local/lib64 -o Rmpi.so conversion.o internal.o RegQuery.o Rmpi.o -lmpi -llam -lutil -lpthread -L/usr/local/lib64/R/lib -lR /usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3/../../../../x86_64-suse-linux/bin /ld: /usr/local/lib/libmpi.a(infoset.o): relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC /usr/local/lib/libmpi.a: could not read symbols: Bad value collect2: ld returned 1 exit status make: *** [Rmpi.so] Error 1 chmod: cannot access `/usr/local/lib64/R/library/Rmpi/libs/*': No such file or directory ERROR: compilation failed for package 'Rmpi' ** Removing '/usr/local/lib64/R/library/Rmpi' May you give me some advice Best EBH Emiliano Barreto_Hernandez Profesor Asociado Colombia EMBnet Node Manager Centro de Bioinformática Instituto de Biotecnología - Universidad Nacional de Colombia Edificio Manuel Ancizar Bogotá - Colombia Tel +57 3165000 ext 16956 Fax +571 3165415 [EMAIL PROTECTED] http://bioinf.ibun.unal.edu.co http://www.co.embnet.org __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rmpi instlation problem (PR#8846)
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --27464147-1443006808-1147172576=:8133 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT First, please do not abuse the bug reporting address to report errors in your own system or in a contributed package: see the FAQ and posting guide. Basic information is missing here, but this looks like a x86_64 version of Linux. The message here is very clear: the error is in /usr/local/lib/libmpi.a. This issue is discussed in the R-admin manual, so please consult it. You need to re-build your installation of MPI as the message suggests. On Tue, 9 May 2006, [EMAIL PROTECTED] wrote: > Ive tryed this: > > R CMD INSTALL Rmpi_0.5-2.tar.gz > > But occurred this error: > > gcc -shared -L/usr/local/lib64 -o Rmpi.so conversion.o internal.o RegQuery.o > Rmpi.o -lmpi -llam -lutil -lpthread -L/usr/local/lib64/R/lib -lR > /usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3/../../../../x86_64-suse-linux/bin > /ld: /usr/local/lib/libmpi.a(infoset.o): relocation R_X86_64_32 can not be > used when making a shared object; recompile with -fPIC > /usr/local/lib/libmpi.a: could not read symbols: Bad value > collect2: ld returned 1 exit status > make: *** [Rmpi.so] Error 1 > chmod: cannot access `/usr/local/lib64/R/library/Rmpi/libs/*': No such file > or directory > ERROR: compilation failed for package 'Rmpi' > ** Removing '/usr/local/lib64/R/library/Rmpi' > > May you give me some advice > > Best > EBH > > > > Emiliano Barreto_Hernandez > Profesor Asociado > Colombia EMBnet Node Manager > Centro de Bioinformática > Instituto de Biotecnología - Universidad Nacional de Colombia > Edificio Manuel Ancizar > Bogotá - Colombia > Tel +57 3165000 ext 16956 Fax +571 3165415 > [EMAIL PROTECTED] > http://bioinf.ibun.unal.edu.co > http://www.co.embnet.org > > __ > 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 --27464147-1443006808-1147172576=:8133-- __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] combn(n, k, ...) and all its re-inventions
Martin Maechler <[EMAIL PROTECTED]> writes:
> tweaks, I have now a version of combn() that is faster than all
> the other implementations {only slightly faster than
> combinations()}, and I plan to add this to R's standard package
> 'utils'.
> Hopefully, the reinventing can be stopped by this, once people
> can rely on a relatively fast implementation of the
> functionality.
>
> One might also consider to include a version of the ``one by
> one'' combination generators {as mentioned above} which is
> needed for larger k.
>
> Opinions ?
While you're in there... combn() has a nice feature that you can apply
a function to each combination, which can be quite useful (and fun) if
you're demonstrating permutation tests:
> x <- combn(20,10,function(i)mean(sleep$extra[i]))
> x <- round(x,2) # this is needed, or you get artifacts
> plot(sort(unique(x)),table(x),type="h")
> plot(sort(x),type="l")
> sum(x <= mean(sleep$extra[1:10])) / length(x)
[1] 0.04072398
However, combn() does its work in sapply() style: First create a list,
then simplify. As this quickly becomes a rather *long* list (e.g., a
slightly larger case with choose(29, 14)==77558760 combinations kills
R for me on a 2GB 64 bit machine), it might be desirable to have an option,
"assume.scalar" or so, to specify that the function always returns a
single scalar.
--
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] Seg fault when installing package from bad repository
On Tue, 9 May 2006, hadley wickham wrote:
> It still segfaults even now that I've fixed the access error. Ah,
> but if I specify type="source", so it must be a problem with having a
> mac binary path but no packages in it.
It seems to be corruption inside the intl library on your machine: note
how the url has been changed to be a file path and the format is an
invalid address. This sort of thing works correctly on my systems:
> download.file("http://ggobi.org/r/bin/macosx/powerpc/contrib/2.2/PACKAGES";,
"/tmp/foo")
trying URL 'http://ggobi.org/r/bin/macosx/powerpc/contrib/2.2/PACKAGES'
Error in
download.file("http://ggobi.org/r/bin/macosx/powerpc/contrib/2.2/PACKAGES";,
:
cannot open URL
'http://ggobi.org/r/bin/macosx/powerpc/contrib/2.2/PACKAGES'
In addition: Warning message:
cannot open: HTTP status was '404 Not Found'
so I surmise it is a MacOS-specific problem.
> Is there anyway to fall back
> to source automatically?
No.
>
> Thanks,
>
> Hadley
>
> On 5/9/06, hadley wickham <[EMAIL PROTECTED]> wrote:
>>> install.packages("rggobi", repos="http://ggobi.org/r/";)
>> Warning in install.packages("rggobi", repos = "http://ggobi.org/r/";) :
>> argument 'lib' is missing: using /Users/hadley/Library/R/library/
>> Reading symbols for shared libraries . done
>>
>> Program received signal EXC_BAD_ACCESS, Could not access memory.
>> Reason: KERN_INVALID_ADDRESS at address: 0x5f4d4550
>> 0x90002f48 in strlen ()
>> (gdb) where
>> #0 0x90002f48 in strlen ()
>> #1 0x9000d7d0 in __vfprintf$LDBL128 ()
>> #2 0x900273cc in vsnprintf$LDBL128 ()
>> #3 0x0108ea1c in Rvsnprintf (buf=0xbfff35f4 "B", size=1000,
>> format=0x3 , ap=0x34 > bounds>) at ../../../../R-2.3.0/src/main/errors.c:211
>> #4 0x01092e68 in Rf_warning (format=0x3 )
>> at ../../../../R-2.3.0/src/main/errors.c:223
>> #5 0x023c39a8 in in_R_HTTPOpen (url=0x212c930
>> "/Library/Frameworks/R.framework/Resources/share/locale/en/LC_MESSAGES/R.mo",
>> cacheOK=404) at
>> ../../../../../R-2.3.0/src/modules/internet/internet.c:490
>> #6 0x023c3f00 in in_do_download (call=0x5f4d4553, op=0xbfff2a03,
>> args=0x195d300, env=0x34) at
>> ../../../../../R-2.3.0/src/modules/internet/internet.c:320
>> #7 0x010b6290 in do_download (call=0x18d0078, op=0x181c2a8,
>> args=0x18c3b50, env=0x18cfd64) at
>> ../../../../R-2.3.0/src/main/internet.c:99
>> #8 0x010cefc4 in do_internal (call=0x18c3b50, op=0xbfff2a03,
>> args=0x0, env=0x18cfd64) at ../../../../R-2.3.0/src/main/names.c:1089
>> #9 0x0109d798 in Rf_eval (e=0x18d0040, rho=0x18cfd64) at
>> ../../../../R-2.3.0/src/main/eval.c:391
>> #10 0x0109f87c in do_set (call=0x18d17b0, op=0x180a190,
>> args=0x18d0008, rho=0x18cfd64) at
>> ../../../../R-2.3.0/src/main/eval.c:1303
>> #11 0x0109d798 in Rf_eval (e=0x18d17b0, rho=0x18cfd64) at
>> ../../../../R-2.3.0/src/main/eval.c:391
>> #12 0x0109d798 in Rf_eval (e=0x18d16b4, rho=0x18cfd64) at
>> ../../../../R-2.3.0/src/main/eval.c:391
>> #13 0x0109f93c in do_begin (call=0x18d1920, op=0x180a0cc,
>> args=0x18d1628, rho=0x18cfd64) at
>> ../../../../R-2.3.0/src/main/eval.c:1067
>> #14 0x0109d798 in Rf_eval (e=0x18d1920, rho=0x18cfd64) at
>> ../../../../R-2.3.0/src/main/eval.c:391
>> #15 0x010a0d34 in Rf_applyClosure (call=0x18f8cf4, op=0x18d2580,
>> arglist=0x18cfb50, rho=0x18f61ac, suppliedenv=0x181d200) at
>> ../../../../R-2.3.0/src/main/eval.c:581
>> #16 0x0109d634 in Rf_eval (e=0x18f8cf4, rho=0x18f61ac) at
>> ../../../../R-2.3.0/src/main/eval.c:422
>> #17 0x0109d66c in Rf_eval (e=0x18d2894, rho=0x18d293c) at
>> ../../../../R-2.3.0/src/main/eval.c:370
>> #18 0x0109d938 in Rf_eval (e=0x1826b18, rho=0x18d293c) at
>> ../../../../R-2.3.0/src/main/eval.c:357
>> #19 0x0109f93c in do_begin (call=0x1a37720, op=0x180a0cc,
>> args=0x1a38f2c, rho=0x18d293c) at
>> ../../../../R-2.3.0/src/main/eval.c:1067
>> #20 0x0109d798 in Rf_eval (e=0x1a37720, rho=0x18d293c) at
>> ../../../../R-2.3.0/src/main/eval.c:391
>> #21 0x0109d798 in Rf_eval (e=0x1a37800, rho=0x18d293c) at
>> ../../../../R-2.3.0/src/main/eval.c:391
>> #22 0x0109f93c in do_begin (call=0x1a37838, op=0x180a0cc,
>> args=0x1a3781c, rho=0x18d293c) at
>> ../../../../R-2.3.0/src/main/eval.c:1067
>> #23 0x0109d798 in Rf_eval (e=0x1a37838, rho=0x18d293c) at
>> ../../../../R-2.3.0/src/main/eval.c:391
>> #24 0x010a0d34 in Rf_applyClosure (call=0x18f8cbc, op=0x1a378c4,
>> arglist=0x18d28b0, rho=0x18f61ac, suppliedenv=0x181d200) at
>> ../../../../R-2.3.0/src/main/eval.c:581
>> #25 0x0109d634 in Rf_eval (e=0x18f8cbc, rho=0x18f61ac) at
>> ../../../../R-2.3.0/src/main/eval.c:422
>> #26 0x0109f87c in do_set (call=0x18f8c68, op=0x180a190,
>> args=0x18f8c84, rho=0x18f61ac) at
>> ../../../../R-2.3.0/src/main/eval.c:1303
>> #27 0x0109d798 in Rf_eval (e=0x18f8c68, rho=0x18f61ac) at
>> ../../../../R-2.3.0/src/main/eval.c:391
>> #28 0x0109f93c in do_begin (call=0x18f88e8, op=0x180a0cc,
>> args=0x18f8c4c, rho=0x18f61ac) at
>> ../../../../R-2.3.0/src/main/eval.c:1067
>> #29 0x0109d798 in Rf_eval (e=0x18f88e8, rho=0x18f61ac) at
>> ../
Re: [Rd] "Unfelicity" :-) with edit()
[Duncan Murdoch]
>I'll fix it.
Thanks, Duncan. While I quite understand that more serious work should
be done within real sources files, fixing and editing is still useful
for quick, evanescent interactive toying.
>edit() is a hack, so you should expect problems. You're better off
>keeping your source in an editor and using source() to get it.
This is not the first time I read such a remark. Maybe it would be
worth a note within ?edit.
>There is no way it could preserve the environment of a function [...]
That might be worth another note within ?edit.
Speaking of which, this "x <- edit()" usage (interactively suggested by
fix when it fails to re-parse the result of edition) is not covered by
?edit. I mean that by reading ?edit, one does not get information about
what a mere "edit()" does. It might be useful that ?edit says a few
words about this particular usage.
The remaining of this message quotes the original message:
[François Pinard]
>Hi, people. This is about R 2.3.0 under Linux.
>It seems that edit() may change a function environment. Here is
>a transcript, more comments follow:
>==>
>>fix(f)
>>f
>function ()
>{
>}
>>fix(f)
>Erreur dans edit(name, file, title, editor) :
> une erreur s'est produite à la ligne 3
> utilisez une commande du genre
> x <- edit()
> pour corriger
>>f <- edit()
>>f
>function ()
>{
>}
>
>==<
>The initial ``fix(f)`` called an editor, which I exited right away. For
>the second ``fix(f)``, I used the editor for adding a slash between
>braces, and exited. The French comment produced by R speaks about an
>error at line 3 and suggests using something like ``x <- edit()`` to
>make a correction. On the third call to the editor, I remove the slash
>and exit. Now, the environment of the function became "base".
>This has unfortunate effects when editing a more substantial function,
>because for example, "stats" or "utils" is not readily available anymore
>after the editing. Is it reasonable to suggest an improvement in the
>mechanics of edit(), for alleviating this drawback ?
--
François Pinard http://pinard.progiciels-bpi.ca
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] "Unfelicity" :-) with edit()
On 5/9/2006 9:17 AM, François Pinard wrote:
> [Duncan Murdoch]
>
>>I'll fix it.
>
> Thanks, Duncan. While I quite understand that more serious work should
> be done within real sources files, fixing and editing is still useful
> for quick, evanescent interactive toying.
>
>>edit() is a hack, so you should expect problems. You're better off
>>keeping your source in an editor and using source() to get it.
>
> This is not the first time I read such a remark. Maybe it would be
> worth a note within ?edit.
>
>>There is no way it could preserve the environment of a function [...]
>
> That might be worth another note within ?edit.
>
> Speaking of which, this "x <- edit()" usage (interactively suggested by
> fix when it fails to re-parse the result of edition) is not covered by
> ?edit. I mean that by reading ?edit, one does not get information about
> what a mere "edit()" does. It might be useful that ?edit says a few
> words about this particular usage.
Yes, it probably would be. Just to clarify: fix(f) *does* preserve the
environment of f, but
fix(f) # introduce a syntax error
f <- edit()
does not.
Duncan Murdoch
>
> The remaining of this message quotes the original message:
>
> [François Pinard]
>>Hi, people. This is about R 2.3.0 under Linux.
>
>>It seems that edit() may change a function environment. Here is
>>a transcript, more comments follow:
>
>>==>
>>>fix(f)
>
>>>f
>>function ()
>>{
>>}
>
>>>fix(f)
>>Erreur dans edit(name, file, title, editor) :
>> une erreur s'est produite à la ligne 3
>> utilisez une commande du genre
>> x <- edit()
>> pour corriger
>
>>>f <- edit()
>
>>>f
>>function ()
>>{
>>}
>>
>>==<
>
>>The initial ``fix(f)`` called an editor, which I exited right away. For
>>the second ``fix(f)``, I used the editor for adding a slash between
>>braces, and exited. The French comment produced by R speaks about an
>>error at line 3 and suggests using something like ``x <- edit()`` to
>>make a correction. On the third call to the editor, I remove the slash
>>and exit. Now, the environment of the function became "base".
>
>>This has unfortunate effects when editing a more substantial function,
>>because for example, "stats" or "utils" is not readily available anymore
>>after the editing. Is it reasonable to suggest an improvement in the
>>mechanics of edit(), for alleviating this drawback ?
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] suppressing "global" cppflags in an individual package
Kasper Daniel Hansen wrote: > Hi > > I can use PKG_CPPFLAGS in a Makevars file to add additional flags to > the c++ compiler for a given package. Is it possible to remove flags > passed to the packages from R. Eg: say R have been compiled with -O2 > and I want the package to be compiled with another optimization level? Do you mean the flags passed to the c++ compiler (CXXFLAGS) or to the C proprocessor (CPPFLAGS)? Do not confuse the two. I think the "proper" way would be to write a full makefile. (there are plenty of examples on CRAN). Now, out of curiosity - why would you want to do that? The actual difference in CPU time usage is often small (10%?), so unless the package triggers a compiler bug at specific optimization level and gets mis-compiled, it is probably not worth the trouble. And if the package is that sensitive to optimization level and can get mis-compiled, one of them (the package or the compiler) needs fixing. HTL __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] suppressing "global" cppflags in an individual package
On May 9, 2006, at 9:49 AM, Hin-Tak Leung wrote: > Kasper Daniel Hansen wrote: >> Hi >> I can use PKG_CPPFLAGS in a Makevars file to add additional flags >> to the c++ compiler for a given package. Is it possible to remove >> flags passed to the packages from R. Eg: say R have been compiled >> with -O2 and I want the package to be compiled with another >> optimization level? > > Do you mean the flags passed to the c++ compiler (CXXFLAGS) or > to the C proprocessor (CPPFLAGS)? Do not confuse the two. Hmm good point. I think I have indeed confused the two. > I think the "proper" way would be to write a full makefile. > (there are plenty of examples on CRAN). I would like to avoid this, see below. > Now, out of curiosity - why would you want to do that? The actual > difference in CPU time usage is often small (10%?), so unless the > package triggers a compiler bug at specific optimization level and > gets mis-compiled, it is probably not worth the trouble. And if > the package is that sensitive to optimization level and can get mis- > compiled, one of them (the package or the compiler) needs fixing. It is indeed the case that after updating to GCC 4 the package gets broken using -O2. I agree this needs to be fixed, but the error (which I believe I have kind of localized, but not really understood) stems from a C++ library we have little control over, so it would be nice to have a fix for the time being that does not require a reinstallation of R - especially since we actually have users who currently (or soon will be) testing it. I was thus looking for a temporary quick fix allowing me to disable the optimization level, while I take the time to fix it properly. Kurt Hornik have replied of-list that it is possible to do so using a ~/.R/Makevars file (which I have not had the time to test unfortunately), but reading your comment about CPPFLAGS and CXXFLAGS makes me think I can indeed override it using the package Makevars file. The flags I was passing to the compiler were library locations anyway which was for the preprocessor. Thanks for the help, Kasper > HTL __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] YA S4 method dispatch question
I recently encountered this and was wondering if someone
could explain what happened. Basis of question involves
what the difference between the calls makes as the end
result is the same:
> identical(matrix(1:8, nrow = 1), array(1:8, c(1, 8)))
TRUE
If I run the code below as shown, I get the following:
> foo(1:8, 4)
foo (vector, numeric)
val = 4
foo (matrix, ANY)
val = 500
foo (matrix, numeric)
val = 500
[1] 500 500 500 500 500 500 500 500
Exchanging the current return for one of the commented ones
(HERE) yields the expected answer:
> foo(1:8, 4)
foo (vector, numeric)
val = 4
foo (matrix, numeric)
val = 4
[1] 4 4 4 4 4 4 4 4
When invoked with array(), it loses track of the second
parameter and gives the wrong answer. While it would seem
to have something to do with the first parameter's
evaluation time, I don't follow why one works and the other
doesn't. Forcing the evaluation via assignment (third case)
also provides the correct result.
Example code follows:
##--
library(methods)
setGeneric("foo",
function(x, val = 500) {
standardGeneric("foo")
})
setMethod("foo",
signature(x = "vector", val = "numeric"),
function(x, val) {
cat(match.call()[[1]], "(vector, numeric)", "\n")
cat("\t", "val =", val, "\n")
## HERE ##
# return(drop(callGeneric(matrix(x, nrow = 1), val)))
return(drop(callGeneric(array(x, c(1, length(x)), val
# return(drop(callGeneric(xm <- array(x, c(1, length(x))), val)))
})
setMethod("foo",
signature(x = "vector"),
function(x, val) {
cat(match.call()[[1]], "(vector, ANY)", "\n")
callGeneric(x, val)
})
setMethod("foo",
signature(x = "matrix", val = "numeric"),
function(x, val) {
cat(match.call()[[1]], "(matrix, numeric)", "\n")
cat("\t", "val =", val, "\n")
return(apply(x, c(1, 2), function(m, v) { m <- v }, val))
})
setMethod("foo",
signature(x = "matrix"),
function(x, val) {
cat(match.call()[[1]], "(matrix, ANY)", "\n")
cat("\t", "val =", val, "\n")
callGeneric(x, val)
})
setMethod("foo",
signature(x = "array"),
function(x, val) {
cat(match.call()[[1]], "(array, ANY)", "\n")
stop(sprintf("method not defined for %s argument",
data.class(x)))
})
setMethod("foo",
signature(x = "ANY"),
function(x, val) {
cat(match.call()[[1]], "(ANY, ANY)", "\n")
stop(sprintf("method not defined for %s argument",
data.class(x)))
})
--
SIGSIG -- signature too long (core dumped)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] suppressing "global" cppflags in an individual package
On May 9, 2006, at 1:11 PM, Kasper Daniel Hansen wrote: > It is indeed the case that after updating to GCC 4 the package > gets broken using -O2. I agree this needs to be fixed, but the error > [...] > unfortunately), but reading your comment about CPPFLAGS and > CXXFLAGS makes me think I can indeed override it using the package > Makevars file. The flags I was passing to the compiler were library > locations anyway which was for the preprocessor. > AFAIR you cannot override CPPFLAGS/CXXFLAGS in Makevars, because it gets included first. You can, however, use something like this: all: $(SHLIB) MYCFLAGS=-O0 %.o: %.c $(CC) $(ALL_CPPFLAGS) $(ALL_CFLAGS) $(MYCFLAGS) -c $< -o $@ for C, or for C++ accordingly: %.o: %.cc $(CXX) $(ALL_CPPFLAGS) $(ALL_CXXFLAGS) $(MYCXXFLAGS) -c $< - o $@ However, don't ask me how portable this is ;). It exploits the fact that old-style rules .c.o used by Makeconf are overridden by the new- style rules regardless of their position. Nevertheless, you could still use specific rules if desired without a full-blown Makefile. (I always recommend the use of Makevars as far as possible, because most writers of Makefiles get the shlib compilation wrong). Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] RFC: log='z' for image, contour, persp?
I've been thinking of adding the possibility of including "z" among the axes to be logged in image, contour, and persp. In the first two, it would only affect where the breaks were set if they are calculated automatically; it would have a bigger effect in persp. For example, image(x, y, z, log="z") would set 12 colours evenly spaced on a log scale of the z values. (12 because that's the default). We already support image(x, y, z, log="x") to scale the x axis (though there's a spurious warning; I'll fix that). image(z, log="x") fails because it tries to take a log of zero. Does it seem like a good idea for these 3D functions to support log="z" the way 2D functions do? Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] YA S4 method dispatch question
You won't like this ...;)
return(drop(callGeneric(array(x,
c(1, length(x)),
val)
)))
i.e., 'val' is inside 'array'!
I was discouraged from answering sooner by the complexity of your
example; simplifying it might have provided an immediate answer...
> x <- 1:8
> foo(array(x, c(1,length(x)), val)
+
! Martin
Paul Roebuck <[EMAIL PROTECTED]> writes:
> I recently encountered this and was wondering if someone
> could explain what happened. Basis of question involves
> what the difference between the calls makes as the end
> result is the same:
>
>> identical(matrix(1:8, nrow = 1), array(1:8, c(1, 8)))
> TRUE
>
> If I run the code below as shown, I get the following:
>
>> foo(1:8, 4)
> foo (vector, numeric)
>val = 4
> foo (matrix, ANY)
>val = 500
> foo (matrix, numeric)
>val = 500
> [1] 500 500 500 500 500 500 500 500
>
> Exchanging the current return for one of the commented ones
> (HERE) yields the expected answer:
>
>> foo(1:8, 4)
> foo (vector, numeric)
>val = 4
> foo (matrix, numeric)
>val = 4
> [1] 4 4 4 4 4 4 4 4
>
>
> When invoked with array(), it loses track of the second
> parameter and gives the wrong answer. While it would seem
> to have something to do with the first parameter's
> evaluation time, I don't follow why one works and the other
> doesn't. Forcing the evaluation via assignment (third case)
> also provides the correct result.
>
> Example code follows:
>
>
> ##--
> library(methods)
>
> setGeneric("foo",
>function(x, val = 500) {
>standardGeneric("foo")
>})
>
> setMethod("foo",
> signature(x = "vector", val = "numeric"),
> function(x, val) {
> cat(match.call()[[1]], "(vector, numeric)", "\n")
> cat("\t", "val =", val, "\n")
> ## HERE ##
> # return(drop(callGeneric(matrix(x, nrow = 1), val)))
> return(drop(callGeneric(array(x, c(1, length(x)), val
> # return(drop(callGeneric(xm <- array(x, c(1, length(x))), val)))
> })
>
> setMethod("foo",
> signature(x = "vector"),
> function(x, val) {
> cat(match.call()[[1]], "(vector, ANY)", "\n")
> callGeneric(x, val)
> })
>
> setMethod("foo",
> signature(x = "matrix", val = "numeric"),
> function(x, val) {
> cat(match.call()[[1]], "(matrix, numeric)", "\n")
> cat("\t", "val =", val, "\n")
> return(apply(x, c(1, 2), function(m, v) { m <- v }, val))
> })
>
> setMethod("foo",
> signature(x = "matrix"),
> function(x, val) {
> cat(match.call()[[1]], "(matrix, ANY)", "\n")
> cat("\t", "val =", val, "\n")
> callGeneric(x, val)
> })
>
> setMethod("foo",
> signature(x = "array"),
> function(x, val) {
> cat(match.call()[[1]], "(array, ANY)", "\n")
> stop(sprintf("method not defined for %s argument",
> data.class(x)))
> })
>
> setMethod("foo",
> signature(x = "ANY"),
> function(x, val) {
> cat(match.call()[[1]], "(ANY, ANY)", "\n")
> stop(sprintf("method not defined for %s argument",
> data.class(x)))
> })
>
> --
> SIGSIG -- signature too long (core dumped)
>
> __
> 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, Rcmdr crash on WinXP PRO laptop (PR#8583)
I think I might have a workaround now. Originally I had all the scripts on my desktop, so I came to think about if the problem is with the shortcuts to the other programs or to My computer or something like that. I put all the scripts to a folder which is still on my desktop, and I haven't experienced any crashes since. My best guess is that it is an explorer/graphics card related issue. JE __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
