[Rd] Buliding a package (on Windows) does not produce libs directory
Dear expeRts! I have produced a package and I would like to compile it on windows to build a binary package. The package also includes Fortran code. This is where I have problems. The package compiles fine, however the Fortran code seams to be ignored. I have the Fortran code in src subdirectory. I have all the compilers installed. Actually, if I compile the Fortran subroutines manually and then place them in the libs subdirectory (which I have to create) in the zip file, the package loads nicely and the Fortran subroutines can be used. At the bottom of the mail is the output I get when calling R CMD build (if I call install the result is similar). I apologize if this has been answered previously, since I have not found it. C:\Ales\Statistika>R CMD build --binary --docs="none" blockmodeling * checking for file 'blockmodeling/DESCRIPTION' ... OK * preparing 'blockmodeling': * checking DESCRIPTION meta-information ... OK * cleaning src * removing junk files * checking for LF line-endings in source files * checking for empty directories * building binary distribution WARNING * some HTML links may not be found installing R.css in C:/TEMP/Rinst.1696 Using auto-selected zip options ' blockmodeling-HELP=ziponly' -- Making package blockmodeling adding build stamp to DESCRIPTION installing R files installing man source files installing indices preparing package blockmodeling for lazy loading adding MD5 sums packaged installation of package 'blockmodeling' as blockmodeling_0.1.0.zip * DONE (blockmodeling) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Buliding a package (on Windows) does not produce libs directory
There is no DLL being built. We have absolutely nothing to go on here, but there are dozens of examples on CRAN which do work. A simple one containing Fortran is 'ash' - perhaps you should study how yours differs from that. And please get R CMD INSTALL working before complicating the issue with the (not recommended) R CMD build --binary. On Fri, 25 Nov 2005, Ales Ziberna wrote: > Dear expeRts! > > > > I have produced a package and I would like to compile it on windows to build > a binary package. The package also includes Fortran code. This is where I > have problems. > > > > The package compiles fine, however the Fortran code seams to be ignored. I > have the Fortran code in src subdirectory. I have all the compilers > installed. Actually, if I compile the Fortran subroutines manually and then > place them in the libs subdirectory (which I have to create) in the zip > file, the package loads nicely and the Fortran subroutines can be used. > > > > At the bottom of the mail is the output I get when calling R CMD build (if I > call install the result is similar). > > > > I apologize if this has been answered previously, since I have not found it. > > > C:\Ales\Statistika>R CMD build --binary --docs="none" blockmodeling > * checking for file 'blockmodeling/DESCRIPTION' ... OK > * preparing 'blockmodeling': > * checking DESCRIPTION meta-information ... OK > * cleaning src > * removing junk files > * checking for LF line-endings in source files > * checking for empty directories > * building binary distribution > WARNING > * some HTML links may not be found > installing R.css in C:/TEMP/Rinst.1696 > > > > Using auto-selected zip options ' blockmodeling-HELP=ziponly' > > > > -- Making package blockmodeling > adding build stamp to DESCRIPTION > installing R files > installing man source files > installing indices > preparing package blockmodeling for lazy loading > adding MD5 sums > > > > packaged installation of package 'blockmodeling' as blockmodeling_0.1.0.zip > * DONE (blockmodeling) > > __ > 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] read.table without sep
Hello all,
I have a data file table.txt which i have attached. I am trying to pass the
columns as arguments to a function "totnorm" where i am displaying a total
normalization plot. The function is given below:
totnorm<-function(x,y){scale<-sum(x)/sum(y);xlab<-colnames(x);ylab<-colnames(y);x1<-x[[1]];y1<-scale*y[[1]];plot(x1,y1,xlab=xlab,ylab=ylab,col=6,
col.lab=4);}
i tried doing this:
data<-read.table("alldata.txt",header=TRUE,sep="\t")
a<-data[1]
b<-data[2]
totnorm(a,b)
The problem i am facing is- xlab and ylab contain the column names of
data[1] and data[2], but data[1][[1]] which is assigned to x1 has different
data which does not correspond to the colname(data[1]). Stating more
clearly, the colnames and the coldata don't match. I tried usind
read.tablewithout sep attribute, as given below:
data1<-read.table("alldata.txt",header=TRUE)
But this statement is not getting executed using Rserve when i make a
connection to R and try to execute it from a java servlet. I don't know why
it was doing so, so thought it would be better to fix this on R side, i.e,
try to use the "sep" attribue in read.table and still make the colnames and
coldata point to the same col#.
Please suggest a solution.
Thanks,
Vasu.
14A_U133A_StatPairs 14A_U133A_Detection 14B_U133A_Signal
88A_U133A_Signal88B_U133A_Signal183A_U133A_Signal
183B_U133A_Signal
AFFX-BioB-5_at 403.0 409.3 611.5 569.2 536.6 580.2
AFFX-BioB-M_at 757.3 574.4 826.7 595.3 755.2 956.0
AFFX-BioB-3_at 284.4 327.3 421.6 336.6 391.3 412.6
AFFX-BioC-5_at 2314.2 1685.3 2264.7 2204.1 2233.1 2458.4
AFFX-BioC-3_at 1574.5 1273.0 1484.6 1321.2 1474.7 1774.1
AFFX-BioDn-5_at 2333.7 1796.8 2464.5 2372.5 2095.9 2735.7
AFFX-BioDn-3_at 13673.9 11463.9 13624.7 14513.9 12934.1 16293.1
AFFX-CreX-5_at 17778.8 15248.8 19977.2 19613.4 18609.1 18988.2
AFFX-CreX-3_at 31056.6 24869.9 30773.4 32918.6 34412.1 33954.6
AFFX-DapX-5_at 36.369.892.052.057.364.9
AFFX-DapX-M_at 133.4 75.176.2108.9 74.0100.2
AFFX-DapX-3_at 10.011.184.09.6 9.3 9.6
AFFX-LysX-5_at 40.431.18.3 6.6 8.6 50.0
AFFX-LysX-M_at 12.816.565.267.813.739.1
AFFX-LysX-3_at 66.18.6 83.59.4 43.928.7
AFFX-PheX-5_at 14.817.69.7 14.715.219.3
AFFX-PheX-M_at 70.612.422.888.08.0 18.5
AFFX-PheX-3_at 33.297.431.631.7129.5 11.1
AFFX-ThrX-5_at 26.431.314.523.428.124.2
AFFX-ThrX-M_at 87.443.989.433.052.452.8
AFFX-ThrX-3_at 19.918.913.926.124.017.0
AFFX-TrpnX-5_at 32.613.526.511.460.318.4
AFFX-TrpnX-M_at 14.97.5 12.110.111.312.8
AFFX-TrpnX-3_at 17.34.3 7.0 26.02.3 8.6
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] 'partial' in sort() inefficient?
I often need to work with large vectors whose distribution I want to
summarize by Q-Q plots. Since the vectors are large, I use a subset
of quantiles, e.g.
quantile(x, probs = ppoints(1000))
Unfortunately, this seemed to be taking too long for large x (much
longer than 'sort'). I initially thought maybe quantile was doing
something sophisticated (which I don't really need with a large data
set), so I would write something simple myself. I did, but then I
noticed that 'quantile' was doing essentially the same thing, with the
exception that it was calling 'sort' with a non-null 'partial'
argument.
?sort says:
If 'partial' is not 'NULL', it is taken to contain indices of
elements of 'x' which are to be placed in their correct positions
by partial sorting. After the sort, the values specified in
'partial' are in their correct position in the sorted array. Any
values smaller than these values are guaranteed to have a smaller
index in the sorted array and any values which are greater are
guaranteed to have a bigger index in the sorted array. This is
included for efficiency, and many of the options are not available
for partial sorting.
However, rather than being efficient, this seems to considerably slow
things down (I haven't checked memory efficiency). Consider the
following code (imitating what 'quantile' does by default):
probs <- ppoints(1000)
for (i in seq(5000, 5, 5000))
{
x <- rnorm(i)
n <- length(x)
index <- 1 + (n - 1) * probs
lo <- floor(index)
hi <- ceiling(index)
keep <- as.integer(unique(c(lo, hi)))
cat(system.time(y1 <- sort(x, partial = keep))[1])
cat("\t")
cat(system.time(y2 <- sort(x))[1])
cat("\t")
cat(round(max(abs( y1 - y2 )), digits = 3))
cat("\t")
cat(max(abs( y1[keep] - y2[keep] )))
cat("\n")
}
The first two columns in the output are timings for 'sort' with and
without 'partial', the last two columns are just a rough check that
partial sorting is doing what it claims. With R-2.2:
0.780 0.031 0
1.640.010.565 0
2.590.010.646 0
3.440.010.487 0
4.4 0.010.569 0
5.260.010.642 0
6.290.011.071 0
7.180.020.566 0
8.180.021.094 0
9.010.030.890
> version
_
platform i686-pc-linux-gnu
arch i686
os linux-gnu
system i686, linux-gnu
status Patched
major2
minor2.0
year 2005
month10
day 16
svn rev 35911
language R
This also holds on (a faster machine running) r-devel
0.390 0.176 0
0.850.010.620
1.320 0.193 0
1.8 0 0.949 0
2.290 0.730
2.770 1.185 0
3.250.010.813 0
3.750.011.171 0
4.210.010.827 0
4.740.010.372 0
> version
_
platform x86_64-unknown-linux-gnu
arch x86_64
os linux-gnu
system x86_64, linux-gnu
status Under development (unstable)
major2
minor3.0
year 2005
month11
day 25
svn rev 36468
language R
Speed improves when the number of 'partial' indices is small, but even
for 10 indices plain 'sort' is faster.
Am I missing something? I haven't checked if NA's make a difference
or if there might be memory usage issues, but even so, could
'quantile' at least have an option to disable partial sorting?
Deepayan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] "integrate" error using a constant function (PR#8348)
Full_Name: Joel Franklin
Version: 2.2.0
OS: WinXP-Prof
Submission from: (NULL) (63.226.223.22)
The "integrate" function, when evaluating an integrand function that is constant
(therefore not a function of the integral) cannot be valuated, and instead
throws an error. Instead, the interate function should evaluate the constant
function as a rectangular area with length (upper-lower).
For example:
integrand<-function(x){5}
integrate(f=integrand,lower=1,upper=5)
"Error in integrate(f = integrand, lower = 1, upper = 5) :
evaluation of function gave a result of wrong length"
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] "integrate" error using a constant function (PR#8348)
Did you check the examples on the help page for integrate?
integrand <- function(x) rep(5, length(x))
should do it. Definitely not a bug.
Peter
[EMAIL PROTECTED] wrote:
> Full_Name: Joel Franklin
> Version: 2.2.0
> OS: WinXP-Prof
> Submission from: (NULL) (63.226.223.22)
>
>
> The "integrate" function, when evaluating an integrand function that is
> constant
> (therefore not a function of the integral) cannot be valuated, and instead
> throws an error. Instead, the interate function should evaluate the constant
> function as a rectangular area with length (upper-lower).
>
> For example:
>
> integrand<-function(x){5}
> integrate(f=integrand,lower=1,upper=5)
>
> "Error in integrate(f = integrand, lower = 1, upper = 5) :
> evaluation of function gave a result of wrong length"
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Peter Ehlers
Department of Mathematics and Statistics
University of Calgary, 2500 University Dr. NW ph: 403-220-3936
Calgary, Alberta T2N 1N4, CANADA fax: 403-282-5150
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] list.files(recursive=T) does not return directory names
list.files() (and dir()) don't appear to return names of
directories when one uses the recursive=T argument. E.g.,
> dir(file.path(R.home(),"library"), pattern="^R$", recursive=T)
[1] "Malmig/help/R"
but the unix find commmand finds lots of R directories
> z <- system(paste("find", file.path(R.home(),"library"), "-name R"),
intern=T)
> length(z)
[1] 665
> file.info(z[1:3])[,1:3]
size isdir mode
/dept/devel/sw/R/R.linux/R/library/aCGH/R 4096 TRUE 2755
/dept/devel/sw/R/R.linux/R/library/RBGL/R 4096 TRUE 2755
/dept/devel/sw/R/R.linux/R/library/XML/R 4096 TRUE 2755
The help file is silent on this behavior. I am writing
an emulation of these for functions for Splus and was
wondering about 3 things.
a) Is this behavior intended?
b) Is there an easy way to get the names of all directories
under a given one?
b) I would like to add an argument to list.files() to specify
that I'd like the names of only non-directories, only directories,
or both. I've tentatively called this argument "type" (following
the unix find command) and the acceptable values are "files",
"directories", and "all" (or any abbreviation). Symbolic links,
fifos, etc. might be nice, but I don't want to fill the code
with unixisms or tempt folks to use them. Would adding
type = "files","directories","all"
to list.files and dir conflict with any plans for R's list.files
or dir?
Bill Dunlap
Insightful Corporation
bill at insightful dot com
360-428-8146
"Formerly known as MathSoft, Insightful Corporation provides analytical
solutions leveraging S-PLUS, StatServer and consulting services."
"All statements in this message represent the opinions of the author and do
not necessarily reflect Insightful Corporation policy or position."
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] list.files(recursive=T) does not return directory names
Hi,
the R.utils package has a function listDirectory() that returns the
directory names too. (I've made some changes to the function recently,
which is not in the CRAN version, so get it from http://www.braju.com/R/
instead.)
The package also has isFile() and isDirectory() to test if a pathname
refers to an existing file and directory, respectively. These are not
"vectorized" (yet), so you have to call them with sapply() if you have
many pathnames, e.g.
> path <- file.path(R.home(), "share")
> ld <- listDirectory(path, recursive=TRUE, fullNames=TRUE)
> ld[sapply(ld, isDirectory)]
[1] "C:\\PROGRA~1\\R\\rw2011pat/share/licenses"
[2] "C:\\PROGRA~1\\R\\rw2011pat/share/locale"
[3] "C:\\PROGRA~1\\R\\rw2011pat/share/make"
...
[27] "C:\\PROGRA~1\\R\\rw2011pat/share/perl/R"
[28] "C:\\PROGRA~1\\R\\rw2011pat/share/perl/Text"
> ld[sapply(ld, isFile)]
[1] "C:\\PROGRA~1\\R\\rw2011pat/share/licenses/Artistic"
[2] "C:\\PROGRA~1\\R\\rw2011pat/share/licenses/BSD"
[3] "C:\\PROGRA~1\\R\\rw2011pat/share/licenses/GPL-2"
...
[50] "C:\\PROGRA~1\\R\\rw2011pat/share/texmf/ts1aett.fd"
[51] "C:\\PROGRA~1\\R\\rw2011pat/share/texmf/upquote.sty"
Hope this helps.
BTW, this package also have functions to read Windows Shortcuts files
(*.lnk) and the function filePath("data", "raw", expandLinks="any") will
recognize if any part is a shortcut to another directory, e.g. data.lnk
links to another directory containing subdirectory "raw" (and directory
data/ does not exist). (filePath() also not vectorized).
listDirectory() does not follow Windows Shortcuts.
Henrik
[EMAIL PROTECTED] wrote:
> list.files() (and dir()) don't appear to return names of
> directories when one uses the recursive=T argument. E.g.,
> > dir(file.path(R.home(),"library"), pattern="^R$", recursive=T)
> [1] "Malmig/help/R"
> but the unix find commmand finds lots of R directories
> > z <- system(paste("find", file.path(R.home(),"library"), "-name R"),
> intern=T)
> > length(z)
> [1] 665
> > file.info(z[1:3])[,1:3]
> size isdir mode
> /dept/devel/sw/R/R.linux/R/library/aCGH/R 4096 TRUE 2755
> /dept/devel/sw/R/R.linux/R/library/RBGL/R 4096 TRUE 2755
> /dept/devel/sw/R/R.linux/R/library/XML/R 4096 TRUE 2755
>
> The help file is silent on this behavior. I am writing
> an emulation of these for functions for Splus and was
> wondering about 3 things.
>
> a) Is this behavior intended?
>
> b) Is there an easy way to get the names of all directories
> under a given one?
>
> b) I would like to add an argument to list.files() to specify
> that I'd like the names of only non-directories, only directories,
> or both. I've tentatively called this argument "type" (following
> the unix find command) and the acceptable values are "files",
> "directories", and "all" (or any abbreviation). Symbolic links,
> fifos, etc. might be nice, but I don't want to fill the code
> with unixisms or tempt folks to use them. Would adding
> type = "files","directories","all"
> to list.files and dir conflict with any plans for R's list.files
> or dir?
>
>
> Bill Dunlap
> Insightful Corporation
> bill at insightful dot com
> 360-428-8146
> "Formerly known as MathSoft, Insightful Corporation provides analytical
> solutions leveraging S-PLUS, StatServer and consulting services."
>
> "All statements in this message represent the opinions of the author and do
> not necessarily reflect Insightful Corporation policy or position."
>
> __
> 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
