Re: [Rd] assigning to a null data frame. (PR#4727)
ashenfluff == ashenfluff [EMAIL PROTECTED] on Wed, 22 Oct 2003 22:29:23 +0200 (MET DST) writes: ashenfluff Full_Name: Ben K. ashenfluff Version: 1.8.0 ashenfluff OS: win2k ashenfluff Submission from: (NULL) (208.243.20.222) ashenfluff This fails: ashenfluff vars-data.frame(NULL) ashenfluff vars$delta-4 ashenfluff output: Error in $-.data.frame(`*tmp*`, delta, value = 4) : ashenfluff replacement has 1 rows, data has 0 ashenfluff It worked in 1.7.0 and all previous, well, I think it was a bug in the way it did worked, since it left a very strange object `vars' that certainly wasn't a valid data frame: Whereas data.frame(NULL) is a valid data.frame, the `vars' resulting fron vars$delta - 4 definitely wasn't valid in R 1.7.1 : it had rownames of length 0 and dimension c(0, 1): v - data.frame(NULL); v$delta - 4; v [1] delta 0 rows (or 0-length row.names) dim(v) [1] 0 1 dput(v) structure(list(delta = 4), .Names = delta, row.names = character(0), class = data.frame) Note that S-plus 6.1.2 has the same problematic behavior as R(= 1.7.1). I do agree that the data.frame method for $- could be made to work properly here (namely producing a data frame of dimension (1,1) with rownames = 1). BTW, I think even more than that I would argue that I'd want cbind() to work with data.frame(NULL), i.e., the following could be made to work v - data.frame(NULL) v - cbind(v, delta = 4) (It does work in S+ though there, the 1st statement gives a warning, and the 2nd gives two warnings ..) ashenfluff and if we initialize vars without NULL, ashenfluff R is OK with it: ashenfluff vars-data.frame(dummy=4) ashenfluff vars$delta-4 Yes, because in this call to data.frame(.) you produced a well-dimensioned data.frame with which the $- operator worked properly. __ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Something strange in cor.test in R-1.8.0 (PR#4718)
maechler writes:
Duncan == Duncan Murdoch [EMAIL PROTECTED]
on Wed, 22 Oct 2003 08:17:32 -0400 writes:
Duncan I've now tried the code
set.seed(1)
x - rnorm(50)
y - rnorm(50)
cor.test(x,y,method=spearman)
x - rnorm(50)
y - rnorm(50)
cor.test(x,y,method=spearman)
Duncan in r-patched (which gives apparently correct results), and r-devel,
Duncan which gives the first result correct, the second incorrect; when
Duncan repeated, both are bad.
Hmm,
funny.
I get repeatable results in in R 1.7.1 , 1.8.0, R-patched and
R-devel (all on Linux),
with an (ugly but convenient) 1-liner :
set.seed(1); for(k in 1:2){x - rnorm(50);y -
rnorm(50);print(unlist(cor.test(x,y,method=spearman)[1:4]))}
statistic.S p.value estimate.rho
23640.000 0.3482088-0.1351741
statistic.S p.value estimate.rho
1.724800e+04 2.322263e-01 1.717647e-01
I get the same on Debian GNU/Linux.
Where do we stand on this? Windows-specific?
-k
__
[EMAIL PROTECTED] mailing list
https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Something strange in cor.test in R-1.8.0 (PR#4718)
Kurt Hornik [EMAIL PROTECTED] writes:
maechler writes:
Duncan == Duncan Murdoch [EMAIL PROTECTED]
on Wed, 22 Oct 2003 08:17:32 -0400 writes:
Duncan I've now tried the code
set.seed(1)
x - rnorm(50)
y - rnorm(50)
cor.test(x,y,method=spearman)
x - rnorm(50)
y - rnorm(50)
cor.test(x,y,method=spearman)
Duncan in r-patched (which gives apparently correct results), and r-devel,
Duncan which gives the first result correct, the second incorrect; when
Duncan repeated, both are bad.
Hmm,
funny.
I get repeatable results in in R 1.7.1 , 1.8.0, R-patched and
R-devel (all on Linux),
with an (ugly but convenient) 1-liner :
set.seed(1); for(k in 1:2){x - rnorm(50);y -
rnorm(50);print(unlist(cor.test(x,y,method=spearman)[1:4]))}
statistic.S p.value estimate.rho
23640.000 0.3482088-0.1351741
statistic.S p.value estimate.rho
1.724800e+04 2.322263e-01 1.717647e-01
I get the same on Debian GNU/Linux.
Where do we stand on this? Windows-specific?
Probably, but of a nasty kind which I think we need to get to the
bottom of. As I see it there are two possible causes
1. A bug in a Windows library or compiler. Potentially that could
affect everything else.
2. A bug in ctest that just happens only to cause visible damage on
Windows, but perhaps invisible damage elsewhere.
Either way, I think we need to investigate.
--
O__ Peter Dalgaard Blegdamsvej 3
c/ /'_ --- Dept. of Biostatistics 2200 Cph. N
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
[EMAIL PROTECTED] mailing list
https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Something strange in cor.test in R-1.8.0 (PR#4718)
Peter Dalgaard writes:
Kurt Hornik [EMAIL PROTECTED] writes:
maechler writes:
Duncan == Duncan Murdoch [EMAIL PROTECTED]
on Wed, 22 Oct 2003 08:17:32 -0400 writes:
Duncan I've now tried the code
set.seed(1)
x - rnorm(50)
y - rnorm(50)
cor.test(x,y,method=spearman)
x - rnorm(50)
y - rnorm(50)
cor.test(x,y,method=spearman)
Duncan in r-patched (which gives apparently correct results), and r-devel,
Duncan which gives the first result correct, the second incorrect; when
Duncan repeated, both are bad.
Hmm,
funny.
I get repeatable results in in R 1.7.1 , 1.8.0, R-patched and
R-devel (all on Linux),
with an (ugly but convenient) 1-liner :
set.seed(1); for(k in 1:2){x - rnorm(50);y -
rnorm(50);print(unlist(cor.test(x,y,method=spearman)[1:4]))}
statistic.S p.value estimate.rho
23640.000 0.3482088-0.1351741
statistic.S p.value estimate.rho
1.724800e+04 2.322263e-01 1.717647e-01
I get the same on Debian GNU/Linux.
Where do we stand on this? Windows-specific?
Probably, but of a nasty kind which I think we need to get to the
bottom of. As I see it there are two possible causes
1. A bug in a Windows library or compiler. Potentially that could
affect everything else.
2. A bug in ctest that just happens only to cause visible damage on
Windows, but perhaps invisible damage elsewhere.
Either way, I think we need to investigate.
As Brian had written earlier in this thread, we need a reproducible
example. If Duncan's example can be reproduced on Windows but not on
Linux (and I cannot), odds are in favor of the problem being Windows
specific.
-k
__
[EMAIL PROTECTED] mailing list
https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Something strange in cor.test in R-1.8.0 (PR#4718)
Peter Dalgaard writes:
Kurt Hornik [EMAIL PROTECTED] writes:
maechler writes:
Duncan == Duncan Murdoch [EMAIL PROTECTED]
on Wed, 22 Oct 2003 08:17:32 -0400 writes:
Duncan I've now tried the code
set.seed(1)
x - rnorm(50)
y - rnorm(50)
cor.test(x,y,method=spearman)
x - rnorm(50)
y - rnorm(50)
cor.test(x,y,method=spearman)
Duncan in r-patched (which gives apparently correct results), and r-devel,
Duncan which gives the first result correct, the second incorrect; when
Duncan repeated, both are bad.
Hmm,
funny.
I get repeatable results in in R 1.7.1 , 1.8.0, R-patched and
R-devel (all on Linux),
with an (ugly but convenient) 1-liner :
set.seed(1); for(k in 1:2){x - rnorm(50);y -
rnorm(50);print(unlist(cor.test(x,y,method=spearman)[1:4]))}
statistic.S p.value estimate.rho
23640.000 0.3482088-0.1351741
statistic.S p.value estimate.rho
1.724800e+04 2.322263e-01 1.717647e-01
I get the same on Debian GNU/Linux.
Where do we stand on this? Windows-specific?
Probably, but of a nasty kind which I think we need to get to the
bottom of. As I see it there are two possible causes
1. A bug in a Windows library or compiler. Potentially that could
affect everything else.
2. A bug in ctest that just happens only to cause visible damage on
Windows, but perhaps invisible damage elsewhere.
Either way, I think we need to investigate.
As Brian had written earlier in this thread, we need a reproducible
example. If Duncan's example can be reproduced on Windows but not on
Linux (and I cannot), odds are in favor of the problem being Windows
specific.
-k
__
[EMAIL PROTECTED] mailing list
https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Something strange in cor.test in R-1.8.0 (PR#4718)
[EMAIL PROTECTED] writes: Probably, but of a nasty kind which I think we need to get to the bottom of. As I see it there are two possible causes 1. A bug in a Windows library or compiler. Potentially that could affect everything else. 2. A bug in ctest that just happens only to cause visible damage on Windows, but perhaps invisible damage elsewhere. Either way, I think we need to investigate. As Brian had written earlier in this thread, we need a reproducible example. If Duncan's example can be reproduced on Windows but not on Linux (and I cannot), odds are in favor of the problem being Windows specific. No, odds are in favor of the *symptom* being Windows-specific. See above... Problem is, we need a Windows guru to debug in that case. -p -- O__ Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Something strange in cor.test in R-1.8.0 (PR#4718)
On 23 Oct 2003, Peter Dalgaard wrote: [EMAIL PROTECTED] writes: Probably, but of a nasty kind which I think we need to get to the bottom of. As I see it there are two possible causes 1. A bug in a Windows library or compiler. Potentially that could affect everything else. 2. A bug in ctest that just happens only to cause visible damage on Windows, but perhaps invisible damage elsewhere. Either way, I think we need to investigate. As Brian had written earlier in this thread, we need a reproducible example. If Duncan's example can be reproduced on Windows but not on Linux (and I cannot), odds are in favor of the problem being Windows specific. No, odds are in favor of the *symptom* being Windows-specific. See above... Problem is, we need a Windows guru to debug in that case. cor.test.default calls the second arg of prho as as.integer(q + 1), but someone altered the C code (at the last minute before 1.8.0 was frozen) to *double. So I think Peter is probably right. -- 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 __ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
[Rd] Re: ichar() function in R : 1st implementation, RFC
(RFC := Request For Comments)
Tim == Tim Keighley [EMAIL PROTECTED]
on Thu, 23 Oct 2003 11:45:22 +1000 writes:
Tim Hi Martin,
Tim In October 2000 you wrote to r-help:
which reminds me that I've had a desire for something like
the old S function [from the blue book, and library(examples) I think]
ichar(ch)
which would return a vector of integers, each the (decimal) equivalent of
the (ISO-latin1) representation of the corresponding characters in ch.
This should be easy enough (and be done in C).
Any volunteers?
Tim Did you get any volunteers?
no.
Thank you for reminding me!
Tim Is this function or an
Tim equivalent now available in R? I have been unsuccessful
Tim in my investigation but I do not have all the available
Tim CRAN packages, so it might be in one of them.
I've searched myself (we have almost all of them installed), and
didn't find anything.
Tim Cheers,
Tim Tim Keighley
I now did a first cut, using R only code,
(and realizing that most of chars8bit() should really happen in C).
I'm proposing to add something like this to R-devel in the near
future.
Note that AsciiToInt() and ichar() ar for S-plus and old S
compatibility, whereas I think we'd really want (equivalents) of
the three functions
digitsBase()
chars8bit()
strcodes()
in R eventually.
I'm very interested in feedback,
particularly
- function and arguments' naming
- proposals for improvements
- neat examples of usage.
Martin
Martin Maechler [EMAIL PROTECTED] http://stat.ethz.ch/~maechler/
Seminar fuer Statistik, ETH-Zentrum LEO C16Leonhardstr. 27
ETH (Federal Inst. Technology) 8092 Zurich SWITZERLAND
phone: x-41-1-632-3408 fax: ...-1228
### This was digits.v() in library(sfsmisc):
### -- get it's help() file /u/maechler/R/Pkgs/sfsmisc/man/digits.Rd
digitsBase - function(x, base = 2, ndigits = 1 + floor(log(max(x),base)))
{
## Purpose: Give the vector A of the base-_base_ representation of _n_:
## --- n = sum_{k=0}^M A_{M-k} base ^ k , where M = length(a) - 1
## Value: MATRIX M where M[,i] corresponds to x[i]
## c( result ) then contains the blocks in proper order ..
## Author: Martin Maechler, Date: Wed Dec 4 14:10:27 1991
##
## Arguments: x: vector of non-negative integers
## base: Base for representation
## ndigits: Number of digits/bits to use
## EXAMPLE: digitsBase(1:24, 8) #-- octal representation
##
if(any((x - as.integer(x)) 0))
stop(`x' must be non-negative integers)
r - matrix(0, nrow = ndigits, ncol = length(x))
if(ndigits = 1) for (i in ndigits:1) {
r[i,] - x %% base
if (i 1) x - x %/% base
}
r
}
### This is an improved version of make.ASCII() in 1991's ~/S/Good-string.S !
chars8bit - function(i = 0:255)
{
## Purpose: Compute a character vector from its ASCII codes.
## We seem to have to use this complicated way thru text and parse.
## Author: Martin Maechler, Original date: Wed Dec 4, 1991
##
i - as.integer(i)
if(any(i 0 | i 255)) stop(`i' must be in 0:255)
i8 - apply(digitsBase(i, base = 8), 2, paste, collapse=)
c8 - paste('\\', i8, '', sep=)
eval(parse(text = paste(c(,paste(c8, collapse=,),), sep=)))
}
strcodes - function(x, table = chars8bit(0:255))
{
## Purpose: R (code) implementation of old S's ichar()
## --
## Arguments: x: character vector
## --
## Author: Martin Maechler, Date: 23 Oct 2003, 12:42
lapply(strsplit(x, ), match, table = table)
}
## S-PLUS has AsciiToInt() officially, and ichar() in library(examples):
AsciiToInt - ichar - function(strings) unname(unlist(strcodes(strings)))
## Examples:
all8bit - chars8bit(0:255)
matrix(all8bit, 32, 8, byrow = TRUE)
x - c(a = abc, bb = BLA blu, Person = Mächler, Zürich)
strcodes(x)
AsciiToInt(x)
__
[EMAIL PROTECTED] mailing list
https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] linking to R.dll on Win32 - issues with recent MinGW?
I was told that direct linking against foo.dll is not supported. One problem is that the link priority order gets broken, and R.dll gets used for things it should not be used for (malloc springs to mind). You should be able to use libR.a, though. It does not need to export R_Home, as you should know what that is when you call R_SetParams. I would make sure that you are really using the mallocs you think you are. (One day soon we will try to find a better solution for that, but that probably depends on me having a working Windows laptop again, as well as time to program on it.) In a few places (Rlapack.dll as I recall) we have had to force in entry points to get things resolved in the right place: pedump will tell you where they are resolved, and at least this is done at link time and not run time so is fairly easy to track down. Brian On Thu, 23 Oct 2003, Simon Urbanek wrote: I encountered several strange issues when linking to R.dll on Windows and I wonder if anyone of the Windows savvy-folks here had seen some of the issues before and have some explanation. My Rserve links to R dynamic library. That works perfectly on unix boxes and worked fairly well with older MinGW and older R (=1.7.1). What I do in fact is that I specify -L$(R_HOME)/bin -lR when linking. This produced valid exe which was linked to R.dll. In fact you could compile everything with the regular binary distribution of R, even without R sources (MinGW got all it needs directly from R.dll). Now with R-1.8.0 (which is presumably compiled with more recent MinGW) and MinGW 3.1 this doesn't work anymore on certain Win32 platforms, e.g. I got reports that on W2k Rserve bails out with Can't load R.dll. Further investigation reveals that the .exe tries to load R file and not R.dll. But if you copy R.dll to R then both R and R.dll get loaded, since R loads Rblas.dll which loads (correctly) R.dll. Then everything crashes (presumably the two dlls fight each other). XP seems to have a fix for that (i.e. a request for R will in fact load R.dll), but not W2k. Did anyone see this or does anyone have an idea how to prevent this (except for downgrading MinGW)? Now, I thought I'll use libR.a from the R sources instead of using the final R.dll, because that's what libR.a is for, right? The first obstacle was that libR.a doesn't export R_Home which I need to set in my init routine, but fortunately there is exported-vars for that case. But after finally compiling everything, Rserve crashes. It doesn't even get as far as main. What I get is this: Warning: Invalid Address specified to RtlSizeHeap( 003F, 0146008 ) and later a crash somewhere deep in libwsock32 (the trace is rather weird) ... I guess the problem is the heap, not wsock itself. Any idea what that could be? All the above was tested with MinGW-3.1. Any ideas? Is that a MinGW bug or something I did? ;) Thanks. Simon --- Simon Urbanek Department of computer oriented statistics and data analysis University of Augsburg Universitätsstr. 14 86135 Augsburg Germany Tel: +49-821-598-2236 Fax: +49-821-598-2200 [EMAIL PROTECTED] http://simon.urbanek.info __ [EMAIL PROTECTED] mailing list https://www.stat.math.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 __ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Re: ichar() function in R : 1st implementation, RFC
Martin Maechler writes:
(RFC := Request For Comments)
My preference would be that we start by adding a version of sscanf().
-k
Tim == Tim Keighley [EMAIL PROTECTED]
on Thu, 23 Oct 2003 11:45:22 +1000 writes:
Tim Hi Martin,
Tim In October 2000 you wrote to r-help:
which reminds me that I've had a desire for something like
the old S function [from the blue book, and library(examples) I think]
ichar(ch)
which would return a vector of integers, each the (decimal) equivalent of
the (ISO-latin1) representation of the corresponding characters in ch.
This should be easy enough (and be done in C).
Any volunteers?
Tim Did you get any volunteers?
no.
Thank you for reminding me!
Tim Is this function or an
Tim equivalent now available in R? I have been unsuccessful
Tim in my investigation but I do not have all the available
Tim CRAN packages, so it might be in one of them.
I've searched myself (we have almost all of them installed), and
didn't find anything.
Tim Cheers,
Tim Tim Keighley
I now did a first cut, using R only code,
(and realizing that most of chars8bit() should really happen in C).
I'm proposing to add something like this to R-devel in the near
future.
Note that AsciiToInt() and ichar() ar for S-plus and old S
compatibility, whereas I think we'd really want (equivalents) of
the three functions
digitsBase()
chars8bit()
strcodes()
in R eventually.
I'm very interested in feedback,
particularly
- function and arguments' naming
- proposals for improvements
- neat examples of usage.
Martin
Martin Maechler [EMAIL PROTECTED] http://stat.ethz.ch/~maechler/
Seminar fuer Statistik, ETH-Zentrum LEO C16 Leonhardstr. 27
ETH (Federal Inst. Technology)8092 Zurich SWITZERLAND
phone: x-41-1-632-3408fax: ...-1228
### This was digits.v() in library(sfsmisc):
### -- get it's help() file /u/maechler/R/Pkgs/sfsmisc/man/digits.Rd
digitsBase - function(x, base = 2, ndigits = 1 + floor(log(max(x),base)))
{
## Purpose: Give the vector A of the base-_base_ representation of _n_:
## --- n = sum_{k=0}^M A_{M-k} base ^ k , where M = length(a) - 1
## Value: MATRIX M where M[,i] corresponds to x[i]
##c( result ) then contains the blocks in proper order ..
## Author: Martin Maechler, Date: Wed Dec 4 14:10:27 1991
##
## Arguments: x: vector of non-negative integers
##base: Base for representation
##ndigits: Number of digits/bits to use
## EXAMPLE: digitsBase(1:24, 8) #-- octal representation
##
if(any((x - as.integer(x)) 0))
stop(`x' must be non-negative integers)
r - matrix(0, nrow = ndigits, ncol = length(x))
if(ndigits = 1) for (i in ndigits:1) {
r[i,] - x %% base
if (i 1) x - x %/% base
}
r
}
### This is an improved version of make.ASCII() in 1991's ~/S/Good-string.S !
chars8bit - function(i = 0:255)
{
## Purpose: Compute a character vector from its ASCII codes.
## We seem to have to use this complicated way thru text and parse.
## Author: Martin Maechler, Original date: Wed Dec 4, 1991
##
i - as.integer(i)
if(any(i 0 | i 255)) stop(`i' must be in 0:255)
i8 - apply(digitsBase(i, base = 8), 2, paste, collapse=)
c8 - paste('\\', i8, '', sep=)
eval(parse(text = paste(c(,paste(c8, collapse=,),), sep=)))
}
strcodes - function(x, table = chars8bit(0:255))
{
## Purpose: R (code) implementation of old S's ichar()
## --
## Arguments: x: character vector
## --
## Author: Martin Maechler, Date: 23 Oct 2003, 12:42
lapply(strsplit(x, ), match, table = table)
}
## S-PLUS has AsciiToInt() officially, and ichar() in library(examples):
AsciiToInt - ichar - function(strings) unname(unlist(strcodes(strings)))
## Examples:
all8bit - chars8bit(0:255)
matrix(all8bit, 32, 8, byrow = TRUE)
x - c(a = abc, bb = BLA blu, Person = Mächler, Zürich)
strcodes(x)
AsciiToInt(x)
__
[EMAIL PROTECTED] mailing list
https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
__
[EMAIL PROTECTED] mailing list
https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
[Rd] Accessing data files w/ --use-zip-data
I have encountered an issue while preparing some of the Bioconductor packages for our upcoming release, and Duncan Murdoch suggested that I bring one of the related points up here. The background is that we are building our packages under Windows with Rcmd install --build which will flag the zip options. When the total size of files in pkg\data are over a certain threshold of size (100k IIRC) the will be zipped in a file named Rdata.zip to save space. So far, so good. The problem arose in that at least one of the packages in the BioC suite is directly acccessing files in the data directory and not going through the data() command or related functions - and in this case the package authors are doing it in .First.lib() which causes the package loading to fail. The issue that Duncan suggested I raise is whether or not it should be considered accepted behaviour for a package author to be accessing files in pkg\data (at this time I don't know the reasoning behind the specific example here, I just know that that's what they've done) or if this should be considered a Bad Thing. Thanks -Jeff __ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Accessing data files w/ --use-zip-data
Jeff Gentry wrote: ... The issue that Duncan suggested I raise is whether or not it should be considered accepted behaviour for a package author to be accessing files in pkg\data (at this time I don't know the reasoning behind the specific example here, I just know that that's what they've done) or if this should be considered a Bad Thing. I do this in some instances where I have data in a format not supported by data(), for example, database files that are used by package programs or tests (but I have always wondered if it is the right thing to do). If it is considered a Bad Thing then there needs to be another location for files like this, perhaps inst/data or something like that. Paul Gilbert __ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Accessing data files w/ --use-zip-data
On Thu, 23 Oct 2003, Paul Gilbert wrote: Jeff Gentry wrote: ... The issue that Duncan suggested I raise is whether or not it should be considered accepted behaviour for a package author to be accessing files in pkg\data (at this time I don't know the reasoning behind the specific example here, I just know that that's what they've done) or if this should be considered a Bad Thing. I do this in some instances where I have data in a format not supported by data(), for example, database files that are used by package programs or tests (but I have always wondered if it is the right thing to do). If it is considered a Bad Thing then there needs to be another location for files like this, perhaps inst/data or something like that. inst/data will get copied into data in the installed version. We would prefer you used inst/mydata copied to mydata (for some value of `mydata' != `data'), as package spatial does. This allows the QC tools to check out aspects of the installed data directory unhindered. -- 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 __ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
[Rd] texi2dvi and buildVignettes() on Windows
I am currently writing a (private) package in which I produce pdf
files from within R using LaTeX. To do so I mainly copied some lines
from the buildVignettes() function in the tools package. This uses the
texi2dvi which is included in R's bin directory:
system(paste(file.path(R.home(), bin, texi2dvi),
--quiet --pdf, bft))
This runs fine on Linux and I assumed that as it is included in
buildVignettes() it should also work on Windows (which is important
for me because I want to share the package with a couple of colleagues
working on Windows). But apparently, texi2dvi is not provided in the
Windows distribution of R.
I already asked Duncan privately about this who kindly tried to run
buildVignettes() on the vignette in my lmtest package. He got the
results:
quote
I get the following:
buildVignettes('lmtest')
Warning message:
F:\R\rw1080/bin/texi2dvi not found
The help for buildVignettes says it's an internal command; perhaps the
thing that calls it has some workaround for Windows. I only see it
being called from src/scripts/build.in, which runs under Windows, but
I can't see any attempt to work around this limitation, so maybe it's
just not working.
/quote
So maybe I am missing something here (which is rather likely as I'm
not used to Windows at all...) but is it possible that
buildVignettes() does not work on Windows? If it has some workaround I
would be glad to learn how that works. Other suggestions on how to
compile LaTeX from within R in some (more or less) cross-platform way
are of course also very welcome.
thanks in advance,
Z
__
[EMAIL PROTECTED] mailing list
https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Ask for information about device architecture
Hi [EMAIL PROTECTED] wrote: Hello. I'm looking for documentation about the graphic device model in R. I would understand it in the details, but it seems a bit complex :) Thanks for any documents which will help me. I'm assuming you want to write a new device ... Here are a couple of places to look: The API for graphics devices (such as it is) is in R/src/include/R_ext/graphicsDevice.h There's a reasonable amount of documentation in the code; you should probably ingore the first set of NOTES and look at all of the comments in the NewDevDesc structure, plus the stuff at the end of the file. The file R/src/modules/X11/devX11.c provides a template for how a device should be implemented. It also has a reasonable amount of documentation in the code. Most of the device functions should be fairly straightforward -- depending on what sort of device you want to implement, dev_MetricInfo can be challenging, but returning 0 for all values is a valid option at least initially. Probably the trickiest part is writing the device initialisation and making sure that you allocate/deallocate structures in the correct places -- here the X11 template can be particularly useful. There are a couple of examples of add-on devices for R, so the source code for these (particularly the stuff for initialising the device) might be useful; see the gtkDevice package and the RSvgDevice package (both on CRAN). There is a document describing a reorganisation of R's graphics code (started a couple of years ago, but still ongoing -- see below) at http://www.stat.auckland.ac.nz/~paul/R/graphicsChanges.html Some of this is relevant to graphics device structures and includes a section on what should happen when a device is started and when it is killed. Note that my current plan is to make some changes to this stuff in the near future (e.g., the graphical primitive functions dev_line, etc will be getting a graphical-parameter-structure rather than individual graphical parameters col, lwd, ...), so if you go ahead with anything, please keep in touch so that I can let you know when these changes (are about to) happen. Paul -- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckland New Zealand 64 9 3737599 x85392 [EMAIL PROTECTED] http://www.stat.auckland.ac.nz/~paul/ __ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Ask for information about device architecture
I'm assuming you want to write a new device ... Yes. I plan to write a GLX device. The rgl package writed by Daniel Adler is very interesting but don't correspond to what I want. I want to write a full device, based on X11 at first, then add specific features for 3D representation. Here are a couple of places to look: R/src/include/R_ext/graphicsDevice.h R/src/modules/X11/devX11.c There are a couple of examples of add-on devices for R, so the source code for these (particularly the stuff for initialising the device) might be useful; see the gtkDevice package and the RSvgDevice package (both on CRAN). RSvgDevice sounds good :) Thanks for locations and informations. There is a document describing a reorganisation of R's graphics code (started a couple of years ago, but still ongoing -- see below) at http://www.stat.auckland.ac.nz/~paul/R/graphicsChanges.html I've timeout problems to reach the site. ( Even electrons do strike in France ;) ) Some of this is relevant to graphics device structures and includes a section on what should happen when a device is started and when it is killed. Ok. This will be very usefull to begin the (hard) work. Note that my current plan is to make some changes to this stuff in the near future (e.g., the graphical primitive functions dev_line, etc will be getting a graphical-parameter-structure rather than individual graphical parameters col, lwd, ...), so if you go ahead with anything, please keep in touch so that I can let you know when these changes (are about to) happen. Ok. I'm going to dive in the R code. If the project is still standing after this, I keep you informed. Thanks a lot, Laurent __ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
[Rd] IPFS Watch This St ock Trade
Hot Pennies.net Special Situation Alert Watch This Stock Trade!!! STOCK DETAILS Symbol: IPFS Exchange: OTCBB Shares Outstanding: 13,379,000 Current Price: $1.10 Industry: Wireless Manufacturing and Technology COMPANY DETAILS Integrated Performance Systems Inc 17300 N. Dallas Parkway, Ste. 2040 Dallas, Texas 75248 Phone: 972/381-1212 Web: www.IntegratedPerformanceSystems.com http://www.IntegratedPerformanceSystems.com BUSINESS SUMMARY Integrated Performance Systems, Inc. (IPFS) is a Dallas, Texas based holding company which serves the wireless microwave and communication industry. From its state of the art manufacturing plant north of Dallas, IPFS manufactures high performance digital and microwave products for the defense, avionics, and telecommunications industries. IPFS manufactures for industry leaders like Lockheed Martin, Rockwell, Honeywell, Ball Aerospace, L-3, Raytheon and Celestica, and has won customer awards for its high quality manufacturing. The company is engaged in a strategic plan to capitalize on its industry leadership through internal growth and synergistic acquisitions, with the goal of achieving dramatic growth while enhancing profitability through elimination of redundant overhead. http://www.hotpennies.net/images/IPFS/HPIM0606.JPG Through it's Asian subsidiary, Voium, the company has gained an entrance into the fast growing Asian wireless market by providing wireless data streaming technologies. The company has just begun offering instant news and financial messaging services to Singapore wireless customers in affiliation with Standard and Poors and Sing Tel. It is anticipated that this service will be expanded to China and to other markets and telecommunication carriers now that the revenue enhancement potential for carriers has been proven. In addition, Voium is pursuing opportunities to develop wireless infrastructure using a patented broadband technology in conjunction with Asian telecom companies. These technologies, beyond their significant profit potential, may also open the door for IPFS to begin manufacturing operations in Asia as a part of its worldwide expansion plan. IPFS benefits from: * Blue chip client base * Reputation from superior quality * Niche markets with few qualified competitors * High margins (70%) over material cost * Strong partners in Asian Telecom market Clients use IPFS because of: * Ability to deliver hard to build products * Product design improvements * Cost reductions for long running programs * Superior data streaming technology enhances revenues for Asian Telcos Highlights of recent accomplishments: * IPFS achieves positive EBITDA in fourth quarter on increased telecommunications business * Wireless data streaming partnership with Standard Poors and Sing Tel proves concept for Chinese and other Asian telcos. * IPFS receives record defense orders in month following start of Iraq war * IPFS acquires Voium, entering Asian wireless technology market IPFS is poised for explosive growth through its acquisition program and the anticipated growth in the defense and telecommunications industry over the next few years. PRODUCTS AND TECHNOLOGY OVERVIEW Manufacturing IPFS is a contract manufacturer of microwave frequency components, high-speed digital boards, antennas, and other wireless communications components. As these products become more complex, the need for IPFS' experience in delivering high speed, performance driven components continues to grow. Products manufactured in the company's 45,000 square foot plant in Frisco, Texas, include: * Metal Back Microwave Circuit Boards are used in military, avionics, and telecommunications applications where high frequency and high power generate large heat loads which must be dissipated. IPFS has sophisticated machine shop and lamination facilities which make it one of the only U.S. producers of metal back boards. Examples of metal back boards include cell tower power amplifiers and commercial aircraft collision control devices. * High Speed Digital Boards are produced with a licensed technology using insulated wires to build high-speed boards. IPFS is one of the two licensees of this technology, known as DWT, in the U.S. Currently DWT boards are used in telecommunications switching. * Antennas are a specialty of IPFS because of its unique capability to produce large format antennas up to 80 inches long. In addition, IPFS' microwave expertise allows it to produce radar antennas. Company products are used in cell towers, several U.S. missiles, and in Navy Aegis warships. * Value Added Components allow IPFS to deliver a
