[Rd] indexing and regression testing
Dear all,
It was a pleasure to meet you at Iowa State University. Two days ago I
submitted two experimental packages to CRAN (hope it will be there soon):
rindex: quick indexing of large objects (currently only character, see ?index)
regtest: some first support for automated regression testing (heavily used in
\dontshow{} section of ?index)
With rindex you can for example
i <- index(rownames(someDataFrame))
# then this
someDataFrame[match(fewRowNames, i),]
# is much faster than that
someDataFrame[match(fewRowNames, rownames(someDataFrame)),]
# which still is much faster than
someDataFrame[fewRowNames, ]
# the latter being surprisingly slow as it can be worked around by match (even
without indexing)
I'd appreciate any comments, especially on the "Open Questions" secion in
?index, in order to
1) extend to all atomic types and be UTF8-safe
2) extend to packages R.huge and/or ff
3) optimally integrate with sort(OK), order(no generic yet) and match(no
generic and dispatch rather needed on second argument)
Both packages were developed under 2.5.1 and I plan to publish them under a
GPL2-QA, a GPL2 clone that obliges users to participate in some kind of
regression testing (to be defined).
Best regards
Jens Oehlschlägel
P.S.
> # some timings using timefactor(regtest)
> library(rindex)
>
> Vec1 <- c(NA, paste('a', 1:100, sep=""))
> Vec2 <- c(paste('a', 1:100, sep=""), NA)
> iVec1 <- index(Vec1, verbose=TRUE)
user.self sys.self elapsed
sort 7.85 0.017.86
tree 0.00 0.000.00
> iVec2 <- index(Vec2, verbose=TRUE)
finalized tree
user.self sys.self elapsed
sort 7.7807.79
tree 0.0000.00
>
> timefactor(any(Vec1=="a999"), any(iVec1=="a999"), 10, 100)
finalized tree
nom denom factor
user.self 0.041 0.0036 11.38889
sys.self 0.000 0. NaN
elapsed 0.041 0.0036 11.38889
> timefactor(any(Vec2=="a999"), any(iVec2=="a999"), 10, 100)
nom denom factor
user.self 0.040 0.0036 11.1
sys.self 0.000 0. NaN
elapsed 0.041 0.0036 11.38889
>
> timefactor(length(match("a999", Vec1)), length(match("a999", iVec1)), 10,
> 1000)
nom denom factor
user.self 0.125 0.00017 735.2941
sys.self 0.000 0.0 NaN
elapsed 0.125 0.00018 694.
> timefactor(length(match("a999", Vec2)), length(match("a999", iVec2)), 10,
> 1000)
nom denom factor
user.self 0.123 0.00015 820.
sys.self 0.003 0.0 Inf
elapsed 0.127 0.00015 846.6667
>
> timefactor(length(match(c("a9","a99","a999","a"), Vec1)),
> length(match(c("a9","a99","a999","a"), iVec1)), 10, 1000)
nom denom factor
user.self 0.126 0.00022 572.7273
sys.self 0.000 0.0 NaN
elapsed 0.127 0.00022 577.2727
> timefactor(length(match(c("a9","a99","a999","a"), Vec2)),
> length(match(c("a9","a99","a999","a"), iVec2)), 10, 1000)
nom denom factor
user.self 0.125 0.00022 568.1818
sys.self 0.002 0.0 Inf
elapsed 0.126 0.00022 572.7273
>
> # and not too bad with respect to the recent hasNA() / anyNA() thread (once
> the index has been built)
> timefactor(any(is.na(Vec1)), any(is.na(iVec1)), 50, 50)
nom denom factor
user.self 0.0040 0.003 1.33
sys.self 0.0004 0.000 Inf
elapsed 0.0044 0.003 1.47
> timefactor(any(is.na(Vec2)), any(is.na(iVec2)), 50, 50)
nom denom factor
user.self 0.0040 0.0036 1.11
sys.self 0.0008 0. Inf
elapsed 0.0046 0.0034 1.352941
>
> # especially if using a better function for this
> timefactor(any(is.na(Vec1)), length(match(NA, iVec1)), 50, 1000)
nom denom factor
user.self 0.0044 0.00013 33.84615
sys.self 0.0002 0.0 Inf
elapsed 0.0046 0.00013 35.38462
> timefactor(any(is.na(Vec2)), length(match(NA, iVec2)), 50, 1000)
nom denom factor
user.self 0.0044 0.00014 31.42857
sys.self 0. 0.0 NaN
elapsed 0.0042 0.00014 30.0
>
> # or ask directly :-)
> timefactor(any(is.na(Vec1)), iVec1$nNA, 50, 1)
nom denom factor
user.self 0.0044 9e-06 488.8889
sys.self 0. 0e+00 NaN
elapsed 0.0044 9e-06 488.8889
> timefactor(any(is.na(Vec2)), iVec2$nNA, 50, 1)
nom denom factor
user.self 0.0046 1e-05 460.
sys.self 0. 0e+00 NaN
elapsed 0.0046 9e-06 511.
>
> version
_
platform i386-pc-mingw32
arch i386
os mingw32
system i386, mingw32
status
major 2
minor 5.1
year 2007
month 06
day27
svn rev42083
language R
version.string R versio
Re: [Rd] paste() with NAs .. change worth persuing?
On 22 Aug 2007, at 20:16, Duncan Murdoch wrote:
> On 8/22/2007 11:50 AM, Martin Maechler wrote:
>> Consider this example code
>>
>> c1 <- letters[1:7]; c2 <- LETTERS[1:7]
>> c1[2] <- c2[3:4] <- NA
>> rbind(c1,c2)
>>
>> ## [,1] [,2] [,3] [,4] [,5] [,6] [,7]
>> ## c1 "a" NA "c" "d" "e" "f" "g"
>> ## c2 "A" "B" NA NA "E" "F" "G"
>>
>> paste(c1,c2)
>>
>> ## -> [1] "a A" "NA B" "c NA" "d NA" "e E" "f F" "g G"
>>
>> where a more logical result would have entries 2:4 equal to
>> NA
>> i.e., as.character(NA)
>> akaNA_character_
>>
>> Is this worth persuing, or does anyone see why not?
>
> A fairly common use of paste is to put together reports for human
> consumption. Currently we have
>
>> p <- as.character(NA)
>> paste("the value of p is", p)
> [1] "the value of p is NA"
>
> which looks reasonable. Would this become
>
>> p <- as.character(NA)
>> paste("the value of p is", p)
> [1] NA
>
> under your proposal? (In a quick search I was unable to find a real
> example where this would happen, but it would worry me...)
At least stop() seems to include such a case:
message <- paste(args, collapse = "")
and we may expect there are NAs sometimes in stop().
cheers, jazza
--
Jari Oksanen, Oulu, Finland
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] nls fails with large numbers of variables (PR#9873)
Full_Name: Yan Wong
Version: 2.5.1
OS: Mac OS X 10.4
Submission from: (NULL) (129.11.77.198)
If nls is called with a large number of variables & parameters (>200), then it
fails because of the default setting of max.names = 200 in the all.vars
function. I guess that nls should either give a meaningful warning ("you can
only have 200 names in an nls formula"), or should not have such a restriction.
If this restriction is kept, for my purposes it would be useful to have a way of
setting max.names in the nls call.
I encountered this in a real dataset, but an example
> #nls fails on 100 vars+ 100 params
> d<-data.frame(matrix(runif(100*1000), 1000, 100))
> y <- rowSums(d)+rnorm(1000)
> params <- paste("c", colnames(d), sep=".")
> st <- rep(1,100); names(st) <- params
> nls(as.formula(paste("y ~", paste(params, "*", colnames(d), collapse=" + "))),
data=d, start=st)
Error in eval(expr, envir, enclos) : object "X100" not found
> #works with 50 vars+ 50 params
> d<-data.frame(matrix(runif(100*1000), 1000, 50))
> y <- rowSums(d)+rnorm(1000)
> params <- paste("c", colnames(d), sep=".")
> st <- rep(1,50); names(st) <- params
> nls(as.formula(paste("y ~", paste(params, "*", colnames(d), collapse=" + "))),
data=d, start=st)
Nonlinear regression model
model: y ~ c.X1 * X1 + c.X2 * X2 + c.X3 * X3 + c.X4 * X4 + c.X5 * X5 +
c.X6 * X6 + c.X7 * X7 + c.X8 * X8 + c.X9 * X9 + c.X10 * X10 + c.X11 * X11 +
c.X12 * X12 + c.X13 * X13 + c.X14 * X14 + c.X15 * X15 + c.X16 * X16 + c.X17
* X17 + c.X18 * X18 + c.X19 * X19 + c.X20 * X20 + c.X21 * X21 + c.X22 * X22
+ c.X23 * X23 + c.X24 * X24 + c.X25 * X25 + c.X26 * X26 + c.X27 * X27 +
c.X28 * X28 + c.X29 * X29 + c.X30 * X30 + c.X31 * X31 + c.X32 * X32 + c.X33
* X33 + c.X34 * X34 + c.X35 * X35 + c.X36 * X36 + c.X37 * X37 + c.X38
* X38 + c.X39 * X39 + c.X40 * X40 + c.X41 * X41 + c.X42 * X42 + c.X43 * X43
+ c.X44 * X44 + c.X45 * X45 + c.X46 * X46 + c.X47 * X47 + c.X48 * X48 +
c.X49 * X49 + c.X50 * X50
data: d
c.X1 c.X2 c.X3 c.X4 c.X5 c.X6 c.X7 c.X8 c.X9 c.X10 c.X11
c.X12 c.X13 c.X14 c.X15 c.X16 c.X17 c.X18 c.X19 c.X20 c.X21 c.X22
c.X23
0.9400 0.9750 0.9614 1.1029 0.9663 1.1426 1.1534 1.0353 1.0560 0.8258 0.9527
1.1092 0.4769 0.8955 1.0689 0.7415 1.0656 1.0657 1.0430 1.1034 0.9392 1.1177
1.0712
c.X24 c.X25 c.X26 c.X27 c.X28 c.X29 c.X30 c.X31 c.X32 c.X33 c.X34
c.X35 c.X36 c.X37 c.X38 c.X39 c.X40 c.X41 c.X42 c.X43 c.X44 c.X45
c.X46
0.8883 0.9722 1.1377 1.1142 0.9033 1.1225 0.7447 1.2757 0.8746 1.1901 1.1669
1.0322 0.9043 1.0546 1.0222 0.9641 1.0834 0.9977 1.0723 0.9720 1.0978 0.9222
0.8162
c.X47 c.X48 c.X49 c.X50
0.8824 1.0690 1.0078 0.9063
residual sum-of-squares: 959.4
Number of iterations to convergence: 1
Achieved convergence tolerance: 1.215e-07
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] paste() with NAs .. change worth persuing?
On Wed, Aug 22, 2007 at 08:53:39PM +0300, Jari Oksanen wrote:
>
> On 22 Aug 2007, at 20:16, Duncan Murdoch wrote:
> > A fairly common use of paste is to put together reports for human
> > consumption. Currently we have
> >
> >> p <- as.character(NA)
> >> paste("the value of p is", p)
> > [1] "the value of p is NA"
> >
> > which looks reasonable. Would this become
> >
> >> p <- as.character(NA)
> >> paste("the value of p is", p)
> > [1] NA
> >
> > under your proposal? (In a quick search I was unable to find a real
> > example where this would happen, but it would worry me...)
>
> At least stop() seems to include such a case:
>
> message <- paste(args, collapse = "")
>
> and we may expect there are NAs sometimes in stop().
The examples show, that changing the behavior of paste in general
may not be appropriate. On the other hand, if we concatenate
character vectors, which are part of data, then is.na(paste(...,NA,...))
makes sense. Character vectors in data are usually represented
by factors. On the other hand, factors are not typical in cases,
where paste is used to produce a readable message. Hence, it
could be possible to have is.na(u[i]) for those i, for which
some of the vectors v1, ..., vn in
u <- paste(v1,,vn)
is a factor and has NA at i-th position.
Petr Savicky.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] nls fails with large numbers of variables (PR#9873)
This is fixed in the current R-devel.
On Wed, 22 Aug 2007, [EMAIL PROTECTED] wrote:
> Full_Name: Yan Wong
> Version: 2.5.1
> OS: Mac OS X 10.4
> Submission from: (NULL) (129.11.77.198)
>
>
> If nls is called with a large number of variables & parameters (>200), then it
> fails because of the default setting of max.names = 200 in the all.vars
> function. I guess that nls should either give a meaningful warning ("you can
> only have 200 names in an nls formula"), or should not have such a
> restriction.
> If this restriction is kept, for my purposes it would be useful to have a way
> of
> setting max.names in the nls call.
>
> I encountered this in a real dataset, but an example
>
>> #nls fails on 100 vars+ 100 params
>> d<-data.frame(matrix(runif(100*1000), 1000, 100))
>> y <- rowSums(d)+rnorm(1000)
>> params <- paste("c", colnames(d), sep=".")
>> st <- rep(1,100); names(st) <- params
>> nls(as.formula(paste("y ~", paste(params, "*", colnames(d), collapse=" +
>> "))),
> data=d, start=st)
> Error in eval(expr, envir, enclos) : object "X100" not found
>
>
>> #works with 50 vars+ 50 params
>> d<-data.frame(matrix(runif(100*1000), 1000, 50))
>> y <- rowSums(d)+rnorm(1000)
>> params <- paste("c", colnames(d), sep=".")
>> st <- rep(1,50); names(st) <- params
>> nls(as.formula(paste("y ~", paste(params, "*", colnames(d), collapse=" +
>> "))),
> data=d, start=st)
> Nonlinear regression model
> model: y ~ c.X1 * X1 + c.X2 * X2 + c.X3 * X3 + c.X4 * X4 + c.X5 * X5 +
> c.X6 * X6 + c.X7 * X7 + c.X8 * X8 + c.X9 * X9 + c.X10 * X10 + c.X11 *
> X11 +
> c.X12 * X12 + c.X13 * X13 + c.X14 * X14 + c.X15 * X15 + c.X16 * X16 +
> c.X17
> * X17 + c.X18 * X18 + c.X19 * X19 + c.X20 * X20 + c.X21 * X21 + c.X22 *
> X22
> + c.X23 * X23 + c.X24 * X24 + c.X25 * X25 + c.X26 * X26 + c.X27 * X27 +
> c.X28 * X28 + c.X29 * X29 + c.X30 * X30 + c.X31 * X31 + c.X32 * X32 +
> c.X33
> * X33 + c.X34 * X34 + c.X35 * X35 + c.X36 * X36 + c.X37 * X37 +
> c.X38
> * X38 + c.X39 * X39 + c.X40 * X40 + c.X41 * X41 + c.X42 * X42 + c.X43 *
> X43
> + c.X44 * X44 + c.X45 * X45 + c.X46 * X46 + c.X47 * X47 + c.X48 * X48 +
> c.X49 * X49 + c.X50 * X50
> data: d
> c.X1 c.X2 c.X3 c.X4 c.X5 c.X6 c.X7 c.X8 c.X9 c.X10 c.X11
> c.X12 c.X13 c.X14 c.X15 c.X16 c.X17 c.X18 c.X19 c.X20 c.X21 c.X22
> c.X23
> 0.9400 0.9750 0.9614 1.1029 0.9663 1.1426 1.1534 1.0353 1.0560 0.8258 0.9527
> 1.1092 0.4769 0.8955 1.0689 0.7415 1.0656 1.0657 1.0430 1.1034 0.9392 1.1177
> 1.0712
> c.X24 c.X25 c.X26 c.X27 c.X28 c.X29 c.X30 c.X31 c.X32 c.X33 c.X34
> c.X35 c.X36 c.X37 c.X38 c.X39 c.X40 c.X41 c.X42 c.X43 c.X44 c.X45
> c.X46
> 0.8883 0.9722 1.1377 1.1142 0.9033 1.1225 0.7447 1.2757 0.8746 1.1901 1.1669
> 1.0322 0.9043 1.0546 1.0222 0.9641 1.0834 0.9977 1.0723 0.9720 1.0978 0.9222
> 0.8162
> c.X47 c.X48 c.X49 c.X50
> 0.8824 1.0690 1.0078 0.9063
> residual sum-of-squares: 959.4
>
> Number of iterations to convergence: 1
> Achieved convergence tolerance: 1.215e-07
>
> __
> 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] compiling R under cygwin
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Prof Brian Ripley > Sent: Thursday, August 23, 2007 2:54 AM > To: Denham Robert > Cc: r-devel@r-project.org; Duncan Murdoch > Subject: Re: [Rd] compiling R under cygwin > > On Thu, 23 Aug 2007, Denham Robert wrote: > > >>> For various reasons, > >> I think it is only courteous to mention some good reasons > if you want > > to take up people's time. > > > > Some of the reasons we would like a cygwin version aren't > necessarily > > good reasons. We have been using cygwin for sometime, > mostly to deal > > with scripting in a combined windows/unix environment. We have a > > setup which allows windows users to run many scripts in the > same way > > as unix users. These scripts are often python or shell > scripts. We > > have R installed on the unix machines, and the system > administrators > > would like to be able to have R on windows in the same > environment. > > This set up also means that the administrator can fairly easily > > maintain the version of software used on all user's machines. > > Probably this could all be managed and still use the native windows > > version of R, but the administrator is familiar with cygwin > and they > > could manage this software in the same way they manage > other packages. > > Yes, it could almost certainly be done with Rterm.exe. > > The issue I came across was the so-called 'posix file paths' > that Cygwin uses. Most (but not all) Windows programs accept > file paths with / as the path separator, and most (but not > all, e.g. tar) Cygwin programs accept paths of the forn > c:/path/to/file. So provided you use that as your format, > interworking with Unix and Unix-like shells work fine. It > used to be the case that if you had just one drive C: then > Cygwin programs produced paths of the form /path/to/file that > also worked on Windows. Now they produce > /cygdrive/c/path/to/file that works nowhere else. I'm not sure what you mean by "produce" above but one can easily setup (by mount option) cygwin to use "/" instead of "/cygdrive/" so that your example above will become "/c/path/to/file". That's if you insist on using drive letters. Otherwise w/ proper mounting (in cygwin) one can have "usual" *nix dir tree. Regards, Latchezar PS. I really like the idea of having (the same) bare terminal/command window interface to R anywhere as well as anything else (like admin tasks above) to be the same. So please put my vote (if you care) to have R Windows installation look the same as *nix (up to the point when you start R from Start button to have terminal version started instead of Rgui as it is now) and keep GUI candies separately for whoever wants/needs them. Sorry if that's been already done and I did not know about it. > > In general this is a minor nuisance, but I needed to be able > to cross-build R in an environment where I only have > Cygwin-based cross-compilers, and there the path issues bit > me: I needed a version of R that accepted and returned > Cygwin-style paths. So I made the configure changes > necessary to build R under Cygwin, and had it running in 20 mins. > > > We would like to be able to use linux machines on pc's but > > unfortunately we have restrictions imposed on us that > prevent this. > > This restriction also goes as far as the use of virtual > machines. My > > personal preference would be to run linux on my work pc, and use a > > virtual machine to run windows software, such as ArcGIS and > Imagine, > > that are not available for linux. This does not seem to be > an option for us. > > > > One thing I was interested in was knowing if there are > others who also > > would like a cygwin version. From the replies to my post, > and from a > > search of the mailing list archive, I think that there is little > > demand for this. We would, however, be prepared to help in > some way > > for the few people who are interested. > > As I said earlier, it builds out of the box in R-devel (with > suitable options documented in the R-admin manual). No > guarantees that it will continue to do so unless tested in > the alpha/beta phase though. As no other platform we use > nowadays requires that shared objects/dynamic libraries have > all imports satisfied at build time, this is liable to get broken. > > But I would encourage people to use Rterm.exe if it can be > made to do what you need. > > > > > > > > > > Robert Denham > > Environmental Statistician > > Remote Sensing Centre > > Telephone 07 3896 9899 > > www.nrw.qld.gov.au > > > > Department of Natural Resources & Water > > QScape Building, 80 Meiers Road, Indooroopilly Qld 4068 > > > > -Original Message- > > From: Prof Brian Ripley [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, 21 August 2007 9:53 PM > > To: Duncan Murdoch > > Cc: Denham Robert; r-devel@r-project.org > > Subject: Re: [Rd] compiling R under cygwin > >
Re: [Rd] compiling R under cygwin
Having it be the same under cygwin as it is for other UNIX systems would be ok but for the native Windows port R should behave like other Windows applications, not like UNIX applications. On 8/23/07, Latchezar (Lucho) Dimitrov <[EMAIL PROTECTED]> wrote: > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Prof Brian Ripley > > Sent: Thursday, August 23, 2007 2:54 AM > > To: Denham Robert > > Cc: r-devel@r-project.org; Duncan Murdoch > > Subject: Re: [Rd] compiling R under cygwin > > > > On Thu, 23 Aug 2007, Denham Robert wrote: > > > > >>> For various reasons, > > >> I think it is only courteous to mention some good reasons > > if you want > > > to take up people's time. > > > > > > Some of the reasons we would like a cygwin version aren't > > necessarily > > > good reasons. We have been using cygwin for sometime, > > mostly to deal > > > with scripting in a combined windows/unix environment. We have a > > > setup which allows windows users to run many scripts in the > > same way > > > as unix users. These scripts are often python or shell > > scripts. We > > > have R installed on the unix machines, and the system > > administrators > > > would like to be able to have R on windows in the same > > environment. > > > This set up also means that the administrator can fairly easily > > > maintain the version of software used on all user's machines. > > > Probably this could all be managed and still use the native windows > > > version of R, but the administrator is familiar with cygwin > > and they > > > could manage this software in the same way they manage > > other packages. > > > > Yes, it could almost certainly be done with Rterm.exe. > > > > The issue I came across was the so-called 'posix file paths' > > that Cygwin uses. Most (but not all) Windows programs accept > > file paths with / as the path separator, and most (but not > > all, e.g. tar) Cygwin programs accept paths of the forn > > c:/path/to/file. So provided you use that as your format, > > interworking with Unix and Unix-like shells work fine. It > > used to be the case that if you had just one drive C: then > > Cygwin programs produced paths of the form /path/to/file that > > also worked on Windows. Now they produce > > /cygdrive/c/path/to/file that works nowhere else. > > I'm not sure what you mean by "produce" above but one can easily setup > (by mount option) cygwin to use "/" instead of "/cygdrive/" so that your > example above will become "/c/path/to/file". That's if you insist on > using drive letters. Otherwise w/ proper mounting (in cygwin) one can > have "usual" *nix dir tree. > > Regards, > Latchezar > > PS. I really like the idea of having (the same) bare terminal/command > window interface to R anywhere as well as anything else (like admin > tasks above) to be the same. So please put my vote (if you care) to have > R Windows installation look the same as *nix (up to the point when you > start R from Start button to have terminal version started instead of > Rgui as it is now) and keep GUI candies separately for whoever > wants/needs them. Sorry if that's been already done and I did not know > about it. > > > > > In general this is a minor nuisance, but I needed to be able > > to cross-build R in an environment where I only have > > Cygwin-based cross-compilers, and there the path issues bit > > me: I needed a version of R that accepted and returned > > Cygwin-style paths. So I made the configure changes > > necessary to build R under Cygwin, and had it running in 20 mins. > > > > > We would like to be able to use linux machines on pc's but > > > unfortunately we have restrictions imposed on us that > > prevent this. > > > This restriction also goes as far as the use of virtual > > machines. My > > > personal preference would be to run linux on my work pc, and use a > > > virtual machine to run windows software, such as ArcGIS and > > Imagine, > > > that are not available for linux. This does not seem to be > > an option for us. > > > > > > One thing I was interested in was knowing if there are > > others who also > > > would like a cygwin version. From the replies to my post, > > and from a > > > search of the mailing list archive, I think that there is little > > > demand for this. We would, however, be prepared to help in > > some way > > > for the few people who are interested. > > > > As I said earlier, it builds out of the box in R-devel (with > > suitable options documented in the R-admin manual). No > > guarantees that it will continue to do so unless tested in > > the alpha/beta phase though. As no other platform we use > > nowadays requires that shared objects/dynamic libraries have > > all imports satisfied at build time, this is liable to get broken. > > > > But I would encourage people to use Rterm.exe if it can be > > made to do what you need. > > > > > > > > > > > > > > > > Robert Denham > > > Environmental Statistician > > > Remote Sensing Centre >
Re: [Rd] compiling R under cygwin
Depending on what you mean by "native". Anyway, I'd rather have it uniform to use and easy to maintain across the platforms then keeping the face of the host os. In any case what I'd suggested is to have the uniform setup everywhere and "os" specific somewhere in case anybody needs it. How is that bad? I can tell you it would be a very big issue to make a "native Windows" user of R to find setwd() on *nix platform. BTW, R preferred usage is CLI, isn't it. CLI is fully maintained on Windows too. Please also note I did not mention cygwin or something and did not express any attitude to the port/implementation. Finally I just wanted to have my vote put there (apparently not where your vote is) not to argue. > -Original Message- > From: Gabor Grothendieck [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 23, 2007 4:01 PM > To: Latchezar (Lucho) Dimitrov > Cc: r-devel@r-project.org > Subject: Re: [Rd] compiling R under cygwin > > Having it be the same under cygwin as it is for other UNIX > systems would be ok but for the native Windows port R should > behave like other Windows applications, not like UNIX applications. > > On 8/23/07, Latchezar (Lucho) Dimitrov <[EMAIL PROTECTED]> wrote: > > > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] On Behalf Of Prof Brian > > > Ripley > > > Sent: Thursday, August 23, 2007 2:54 AM > > > To: Denham Robert > > > Cc: r-devel@r-project.org; Duncan Murdoch > > > Subject: Re: [Rd] compiling R under cygwin > > > > > > On Thu, 23 Aug 2007, Denham Robert wrote: > > > > > > >>> For various reasons, > > > >> I think it is only courteous to mention some good reasons > > > if you want > > > > to take up people's time. > > > > > > > > Some of the reasons we would like a cygwin version aren't > > > necessarily > > > > good reasons. We have been using cygwin for sometime, > > > mostly to deal > > > > with scripting in a combined windows/unix environment. > We have a > > > > setup which allows windows users to run many scripts in the > > > same way > > > > as unix users. These scripts are often python or shell > > > scripts. We > > > > have R installed on the unix machines, and the system > > > administrators > > > > would like to be able to have R on windows in the same > > > environment. > > > > This set up also means that the administrator can fairly easily > > > > maintain the version of software used on all user's machines. > > > > Probably this could all be managed and still use the native > > > > windows version of R, but the administrator is familiar with > > > > cygwin > > > and they > > > > could manage this software in the same way they manage > > > other packages. > > > > > > Yes, it could almost certainly be done with Rterm.exe. > > > > > > The issue I came across was the so-called 'posix file paths' > > > that Cygwin uses. Most (but not all) Windows programs > accept file > > > paths with / as the path separator, and most (but not > all, e.g. tar) > > > Cygwin programs accept paths of the forn c:/path/to/file. So > > > provided you use that as your format, interworking with Unix and > > > Unix-like shells work fine. It used to be the case that > if you had > > > just one drive C: then Cygwin programs produced paths of the form > > > /path/to/file that also worked on Windows. Now they produce > > > /cygdrive/c/path/to/file that works nowhere else. > > > > I'm not sure what you mean by "produce" above but one can > easily setup > > (by mount option) cygwin to use "/" instead of "/cygdrive/" so that > > your example above will become "/c/path/to/file". That's if > you insist > > on using drive letters. Otherwise w/ proper mounting (in > cygwin) one > > can have "usual" *nix dir tree. > > > > Regards, > > Latchezar > > > > PS. I really like the idea of having (the same) bare > terminal/command > > window interface to R anywhere as well as anything else (like admin > > tasks above) to be the same. So please put my vote (if you care) to > > have R Windows installation look the same as *nix (up to the point > > when you start R from Start button to have terminal version started > > instead of Rgui as it is now) and keep GUI candies separately for > > whoever wants/needs them. Sorry if that's been already done > and I did > > not know about it. > > > > > > > > In general this is a minor nuisance, but I needed to be able to > > > cross-build R in an environment where I only have Cygwin-based > > > cross-compilers, and there the path issues bit > > > me: I needed a version of R that accepted and returned > Cygwin-style > > > paths. So I made the configure changes necessary to > build R under > > > Cygwin, and had it running in 20 mins. > > > > > > > We would like to be able to use linux machines on pc's but > > > > unfortunately we have restrictions imposed on us that > > > prevent this. > > > > This restriction also goes as far as the use of virtual > > > machines. My
Re: [Rd] compiling R under cygwin
Many people, probably about half, of R users are Windows users either primarily or only and most would expect all their programs on their Windows machine to work in the same consistent way as all other Windows programs following a certain Windows look and feel and way of operating. Software which follows a UNIX look and feel and way of operating is hard or jarring to use when all the other software on your system follows the Windows way. There is a special Windows version of R that is distinct for a good reason. If a cygwin version of R were to exist for UNIX people who want to use R on Windows who basically want to use UNIX on top of Windows that would be ok but that is not Windows. Rather, cygwin is primarily a UNIX system that happens to sit on Windows. The normal Windows version of R that most people use is and should be Windows centric. Regarding your question, native means the ordinary R version on Windows as opposed to a special cygwin version that might exist in the future. On 8/23/07, Latchezar (Lucho) Dimitrov <[EMAIL PROTECTED]> wrote: > Depending on what you mean by "native". Anyway, I'd rather have it > uniform to use and easy to maintain across the platforms then keeping > the face of the host os. In any case what I'd suggested is to have the > uniform setup everywhere and "os" specific somewhere in case anybody > needs it. How is that bad? I can tell you it would be a very big issue > to make a "native Windows" user of R to find setwd() on *nix platform. > BTW, R preferred usage is CLI, isn't it. CLI is fully maintained on > Windows too. > > Please also note I did not mention cygwin or something and did not > express any attitude to the port/implementation. > > Finally I just wanted to have my vote put there (apparently not where > your vote is) not to argue. > > > -Original Message- > > From: Gabor Grothendieck [mailto:[EMAIL PROTECTED] > > Sent: Thursday, August 23, 2007 4:01 PM > > To: Latchezar (Lucho) Dimitrov > > Cc: r-devel@r-project.org > > Subject: Re: [Rd] compiling R under cygwin > > > > Having it be the same under cygwin as it is for other UNIX > > systems would be ok but for the native Windows port R should > > behave like other Windows applications, not like UNIX applications. > > > > On 8/23/07, Latchezar (Lucho) Dimitrov <[EMAIL PROTECTED]> wrote: > > > > > > > > > > -Original Message- > > > > From: [EMAIL PROTECTED] > > > > [mailto:[EMAIL PROTECTED] On Behalf Of Prof Brian > > > > Ripley > > > > Sent: Thursday, August 23, 2007 2:54 AM > > > > To: Denham Robert > > > > Cc: r-devel@r-project.org; Duncan Murdoch > > > > Subject: Re: [Rd] compiling R under cygwin > > > > > > > > On Thu, 23 Aug 2007, Denham Robert wrote: > > > > > > > > >>> For various reasons, > > > > >> I think it is only courteous to mention some good reasons > > > > if you want > > > > > to take up people's time. > > > > > > > > > > Some of the reasons we would like a cygwin version aren't > > > > necessarily > > > > > good reasons. We have been using cygwin for sometime, > > > > mostly to deal > > > > > with scripting in a combined windows/unix environment. > > We have a > > > > > setup which allows windows users to run many scripts in the > > > > same way > > > > > as unix users. These scripts are often python or shell > > > > scripts. We > > > > > have R installed on the unix machines, and the system > > > > administrators > > > > > would like to be able to have R on windows in the same > > > > environment. > > > > > This set up also means that the administrator can fairly easily > > > > > maintain the version of software used on all user's machines. > > > > > Probably this could all be managed and still use the native > > > > > windows version of R, but the administrator is familiar with > > > > > cygwin > > > > and they > > > > > could manage this software in the same way they manage > > > > other packages. > > > > > > > > Yes, it could almost certainly be done with Rterm.exe. > > > > > > > > The issue I came across was the so-called 'posix file paths' > > > > that Cygwin uses. Most (but not all) Windows programs > > accept file > > > > paths with / as the path separator, and most (but not > > all, e.g. tar) > > > > Cygwin programs accept paths of the forn c:/path/to/file. So > > > > provided you use that as your format, interworking with Unix and > > > > Unix-like shells work fine. It used to be the case that > > if you had > > > > just one drive C: then Cygwin programs produced paths of the form > > > > /path/to/file that also worked on Windows. Now they produce > > > > /cygdrive/c/path/to/file that works nowhere else. > > > > > > I'm not sure what you mean by "produce" above but one can > > easily setup > > > (by mount option) cygwin to use "/" instead of "/cygdrive/" so that > > > your example above will become "/c/path/to/file". That's if > > you insist > > > on using drive letters. Otherwise w/ proper mounting (in > > cygwin) one > > > can have "usual" *nix dir tree. >
Re: [Rd] compiling R under cygwin
Sorry but you pushed me where I did not want to go. Anyway this will be my _last e-mail on this subj_. 1. I did not mention anything about cygwin. 2. Although I mentioned several times *nix if you had read a little bit more carefully their spirit you would probably have grasped I actually talked about CLI as in R spirit/recommended/preferred usage (and maintenance/administration). 3. CLI is full fledged Windows look and feel while Rgui is a mish-mash, cf. my prev example with setwd(). Again I don't mind having it at all as any other R candies (I do not consider candies to be unhealthy :-)). 4. For those half or whatever users you mentioned I suggested keeping their favorite look and feel but _not as the main stream implementation replacement_. 5. AFAIK 64-bit R on your favorite Windows is far far away (even Windows is not close enough although it's getting there) and I'd like to see those above (and enjoy watching them) when Windows is not enough, e.g., microarray analysis/BioConductor. 7. Have you really read my e-mails, I mean from the beginning to the end? 8. Sorry if this sounds harsh but your persistence on having Rgui as mainstream Windows R asked for it. 9. Please consider all my e-mail on the subj. as an expression and/or explanation of my wish to have my vote put for CLI mainstream R anywhere as opposed to anything else. I did not aim convincing you neither do I like your attempts to convert me. Best regards, Latchezar > -Original Message- > From: Gabor Grothendieck [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 23, 2007 5:02 PM > To: Latchezar (Lucho) Dimitrov > Cc: r-devel@r-project.org > Subject: Re: [Rd] compiling R under cygwin > > Many people, probably about half, of R users are Windows > users either primarily or only and most would expect all > their programs on their Windows machine to work in the same > consistent way as all other Windows programs following a > certain Windows look and feel and way of operating. > > Software which follows a UNIX look and feel and way of > operating is hard or jarring to use when all the other > software on your system follows the Windows way. There is a > special Windows version of R that is distinct for a good reason. > > If a cygwin version of R were to exist for UNIX people who > want to use R on Windows who basically want to use UNIX on > top of Windows that would be ok but that is not Windows. > Rather, cygwin is primarily a UNIX system that happens to sit > on Windows. The normal Windows version of R that most people > use is and should be Windows centric. > > Regarding your question, native means the ordinary R version > on Windows as opposed to a special cygwin version that might > exist in the future. > > On 8/23/07, Latchezar (Lucho) Dimitrov <[EMAIL PROTECTED]> wrote: > > Depending on what you mean by "native". Anyway, I'd rather have it > > uniform to use and easy to maintain across the platforms > then keeping > > the face of the host os. In any case what I'd suggested is > to have the > > uniform setup everywhere and "os" specific somewhere in > case anybody > > needs it. How is that bad? I can tell you it would be a > very big issue > > to make a "native Windows" user of R to find setwd() on > *nix platform. > > BTW, R preferred usage is CLI, isn't it. CLI is fully maintained on > > Windows too. > > > > Please also note I did not mention cygwin or something and did not > > express any attitude to the port/implementation. > > > > Finally I just wanted to have my vote put there (apparently > not where > > your vote is) not to argue. > > > > > -Original Message- > > > From: Gabor Grothendieck [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, August 23, 2007 4:01 PM > > > To: Latchezar (Lucho) Dimitrov > > > Cc: r-devel@r-project.org > > > Subject: Re: [Rd] compiling R under cygwin > > > > > > Having it be the same under cygwin as it is for other > UNIX systems > > > would be ok but for the native Windows port R should behave like > > > other Windows applications, not like UNIX applications. > > > > > > On 8/23/07, Latchezar (Lucho) Dimitrov > <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > -Original Message- > > > > > From: [EMAIL PROTECTED] > > > > > [mailto:[EMAIL PROTECTED] On Behalf Of > Prof Brian > > > > > Ripley > > > > > Sent: Thursday, August 23, 2007 2:54 AM > > > > > To: Denham Robert > > > > > Cc: r-devel@r-project.org; Duncan Murdoch > > > > > Subject: Re: [Rd] compiling R under cygwin > > > > > > > > > > On Thu, 23 Aug 2007, Denham Robert wrote: > > > > > > > > > > >>> For various reasons, > > > > > >> I think it is only courteous to mention some good reasons > > > > > if you want > > > > > > to take up people's time. > > > > > > > > > > > > Some of the reasons we would like a cygwin version aren't > > > > > necessarily > > > > > > good reasons. We have been using cygwin for sometime, > > > > > mostly to deal > > > > > > with scripting in a c
Re: [Rd] compiling R under cygwin
On 23/08/2007 3:33 PM, Latchezar (Lucho) Dimitrov wrote: > > >> -Original Message- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf Of Prof Brian Ripley >> Sent: Thursday, August 23, 2007 2:54 AM >> To: Denham Robert >> Cc: r-devel@r-project.org; Duncan Murdoch >> Subject: Re: [Rd] compiling R under cygwin >> >> On Thu, 23 Aug 2007, Denham Robert wrote: >> > For various reasons, I think it is only courteous to mention some good reasons >> if you want >>> to take up people's time. >>> >>> Some of the reasons we would like a cygwin version aren't >> necessarily >>> good reasons. We have been using cygwin for sometime, >> mostly to deal >>> with scripting in a combined windows/unix environment. We have a >>> setup which allows windows users to run many scripts in the >> same way >>> as unix users. These scripts are often python or shell >> scripts. We >>> have R installed on the unix machines, and the system >> administrators >>> would like to be able to have R on windows in the same >> environment. >>> This set up also means that the administrator can fairly easily >>> maintain the version of software used on all user's machines. >>> Probably this could all be managed and still use the native windows >>> version of R, but the administrator is familiar with cygwin >> and they >>> could manage this software in the same way they manage >> other packages. >> >> Yes, it could almost certainly be done with Rterm.exe. >> >> The issue I came across was the so-called 'posix file paths' >> that Cygwin uses. Most (but not all) Windows programs accept >> file paths with / as the path separator, and most (but not >> all, e.g. tar) Cygwin programs accept paths of the forn >> c:/path/to/file. So provided you use that as your format, >> interworking with Unix and Unix-like shells work fine. It >> used to be the case that if you had just one drive C: then >> Cygwin programs produced paths of the form /path/to/file that >> also worked on Windows. Now they produce >> /cygdrive/c/path/to/file that works nowhere else. > > I'm not sure what you mean by "produce" above but one can easily setup > (by mount option) cygwin to use "/" instead of "/cygdrive/" so that your > example above will become "/c/path/to/file". That's if you insist on > using drive letters. Otherwise w/ proper mounting (in cygwin) one can > have "usual" *nix dir tree. The issue is compatibility with other Windows programs. /path/to/file works in lots of Windows programs, and is interpreted relative to the current drive. In the common situation where the user only has one partition which is mounted as C:, it works (as long as they didn't switch to a CD or USB drive). /c/path/to/file wouldn't work anywhere but in Cygwin or similar. Duncan Murdoch > > Regards, > Latchezar > > PS. I really like the idea of having (the same) bare terminal/command > window interface to R anywhere as well as anything else (like admin > tasks above) to be the same. So please put my vote (if you care) to have > R Windows installation look the same as *nix (up to the point when you > start R from Start button to have terminal version started instead of > Rgui as it is now) and keep GUI candies separately for whoever > wants/needs them. Sorry if that's been already done and I did not know > about it. > >> In general this is a minor nuisance, but I needed to be able >> to cross-build R in an environment where I only have >> Cygwin-based cross-compilers, and there the path issues bit >> me: I needed a version of R that accepted and returned >> Cygwin-style paths. So I made the configure changes >> necessary to build R under Cygwin, and had it running in 20 mins. >> >>> We would like to be able to use linux machines on pc's but >>> unfortunately we have restrictions imposed on us that >> prevent this. >>> This restriction also goes as far as the use of virtual >> machines. My >>> personal preference would be to run linux on my work pc, and use a >>> virtual machine to run windows software, such as ArcGIS and >> Imagine, >>> that are not available for linux. This does not seem to be >> an option for us. >>> One thing I was interested in was knowing if there are >> others who also >>> would like a cygwin version. From the replies to my post, >> and from a >>> search of the mailing list archive, I think that there is little >>> demand for this. We would, however, be prepared to help in >> some way >>> for the few people who are interested. >> As I said earlier, it builds out of the box in R-devel (with >> suitable options documented in the R-admin manual). No >> guarantees that it will continue to do so unless tested in >> the alpha/beta phase though. As no other platform we use >> nowadays requires that shared objects/dynamic libraries have >> all imports satisfied at build time, this is liable to get broken. >> >> But I would encourage people to use Rterm.exe if it can b
Re: [Rd] compiling R under cygwin
> -Original Message- > From: Duncan Murdoch [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 23, 2007 9:15 PM > To: Latchezar (Lucho) Dimitrov > Cc: Prof Brian Ripley; Denham Robert; r-devel@r-project.org > Subject: Re: [Rd] compiling R under cygwin > > On 23/08/2007 3:33 PM, Latchezar (Lucho) Dimitrov wrote: > > > > > >> -Original Message- > >> From: [EMAIL PROTECTED] > >> [mailto:[EMAIL PROTECTED] On Behalf Of Prof > Brian Ripley > >> Sent: Thursday, August 23, 2007 2:54 AM > >> To: Denham Robert > >> Cc: r-devel@r-project.org; Duncan Murdoch > >> Subject: Re: [Rd] compiling R under cygwin > >> > >> On Thu, 23 Aug 2007, Denham Robert wrote: > >> > > For various reasons, > I think it is only courteous to mention some good reasons > >> if you want > >>> to take up people's time. > >>> > >>> Some of the reasons we would like a cygwin version aren't > >> necessarily > >>> good reasons. We have been using cygwin for sometime, > >> mostly to deal > >>> with scripting in a combined windows/unix environment. We have a > >>> setup which allows windows users to run many scripts in the > >> same way > >>> as unix users. These scripts are often python or shell > >> scripts. We > >>> have R installed on the unix machines, and the system > >> administrators > >>> would like to be able to have R on windows in the same > >> environment. > >>> This set up also means that the administrator can fairly easily > >>> maintain the version of software used on all user's machines. > >>> Probably this could all be managed and still use the > native windows > >>> version of R, but the administrator is familiar with cygwin > >> and they > >>> could manage this software in the same way they manage > >> other packages. > >> > >> Yes, it could almost certainly be done with Rterm.exe. > >> > >> The issue I came across was the so-called 'posix file paths' > >> that Cygwin uses. Most (but not all) Windows programs accept file > >> paths with / as the path separator, and most (but not all, > e.g. tar) > >> Cygwin programs accept paths of the forn c:/path/to/file. So > >> provided you use that as your format, interworking with Unix and > >> Unix-like shells work fine. It used to be the case that > if you had > >> just one drive C: then Cygwin programs produced paths of the form > >> /path/to/file that also worked on Windows. Now they produce > >> /cygdrive/c/path/to/file that works nowhere else. > > > > I'm not sure what you mean by "produce" above but one can > easily setup > > (by mount option) cygwin to use "/" instead of "/cygdrive/" so that > > your example above will become "/c/path/to/file". That's if > you insist > > on using drive letters. Otherwise w/ proper mounting (in > cygwin) one > > can have "usual" *nix dir tree. > > The issue is compatibility with other Windows programs. > /path/to/file works in lots of Windows programs, and is > interpreted relative to the current drive. In the common > situation where the user only has one partition which is > mounted as C:, it works (as long as they didn't switch to a > CD or USB drive). As I said _if_ you insist on using c (which btw is absolutely not necessary) Please see the output of 'ls' and 'dir' bellow: C:\Documents and Settings\Latchezar M Dimitrov>dir "u:\home\Latchezar M Dimitrov\cygwin" Volume in drive U is Users': Volume Serial Number is 7FC9-20D1 Directory of u:\home\Latchezar M Dimitrov\cygwin 07/30/2007 07:00 PM . 07/30/2007 07:00 PM .. 07/31/2005 07:39 PM 7,664 .alias 07/29/2005 10:29 AM 7,664 .alias~ 07/22/2005 11:24 AM .autosave 02/13/2007 04:46 PM 2,791 .bashrc 01/27/2007 08:47 PM 2,631 .bashrc~ 08/20/2007 11:55 AM25,966 .bash_history 01/27/2007 08:48 PM 959 .bash_profile 05/28/2005 06:18 PM 959 .bash_profile~ 10/27/2003 09:09 PM 569 .emacs 05/28/2005 06:18 PM 608 .inputrc 11/03/2004 07:17 PM 135 .saves-2440-TheComputer 09/13/2005 01:40 PM .semanticdb 07/22/2005 11:24 AM .ssh 02/09/2002 11:43 PM 1,003 .Xdefaults 02/22/2006 01:33 AM .xemacs $ls /home/Latchezar\ M\ Dimitrov/cygwin/ total 962 -rwxrwxrwx 1 Latchezar M Dimitrov None 1003 Feb 9 2002 .Xdefaults* -rwxrwxrwx 1 Latchezar M Dimitrov None 7664 Jul 31 2005 .alias* -rwxrwxrwx 1 Latchezar M Dimitrov None 7664 Jul 29 2005 .alias~* drwxrwxrwx+ 2 Latchezar M Dimitrov None 0 Jul 22 2005 .autosave/ -rwxrwxrwx 1 Latchezar M Dimitrov None 25966 Aug 20 11:55 .bash_history* -rwxrwxrwx 1 Latchezar M Dimitrov None959 Jan 27 2007 .bash_profile* -rwxrwxrwx 1 Latchezar M Dimitrov None959 May 28 2005 .bash_profile~* -rwxrwxrwx 1 Latchezar M Dimitrov None 2791 Feb 13 2007 .bashrc* -rwxrwxrwx 1 Latchezar M Dimitrov None 2631 Jan 27 2007 .bashrc~* -rwxrwxrwx 1 Latch
Re: [Rd] compiling R under cygwin
On Thu, 23 Aug 2007, Duncan Murdoch wrote: > The issue is compatibility with other Windows programs. /path/to/file works > in lots of Windows programs, and is interpreted relative to the current > drive. In the common situation where the user only has one partition which > is mounted as C:, it works (as long as they didn't switch to a CD or USB > drive). In particular, it does not work on my system where I need to run under two OSes, Vista64 on C: and WinXP on D:, with common development on E: . I had originally intended to work entirely on E: and mount E:/ as /, which is what you need to get Cygwin to return /path/to/file for working files on E: . But Cygwin does not handle permissions on a Vista NTFS file system well enough. Latchezar (Lucho) Dimitrov wrote > 5. AFAIK 64-bit R on your favorite Windows is far far away (even Windows > is not close enough although it's getting there) and I'd like to see > those above (and enjoy watching them) when Windows is not enough, e.g., > microarray analysis/BioConductor. That's just not true. There have been reports of 64-bit R ports to Windows and many people are running 64-bit Windows on servers and some on desktops (including me). A MinGW-based 64-bit R for Windows is under active development (which is why I have Vista64 installed). This is even covered in the rw-FAQ (Q8.1, and yes that is a file with numbered TOC). What seems 'far, far away' is something like Cygwin for 64-bit Windows. (I saw on a Cygwin list that RedHat wanted $ to do it, for too many $ for the potential customers.) The 32-bit version is said to work under the WOW 32-bit emulation layer but many of us find it flaky. Personally I use Linux (the main OS on the machine I mention above) and Solaris: however many R users (quite possibly the substantial majority of all R users even excluding student usage) want a native Windows version. -- 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
