[Rd] Feil i websider (PR#7228)
Warnings about /metno/internweb/fouweb/htdocs/teknisk/verktoy/R/faq.html BAD LINK: http://stat.ethz.ch/R/manual/ BAD LINK: http://nlme.stat.wisc.edu/MEMSS/ BAD LINK: http://stats.mth.uea.ac.uk/Rcgi/ BAD LINK: http://software.biostat.washington.edu/statsoft/ess/ Warnings about /metno/internweb/fouweb/htdocs/teknisk/verktoy/R/resources.html BAD LINK: http://fou.oslo.dnmi.no/teknisk/verktoy/R/[EMAIL PROTECTED] BAD LINK: http://fou.oslo.dnmi.no/teknisk/verktoy/R/[EMAIL PROTECTED] BAD LINK: http://fou.oslo.dnmi.no/teknisk/verktoy/R/[EMAIL PROTECTED] BAD LINK: http://fou.oslo.dnmi.no/teknisk/verktoy/R/[EMAIL PROTECTED] BAD LINK: http://fou.oslo.dnmi.no/teknisk/verktoy/R/[EMAIL PROTECTED] BAD LINK: http://fou.oslo.dnmi.no/teknisk/verktoy/R/[EMAIL PROTECTED] BAD LINK: http://mirror.aarnet.edu.au/pub/CRAN/ BAD LINK: http://mirrors.theonlinerecordstore.com/CRAN/ __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
RE: [Rd] memory allocation questions
Thanks both All seems to work now, whether I use R_chk_alloc etc. (as per RS.h) or the Delphi routines. Sounds like I might as well stick with the latter though, since I have to do the housekeeping anyway. Mark #>should I bother using the R [memory allocation] routines instead [of the Delphi built-ins]? # #There is not much reason to need to use the R routines. The #disadvantages of using Delphi allocation are: # # - Your allocations won't be automatically deleted by the garbage #collector (but neither are those of Calloc, you need R_alloc for that) # - If allocation fails, it will be up to you to detect that and deal #with it. # #The disadvantage of using the R routines Calloc etc. is that # - You need to translate C macros to Delphi. # - You need to worry about whether the RS.h file has changed with #each release (but the Calloc etc. macros are likely to be very stable, #they haven't changed since 2000). # #Duncan Murdoch # #> if I do use the R replacements, what are their names nowadays? # #> R-EXTS refers to Calloc, Realloc and Free, but these aren't exported by #> R.DLL (for R1.9.0 or 1.9.1) and I couldn't find mention of any name #> change in the NEWS file. # #There is no change. R-exts does say you must include the appropriate #headers, in this case include/R_ext/RS.h. They are defines, and not just #simple calls to entry points. I'll leave you to take a closer look. # #-- #Brian D. Ripley, [EMAIL PROTECTED] __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] prototype in setClass.
Hi!
To specify a prototype in the setClass declaration is a great feature.
But prototype seems no to work for slots of the "super" class.
eg. The following code is declaring first the super class "List". This class has a
slot "content".
The class "AtomList" inherits from it and I would like to set content="Atom" by
prototype(content="Atom").
But after new("AtomList") is called the slot content is empty as you can see running
the code below.
setClass("List"
,representation(
uniq="logical"
,content="character" # would
like to set this when declaring the inheriting class.
,names="character")
,contains="list"
,prototype(uniq=FALSE)
)
setClass("AtomList"
,contains="List"
,prototype(content="Atom")## would like to
specify this
)
new("AtomList")
An object of class "AtomList"
list()
Slot "uniq":
[1] FALSE
Slot "content":
character(0)###<-still
not specified even if provided in prototype.
Slot "names":
character(0)
Version:
R : Copyright 2004, The R Foundation for Statistical Computing
Version 2.0.0 alpha (2004-09-14), ISBN 3-900051-07-0
or
R1.9.1 patched.
/E
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
RE: [Rd] how to use update if method for formula is not in namesp ace?
> From: Prof Brian Ripley > > On Tue, 14 Sep 2004, Liaw, Andy wrote: > > > Dear R-devel, > > > > I've noticed that if the method for formula is not exported > in NAMESPACE, > > then update() would fail. As an example: > > > > > library(e1071) > > > data(iris) > > > iris.svm <- svm(Species ~ ., data=iris) > > > update(iris.svm) > > Error in eval(expr, envir, enclos) : couldn't find function > "svm.formula" > > > > The same thing happens with randomForest, because > randomForest.formula() was > > not exported. Is this the intended behavior of update()? > What would be the > > preferred work-around? > > It is. randomForest.formula should be written to report its > call as to > randomForest. Take a look at e.g. rlm.formula. Got it! Works now. Many thanks! Best, Andy > -- > 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://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] how to use update if method for formula is not in namespace?
On Tue, 14 Sep 2004, Liaw, Andy wrote: > Dear R-devel, > > I've noticed that if the method for formula is not exported in NAMESPACE, > then update() would fail. As an example: > > > library(e1071) > > data(iris) > > iris.svm <- svm(Species ~ ., data=iris) > > update(iris.svm) > Error in eval(expr, envir, enclos) : couldn't find function "svm.formula" > > The same thing happens with randomForest, because randomForest.formula() was > not exported. Is this the intended behavior of update()? What would be the > preferred work-around? It is. randomForest.formula should be written to report its call as to randomForest. Take a look at e.g. rlm.formula. -- 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://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] how to use update if method for formula is not in namespace?
Dear R-devel, I've noticed that if the method for formula is not exported in NAMESPACE, then update() would fail. As an example: > library(e1071) > data(iris) > iris.svm <- svm(Species ~ ., data=iris) > update(iris.svm) Error in eval(expr, envir, enclos) : couldn't find function "svm.formula" The same thing happens with randomForest, because randomForest.formula() was not exported. Is this the intended behavior of update()? What would be the preferred work-around? Best, Andy __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] is it a typo?
> "AndyL" == Liaw, Andy <[EMAIL PROTECTED]> > on Tue, 14 Sep 2004 10:28:31 -0400 writes: AndyL> In ?options: AndyL> 'warning.expression': an R code expression to be called if a AndyL> warning is generated, replacing the standard message. If AndyL> non-null is called irrespective of the value of option AndyL> 'warn'. AndyL> Is there a missing `it' between `non-null' and `is'? yes, thank you -- now fixed. Martin __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] documentation error par("cin") and par("cra") (PR#7227)
On Tue, 14 Sep 2004 [EMAIL PROTECTED] wrote:
> the help of par() claims that
> cin and cra are
> c(width, height)
That is the design intention.
> but it appears to be rather
> c(height, width)
On what evidence? W has no descenders, so its height is less than the
typical box. It's coincidence, BTW, that the numbers are the same: I get
> par("cin")
[1] 0.15 0.20
> strheight("W", unit="inches")
[1] 0.1196667
and characters are on average taller than they are wide. strheight
reports the same for all characters, but strwidth does not.
Here is the code (in par.c)
else if (streql(what, "cin")) {
value = allocVector(REALSXP, 2);
REAL(value)[0] = Rf_dpptr(dd)->cra[0]*Rf_dpptr(dd)->ipr[0];
REAL(value)[1] = Rf_dpptr(dd)->cra[1]*Rf_dpptr(dd)->ipr[1];
}
cra is set in the driver, and postscript has
dd->cra[0] = 0.9 * pointsize;
dd->cra[1] = 1.2 * pointsize;
whereas windows() has
gcharmetric(xd->gawin, xd->font, -1, &a, &d, &w);
dd->cra[0] = w * xd->rescale_factor;
dd->cra[1] = (a + d) * xd->rescale_factor;
so it really is (width, height). OTOH, strheight doesn't look at the
character, just the height of "M" (no descenders). See the comment
/* cra is based on the font pointsize at the
* time the device was created.
* Adjust for potentially different current pointsize
* This is a crude calculation that might be better
* performed using a device call that responds with
* the current font pointsize in device coordinates.
*/
/* Add in the ascent of the font, if available */
--
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://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] is it a typo?
In ?options: 'warning.expression': an R code expression to be called if a warning is generated, replacing the standard message. If non-null is called irrespective of the value of option 'warn'. Is there a missing `it' between `non-null' and `is'? Best, Andy __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] documentation error par("cin") and par("cra") (PR#7227)
Dear all,
the help of par() claims that
cin and cra are
c(width, height)
but it appears to be rather
c(height, width)
Best regards
Jens Oehlschlägel
> plot.new()
> strheight("W", unit="inches")
[1] 0.1354167
> par("cin")
[1] 0.1354167 0.1875000
> version
_
platform i386-pc-mingw32
arch i386
os mingw32
system i386, mingw32
status
major1
minor9.1
year 2004
month06
day 21
language R
--
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] memory allocation questions
On Tue, 14 Sep 2004 09:38:55 +1000, <[EMAIL PROTECTED]> wrote : >Dear R-devel > >This one seems a bit arcane for R-help. I very often use R to call routines written >in Delphi (son of Pascal), doing "persistent" memory allocation within Delphi. That >is, I start R and load the Delphi DLL; then I use .C to call a Delphi routine which >allocates a piece of memory X and returns to R a pointer to X; then I do some more >stuff in R; then I call another Delphi routine, passing it the pointer to X. Finally, >I call another Delphi routine from R to free the memory at X. > >For years, I've used Delphi's own memory manager for this (the basic one, not >SHAREMEM.DLL), but recently I've been wondering whether it would be better to use R's >wrappers for "alloc" etc. instead. The Delphi routines seem generally to work fine, >but my nagging concern [based on ignorance] is whether R's memory manager will >somehow not realize that Delphi has already allocated the memory, and will overwrite >it inadvertently. It's fairly easy to replace Delphi's manager with the R routines, >following the instructions in section 5.1.2 of R-EXTS and the Delphi manual. So my >first question is: > >should I bother using the R routines instead? There is not much reason to need to use the R routines. The disadvantages of using Delphi allocation are: - Your allocations won't be automatically deleted by the garbage collector (but neither are those of Calloc, you need R_alloc for that) - If allocation fails, it will be up to you to detect that and deal with it. The disadvantage of using the R routines Calloc etc. is that - You need to translate C macros to Delphi. - You need to worry about whether the RS.h file has changed with each release (but the Calloc etc. macros are likely to be very stable, they haven't changed since 2000). Duncan Murdoch __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Re: [R] R-2.0.0 CMD check . and datasets
This is question about the the development version of R and should have gone to the R-devel list according to the posting guide. R-devel is intended for questions and discussion about code development in R. Questions likely to prompt discussion unintelligible to non-programmers should go to to R-devel. Did you read the NEWS for that version, and did you look at the notes on developer.r-project.org for 2.0.0 (as posted to the R-devel list recently)? If not, please do so now. Please, as the FAQ asks, don't give us an incorrect explanation but facts. Your problem *appears* to be that you have ignored the following statement in `Writing R Extensions': Note that R code should be "self-sufficient" and not make use of extra functionality provided by the package, so that the data file can also be used without having to load the package. and as the notes for 2.0.0 say, this is now enforced. As you have quibbled once before, let me stress this a pre-existing error that is now detected. On Tue, 14 Sep 2004, Robin Hankin wrote: > Hello everyone > > I'm having a little difficulty with R-2.0.0 CMD check. My field is > Bayesian calibration of computer models. > > The problem is that I have a large collection of toy datasets, that > in R-1.9.1 were specified with lines > like this: > > x.toy <- 1:6 > y.toy <- computer.model(x.toy) > z.toy <- reality(x.toy) > > in file ./data/toys.R ; functions computer.model() and reality() are > defined in ./R/calibrator.R. > > [In this application, the (toy) functions computer.model() and > reality() are the objects of inference, as > per the standard Bayesian approach. The functions are nonrandom in > that they are deterministic but > random in the Bayesian sense. Thus y.toy and z.toy are observations > of (random) functions]. > > In the Real World, one would have access to x.toy, y.toy, and z.toy > but not (of course) computer.model() > or reality(). These functions should never be seen or referred to > because they are Unknown. > > So, in many of the code examples, I use things like > "some.function(y.toy, z.toy)" . . . and I need > y.toy and z.toy to be consistent between different functions. > > I think R-2.0.0 sources ./data/toys.R *before* the files in ./R/ ; > and this throws an error in > R2 CMD check, because the functions are not found. > > What is best practice to generate this kind of toy dataset? > > > > -- 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://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] reorder [stats] and reorder.factor [lattice]
Summary: I have just put a version in stats as supplied by Deepayan. It is more or less the same as that in Trellis (there never was one in lattice AFAIK), except that the result is by default only ordered if the input was, and the `scores' used to do the ordering are returned. (Both points I raised in earlier discussions.) Package gregmisc has a different function of that name which appears to be more related to relevel and levels<-. On Tue, 14 Sep 2004, Martin Maechler wrote: > > "DeepS" == Deepayan Sarkar <[EMAIL PROTECTED]> > > on Mon, 13 Sep 2004 14:54:52 -0500 writes: > > DeepS> Before it's too late for R 2.0.0, do we have a final decision yet on > DeepS> having a reorder method for "factor" in stats? > > Since the thread is quite a bit old, (and I have been in vacation back then), > could you summarize what you think about it? > > When skimming through the thread I got the impression that, yes, > it was worth to "centralize" such a method in 'stats' rather > than have different slightly incompatible versions in different > other packages. > This is of tangential interest to me as I have been slightly > involved with reorder.dendrogram() > > Regards, > Martin > > __ > [EMAIL PROTECTED] 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 __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
