Re: [Rd] external pointers
On Mon, 12 Dec 2005, Roger Bivand wrote: >> Where would be best to read about externalptr? I'm having trouble >> finding material in the manuals or the site-search. >> >> And would I need to use all the .Call machinery and C headers and SEXP >> etc in order to handle externalptr objects? > > One package using externalptr is rgdal - Tim Keitt wrote the bindings to > the external GDAL library for reading raster images to first return a > pointer to a dataset (on disk) opened by GDAL, then to use the object to > retrieve (parts of) the data. Most of the .Call/SEXP machinery is there > (for the C++ case, GDAL is C++, so GDAL manages its own memory for its > objects). The package also uses S4 classes, which may be overkill for your > purposes. RODBC is another, somewhat simpler, one. There is documentation on developer.r-project.org, but my recollection is that is was not up to date (and in particular not re finalizers). On my TODO list is to add end-user documentation to `Writing R Extensions'. -- 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] extension to missing()? {was "hist() ... helpful warning? (PR#8376)"}
[taken off R-bugs as a non-bug]
> "AndrewC" == clausen <[EMAIL PROTECTED]>
> on Sun, 11 Dec 2005 08:40:01 +0100 (CET) writes:
AndrewC> Hi Brian,
AndrewC> On Sun, Dec 11, 2005 at 04:34:50AM +, Prof Brian Ripley wrote:
>> Did you check the help page? ?plot.histogram shows plot.histogram has a
>> 'freq' argument, and the correct usage is
>>
>> plot(hist(x), freq=FALSE)
AndrewC> Ah, thanks for the explanation.
AndrewC> I didn't occur to me to check the plot.histogram()
AndrewC> help page.
[ even though it's prominently mentioned on help(hist) ?? ]
AndrewC> Besides, even if I had read it, I still don't think
AndrewC> the semantics would have been clear to me without
AndrewC> additional experimentation.
AndrewC> Perhaps it might be helpful to document in the
AndrewC> hist() help page which attributes are stored in the
AndrewC> hist() object.
you mean the 'histogram' object.
Yes, that might be helpful; diffs against
https://svn.R-project.org/R/trunk/src/library/graphics/man/hist.Rd
are welcome.
AndrewC> Alternatively/additionally, hist()
AndrewC> could emit a warning or error if plot=FALSE and
AndrewC> irrelevant (non-stored) attributes are set.
interesting proposal.
I've looked at it for a bit, and found that it seems not to be
doable both easily and elegantly, at least not along the first
line I've tried, and so I think it raises a slightly more
general somewhat interesting problem:
Since *most* arguments of hist.default, including '...' are only
made use of when plot = TRUE, and the code with the warning would
have to look at all of them, and we want to have a nicely
maintainable solution, I had wanted to have a solution which
looks at {almost} all formals() and which of them are missing().
Since formals() is a list,
is.miss <- lapply(formals(), missing)
was the one I've tried but failed with
Error in lapply(fm, missing) : 2 arguments passed to 'missing' which requires 1
which might be a bit astonishing {missing is Primitive though..}
and of course
is.miss <- lapply(formals(), function(n) missing(n))
``works'' but trivially {why ?} and hence not usefully.
I've needed to make use of eval and substitute in order to make
use of missing() here.
Hence, I'm wondering if we maybe could generalize missing()
by something like missing(all.formals = TRUE) {or better syntax}
which would make the following a bit easier.
Here's a context diff of my working version of hist.default()
which implements the above proposal:
--- hist.R (Revision 36695)
+++ hist.R (working copy)
@@ -108,7 +108,19 @@
axes = axes, labels = labels, ...)
invisible(r)
}
-else r
+else { ## plot is FALSE
+nf <- names(formals()) ## all formals but those 4:
+nf <- nf[match(nf, c("x", "breaks", "nclass", "plot"), nomatch=0) == 0]
+missE <- lapply(nf, function(n)
+substitute(missing(.), list(. = as.name(n
+not.miss <- ! sapply(missE, eval, envir = environment())
+if(any(not.miss))
+warning(sprintf(ngettext(sum(not.miss),
+ "argument %s is not made use of",
+ "arguments %s are not made use of"),
+paste(sQuote(nf[not.miss]), collapse=", ")))
+r
+}
}
plot.histogram <-
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] data.frame() size
I guess the mail list precludes attachments then, makes sense. I have sent
the modified source directly to anyone who has asked.
I had a look at the light-weight data.frame class post
(http://tolstoy.newcastle.edu.au/R/devel/05/05/0837.html) :
> Now the transcript itself:
> # the motivation: subscription of a data.frame is *much* (almost 20
times) slower than that of a list
> # compare
> n = 1e6
> i = seq(n)
> x = data.frame(a=seq(n), b=seq(n))
> system.time(x[i,], gcFirst=TRUE)
[1] 1.01 0.14 1.14 0.00 0.00
>
> x = list(a=seq(n), b=seq(n))
> system.time(lapply(x, function(col) col[i]), gcFirst=TRUE)
[1] 0.06 0.00 0.06 0.00 0.00
>
> # the solution: define methods for the light-weight data.frame class
> lwdf = function(...) structure(list(...), class = "lwdf")
> ...
But if I have understood correctly I think the time difference here is just
down to the rownames. The rownames are 1:n stored in character form. This
takes the most time and space in this example, but are never used. I'm not
sure why 1:n in character form would ever be useful in fact. Running the
example above with my modifications appears to fix the problem ie negligible
time difference. I needed to make a one line change to [.data.frame, and
I've sent that to anyone who requested the code.
I can see the problem :
> apropos("data.frame")
[1] "[.data.frame" "as.matrix.data.frame"
"data.frame""dim.data.frame"
[5] "format.data.frame" "print.data.frame"
".__C__data.frame" "aggregate.data.frame"
[9] "$<-.data.frame""Math.data.frame"
"Ops.data.frame""Summary.data.frame"
[13] "[.data.frame" "[<-.data.frame"
"[[.data.frame" "[[<-.data.frame"
[17] "as.data.frame" "as.data.frame.AsIs"
"as.data.frame.Date""as.data.frame.POSIXct"
[21] "as.data.frame.POSIXlt" "as.data.frame.array"
"as.data.frame.character" "as.data.frame.complex"
[25] "as.data.frame.data.frame" "as.data.frame.default"
"as.data.frame.factor" "as.data.frame.integer"
[29] "as.data.frame.list""as.data.frame.logical"
"as.data.frame.matrix" "as.data.frame.model.matrix"
[33] "as.data.frame.numeric" "as.data.frame.ordered"
"as.data.frame.package_version" "as.data.frame.raw"
[37] "as.data.frame.table" "as.data.frame.ts"
"as.data.frame.vector" "as.list.data.frame"
[41] "as.matrix.data.frame" "by.data.frame"
"cbind.data.frame" "data.frame"
[45] "dim.data.frame""dimnames.data.frame"
"dimnames<-.data.frame" "duplicated.data.frame"
[49] "format.data.frame" "is.data.frame"
"is.na.data.frame" "mean.data.frame"
[53] "merge.data.frame" "print.data.frame"
"rbind.data.frame" "row.names.data.frame"
[57] "row.names<-.data.frame""rowsum.data.frame"
"split.data.frame" "split<-.data.frame"
[61] "stack.data.frame" "subset.data.frame"
"summary.data.frame""t.data.frame"
[65] "transform.data.frame" "unique.data.frame"
"unstack.data.frame""xpdrows.data.frame"
>
But I think the changes would be quick to make. Is anything else effected?
Do any test suites exist to confirm R hasn't broken?
On the face of it allowing data frames to have null row names seems a small
change, and would make them consistent with matrices, with large time and
space benefits. However, I can see the argument for a new class instead for
safety. Whats the consenus?
-Original Message-
From: Hin-Tak Leung [mailto:[EMAIL PROTECTED]
Sent: 09 December 2005 18:41
To: Gabor Grothendieck
Cc: Matthew Dowle; r-devel@r-project.org; Peter Dalgaard
Subject: Re: [Rd] [R] data.frame() size
Gabor Grothendieck wrote:
> There was nothing attached in the copy that came through
> to me.
I like to see that patch also.
> By the way, there was some discussion earlier this year
> on a light-weight data.frame class but I don't think anyone ever
> posted any code.
It may have been me. I am working on a bit-packed data.frame which only uses
2-bits per unit of data, so it is 4 units per RAWSXP. (work in progress,
nothing to show).
So I am very interested to see the patch.
Yes, I took a couple of weeks reading/learning where have all the memory
gone in data.frame. The rowname/column names allocation is a bit stupid.
Each rowname and each column name is a full R object, so there is a 32(or
28) byte overhead just from managing that, before the STRSXP for the actual
string, which is another X bytes. so for an 1 x N data.frame with integers
for content, the the content is 4-byte * N, but the rowname/columnname is 32
* N -ish. (a 9x increase). Word is 32-bit on most
Re: [Rd] [R] data.frame() size
Data frames have unique row names *by definition* (White Book p.57).
Note that R is extensible, so any package writer has (for 14 years since
the White Book) been entitled to assume that. A minimum test suite is to
run R CMD check on all CRAN packages, and to read all the relevant
documentation. That would reveal a large number of uses of row names and
of their uniqueness.
On Mon, 12 Dec 2005, Matthew Dowle wrote:
I guess the mail list precludes attachments then, makes sense. I have sent
the modified source directly to anyone who has asked.
I had a look at the light-weight data.frame class post
(http://tolstoy.newcastle.edu.au/R/devel/05/05/0837.html) :
Now the transcript itself:
# the motivation: subscription of a data.frame is *much* (almost 20
times) slower than that of a list
# compare
n = 1e6
i = seq(n)
x = data.frame(a=seq(n), b=seq(n))
system.time(x[i,], gcFirst=TRUE)
[1] 1.01 0.14 1.14 0.00 0.00
x = list(a=seq(n), b=seq(n))
system.time(lapply(x, function(col) col[i]), gcFirst=TRUE)
[1] 0.06 0.00 0.06 0.00 0.00
# the solution: define methods for the light-weight data.frame class
lwdf = function(...) structure(list(...), class = "lwdf")
...
But if I have understood correctly I think the time difference here is just
down to the rownames. The rownames are 1:n stored in character form. This
takes the most time and space in this example, but are never used. I'm not
sure why 1:n in character form would ever be useful in fact. Running the
example above with my modifications appears to fix the problem ie negligible
time difference. I needed to make a one line change to [.data.frame, and
I've sent that to anyone who requested the code.
I can see the problem :
apropos("data.frame")
[1] "[.data.frame" "as.matrix.data.frame"
"data.frame""dim.data.frame"
[5] "format.data.frame" "print.data.frame"
".__C__data.frame" "aggregate.data.frame"
[9] "$<-.data.frame""Math.data.frame"
"Ops.data.frame""Summary.data.frame"
[13] "[.data.frame" "[<-.data.frame"
"[[.data.frame" "[[<-.data.frame"
[17] "as.data.frame" "as.data.frame.AsIs"
"as.data.frame.Date""as.data.frame.POSIXct"
[21] "as.data.frame.POSIXlt" "as.data.frame.array"
"as.data.frame.character" "as.data.frame.complex"
[25] "as.data.frame.data.frame" "as.data.frame.default"
"as.data.frame.factor" "as.data.frame.integer"
[29] "as.data.frame.list""as.data.frame.logical"
"as.data.frame.matrix" "as.data.frame.model.matrix"
[33] "as.data.frame.numeric" "as.data.frame.ordered"
"as.data.frame.package_version" "as.data.frame.raw"
[37] "as.data.frame.table" "as.data.frame.ts"
"as.data.frame.vector" "as.list.data.frame"
[41] "as.matrix.data.frame" "by.data.frame"
"cbind.data.frame" "data.frame"
[45] "dim.data.frame""dimnames.data.frame"
"dimnames<-.data.frame" "duplicated.data.frame"
[49] "format.data.frame" "is.data.frame"
"is.na.data.frame" "mean.data.frame"
[53] "merge.data.frame" "print.data.frame"
"rbind.data.frame" "row.names.data.frame"
[57] "row.names<-.data.frame""rowsum.data.frame"
"split.data.frame" "split<-.data.frame"
[61] "stack.data.frame" "subset.data.frame"
"summary.data.frame""t.data.frame"
[65] "transform.data.frame" "unique.data.frame"
"unstack.data.frame""xpdrows.data.frame"
But I think the changes would be quick to make. Is anything else effected?
Do any test suites exist to confirm R hasn't broken?
On the face of it allowing data frames to have null row names seems a small
change, and would make them consistent with matrices, with large time and
space benefits. However, I can see the argument for a new class instead for
safety. Whats the consenus?
-Original Message-
From: Hin-Tak Leung [mailto:[EMAIL PROTECTED]
Sent: 09 December 2005 18:41
To: Gabor Grothendieck
Cc: Matthew Dowle; r-devel@r-project.org; Peter Dalgaard
Subject: Re: [Rd] [R] data.frame() size
Gabor Grothendieck wrote:
There was nothing attached in the copy that came through
to me.
I like to see that patch also.
By the way, there was some discussion earlier this year
on a light-weight data.frame class but I don't think anyone ever
posted any code.
It may have been me. I am working on a bit-packed data.frame which only uses
2-bits per unit of data, so it is 4 units per RAWSXP. (work in progress,
nothing to show).
So I am very interested to see the patch.
Yes, I took a couple of weeks reading/learning where have all the memory
gone in data.frame. The rowname/column names allocation is a bit stupid.
Each rowname and each column name is a full R object, so there is a 32(or
28) byte overhead just from managing that, before the STRSXP for the actual
stri
Re: [Rd] [R] data.frame() size
Prof Brian Ripley wrote: > Data frames have unique row names *by definition* (White Book p.57). Yes - I happened to have the White Book on my desk (not mine...) - indeed, the first sentence on page 57 is (quote verbatim, the "never" is in italic in the book, which I have added the "*" before and after): If all else fails, the row names are just the row numbers. They are *never* null and must be unique. So patching data.frame.R is quite wrong. However, the rowname/colname overhead is definitely an issue for processing of large data sets, both for speed and amount of memory consumed. So it is probably best to extend the data.frame class and call it something else instead, for those who needs to go that route. (What I am doing is already called a different name so it isn't affected by this argument). Hin-Tak __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] data.frame() size
Hin-Tak Leung <[EMAIL PROTECTED]> writes: > Prof Brian Ripley wrote: > > Data frames have unique row names *by definition* (White Book p.57). > > Yes - I happened to have the White Book on my desk (not mine...) > - indeed, the first sentence on page 57 is (quote verbatim, the > "never" is in italic in the book, which I have added the "*" before > and after): > > If all else fails, the row names are just the row numbers. They > are *never* null and must be unique. > > So patching data.frame.R is quite wrong. However, the rowname/colname > overhead is definitely an issue for processing of large data sets, > both for speed and amount of memory consumed. So it is probably best > to extend the data.frame class and call it something else instead, > for those who needs to go that route. Exactly. I recall from the Insightful people at the DSC in Seattle that something is going to happen with the rownames in S-PLUS or has happened in the latest release, but I don't remember exactly how they did it, and if and how it had to do with their "big dataframe" code. We might want R to follow suit in this respect. Other options might include doing something about the string-storage of rownames, which is quite wasteful in R (every string is an R object, a string vector is really a list of CHARSXP objects). Either one could improve on the internal storage format, or one could allow rownames to be integers with semantics like "virtual strings" so that x["123",] still works. > (What I am doing is already called a different name so it isn't > affected by this argument). > > Hin-Tak > > > -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Problems with sending data to FORTRAN subrutine
Dear ExpeRts!
I have problem with sending data to FORTRAN subroutine on Windows XP and R
2.1.1. When I call it using .Fortran, I get the following error:
R for Windows GUI front-end has encountered a problem and needs to close. We
are sorry for the inconvenience.
Error signature
AppName: rgui.exe AppVer: 2.11.50620.0 ModName: read.dll
ModVer: 0.0.0.0 Offset: 1683
It seams that the error is somehow related to the size of the data. Here are
the calls:
dyn.load("C:/ales/b_for/read.dll")
#The FORTRUN subroutine used to create the "read.dll" ("read.f") is attached
(and in case something happens to the attachment also at the end of the
mail.
n<-as.integer(134);k<-as.integer(2);M<-matrix(as.double(rnorm(n=n^2)),nrow=n,ncol=n);.Fortran("read",M=M,n=as.integer(n),clu=as.integer(sample(1:k,size=n,replace=TRUE)),
k=as.integer(k),diag=as.integer(1),err=as.double(0.0),E=matrix(as.double(0),ncol=k,nrow=k),
BM=matrix(as.double(0),ncol=k,nrow=k))
#This works ok
n<-as.integer(134);k<-as.integer(4);M<-matrix(as.double(rnorm(n=n^2)),
nrow=n,ncol=n);.Fortran("read",M=M,n=as.integer(n),clu=as.integer(sample(1:k,size=n,replace=TRUE)),
k=as.integer(k),diag=as.integer(1),err=as.double(0.0),E=matrix(as.double(0),ncol=k,nrow=k),
BM=matrix(as.double(0),ncol=k,nrow=k))
#Now the k is incrised form 2 to 4 and the error occours.
n<-as.integer(40);k<-as.integer(4);M<-matrix(as.double(rnorm(n=n^2)),nrow=n,ncol=n);.Fortran("read",M=M,n=as.integer(n),clu=as.integer(sample(1:k,size=n,replace=TRUE)),
k=as.integer(k),diag=as.integer(1),err=as.double(0.0),E=matrix(as.double(0),ncol=k,nrow=k),
BM=matrix(as.double(0),ncol=k,nrow=k))
#If I leave the k at 4 and reduce the n to 40, then it works.
Any suggestions are welcomed. Thank you in advance!
Best regards,
Ales Ziberna
The commands used to generate "read.dll".
g77 -c read.f
R CMD SHLIB read.o
The FORTRAN subroutine ("read.f"):
subroutine read(M,n,clu,k,diag,err,E,BM)
INTEGER n, clu, k, i, j, ii, nA, nAD
DOUBLE PRECISION M, E, BM, A, AD, vecA, vecAD, err, mean, temp, ss
LOGICAL diag
DIMENSION M(n,n), clu(n), E(k,k), BM(k,k), A(k,k,n*n), AD(k,n),
nA(k,k), nAD(k), vecA(n*n), vecAD(n)
end
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] notification (PR#8383)
--=_Part_37369_7912743.1134408569488 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit The Gardener Humanitarian Project,Van-gennelaan 371,4512DT,Delft,Holland PIN No:627462128TW, I wish to bring to your information that at the just concluded end of year draw of above named humanitarian firm held on the 9th of December,2005. Be informed also that the identification number fixed to your email address propelled out of the third jump,making you the winner of the slated sum of two hundred and fifty thousand USD($250,000). The source of fund is majorly from well meaning companies and humananitarian sprited industries selected from european community.Based on the joint management guideline,a reasonable proportion of your win(10% at the minumum) should be disbursed to a selfless activity in your locality ,on the reception of your fund. Application should be forwarded to Mrs Marina Van Kleiweg via e-mail ;([EMAIL PROTECTED]) Accept my heart felt congratulations. Mrs Patricia Peter PS:Kindly state your PIN No in your expected application. --=_Part_37369_7912743.1134408569488 Content-Type: text/html;charset="UTF-8" Content-Transfer-Encoding: 7bit The Gardener Humanitarian Project,Van-gennelaan 371,4512DT,Delft,Holland PIN No:627462128TW, I wish to bring to your information that at the just concluded end of year draw of above named humanitarian firm held on the 9th of December,2005. Be informed also that the identification number fixed to your email address propelled out of the third jump,making you the winner of the slated sum of two hundred and fifty thousand USD($250,000). The source of fund is majorly from well meaning companies and humananitarian sprited industries selected from european community.Based on the joint management guideline,a reasonable proportion of your win(10% at the minumum) should be disbursed to a selfless activity in your locality ,on the reception of your fund. Application should be forwarded to Mrs Marina Van Kleiweg via e-mail ;(mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED].) Accept my heart felt congratulations. Mrs Patricia Peter PS:Kindly state your PIN No in your expected application. --=_Part_37369_7912743.1134408569488-- __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] FW: Bug in sum() with named data frame arguments
I got an email error message when I attempted to send this from my work
account. I have manually added it to the bug tracker, and am resending from
my personal account.
-G
On 12/12/05, Warnes, Gregory R <[EMAIL PROTECTED]> wrote:
>
>
>
> > -Original Message-
> > From: Warnes, Gregory R
> > Sent: Monday, December 12, 2005 1:53 PM
> > To: '[EMAIL PROTECTED]'
> > Subject: Bug in sum() with named data frame arguments
> >
> >
> > Sum fails if it is passed a data frame argument with a name. It also
> generated different error messages depending on exactly how the data frame
> is passed in:
> >
> > > df <- data.frame(m1=1:2,m2=3:4)
> > > df
> > m1 m2
> > 1 1 3
> > 2 2 4
> > > sum(df) # succeeds
> > [1] 10
> > > sum(df=df) # fails
> > Error in as.matrix(x) : argument "x" is missing, with no default
> > > sum(1,df=df) # fails, different error message
> > Error in sum(..., na.rm = na.rm) : invalid 'mode' of argument
> > > sum(df=df,1) # fails, different error message
> > Error in sum.default(..., na.rm = na.rm) :
> > invalid 'mode' of argument
> > ## Note: no sum.default exists...
> >
> >
> > No similar problem exists for matrixes:
> >
> > > x <- as.matrix(df)
> > > sum(x)
> > [1] 10
> > > sum(df=x)
> > [1] 10
> > > sum(m1=x)
> > [1] 10
> > > sum(1,m1=x)
> > [1] 11
> > > sum(m1=x,1)
> > [1] 11
> > >
> >
> > The cause seems to be that the generic sum is defined as:
> >
> > > sum
> > function (..., na.rm = FALSE)
> > .Internal(sum(..., na.rm = na.rm))
> >
> >
> > but the S3 methods are defined as
> >
> > > Summary.data.frame
> > function (x, ...)
> > {
> > x <- as.matrix(x)
> > if (!is.numeric(x) && !is.complex(x))
> > stop("only defined on a data frame with all numeric or complex
> variables")
> > NextMethod(.Generic)
> > }
> >
> >
> > I suspect that the proper resolution of this bug is to change the base
> 'sum' method to provide a 1st argument named 'x', and to update the
> documentation.
> >
> > Note that the current implementation also failes when more than one data
> frame argument is supplied:
> >
> > > sum(y,y,y)
> > Error in sum.default(..., na.rm = na.rm) :
> > invalid 'mode' of argument
> >
> > while the same thing with matrixes works fine:
> >
> > > sum(y,y,y)
> > Error in sum.default(..., na.rm = na.rm) :
> > invalid 'mode' of argument
> >
> > -Greg
> >
> > Gregory R. Warnes, Ph.D.
> > Associate Director, Non-Clinical Statistics
> > Pfizer Global Research and Development
> >
>
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] extension to missing()? {was "hist() ... helpful warning? (PR#8376)"}
Hi Martin,
On Mon, Dec 12, 2005 at 12:20:06PM +0100, Martin Maechler wrote:
> AndrewC> I didn't occur to me to check the plot.histogram()
> AndrewC> help page.
>
> [ even though it's prominently mentioned on help(hist) ?? ]
Yes. I expected plot.histogram() was something that no-one ever
calls directly (and I still expect that!), and I expected hist()
to pass everything on to plot.histogram().
I guess I think the most elegant design would be to remove all
plotting functionality from hist(), and put all arguments into
plot.histogram(). Or make histogram objects store everything.
But, I expect you can't changed this now, for compatability / user
familiarity reasons...
> AndrewC> Perhaps it might be helpful to document in the
> AndrewC> hist() help page which attributes are stored in the
> AndrewC> hist() object.
> you mean the 'histogram' object.
Yes.
> Yes, that might be helpful; diffs against
> https://svn.R-project.org/R/trunk/src/library/graphics/man/hist.Rd
> are welcome.
I added it to my R-TODO. (I doubt I will be able to get to this
for about a year... I am at the oppressive beginning of an obnoxious
degree program!)
> and of course
> is.miss <- lapply(formals(), function(n) missing(n))
> ``works'' but trivially {why ?} and hence not usefully.
R's introspection capabilities are a little mysterious to me.
The missing() docs mention that it should be improved in future.
That might be a better long-term solution?
Cheers,
Andrew
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] external pointers
There's also Luke's own site, in particular http://www.stat.uiowa.edu/ ~luke/R/weakfinex.html On Dec 12, 2005, at 12:16 AM, Prof Brian Ripley wrote: > On Mon, 12 Dec 2005, Roger Bivand wrote: > >>> Where would be best to read about externalptr? I'm having trouble >>> finding material in the manuals or the site-search. >>> >>> And would I need to use all the .Call machinery and C headers and >>> SEXP >>> etc in order to handle externalptr objects? >> >> One package using externalptr is rgdal - Tim Keitt wrote the >> bindings to >> the external GDAL library for reading raster images to first return a >> pointer to a dataset (on disk) opened by GDAL, then to use the >> object to >> retrieve (parts of) the data. Most of the .Call/SEXP machinery is >> there >> (for the C++ case, GDAL is C++, so GDAL manages its own memory for >> its >> objects). The package also uses S4 classes, which may be overkill >> for your >> purposes. > > RODBC is another, somewhat simpler, one. > > There is documentation on developer.r-project.org, but my > recollection is > that is was not up to date (and in particular not re finalizers). > On my > TODO list is to add end-user documentation to `Writing R Extensions'. > > -- > 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 --- Byron Ellis ([EMAIL PROTECTED]) "Oook" -- The Librarian __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] external pointers
On Mon, 12 Dec 2005, Byron Ellis wrote: > There's also Luke's own site, in particular http://www.stat.uiowa.edu/ > ~luke/R/weakfinex.html Hmm, that _is_ a link on the page I pointed you to, under its actual subject, weak references. > On Dec 12, 2005, at 12:16 AM, Prof Brian Ripley wrote: > >> On Mon, 12 Dec 2005, Roger Bivand wrote: >> Where would be best to read about externalptr? I'm having trouble finding material in the manuals or the site-search. And would I need to use all the .Call machinery and C headers and SEXP etc in order to handle externalptr objects? >>> >>> One package using externalptr is rgdal - Tim Keitt wrote the bindings to >>> the external GDAL library for reading raster images to first return a >>> pointer to a dataset (on disk) opened by GDAL, then to use the object to >>> retrieve (parts of) the data. Most of the .Call/SEXP machinery is there >>> (for the C++ case, GDAL is C++, so GDAL manages its own memory for its >>> objects). The package also uses S4 classes, which may be overkill for your >>> purposes. >> >> RODBC is another, somewhat simpler, one. >> >> There is documentation on developer.r-project.org, but my recollection is >> that is was not up to date (and in particular not re finalizers). On my >> TODO list is to add end-user documentation to `Writing R Extensions'. -- 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
