Re: [Rd] symbols function -- possible enhancements
Hi Jean,
now that you've been told `the truth' .. :
If you'd like to carefully look at symbols() and its help page and see
which arguments ('axes' but maybe more) would be useful to pass
to plot.default and if you provide enhanced versions of the two files
https://svn.r-project.org/R/trunk/src/library/graphics/R/symbols.R
and https://svn.r-project.org/R/trunk/src/library/graphics/man/symbols.Rd
I'll gladly look at them and incorporate them for R 2.3.0
(unless they break something)
Best regards,
Martin Maechler
> "BDR" == Prof Brian Ripley <[EMAIL PROTECTED]>
> on Tue, 17 Jan 2006 23:15:19 + (GMT) writes:
BDR> On Tue, 17 Jan 2006, Thomas Lumley wrote:
>> On Tue, 17 Jan 2006, Jean Eid wrote:
>>
>>> Hi
>>>
>>> I do not get why the symbols function produces warnings when axes=F is
>>> added. The following example illustrate this
>>>
symbols(0,10, inches=T, circles=1, axes=F, xlab="", ylab="")
>>> Warning message:
>>> parameter "axes" could not be set in high-level plot() function
>>>
>>>
>>> I augmented symbols and added the axes=F argument to the plot function
>>> inside the original symbols function. It works as expected, no warning
>>> message. I am just lost as to why the extra arguments in symbols (...)
>>> are not behaving as expected.
>>>
>>
>> The ... argument is also passed to .Internal, and presumably the code
>> there gives the warning.
BDR> Indeed. axes=F is not in the allowed list
BDR> ...: graphics parameters can also be passed to this function, as
BDR> can the plot aspect ratio 'asp' (see 'plot.window').
BDR> People confuse 'axes' with the graphics parameters, but it is in fact
an
BDR> argument to plot.default. (The corresponding graphics parameters
BDR> xaxt and yaxt do work.) R-devel gives a more informative message:
>> attach(trees)
>> symbols(Height, Volume, circles = Girth/24, inches = FALSE, axes=F)
BDR> Warning message:
BDR> "axes" is not a graphical parameter in: symbols(x, y, type, data,
inches,
BDR> bg, fg, ...)
BDR> We do ask people to read the help pages before posting for a good
reason:
BDR> the information is usually there in a more complete and accurate form
than
BDR> people remember.
BDR> --
BDR> Brian D. Ripley, [EMAIL PROTECTED]
BDR> Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
BDR> University of Oxford, Tel: +44 1865 272861 (self)
BDR> 1 South Parks Road, +44 1865 272866 (PA)
BDR> Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] natural sorting
> "Greg" == Warnes, Gregory R <[EMAIL PROTECTED]>
> on Tue, 17 Jan 2006 14:48:46 -0500 writes:
Greg> The 'mixedsort' function in the 'gtools' package does
Greg> this. It is probably slower than the c version you
Greg> point to, but it is already working in R.
Thank you, Greg.
BTW, given the thread, this is a typical example where it might
be very useful to add the following two concepts to the
mixedsort.Rd file in gtools :
\concept{natural sort}
\concept{dictionary sort}
so that mixedsort() will be quickly found by help.search("natural sort")
and possibly also via the java search from the HTML help interface?
(I never use it; I use help.search() {or then RSiteSearch()}
exclusively.)
Martin
>> -Original Message-
>> From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED] Behalf Of Andrew Piskorski
>> Sent: Thursday, January 12, 2006 10:40 AM
>> To: R Development Mailing List
>> Subject: Re: [Rd] natural sorting
>>
>>
>> On Wed, Jan 11, 2006 at 05:45:10PM -0500, Gabor Grothendieck wrote:
>> > It would be nifty to incorporate this into R or into an R package:
>> >
>> > http://sourcefrog.net/projects/natsort/
>>
>> Btw, I haven't looked at the implementation, but Tcl also contains
>> equivalent functionality, they call it dictionary sort:
>>
>> http://tcl.activestate.com/man/tcl8.4/TclCmd/lsort.htm
>>
>> --
>> Andrew Piskorski <[EMAIL PROTECTED]>
>> http://www.piskorski.com/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Section 7.1 HML documentation (PR#8484)
Greg Kochanski wrote: > Well, I don't know how it can be precise > and correct when it has dangling antecedents. > Gramatically speaking, that's the equivalent of > an uninitialized pointer. I don't think there is anything "dangling" there. What the paragraph assumes (and quite patently wrongly) is that the reader had encountered the concept of "R connection object of the socket type" elsewhere. Without that background, one tends to interprete the phrase "socket connection" in the traditional unix sense (i.e. = "BSD socket"), and hence one reads the paragraph as " XXX is older than XXX and XXX is newer than XXX and there had been potential problems with XXX and one should use XXX instead (of XXX)". > However, I agree with you that it probably just > needs a minor bit of fiddling to make sure it > answers "Instead of what?" and "Earlier than what?" I have re-read R-data and it seems the fault is yours. Because "Connection" is mentioned in quite a major way and is the entire subject of chapter 6 and comes earlier than the paragraph you quoted in chapter 7. So it seems to be your own fault of trying to understand chapter 7 without noticing the header of chapter 6 nor reading it! === 6 Connections "Connections" are used in R in the sense of Chambers (1998), a set of functions to replace the use of file names by a flexible interface to file-like objects. ... 6.1 Types of connections ... Sockets can also be used as connections via function socketConnection on platforms which support Berkeley-like sockets (most Unix systems, Linux and Windows). Sockets can be written to or read from, and both client and server sockets can be used. ... 7 Network interfaces Some limited facilities are available to exchange data at a lower level across network connections. 7.1 Reading from sockets ... = > Hin-Tak Leung wrote: > >> [EMAIL PROTECTED] wrote: >> >>> Full_Name: Greg Kochanski >>> Version: 2.2.0 >>> OS: Debian Linux i686 >>> Submission from: (NULL) (212.159.16.190) >>> >>> >>> In /usr/share/doc/r-doc-html/manual/R-data.html (at least that's where >>> it is on Debian...) the documentation is unclear. Comments below. >> >> >> >> The documentation is, I believe, correct and precise as it stands. >> What it doesn't emphasize and mention is the difference between >> "BSD socket" and "socket connection", or an "R connection of the >> socket type". And it is recommended that you >> use "socket connection" instead of "BSD socket". >> >> The earlier "BSD socket" is created, read, write with >> "make.socket"/"read.socket"/"write socket"/"close socket". >> >> The newer "socket connection" is created by creating a new connection >> object like this: >> con <- socketConnection(port = 79, blocking = TRUE) >> and invoking the open/write/read method of the "connection" >> object. type "?connection" in an R prompt for details. >> >> "BSD socket" is a unix concept, "socket connection" is an R object. >> The paragraph should have put "BSD socket" and "socket connection" >> in quote or italics. Make more sense? >> >> Somebody please fix the paragraph... :-). >> >>> The paragraph has unclear references, and I have no idea what >>> it actually means. >>> >>> > Base R comes with some facilities to communicate via BSD sockets on > systems >>> >>> >>> >>> that support them (...). One potential problem >>> > For new projects it is suggested that socket connections are used > instead. >>> >>> >>> >>> >>> "Used instead"? Instead of what? >>> >>> > The earlier low-level interface is given by functions make.socket, >>> >>> >>> >>> read.socket, write.socket and close.socket. >>> What does "earlier" mean? Earlier than what? >>> >>> __ >>> 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
[Rd] phyper returns 1 if x==k (PR#8499)
Full_Name: Utz J. Pape Version: 2.2.0 OS: linux Submission from: (NULL) (141.14.23.12) If I use phyper and set parameter x equal to k (meaning that all balls I draw are white) phyper returns 1 which is not (always) correct: [EMAIL PROTECTED]:~> R2.2.0 --vanilla R : Copyright 2005, The R Foundation for Statistical Computing Version 2.2.0 (2005-10-06 r35749) ISBN 3-900051-07-0 R is free software and comes with ABSOLUTELY NO WARRANTY. You are welcome to redistribute it under certain conditions. Type 'license()' or 'licence()' for distribution details. R is a collaborative project with many contributors. Type 'contributors()' for more information and 'citation()' on how to cite R or R packages in publications. Type 'demo()' for some demos, 'help()' for on-line help, or 'help.start()' for a HTML browser interface to help. Type 'q()' to quit R. > x <- 10; m <- 20; n <- 5; k <- 10 > phyper(x,m,n,k) [1] 1 > choose(m,x) * choose(n,k-x) / choose(m+n,k) [1] 0.05652174 > version _ platform i686-pc-linux-gnu arch i686 os linux-gnu system i686, linux-gnu status major2 minor2.0 year 2005 month10 day 06 svn rev 35749 language R > sessionInfo() R version 2.2.0, 2005-10-06, i686-pc-linux-gnu attached base packages: [1] "methods" "stats" "graphics" "grDevices" "utils" "datasets" [7] "base" __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] phyper returns 1 if x==k (PR#8499)
On Wed, 18 Jan 2006 [EMAIL PROTECTED] wrote: > Full_Name: Utz J. Pape > Version: 2.2.0 > OS: linux > Submission from: (NULL) (141.14.23.12) > > > If I use phyper and set parameter x equal to k (meaning that all balls I draw > are white) phyper returns 1 which is not (always) correct: I think you are confusing this with dhyper. How can you possibly get more white balls than exist in the urn? That you cannot is what p = 1 is telling you. We do quite specifically ask you not to report on obselete versions of R. Of course, as this is NOT A BUG, it is the same in the current R. > > [EMAIL PROTECTED]:~> R2.2.0 --vanilla > > R : Copyright 2005, The R Foundation for Statistical Computing > Version 2.2.0 (2005-10-06 r35749) > ISBN 3-900051-07-0 > > R is free software and comes with ABSOLUTELY NO WARRANTY. > You are welcome to redistribute it under certain conditions. > Type 'license()' or 'licence()' for distribution details. > > R is a collaborative project with many contributors. > Type 'contributors()' for more information and > 'citation()' on how to cite R or R packages in publications. > > Type 'demo()' for some demos, 'help()' for on-line help, or > 'help.start()' for a HTML browser interface to help. > Type 'q()' to quit R. > >> x <- 10; m <- 20; n <- 5; k <- 10 >> phyper(x,m,n,k) > [1] 1 >> choose(m,x) * choose(n,k-x) / choose(m+n,k) > [1] 0.05652174 >> version > _ > platform i686-pc-linux-gnu > arch i686 > os linux-gnu > system i686, linux-gnu > status > major2 > minor2.0 > year 2005 > month10 > day 06 > svn rev 35749 > language R >> sessionInfo() > R version 2.2.0, 2005-10-06, i686-pc-linux-gnu > > attached base packages: > [1] "methods" "stats" "graphics" "grDevices" "utils" "datasets" > [7] "base" > > __ > 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] Section 7.1 HML documentation (PR#8484)
Well, you make two very strong assumptions. First, that your readers start in the beginning and read to the end. Second, that your readers are sufficiently dedicated to learn your terminology. The first is false: I got to that page via Google. The second is only true in varying degrees, and I wouldn't depend on it too strongly. When writing documentation, you really have to write for the case of someone who has a specific problem and wants to understand that problem as quickly as possible. That means the manuals should have "local support" -- most of what you need to know should be in one place, and everything else should be referenced or hyperlinked. Speaking almost professionally (since I'm almost a linguist), the word "instead" is normally used in the form "instead of X", and you can only delete the "of X" when X is clear and obvious. For instance, one wouldn't just write "I go to work instead." because your readers won't know the alternative to work. Likewise, with "earlier": the underlying form is "earlier than Y", and you can only delete "than Y" when your readers are quite clear what you are comparing to. That's what I meant by "dangling": that X and Y were not clear. Hin-Tak Leung wrote: > Greg Kochanski wrote: > >> Well, I don't know how it can be precise >> and correct when it has dangling antecedents. >> Gramatically speaking, that's the equivalent of >> an uninitialized pointer. > > > I don't think there is anything "dangling" there. What the paragraph > assumes (and quite patently wrongly) is that the reader had encountered > the concept of "R connection object of the socket type" elsewhere. > Without that background, one tends to interprete the phrase "socket > connection" in the traditional unix sense (i.e. = "BSD socket"), and > hence one reads the paragraph as " XXX is older than XXX and XXX is > newer than XXX and there had been potential problems with XXX and > one should use XXX instead (of XXX)". Yep. > >> However, I agree with you that it probably just >> needs a minor bit of fiddling to make sure it >> answers "Instead of what?" and "Earlier than what?" > > > I have re-read R-data and it seems the fault is yours. Because > "Connection" is mentioned in quite a major way and is the entire subject > of chapter 6 and comes earlier than the paragraph you quoted in > chapter 7. So it seems to be your own fault of trying to > understand chapter 7 without noticing the header of chapter 6 > nor reading it! That may be so, but it is irrelevant. The object of this exercise is not to assign blame, but to make the software more useful for the next user. Consequently, you might want to fix it (even if it is my fault), so long as it is likely to help the next guy (even if it is his fault). And, I contend that a lot more people Google into the middle of the documentation than read it from beginning to end. QED. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Section 7.1 HML documentation (PR#8484)
Well, you make two very strong assumptions. First, that your readers start in the beginning and read to the end. Second, that your readers are sufficiently dedicated to learn your terminology. The first is false: I got to that page via Google. The second is only true in varying degrees, and I wouldn't depend on it too strongly. When writing documentation, you really have to write for the case of someone who has a specific problem and wants to understand that problem as quickly as possible. That means the manuals should have "local support" -- most of what you need to know should be in one place, and everything else should be referenced or hyperlinked. Speaking almost professionally (since I'm almost a linguist), the word "instead" is normally used in the form "instead of X", and you can only delete the "of X" when X is clear and obvious. For instance, one wouldn't just write "I go to work instead." because your readers won't know the alternative to work. Likewise, with "earlier": the underlying form is "earlier than Y", and you can only delete "than Y" when your readers are quite clear what you are comparing to. That's what I meant by "dangling": that X and Y were not clear. Hin-Tak Leung wrote: > Greg Kochanski wrote: > >> Well, I don't know how it can be precise >> and correct when it has dangling antecedents. >> Gramatically speaking, that's the equivalent of >> an uninitialized pointer. > > > I don't think there is anything "dangling" there. What the paragraph > assumes (and quite patently wrongly) is that the reader had encountered > the concept of "R connection object of the socket type" elsewhere. > Without that background, one tends to interprete the phrase "socket > connection" in the traditional unix sense (i.e. = "BSD socket"), and > hence one reads the paragraph as " XXX is older than XXX and XXX is > newer than XXX and there had been potential problems with XXX and > one should use XXX instead (of XXX)". Yep. > >> However, I agree with you that it probably just >> needs a minor bit of fiddling to make sure it >> answers "Instead of what?" and "Earlier than what?" > > > I have re-read R-data and it seems the fault is yours. Because > "Connection" is mentioned in quite a major way and is the entire subject > of chapter 6 and comes earlier than the paragraph you quoted in > chapter 7. So it seems to be your own fault of trying to > understand chapter 7 without noticing the header of chapter 6 > nor reading it! That may be so, but it is irrelevant. The object of this exercise is not to assign blame, but to make the software more useful for the next user. Consequently, you might want to fix it (even if it is my fault), so long as it is likely to help the next guy (even if it is his fault). And, I contend that a lot more people Google into the middle of the documentation than read it from beginning to end. QED. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Minumum memory requirements to run R.
Quite a while back we set the goal of running R in 16Mb RAM, as people (I think Kjetil) had teaching labs that small. Since then R has grown, and we has recently started to optimize R for speed rather than size. I recently tested R-devel on my ancient Win98 notebook with 64Mb RAM -- it ran but startup was rather slow on what I think is a 233MHz processor and very slow disc. R still runs in 16Mb, but that is getting tight. Does anyone have any need to run on a smaller machine than my 64Mb notebook? -- 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] Loading of namespace on load of .Rdata (was strange behaviour of load)
Last week Giovanni Parrinello posted a message asking why various packages were
loaded when he loaded an .Rdata file. Brian Ripley replied saying he thought it
was because the saved workspace contained a reference to the namespace of
ipred. (Correspondence copied below).
This begs the question: how did the reference to the namespace of ipred come to
be in the .Rdata file? Brian did say it is likely to be because the workspace
contained object(s) saved with environment the namespace of ipred - but how
would this come about?
In this case I think is because the .Rdata file contained an object whose
*parent* environment was the namespace of ipred. Take the following example
from ?bagging (having loaded ipred):
> data(BreastCancer)
>
> mod <- bagging(Class ~ Cl.thickness + Cell.size
+ + Cell.shape + Marg.adhesion
+ + Epith.c.size + Bare.nuclei
+ + Bl.cromatin + Normal.nucleoli
+ + Mitoses, data=BreastCancer, coob=TRUE)
>
> environment(mod$mtrees[[1]]$btree$terms)
>
> parent.env(environment(mod$mtrees[[1]]$btree$terms))
This occurs because the terms object is taken from the model frame which was
evaluated within the environment of a function from the ipred package (here
ipred:::irpart).
Therefore I think the behaviour observed by Giovanni will only occur in unusual
circumstances: when the workspace contains a formula object, a terms object, a
function, or some other object with a non-NULL environment, which has been
created in the environment of a packaged function. In particular, this would
not always occur with a packaged model fitting function, e.g. (from ?loglm in
MASS)
> library(MASS)
> minn38a <- array(0, c(3,4,7,2), lapply(minn38[, -5], levels))
> minn38a[data.matrix(minn38[,-5])] <- minn38$f
> fm <- loglm(~1 + 2 + 3 + 4, minn38a)
> environment(fm$terms)
in this case because the terms component is obtained from the formula, whose
environment is .GlobalEnv.
So, I have two points on this (more for R-devel than R-help now)
1. There is a more general situation where it would be useful to load the
namespace of a package after loading a saved workspace: when the workspace
contains objects of a class for which special methods are required. E.g. if
'fm' from the example above were saved in a workspace, the namespace of MASS
would not be loaded when the workspace was loaded into R. Thus unless MASS was
loaded by the user, default methods would be used by summary(), print() etc
rather than the specialised methods for objects of class "loglm".
Of course the user should quickly realise this, but there may be cases where
the default method gives a convincing but incorrect or unhelpful result. An
alternative would be to add an attribute to objects of class "loglm" (say),
e.g. attr(loglmObject, ".Environment") <- environment(MASS)
so that the namespace would automatically be loaded when it is required. [In
fact alternatives such as environment(loglmObject) <- environment(MASS) or
loglmObject$anyoldthing <- environment(MASS) would work just as well, but
perhaps the first suggestion is neatest.].
What do others think of this idea? Should it (or an equivalent idea) be
encouraged amongst package writers?
2. In the case highlighted by Giovanni, the namespace of ipred was loaded, but
the package was not. This would be fine, except that the packages on which
ipred depends *were* loaded. This seems inconsistent. I guess as long as there
are packages without namespaces though, this is the only way to proceed.
Perhaps in the meantime, package authors should be encouraged to use
importFrom() rather than import()? Or perhaps where packages do have
namespaces, only the namespace should be loaded in such a case.
Heather
> From: Prof Brian Ripley <[EMAIL PROTECTED]>
> Date: 12 January 2006 08:21:35 GMT
> To: giovanni parrinello <[EMAIL PROTECTED]>
> Cc: r-help@stat.math.ethz.ch
> Subject: Re: [R] Strange behaviour of load
>
> On Wed, 11 Jan 2006, giovanni parrinello wrote:
>
>> Dear All,
>> simetimes when I load an Rdata I get this message
>>
>> ###
>> Code:
>>
>> load('bladder1.RData')
>> Carico il pacchetto richiesto: rpart ( Bad traslastion: Load required
>> package-...)
>> Carico il pacchetto richiesto: MASS
>> Carico il pacchetto richiesto: mlbench
>> Carico il pacchetto richiesto: survival
>> Carico il pacchetto richiesto: splines
>>
>> Carico il pacchetto richiesto: 'survival'
>>
>>
>>The following object(s) are masked from package:Hmisc :
>>
>> untangle.specials
>>
>> Carico il pacchetto richiesto: class
>> Carico il pacchetto richiesto: nnet
>> #
>>
>> So I have many unrequired packages loaded.
>> Any idea?
>
> They are required! My guess is that you have object(s) saved with
> environment the namespace of some package, and loading that namespace
> is
> pulling these in. The only CRAN package which requires mlbench
> appears to
> be ipred, and that requires all of those
Re: [Rd] Loading of namespace on load of .Rdata (was strange behaviour of load)
On Wed, 18 Jan 2006, Heather Turner wrote: [Lines wrapped for legibility and R-help removed as it is not an appropriate list.] > Last week Giovanni Parrinello posted a message asking why various > packages were loaded when he loaded an .Rdata file. Brian Ripley replied > saying he thought it was because the saved workspace contained a > reference to the namespace of ipred. (Correspondence copied below). > > This begs the question: how did the reference to the namespace of ipred > come to be in the .Rdata file? Brian did say it is likely to be because > the workspace contained object(s) saved with environment the namespace > of ipred - but how would this come about? > > In this case I think is because the .Rdata file contained an object > whose *parent* environment was the namespace of ipred. Take the > following example from ?bagging (having loaded ipred): Excuse me: environments do not have parents but enclosures according to ?environment. Of course, the environment of mod is itself an object, and so my statement holds true. Saving a workspace saves all the objects (possibly as references) whether named or not. I was fully aware that the namespace was likely to be up the environment tree of a named object when I chose my words carefully. >> data(BreastCancer) >> >> mod <- bagging(Class ~ Cl.thickness + Cell.size > + + Cell.shape + Marg.adhesion > + + Epith.c.size + Bare.nuclei > + + Bl.cromatin + Normal.nucleoli > + + Mitoses, data=BreastCancer, coob=TRUE) >> >> environment(mod$mtrees[[1]]$btree$terms) > >> >> parent.env(environment(mod$mtrees[[1]]$btree$terms)) > parent.env is a very confusing name. To quote the draft R language definition: `The parent.env function may be used to access the enclosure of an environment.' [...] -- 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: ecdf - linear
I'm replying to R-devel, the mailing list which should be used
to discuss R feature enhancements.
> "Norman" == Norman Warthmann <[EMAIL PROTECTED]>
> on Wed, 18 Jan 2006 11:33:22 +0100 writes:
Norman> ..
Norman> Is there a specific reason why in the ecdf-function
Norman> the variable method="constant" is hard-coded?
yes, see below
Norman> I would like to use method="linear" and I have created
Norman> a new function based on yours just changing this and
Norman> it seems to work. I am now wondering whether you did
Norman> that on purpose? Maybe because there is problems
Norman> that are not obvious? If there aren't I would like
Norman> to put in a feature request to include the "method"-
Norman> argument into ecdf.
It can't be the way you did it:
The class "ecdf" inherits from class "stepfun" which is defined
to be "Step functions" and a step function *is* piecewise
constant (also every definition of ecdf in math/statistics
only uses a piecewise constant function).
Of course, it does make sense in some contexts to linearly
(or even "smoothly") interpolate an ecdf, one important context
being versions of "smoothed bootstrap", but the result is not a
proper ecdf anymore.
I think you should rather define a function that takes an ecdf
(of class "ecdf" from R) as input
and returns a piecewise linear function {resulting from
approxfun() as in your example below}. However that result may
*NOT* inherit from "ecdf" (nor "stepfun").
And for that reason {returning a different class}, this
extension should NOT become part of ecdf() itself.
If you write such a "ecdf -> interpolated_ecdf" transforming
function, it might be useful to include in the ecdf() help page
later, so "keep us posted".
Regards,
Martin Maechler, ETH Zurich
Norman> my changed function:
N>> ecdf_linear<-function (x)
N>> {
N>>x <- sort(x)
N>>n <- length(x)
N>>if (n < 1)
N>>stop("'x' must have 1 or more non-missing values")
N>>vals <- sort(unique(x))
N>>rval <- approxfun(vals, cumsum(tabulate(match(x,vals)))/n,
N>> method = "linear", yleft = 0, yright = 1, f = 0,ties = "ordered")
N>>class(rval) <- c("ecdf", "stepfun", class(rval))
N>>attr(rval, "call") <- sys.call()
N>>rval
N>> }
N>> test<-c(1,2,7,8,9,10,10,10,12,13,13,13,14)
N>> constant<-ecdf(test)
N>> linear<- ecdf_linear(test)
N>> plot(constant(1:14),type="b")
N>> points(linear(1:14),type="b",col="red")
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] standard install on OS 10.3.9 crashes on start without useful diagnostics (PR#8500)
Full_Name: Bob Donahue Version: 2.2 OS: Mac OS 10.3.9 Submission from: (NULL) (204.152.13.26) That's pretty much it. I did the most basic install possible, tried running the package through the GUI and on the command line, it crashed hard, immediately, with absolutely NO useful information as to WHY it crashed. To reproduce: 1) get the installer for OS X 2) install in the default places 3) run 4) watch it crash with no useful diagnostics __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Loading of namespace on load of .Rdata (was strange behaviourof load)
Apologies - I was not trying to correct you Brian, but to explore how the situation could arise. I'm sure you had a good idea why the namespace (or a reference to it) had been saved, but this was not clear to me and I thought, possibly not to others either. Thanks for putting me right over parent environments vs. enclosures - again I was not trying to correct you with the point I made there, but to trace back where the reference to the namespace might have come from in Giovanni's case. I think the issues raised are still of interest... Heather >>> Prof Brian Ripley <[EMAIL PROTECTED]> 01/18/06 01:31pm >>> On Wed, 18 Jan 2006, Heather Turner wrote: [Lines wrapped for legibility and R-help removed as it is not an appropriate list.] > Last week Giovanni Parrinello posted a message asking why various > packages were loaded when he loaded an .Rdata file. Brian Ripley replied > saying he thought it was because the saved workspace contained a > reference to the namespace of ipred. (Correspondence copied below). > > This begs the question: how did the reference to the namespace of ipred > come to be in the .Rdata file? Brian did say it is likely to be because > the workspace contained object(s) saved with environment the namespace > of ipred - but how would this come about? > > In this case I think is because the .Rdata file contained an object > whose *parent* environment was the namespace of ipred. Take the > following example from ?bagging (having loaded ipred): Excuse me: environments do not have parents but enclosures according to ?environment. Of course, the environment of mod is itself an object, and so my statement holds true. Saving a workspace saves all the objects (possibly as references) whether named or not. I was fully aware that the namespace was likely to be up the environment tree of a named object when I chose my words carefully. >> data(BreastCancer) >> >> mod <- bagging(Class ~ Cl.thickness + Cell.size > + + Cell.shape + Marg.adhesion > + + Epith.c.size + Bare.nuclei > + + Bl.cromatin + Normal.nucleoli > + + Mitoses, data=BreastCancer, coob=TRUE) >> >> environment(mod$mtrees[[1]]$btree$terms) > >> >> parent.env(environment(mod$mtrees[[1]]$btree$terms)) > parent.env is a very confusing name. To quote the draft R language definition: `The parent.env function may be used to access the enclosure of an environment.' [...] -- 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] symbols function -- possible enhancements
On Wed, 18 Jan 2006, Martin Maechler wrote:
> Hi Jean,
>
> now that you've been told `the truth' .. :
>
> If you'd like to carefully look at symbols() and its help page and see
> which arguments ('axes' but maybe more) would be useful to pass
> to plot.default and if you provide enhanced versions of the two files
> https://svn.r-project.org/R/trunk/src/library/graphics/R/symbols.R
> and https://svn.r-project.org/R/trunk/src/library/graphics/man/symbols.Rd
>
> I'll gladly look at them and incorporate them for R 2.3.0
> (unless they break something)
I am not at all sure this is a good idea. We have a standard way (x/yaxt)
to suppress axes. Let's not propagate the myth that axes=FALSE is
standard, as then people will expect it in all plot() methods. (We have
been here several times before when people have made that incorrect
assumption.)
symbols() is just one of a range of high-level graphics functions such as
(the default methods of) barplot, boxplot, contour, coplot, dotchart,
image, hist, pairs, stars, sunflowerplot. A few do have an 'axes'
argument and others accept one (and most were wrongly documented) and
others do not. In general the S originals do not have an axes or ...
argument, and R has added them rather inconsistently. My preference would
be that ... is used only for graphics parameters, but clearly we cannot
get from here to there.
>
> Best regards,
> Martin Maechler
>
>
>> "BDR" == Prof Brian Ripley <[EMAIL PROTECTED]>
>> on Tue, 17 Jan 2006 23:15:19 + (GMT) writes:
>
>BDR> On Tue, 17 Jan 2006, Thomas Lumley wrote:
>>> On Tue, 17 Jan 2006, Jean Eid wrote:
>>>
>>>> Hi
>>>>
>>>> I do not get why the symbols function produces warnings when axes=F is
>>>> added. The following example illustrate this
>>>>
> symbols(0,10, inches=T, circles=1, axes=F, xlab="", ylab="")
>>>> Warning message:
>>>> parameter "axes" could not be set in high-level plot() function
>>>>
>>>>
>>>> I augmented symbols and added the axes=F argument to the plot function
>>>> inside the original symbols function. It works as expected, no warning
>>>> message. I am just lost as to why the extra arguments in symbols (...)
>>>> are not behaving as expected.
>>>>
>>>
>>> The ... argument is also passed to .Internal, and presumably the code
>>> there gives the warning.
>
>BDR> Indeed. axes=F is not in the allowed list
>
>BDR> ...: graphics parameters can also be passed to this function, as
>BDR> can the plot aspect ratio 'asp' (see 'plot.window').
>
>BDR> People confuse 'axes' with the graphics parameters, but it is in fact
> an
>BDR> argument to plot.default. (The corresponding graphics parameters
>BDR> xaxt and yaxt do work.) R-devel gives a more informative message:
>
>>> attach(trees)
>>> symbols(Height, Volume, circles = Girth/24, inches = FALSE, axes=F)
>BDR> Warning message:
>BDR> "axes" is not a graphical parameter in: symbols(x, y, type, data,
> inches,
>BDR> bg, fg, ...)
>
>BDR> We do ask people to read the help pages before posting for a good
> reason:
>BDR> the information is usually there in a more complete and accurate form
> than
>BDR> people remember.
--
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] (PR#8500) standard install on OS 10.3.9 crashes on start without useful diagnostics (PR#8500)
This won't actually help you at all, but I used the standard install on OS 10.3.9 (Powerbook G4) just last week without any problems. On the other hand, my install was on a machine that had previously had other versions of R. -thomas On Wed, 18 Jan 2006, [EMAIL PROTECTED] wrote: > Full_Name: Bob Donahue > Version: 2.2 > OS: Mac OS 10.3.9 > Submission from: (NULL) (204.152.13.26) > > > That's pretty much it. I did the most basic install possible, tried running > the > package through the GUI and on the command line, it crashed hard, immediately, > with absolutely NO useful information as to WHY it crashed. > > To reproduce: > 1) get the installer for OS X > 2) install in the default places > 3) run > 4) watch it crash with no useful diagnostics > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > Thomas Lumley Assoc. Professor, Biostatistics [EMAIL PROTECTED] University of Washington, Seattle __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] natural sorting
Good idea. Done.
-G
> -Original Message-
> From: Martin Maechler [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, January 18, 2006 4:02 AM
> To: Warnes, Gregory R
> Cc: Andrew Piskorski; R Development Mailing List
> Subject: Re: [Rd] natural sorting
>
>
> > "Greg" == Warnes, Gregory R <[EMAIL PROTECTED]>
> > on Tue, 17 Jan 2006 14:48:46 -0500 writes:
>
> Greg> The 'mixedsort' function in the 'gtools' package does
> Greg> this. It is probably slower than the c version you
> Greg> point to, but it is already working in R.
>
> Thank you, Greg.
>
> BTW, given the thread, this is a typical example where it might
> be very useful to add the following two concepts to the
>mixedsort.Rd file in gtools :
>
> \concept{natural sort}
> \concept{dictionary sort}
>
> so that mixedsort() will be quickly found by
> help.search("natural sort")
> and possibly also via the java search from the HTML help interface?
> (I never use it; I use help.search() {or then RSiteSearch()}
> exclusively.)
>
> Martin
>
>
> >> -Original Message-
> >> From: [EMAIL PROTECTED]
> >> [mailto:[EMAIL PROTECTED] Behalf Of
> Andrew Piskorski
> >> Sent: Thursday, January 12, 2006 10:40 AM
> >> To: R Development Mailing List
> >> Subject: Re: [Rd] natural sorting
> >>
> >>
> >> On Wed, Jan 11, 2006 at 05:45:10PM -0500, Gabor
> Grothendieck wrote:
> >> > It would be nifty to incorporate this into R or into
> an R package:
> >> >
> >> > http://sourcefrog.net/projects/natsort/
> >>
> >> Btw, I haven't looked at the implementation, but Tcl
> also contains
> >> equivalent functionality, they call it dictionary sort:
> >>
> >> http://tcl.activestate.com/man/tcl8.4/TclCmd/lsort.htm
> >>
> >> --
> >> Andrew Piskorski <[EMAIL PROTECTED]>
> >> http://www.piskorski.com/
>
>
--
LEGAL NOTICE\ Unless expressly stated otherwise, this messag...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Suboptimal EPS output (PR#8502)
Full_Name: Mike Prager
Version: 2.2.1
OS: Windows XP with SP2
Submission from: (NULL) (205.156.36.17)
When several EPS files are made with one invocation of postscript(), only the
first displays correctly in gsview. Examination of the generated eps files with
a diff utility reveals that subsequent eps files lack the encoding vector
definition and report page numbers higher than one. This causes (e.g.) gsview to
fail when trying to display the subsequent files.
My copy of the EPS specification does not prohibit %%Pages DSC comments higher
than one, but since an EPS file is not allowed to have multiple pages, it seems
inconsistent at least for the R-generated file to claim to be page 2 or that it
contains more than one page.
The lack of encoding vector definition causes font loading to fail when it the
file later specifies WinAnsiEncoding (as it does by default).
Therefore, it would be desirable for each generated eps file to include the
encoding vector and to state that it is page 1 of 1 and that the number of pages
is 1.
(This can be worked around by closing the device between plots, thus making sure
each EPS file is the first file.)
The following example generates two files, the second of which is incompatible
with gsview on Windows as described:
##
# epstest.r
# M. H. Prager
# Demonstrate (1) possible wrapper function for postscript() and
# (2) problems with current EPS output
# January 17, 2006
##
eps <- function (...)
{
postscript(height = 5, width = 7, onefile = FALSE, horizontal = FALSE,
paper = "special", file = "Rplot%03d.eps", ...)
}
eps()
plot(1:5, rnorm(5))
plot(1:6, rnorm(6))
dev.off()
# END OF EXAMPLE
##
In addition, although it is NOT a bug, I would like to request that a wrapper
function like eps() above be included with the R distribution. This would save
R-help readers from answering the same questions over and over. It would also
make it easier for newcomers to use R for generating eps files. Consideration by
the R Core Team would be appreciated.
Thanks,
...Mike Prager
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] (PR#8502) comment
In my example, I should have included the defaults to the wrapper function in its definition, rather than in the call to postscript(). That of course does NOT affect the validity of my bug report nor the ability of my example to demonstrate it. MHP __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] (PR#8500) standard install on OS 10.3.9 crashes on start without useful diagnostics (PR#8500)
Let me add that you should probably have a crash report on your system. See Console.app inside "Utilities" and search for R.app or R crash report. Check if date/time of the log is the right one and send it to us. Did you have a previous version of R.app installed? An old one? Because the problem could be in the preference file sometimes. thanks stefano Il giorno 18/gen/06, alle ore 16:25, Thomas Lumley ha scritto: > > This won't actually help you at all, but I used the standard > install on OS > 10.3.9 (Powerbook G4) just last week without any problems. > > On the other hand, my install was on a machine that had previously had > other versions of R. > > -thomas > > On Wed, 18 Jan 2006, [EMAIL PROTECTED] wrote: > >> Full_Name: Bob Donahue >> Version: 2.2 >> OS: Mac OS 10.3.9 >> Submission from: (NULL) (204.152.13.26) >> >> >> That's pretty much it. I did the most basic install possible, >> tried running the >> package through the GUI and on the command line, it crashed hard, >> immediately, >> with absolutely NO useful information as to WHY it crashed. >> >> To reproduce: >> 1) get the installer for OS X >> 2) install in the default places >> 3) run >> 4) watch it crash with no useful diagnostics >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > Thomas Lumley Assoc. Professor, Biostatistics > [EMAIL PROTECTED] University of Washington, Seattle > > __ > 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] data.matrix returns mode logical for zero rows (PR#8496)
On Tue, 17 Jan 2006 [EMAIL PROTECTED] wrote:
> Full_Name: Jonathan Swinton
> Version: 2.2.1
> OS: Windows
> Submission from: (NULL) (193.132.159.169)
>
>
> #The first line of description for data.matrix says that it will
> # 'Return the matrix obtained by converting all the variables in a
> #data frame to numeric mode and then binding them together as the
> # columns of a matrix.'
>
> #However when called with a data.frame with zero rows, data.matrix returns a
> matrix
> #of mode logical rather than numeric. This conflicts with the documentation
> #and is not what seems sensible.
You don't show us an example of a data frame with zero rows, nor do you
show an example of data.matrix returning logical, so this report was very
confusing. Please do give a reproducible example as the posting guide and
FAQ ask.
df[FALSE,] is not a data frame, so I don't know why you expect data.matrix
to be applicable (it is the same as as.matrix in such cases).
Here is an actual reproducible example:
DF <- data.frame(x=c("a", "b"), y=2:3)[FALSE,]
typeof(data.matrix(DF))
> One underlying reason for this is that when a zero-length column of a
> matrix of mode logical is asserted to be numeric the matrix is not
> actually cast to numeric. I wonder if that too is a bug?
No, but there is a bug in your description as you are describing
replacement indexing, not `assertion'. Coercion in replacement indexing
is done to accommodate the new values, and there are none in your example.
(That is how S has always done it in my experience, although the Blue
Book p.359 says otherwise.)
If you want to assert that an object be numeric, use mode(x) <- "numeric".
>> R.version.string
> [1] "R version 2.2.1, 2005-12-20"
>> df <- data.frame(matrix(1:2,nrow=2))
>> mode(data.matrix(df)[,1])
> [1] "numeric"
>> mode(data.matrix(df[FALSE,])[,1])
> [1] "numeric"
>>
>> # Underlying cause
>> x <- matrix(nr = 2,nc = 1 )
>> mode(x)
> [1] "logical"
>> x[, 1] <- c(1,2)
>> mode(x)
> [1] "numeric"
>>
>> x0 <- matrix(nr = 0, nc = 1)
>> x0[, 1] <- numeric(0)
>> mode(x0)
> [1] "logical"
>> mode(x0[,1])
> [1] "logical"
--
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] Display an Image on a Plane
Hi, I am new to R and I would like to display an image on a plane in a 3D plot, i.e. I would like to be able to specify a theta and a phi parameters like in the function persp to display a 2D image on an inclined plane. Regards, vincent [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] function 'eigen' (PR#8503)
Full_Name: Pierre Legendre Version: 2.1.1 OS: Mac OSX 10.4.3 Submission from: (NULL) (132.204.120.81) I am reporting the mis-behaviour of the function 'eigen' in 'base', for the following input matrix: A <- matrix(c(2,3,4,-1,3,1,1,-2,0),3,3) eigen(A) I obtain the following results, which are incorrect for eigenvalues and eigenvectors 2 and 3 (incorrect imaginary portions): $values [1] 3+0.00e+00i 1+1.869518e-08i 1-1.869518e-08i $vectors [,1] [,2] [,3] [1,] -0.5345225+0i 4.720910e-17+2.643897e-09i 4.720910e-17-2.643897e-09i [2,] -0.2672612+0i 7.071068e-01+0.00e+00i 7.071068e-01+0.00e+00i [3,] -0.8017837+0i 7.071068e-01-2.643897e-09i 7.071068e-01+2.643897e-09i The eigenvalues of matrix A are 3, 1, and 1. The eigenvectors are real (not complex). Eigenvectors 2 and 3 of matrix A are identical. With R version 2.2.1 on a PC, 'eigen' produces the following (correct) results: Results obtained on a PC (WIndows) using R version 2.2.1: eigen(A) $values [1] 3 1 1 $vectors [,1] [,2] [,3] [1,] -0.5345225 -3.563430e-09 -3.563431e-09 [2,] -0.2672612 -7.071068e-01 7.071068e-01 [3,] -0.8017837 -7.071068e-01 7.071068e-01 I obtained the following results using R version 2.2.1 on a PowerMac G5 under Mac OSX 10.4.4: eigen(A) $values [1] 3+0i 1+0i 1-0i # OK results, although there is no need to show the imaginary portion which is 0 $vectors [,1] [,2] [,3] [1,] -0.5345225+0i 4.720910e-17+2.643897e-09i 4.720910e-17-2.643897e-09i [2,] -0.2672612+0i 7.071068e-01+0.00e+00i 7.071068e-01+0.00e+00i [3,] -0.8017837+0i 7.071068e-01-2.643897e-09i 7.071068e-01+2.643897e-09i Incorrect imaginary portions, again, in eigenvectors 2 and 3. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] StatLib mirror now OK
Pantelis Vlachos (the StatLib admin) and I figured out what the problems with the CRAN mirror on StatLib were and he seems to have fixed all problems in the mirroring process. Please let us know if you still observe problems with the StatLib mirror. Best, -- --- Friedrich Leisch Institut für Statistik Tel: (+43 1) 58801 10715 Technische Universität WienFax: (+43 1) 58801 10798 Wiedner Hauptstraße 8-10/1071 A-1040 Wien, Austria http://www.ci.tuwien.ac.at/~leisch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
