Re: [Rd] str and class
> "HT" == Heather Turner <[EMAIL PROTECTED]> > on Fri, 09 May 2008 18:00:37 +0100 writes: HT> In previous versions of the gnm package, the terms HT> component of "gnm" objects had a "classID" HT> attribute. This caused problems when used with str as HT> the following simple example illustrates: >> x <- 1 >> attr(x, "classID") <- "type1" >> str(x) HT> Class 'type1' Class 'type1' Class 'type1' Class 'type1' Class 'type1' HT> ... HT> Error: evaluation nested too deeply: infinite recursion / HT> options(expressions=)? HT> The problem is that for S3 objects, str saves attr(object, "class") then HT> recalls str on unclass(object) -- any "class" attribute is removed, but HT> then the "classID" attribute is recursively picked up by attr(object, HT> "class") due to partial matching. HT> Obviously the solution is to use more sensibly named attributes, but str HT> could be made more foolproof by using HT> attr(object, "class", exact = TRUE) HT> instead. Indeed, thank you, Heather! Of course, the latter has only been possible in somewhat recent versions of R, and an alternative would seem to be class(object) anyway but that would be wrong, see e.g., class(pi); however oldClass(object) is really equivalent to the "class" attribute (with exact match). I am sure that when I first wrote str(), in 1990, probably for S-plus version 3.0 *and* for S (as in "S from the Bell Labs"), that attr(object, "class") and class(object) hadn't been entirely equivalent; and in any case, what then was class() is now oldClass(). I'm committing a bug fix to R-devel and R-patched. Best regards, Martin HT> Best regards, HT> Heather HT> -- HT> Dr H Turner HT> Research Fellow HT> Dept. of Statistics HT> The University of Warwick HT> Coventry HT> CV4 7AL HT> Tel: 024 76575870 HT> Fax: 024 76524532 HT> Url: www.warwick.ac.uk/go/heatherturner __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] str and class
In previous versions of the gnm package, the terms component of "gnm" objects had a "classID" attribute. This caused problems when used with str as the following simple example illustrates: > x <- 1 > attr(x, "classID") <- "type1" > str(x) Class 'type1' Class 'type1' Class 'type1' Class 'type1' Class 'type1' ... Error: evaluation nested too deeply: infinite recursion / options(expressions=)? The problem is that for S3 objects, str saves attr(object, "class") then recalls str on unclass(object) -- any "class" attribute is removed, but then the "classID" attribute is recursively picked up by attr(object, "class") due to partial matching. Obviously the solution is to use more sensibly named attributes, but str could be made more foolproof by using attr(object, "class", exact = TRUE) instead. Best regards, Heather -- Dr H Turner Research Fellow Dept. of Statistics The University of Warwick Coventry CV4 7AL Tel: 024 76575870 Fax: 024 76524532 Url: www.warwick.ac.uk/go/heatherturner __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Linux installation
On Thu, 2008-05-08 at 15:17 -0500, Marc Schwartz wrote: > on 05/08/2008 10:39 AM Michael Steinbeck-Reeves wrote: > > I have just installed R under Linux and had a tricky time finding out > > that I needed to install r-devel as it was not suggested by yum and > > does not appear in any of the FAQs. Everything was fine until I tried > > to install tseries then I was told in the compiler output that R.h > > was missing. Obviously a search on Google proved fruitless and I was > > forced to ask on r-help. I am now kicking myself, of course, but > > wouldn't it be a useful addition to the R installation FAQs, > > especially for those not acquainted with the C compiler output? > > > > Thanks, > > > > Michael > > The need for the -devel RPMS is referenced in the R Installation and > Administration Manual in Appendix A and Appendix C. You are quite right - it is mentioned but you need to know that you are looking for it to find it - my initial thought was to look for R.h which was a total waste of time of course. All I suggested was that for the new user it might be helpful to have it mentioned in the FAQs or, even better, in the Linux installation section. Michael. > yum won't pick it up because the -devel RPM is not required to run R, > which is the case BTW for most applications installed using yum on RPM > based Linux systems. > > yum won't reference 'suggested RPMs', only those actually required to > run an application. > > However, if you are going to be doing any compilation of source code > against an RPM installed application, you will need the -devel RPMS, > which contain the required header (.h) files, among other things. Again, > under Linux, that is the case not only with R, but generally all > applications installed in this fashion. > > HTH, > > Marc Schwartz > -- Michael Steinbeck-Reeves www.steinbeck-reeves.co.uk Work +44(0)1256 886190 Mobile +44(0)7785 277413 Milton House Stratfield Saye Berkshire RG7 2BT __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Incorrect fix for PR#9316: Cook's Distance & plot.lm
This is a multi-part message in MIME format.
--030304040002000407020206
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Bug PR#9316 noted an inconsistency between the Cook's distance contours
on plot.lm(x, which = 5) and the values given by cooks.distance(x) -- as
shown in plot.lm(x, which = 4) -- for glms:
http://bugs.r-project.org/cgi-bin/R/Analyses-fixed?id=9316;user=guest;selectid=9316
The suggested fix was to modify the contour levels by a dispersion
factor, implemented as follows:
dispersion <- if (isGlm)
summary(x)$dispersion
else 1
cl.h <- sqrt(crit * p * (1 - hh)/hh * dispersion)[1]
where crit is the value of Cook's distance along the contour, p is the
number of parameters and hh is a vector of hat values. It is clear that
in the case of a normal linear model, the cl.h values will depend on
whether the model was fitted by lm or glm. The following example
illustrates this:
par(mfrow = c(2, 2))
plot(lm(y ~ ., data = freeny), 4:5)
plot(glm(y ~ ., data = freeny), 4:5)
For the lm fit we have
crit = (cl.h^2 * hh)/(p * (1 - hh))
where cl.h is on the scale of the standardized residuals. This is the
Cook's distance as defined e.g. in the Cook & Weisberg reference on
?cooks.distance.
For the glm fit we have
crit = (cl.h^2 * hh)/(p * (1 - hh) * summary(x)$dispersion)
which is incorrect.
For glms, as defined in the William's reference on ?cooks.distance, the
Cook's distance is given by
C = (rs^2 * hh)/(p * (1 - hh))
where rs is the standardized *Pearson* residual, i.e.
rs = residuals(x, "pearson")/sqrt(summary(x)$dispersion * (1 - hh))
However plot 5 of plot.lm plots the standardized *deviance* residuals.
Therefore, for non-Gaussian models, contours based on [1], even with
"dispersion" = 1, will be on the wrong scale.
Since the deviance residuals are usually quite similar to the Pearson
residuals, the contours may not be far off, but the difference accounts
for the inconsistency reported in PR#9316.
The solution is simply to plot the standardised Pearson residuals
instead, as in the attached patch.
Best regards,
Heather
--
Dr H Turner
Research Fellow
Dept. of Statistics
The University of Warwick
Coventry
CV4 7AL
Tel: 024 76575870
Fax: 024 76524532
Url: www.warwick.ac.uk/go/heatherturner
--030304040002000407020206
Content-Type: text/x-patch;
name="plot.lm.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="plot.lm.diff"
Index: src/library/stats/R/plot.lm.R
===
--- src/library/stats/R/plot.lm.R (revision 45649)
+++ src/library/stats/R/plot.lm.R (working copy)
@@ -55,7 +55,7 @@
else cooks.distance(x, sd = s, res = r)
}
}
-if (any(show[c(2:3,5)])) {
+if (any(show[2:3])) {
ylab23 <- if (isGlm)
"Std. deviance resid."
else "Standardized residuals"
@@ -167,7 +167,11 @@
text.id(show.r, cook[show.r], show.r, adj.x=FALSE)
}
if (show[5]) {
- ylim <- range(rs, na.rm = TRUE)
+rps <- residuals(x, "pearson")/(s * sqrt(1 - hii))
+ylab5 <- if (isGlm)
+"Std. Pearson resid."
+else "Standardized residuals"
+ ylim <- range(rps, na.rm = TRUE)
if (id.n > 0) {
ylim <- extendrange(r= ylim, f = 0.08)
show.r <- order(-cook)[iid]
@@ -197,15 +201,15 @@
facval[ord] <- facval
xx <- facval # for use in do.plot section.
-plot(facval, rs, xlim = c(-1/2, sum((nlev-1) * ff) + 1/2),
+plot(facval, rps, xlim = c(-1/2, sum((nlev-1) * ff) + 1/2),
ylim = ylim, xaxt = "n",
main = main, xlab = "Factor Level Combinations",
- ylab = ylab23, type = "n", ...)
+ ylab = ylab5, type = "n", ...)
axis(1, at = ff[1]*(1:nlev[1] - 1/2) - 1/2,
labels= x$xlevels[[1]][order(sapply(split(yh,mf[,1]),
mean))])
mtext(paste(facvars[1],":"), side = 1, line = 0.25, adj=-.05)
abline(v = ff[1]*(0:nlev[1]) - 1/2, col="gray", lty="F4")
-panel(facval, rs, ...)
+panel(facval, rps, ...)
abline(h = 0, lty = 3, col = "gray")
}
else { # no factors
@@ -221,21 +225,20 @@
## omit hatvalues of 1.
xx[xx >= 1] <- NA
-plot(xx, rs, xlim = c(0, max(xx, na.rm = TRUE)), ylim = ylim,
- main = main, xlab = "Leverage", ylab = ylab23, type = "n",
+plot(xx, rps, xlim = c(0, max(xx, na.rm = TRUE)), ylim = ylim,
+ main = main, xlab = "Leverage", ylab = ylab5, type = "n",
...)
-panel(xx, rs, ...)
+panel(xx, rps, ...)
abline(h = 0, v = 0, lty = 3, col = "gray")
if (one.fig)
Re: [Rd] comparison (PR#11421)
On 5/9/2008 7:10 AM, [EMAIL PROTECTED] wrote:
In R-2.7.0 release as well as patched (from yesterday) under Windows XP,
R crashes when typing, e.g.:
repeat{
rep(1, 1) == "ö"
}
Note that I cannot reproduce the error in R-2.6.2 nor R-devel.
I can confirm the crash in a US English locale in R-patched. It is a
seg fault in stripAttrib, but so far I haven't found where that is being
called from (gdb never displays the stack properly).
Duncan Murdoch
Uwe Ligges
--please do not edit the information below--
Version:
platform = i386-pc-mingw32
arch = i386
os = mingw32
system = i386, mingw32
status =
major = 2
minor = 7.0
year = 2008
month = 04
day = 22
svn rev = 45424
language = R
version.string = R version 2.7.0 (2008-04-22)
Windows XP (build 2600) Service Pack 2
Locale:
LC_COLLATE=German_Germany.1252;LC_CTYPE=German_Germany.1252;LC_MONETARY=German_Germany.1252;LC_NUMERIC=C;LC_TIME=German_Germany.1252
Search Path:
.GlobalEnv, package:stats, package:graphics, package:grDevices,
package:datasets, package:utils, package:methods, Autoloads, package:base
__
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
Re: [Rd] Have you ever experienced this problem with REAL in a C code
Thanks. These are good suggestions. I'll have a closer look (again) at the code. Best, Mathieu Prof Brian Ripley a écrit : These messages mean that R's internal code is encountering the wrong SEXPTYPE. This almost always means one of - lact of PROTECTion, so objects have been garbage-collected before use. - memory corruption, most often by writing outside array bounds. See the chapter in 'Writing R Extensions' about this, and if possible make use of valgrind. On Fri, 9 May 2008, Mathieu Ribatet wrote: Dear all, I'm currently experiencing big troubles with my C code called by .Call in a R function. I know this may not be the right place for such things but these errors are driving me crazy. And I hope other people may have already experienced these problems so that they could give me good suggestions. Sorry if I'm completely out of topic. Well let's go... I'm writing a MCMC algo for Bayesian analysis. The MCMC part is written in C but call R objects (e.g. output and arguments are SEXP). The C is called by a wrapper R function through .Call. The posterior density is computed using a R code that calls 2 different codes: one for the prior distribution and one for the likelihood. The prior distribution is fully written in R while the likelihood is computed using a C code. Both of these codes are (seem to be) ok and *always* return numeric - and no special values as Inf, NA,... When I'm running my codes (enclosed you'll find the C code), I get one of the following error - *when error occurs*: Error in gibbs(1000, init, prior.p, "whitmat", data = ms1, coord = locations, : REAL() can only be applied to a 'numeric', not a 'raw' or Error in gibbs(1000, init, prior.p, "whitmat", data = ms1, coord = locations, : REAL() can only be applied to a 'numeric', not a 'list' or Error in gibbs(1000, init, prior.p, "whitmat", data = ms1, coord = locations, : REAL() can only be applied to a 'numeric', not an 'integer' The problem is that REAL seems not to be applied to a list (I've got no list objects), and not to an integer too. I checked for wrong allocation memory, infinite values but found nothing... Any suggestions for possible reasons would be definitively appreciated. Again, if this mail has no reason to be in this list; sorry and forget it. Best, Mathieu -- Institute of Mathematics Ecole Polytechnique Fédérale de Lausanne STAT-IMA-FSB-EPFL, Station 8 CH-1015 Lausanne Switzerland http://stat.epfl.ch/ Tel: + 41 (0)21 693 7907 -- Institute of Mathematics Ecole Polytechnique Fédérale de Lausanne STAT-IMA-FSB-EPFL, Station 8 CH-1015 Lausanne Switzerland http://stat.epfl.ch/ Tel: + 41 (0)21 693 7907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Linux installation
On Fri, 2008-05-09 at 09:20 +0100, Sklyar, Oleg (MI London) wrote:
> Michael:
>
> 1) this IS a wrong list for such questions. You mention r-help, but this
> is Rd (developers) and your question is completely unrelated to the
> topics of the list!
Oleg, the gist of Michael's email was to make a suggestion about an
addition to the R FAQ or installation instructions for R. I don't think
that is inappropriate for this list.
I had already provided Micheal with the solution to his original problem
posted on R-Help. In off-list emails I suggested that Michael provide
his feedback to this list and the R Core Team as he had found it
difficult to understand his error and wanted to contribute a suggestion
for improvement. Apologies to the list if my suggestion was in error.
In doing so, however, Michael (and I indirectly) was directed to where
this *is* documented in the R Admin and Installation manual by Marc
Schwartz - so, as so often the case, R Core had already thought of and
implemented Michael's suggestion.
> 2) In Linux, any time you want to compile anything against anything and
> using binary distributions you need *-devel or *-dev packages depending
> on the distribution. Even if it is not mentioned anywhere, it is
> actually how all Linux binary distributions are maintained. What those
> *-devel contain are actually *.h files.
I made the same point in my response to Michael's OP. In our discussion
though I realised that for someone new to R and not familiar with how it
works, it is not immediately clear that you are compiling /against/ R
when /installing/ a package from within R itself. If the instructions
for installing tseries had been, open console, configure, make, install,
then fair enough, we might expect anyone using Linux to realise what was
wrong, but you don't install R packages that way.
With more and more people moving to Linux for various reasons, the
default attitude can't be to assume that if you're a Linux user that you
automatically know how all of this works.
All the best,
G
> 3) Install R from source and you will have no issues.
>
> Best,
>
> Dr Oleg Sklyar
> Technology Group
> Man Investments Ltd
> +44 (0)20 7144 3803
> [EMAIL PROTECTED]
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of Michael
> > Steinbeck-Reeves
> > Sent: 08 May 2008 16:39
> > To: r-devel@r-project.org
> > Subject: [Rd] Linux installation
> >
> > I have just installed R under Linux and had a tricky time
> > finding out that I needed to install r-devel as it was not
> > suggested by yum and does not appear in any of the FAQs.
> > Everything was fine until I tried to install tseries then I
> > was told in the compiler output that R.h was missing.
> > Obviously a search on Google proved fruitless and I was
> > forced to ask on r-help. I am now kicking myself, of course,
> > but wouldn't it be a useful addition to the R installation
> > FAQs, especially for those not acquainted with the C compiler output?
> >
> > Thanks,
> >
> > Michael
> > --
> >
> > Michael Steinbeck-Reeves
> >
> > www.steinbeck-reeves.co.uk
> >
> > Work +44(0)1256 886190
> > Mobile +44(0)7785 277413
> >
> > Milton House
> > Stratfield Saye
> > Berkshire
> > RG7 2BT
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
>
> **
> The contents of this email are for the named addressee(s...{{dropped:22}}
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
Dr. Gavin Simpson [t] +44 (0)20 7679 0522
ECRC, UCL Geography, [f] +44 (0)20 7679 0565
Pearson Building, [e] gavin.simpsonATNOSPAMucl.ac.uk
Gower Street, London [w] http://www.ucl.ac.uk/~ucfagls/
UK. WC1E 6BT. [w] http://www.freshwaters.org.uk
%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] comparison (PR#11421)
In R-2.7.0 release as well as patched (from yesterday) under Windows XP,
R crashes when typing, e.g.:
repeat{
rep(1, 1) == "ö"
}
Note that I cannot reproduce the error in R-2.6.2 nor R-devel.
Uwe Ligges
--please do not edit the information below--
Version:
platform = i386-pc-mingw32
arch = i386
os = mingw32
system = i386, mingw32
status =
major = 2
minor = 7.0
year = 2008
month = 04
day = 22
svn rev = 45424
language = R
version.string = R version 2.7.0 (2008-04-22)
Windows XP (build 2600) Service Pack 2
Locale:
LC_COLLATE=German_Germany.1252;LC_CTYPE=German_Germany.1252;LC_MONETARY=German_Germany.1252;LC_NUMERIC=C;LC_TIME=German_Germany.1252
Search Path:
.GlobalEnv, package:stats, package:graphics, package:grDevices,
package:datasets, package:utils, package:methods, Autoloads, package:base
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Have you ever experienced this problem with REAL in a C code
These messages mean that R's internal code is encountering the wrong SEXPTYPE. This almost always means one of - lact of PROTECTion, so objects have been garbage-collected before use. - memory corruption, most often by writing outside array bounds. See the chapter in 'Writing R Extensions' about this, and if possible make use of valgrind. On Fri, 9 May 2008, Mathieu Ribatet wrote: Dear all, I'm currently experiencing big troubles with my C code called by .Call in a R function. I know this may not be the right place for such things but these errors are driving me crazy. And I hope other people may have already experienced these problems so that they could give me good suggestions. Sorry if I'm completely out of topic. Well let's go... I'm writing a MCMC algo for Bayesian analysis. The MCMC part is written in C but call R objects (e.g. output and arguments are SEXP). The C is called by a wrapper R function through .Call. The posterior density is computed using a R code that calls 2 different codes: one for the prior distribution and one for the likelihood. The prior distribution is fully written in R while the likelihood is computed using a C code. Both of these codes are (seem to be) ok and *always* return numeric - and no special values as Inf, NA,... When I'm running my codes (enclosed you'll find the C code), I get one of the following error - *when error occurs*: Error in gibbs(1000, init, prior.p, "whitmat", data = ms1, coord = locations, : REAL() can only be applied to a 'numeric', not a 'raw' or Error in gibbs(1000, init, prior.p, "whitmat", data = ms1, coord = locations, : REAL() can only be applied to a 'numeric', not a 'list' or Error in gibbs(1000, init, prior.p, "whitmat", data = ms1, coord = locations, : REAL() can only be applied to a 'numeric', not an 'integer' The problem is that REAL seems not to be applied to a list (I've got no list objects), and not to an integer too. I checked for wrong allocation memory, infinite values but found nothing... Any suggestions for possible reasons would be definitively appreciated. Again, if this mail has no reason to be in this list; sorry and forget it. Best, Mathieu -- Institute of Mathematics Ecole Polytechnique Fédérale de Lausanne STAT-IMA-FSB-EPFL, Station 8 CH-1015 Lausanne Switzerland http://stat.epfl.ch/ Tel: + 41 (0)21 693 7907 -- 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] Have you ever experienced this problem with REAL in a C code
Dear all, I'm currently experiencing big troubles with my C code called by .Call in a R function. I know this may not be the right place for such things but these errors are driving me crazy. And I hope other people may have already experienced these problems so that they could give me good suggestions. Sorry if I'm completely out of topic. Well let's go... I'm writing a MCMC algo for Bayesian analysis. The MCMC part is written in C but call R objects (e.g. output and arguments are SEXP). The C is called by a wrapper R function through .Call. The posterior density is computed using a R code that calls 2 different codes: one for the prior distribution and one for the likelihood. The prior distribution is fully written in R while the likelihood is computed using a C code. Both of these codes are (seem to be) ok and *always* return numeric - and no special values as Inf, NA,... When I'm running my codes (enclosed you'll find the C code), I get one of the following error - *when error occurs*: Error in gibbs(1000, init, prior.p, "whitmat", data = ms1, coord = locations, : REAL() can only be applied to a 'numeric', not a 'raw' or Error in gibbs(1000, init, prior.p, "whitmat", data = ms1, coord = locations, : REAL() can only be applied to a 'numeric', not a 'list' or Error in gibbs(1000, init, prior.p, "whitmat", data = ms1, coord = locations, : REAL() can only be applied to a 'numeric', not an 'integer' The problem is that REAL seems not to be applied to a list (I've got no list objects), and not to an integer too. I checked for wrong allocation memory, infinite values but found nothing... Any suggestions for possible reasons would be definitively appreciated. Again, if this mail has no reason to be in this list; sorry and forget it. Best, Mathieu -- Institute of Mathematics Ecole Polytechnique Fédérale de Lausanne STAT-IMA-FSB-EPFL, Station 8 CH-1015 Lausanne Switzerland http://stat.epfl.ch/ Tel: + 41 (0)21 693 7907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-2.8.0 : get platform device with get(getOption("device"))
If you set, say
options(device="pdf")
you get the old behaviour. You really cannot assume that session settings
will be unchanged unless you set them yourself.
On Fri, 9 May 2008, Paul Roebuck wrote:
On Thu, 8 May 2008, Peter Dalgaard wrote:
Prof Brian Ripley wrote:
Here is the NEWS item, for 2.5.0
ooptions(device = ) now accepts a function object as well as
the name of a function.
The construct in the subject line has been broken ever since.
Yet the change produced no warnings when made, so apparently
everyone else missed it!
It did, if you set that option.
OK, but that entry was obviously hard to spot even when looking for it!
On Thu, 8 May 2008, Peter Dalgaard wrote:
Prof Brian Ripley wrote:
Please do study the posting guide. This was covered recently:
https://stat.ethz.ch/pipermail/r-devel/2008-April/049319.html
Nevertheless, perhaps an explicit NEWS entry could be warranted,
something like
oThe "device" option can now be a function, and is one in some
standard setups. Consequentially, get(getOption("device")) will fail;
programmers should usually use dev.new() instead.
So...
oThe "device" option now is a function in some standard setups.
Consequentially, get(getOption("device")) will fail; programmers should
usually use dev.new() instead. (Assuming that the device is a character
string has been incorrect since 2.5.0.)
Prof Brian Ripley noted [in another recent message] that
it was also wrong to assume ANY arguments for dev.new
method. If we are only concerned with interactive screen
devices (i.e., x11, windows, quartz), would it be safe to
come up with a method that can take basic dimension arguments
(width & height)? Suggestions for an R-Core approved method
of doing so?
We use this functionality every day for creating multiple
onscreen windows with specified dimensions.
While I understand things have to change to evolve the
codebase, this change broke the code supporting countless
papers and analyses here in our department, without warning
until now.
--
SIGSIG -- signature too long (core dumped)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-2.8.0 : get platform device with get(getOption("device"))
On Thu, 8 May 2008, Peter Dalgaard wrote:
> Prof Brian Ripley wrote:
> > Here is the NEWS item, for 2.5.0
> >
> > ooptions(device = ) now accepts a function object as well as
> > the name of a function.
> >
> > The construct in the subject line has been broken ever since.
Yet the change produced no warnings when made, so apparently
everyone else missed it!
> OK, but that entry was obviously hard to spot even when looking for it!
> >
> > On Thu, 8 May 2008, Peter Dalgaard wrote:
> >
> >> Prof Brian Ripley wrote:
> >>> Please do study the posting guide. This was covered recently:
> >>>
> >>> https://stat.ethz.ch/pipermail/r-devel/2008-April/049319.html
> >> Nevertheless, perhaps an explicit NEWS entry could be warranted,
> >> something like
> >>
> >> oThe "device" option can now be a function, and is one in some
> >> standard setups. Consequentially, get(getOption("device")) will fail;
> >> programmers should usually use dev.new() instead.
> >>
> So...
>
> oThe "device" option now is a function in some standard setups.
> Consequentially, get(getOption("device")) will fail; programmers should
> usually use dev.new() instead. (Assuming that the device is a character
> string has been incorrect since 2.5.0.)
>
Prof Brian Ripley noted [in another recent message] that
it was also wrong to assume ANY arguments for dev.new
method. If we are only concerned with interactive screen
devices (i.e., x11, windows, quartz), would it be safe to
come up with a method that can take basic dimension arguments
(width & height)? Suggestions for an R-Core approved method
of doing so?
We use this functionality every day for creating multiple
onscreen windows with specified dimensions.
While I understand things have to change to evolve the
codebase, this change broke the code supporting countless
papers and analyses here in our department, without warning
until now.
--
SIGSIG -- signature too long (core dumped)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Linux installation
Michael:
1) this IS a wrong list for such questions. You mention r-help, but this
is Rd (developers) and your question is completely unrelated to the
topics of the list!
2) In Linux, any time you want to compile anything against anything and
using binary distributions you need *-devel or *-dev packages depending
on the distribution. Even if it is not mentioned anywhere, it is
actually how all Linux binary distributions are maintained. What those
*-devel contain are actually *.h files.
3) Install R from source and you will have no issues.
Best,
Dr Oleg Sklyar
Technology Group
Man Investments Ltd
+44 (0)20 7144 3803
[EMAIL PROTECTED]
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Michael
> Steinbeck-Reeves
> Sent: 08 May 2008 16:39
> To: r-devel@r-project.org
> Subject: [Rd] Linux installation
>
> I have just installed R under Linux and had a tricky time
> finding out that I needed to install r-devel as it was not
> suggested by yum and does not appear in any of the FAQs.
> Everything was fine until I tried to install tseries then I
> was told in the compiler output that R.h was missing.
> Obviously a search on Google proved fruitless and I was
> forced to ask on r-help. I am now kicking myself, of course,
> but wouldn't it be a useful addition to the R installation
> FAQs, especially for those not acquainted with the C compiler output?
>
> Thanks,
>
> Michael
> --
>
> Michael Steinbeck-Reeves
>
> www.steinbeck-reeves.co.uk
>
> Work +44(0)1256 886190
> Mobile +44(0)7785 277413
>
> Milton House
> Stratfield Saye
> Berkshire
> RG7 2BT
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
**
The contents of this email are for the named addressee(s...{{dropped:22}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
