[Rd] hist title paste problem (PR#7421)
Full_Name: Barry Rowlingson
Version: 2.0.0
OS: RH FC2 Linux
Submission from: (NULL) (194.80.32.8)
If the title string to a histogram is of length > 1, the words 'Histogram of'
get pasted to each element. Looks wrong.
Example:
hist(apply(matrix(0,10,10),1,function(x){runif(1)}))
Produces a title that goes:
Histogram of apply(matrix(0,10,10),1,function(x){
Histogram of runif(1)
Histogram of })
Its in the way that 'Histogram of' is pasted to the deparsed expression. If that
expression has an anonymous function in it, then that gets deparsed into a
vector of length 3, and hence 'Histogram of' gets put on the start of each one.
There's probably several trivial ways to fix this, so I wont choose one, but
leave it to the experts.
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Hooks, docs [was [Rd] Multiple options for a package]
Brian,
thanks for the useful hints! In fact, that code features several
interesting techniques.
While reading one of the related docs I stumbled upon a slight problem
in the UserHooks {base} docs:
pkgname character string: the package/namespace name. If versioned
install has been used, pkgname should the unversioned name of the
package and any version information will be stripped.
The last sentence doesn't make too much sense to me - either there's a
verb missing after the "should" or it should go away altogether
(depending on what was really meant ...) or there's a better way to put
it...
... and since we're talking about hooks - is there some standard as of
what custom hook names should look like? Or maybe the hook parameters?
(I noticed the one used in grid doesn't supply any parameters at
all...) And finally how should hooks be documented (or the other way
round - how does one look for hook documentation)?
Thanks,
Simon
On Dec 14, 2004, at 8:30 AM, Prof Brian Ripley wrote:
I also don't see why you need to save options to file _within a
session_, and the R testing framework does not do so -- take a look at
what massage-examples does. But if you do save options, remember that
some are read-only. I think you would find .readRDS and allies (see
the help page) more convenient.
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Multiple options for a package
I don't see why package options need have anything to do with options().
It seems to me that they really should be stored in the package namespace
(and so disappear when the package is detached). One package which does
this is 'sm' (although that has been ported from S-PLUS and is not the
cleanest R-only mechanism).
I also don't see why you need to save options to file _within a session_,
and the R testing framework does not do so -- take a look at what
massage-examples does. But if you do save options, remember that some are
read-only. I think you would find .readRDS and allies (see the help page)
more convenient.
On Tue, 14 Dec 2004, Eric Lecoutre wrote:
Hi R-devel,
I am facing a situation where the number of options I would like to propose
to the user is somewhat big (and could easily increase more and more as I
will code up a little more - even coming to a point where an user should be
able to implement his own options).
What we have to handle options is the couple:
options(par=value) and getOption("par")
I was aking myselft what would be the "better" strategy to handle a bunch of
options for a package.
I ended up with the idea of storing a list, as my options would also be
classified, with something like:
--
MyPkgOptions =
list(set1=list(par1=1,par2=2),set2=list(subset1=list(par1=11,par2=22),subset2=list(par1=111,par2=222)))
options(PkgName=MyPkgOptions)
--
Then, to make easier the access to an element, I tweaked a little bit
getOption, with the following version:
--
getOption <- function(x,...)
{
op = options(x)[[1]]
if (length(list(...))>0) op <- op[[c(...)]]
return(op)
}
--
Making possible calls like:
---
getOption("PkgName","set2","subset2","par1")
[1] 111
---
Then, I began to implement things like
SetPkgOption(pkg,value=NULL,pathToValue) and getPkgOption(pkg,pathToValue)
But I wonder if this wont be easier / more efficient at the C level. Sorry: I
dont propose myself to make it, as my C skills are nearly null.
To recap:
- I need a way to set/get a lot of options for a package
- I am ready to go on with my appraoch, delivering at the end some R
functions
- Seeing the way options() are handled with the internal call, I wonder if my
idea is the better one
- Specifically, I think someone with greater C skills should be able to set
up functions like PkgOptions
- I would like to hear about any other idea that would better suit me needs
Best wishes,
Eric
PS: I think handling options at a package level would be a benefit for the
user. Setting options would be done within .First or .onLoad when we know the
package name. The options() tree would be far more readable, separating core
options from others. Two weeks ago, i ended up with a list of 125 elements...
PS2: an other related topic is Saving/Restore options. For my personal needs
(testing within a session), I coded following functions:
saveOptions <- function(file="R.options",...){
opts=options(...)
save(opts,file=file)
}
restoreOptions <- function(file="R.options"){
bool=TRUE
.tmp=new.env()
if (!file.exists(file))
{
warning(paste("file ", file, " does not exist"))
bool=FALSE
}
else
{
}
load(file,.tmp)
opts = get("opts",envir=.tmp)
options(opts)
return(bool)
}
Same scheme could be used for a set of options (say options for a package).
Any comment on the above code?
__
[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
[Rd] Multiple options for a package
Hi R-devel,
I am facing a situation where the number of options I would like to propose
to the user is somewhat big (and could easily increase more and more as I
will code up a little more - even coming to a point where an user should be
able to implement his own options).
What we have to handle options is the couple:
options(par=value) and getOption("par")
I was aking myselft what would be the "better" strategy to handle a bunch
of options for a package.
I ended up with the idea of storing a list, as my options would also be
classified, with something like:
--
MyPkgOptions =
list(set1=list(par1=1,par2=2),set2=list(subset1=list(par1=11,par2=22),subset2=list(par1=111,par2=222)))
options(PkgName=MyPkgOptions)
--
Then, to make easier the access to an element, I tweaked a little bit
getOption, with the following version:
--
getOption <- function(x,...)
{
op = options(x)[[1]]
if (length(list(...))>0) op <- op[[c(...)]]
return(op)
}
--
Making possible calls like:
---
getOption("PkgName","set2","subset2","par1")
[1] 111
---
Then, I began to implement things
like SetPkgOption(pkg,value=NULL,pathToValue) and
getPkgOption(pkg,pathToValue)
But I wonder if this wont be easier / more efficient at the C level. Sorry:
I dont propose myself to make it, as my C skills are nearly null.
To recap:
- I need a way to set/get a lot of options for a package
- I am ready to go on with my appraoch, delivering at the end some R functions
- Seeing the way options() are handled with the internal call, I wonder if
my idea is the better one
- Specifically, I think someone with greater C skills should be able to set
up functions like PkgOptions
- I would like to hear about any other idea that would better suit me needs
Best wishes,
Eric
PS: I think handling options at a package level would be a benefit for the
user. Setting options would be done within .First or .onLoad when we know
the package name. The options() tree would be far more readable, separating
core options from others. Two weeks ago, i ended up with a list of 125
elements...
PS2: an other related topic is Saving/Restore options. For my personal
needs (testing within a session), I coded following functions:
saveOptions <- function(file="R.options",...){
opts=options(...)
save(opts,file=file)
}
restoreOptions <- function(file="R.options"){
bool=TRUE
.tmp=new.env()
if (!file.exists(file))
{
warning(paste("file ", file, " does not exist"))
bool=FALSE
}
else
{
}
load(file,.tmp)
opts = get("opts",envir=.tmp)
options(opts)
return(bool)
}
Same scheme could be used for a set of options (say options for a package).
Any comment on the above code?
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R stat functions do not work as stated on the mannual (PR#7419)
Dear R Developers: I have been playing with R, release 2.0.1 for a week now and have detected = that all stat functions related to distribution probabilities have the same= problem: 1.- According to the manual the log.p parameter is always the last one. 2.- When you use the software, the last parameter seems to be lower.tail Example: > pt (1.1, 5) [1] 0.8392746 > pt (1.1, 5, F) [1] 0.8392746 > pt (1.1, 5, F, T) [1] 0.8392746 >=0D On this example, I have used the Student T distribution. The result of this= example has been tested with the stat calculator at http://calculators.sta= t.ucla.edu/. 1.- This first line shows that when this function has two arguments, the lo= g.p default value is false, and the lower.tail is true. 2.- The second line shows that when this function has 3 arguments, the last= one is the log.p argument and the lower.tail is taken by default to true. 3.- The third line shows that when this function has 4 arguments, the third= one keeps on being the log.p argument and the lower.tail is the last one. 4.- Acording to the mannual, the lower.tail should be the third argument an= d not the last one. Best regards, =0D Jos=E9 Luis Casado Mart=EDnez -- European Computing Consultants C/ Hermanos Garc=EDa Noblejas, N=BA 39, 5=AA, N 1 28037 Madrid Telf.: 34-91-406 19 15. Fax: 34-91-406 19 16 Movil: 34-607-750 316 -- The last line shows that the sum of probabilities of 1.1 using 5 degrees of= freedom adding the lower tail (pt (1.1, 5, F, T)) and not adding the lower= tail ( pt (1.1, 5, F, F)) is 1. This is not the case with log (p). _ Mensaje analizado y protegido, tecnologia antivirus www.trendmicro.es [[alternative HTML version deleted]] __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
RE: [Rd] R stat functions do not work as stated on the mannual ( PR#7419)
> From: [EMAIL PROTECTED] > > > Dear R Developers: > > I have been playing with R, release 2.0.1 for a week now and > have detected = > that all stat functions related to distribution probabilities > have the same= > problem: > > 1.- According to the manual the log.p parameter is always the > last one. > 2.- When you use the software, the last parameter seems to be > lower.tail > > Example: > > > pt (1.1, 5) > [1] 0.8392746 > > pt (1.1, 5, F) > [1] 0.8392746 > > pt (1.1, 5, F, T) > [1] 0.8392746 > >=0D > > On this example, I have used the Student T distribution. The > result of this= > example has been tested with the stat calculator at http://calculators.sta= t.ucla.edu/. 1.- This first line shows that when this function has two arguments, the lo= g.p default value is false, and the lower.tail is true. 2.- The second line shows that when this function has 3 arguments, the last= one is the log.p argument and the lower.tail is taken by default to true. 3.- The third line shows that when this function has 4 arguments, the third= one keeps on being the log.p argument and the lower.tail is the last one. 4.- Acording to the mannual, the lower.tail should be the third argument an= d not the last one. Which manual did you read? ?pt has: Usage [...] pt(q, df, ncp=0, lower.tail = TRUE, log.p = FALSE) So none of the calls you showed actually passed any thing for log.p to pt(): It's the 5th argument. While it seems to be a convention that log.p is the last argument, the actual position can change from distribution to distribution as the number of parameters can differ. Andy Best regards, =0D Jos=E9 Luis Casado Mart=EDnez -- European Computing Consultants C/ Hermanos Garc=EDa Noblejas, N=BA 39, 5=AA, N 1 28037 Madrid Telf.: 34-91-406 19 15. Fax: 34-91-406 19 16 Movil: 34-607-750 316 -- The last line shows that the sum of probabilities of 1.1 using 5 degrees of= freedom adding the lower tail (pt (1.1, 5, F, T)) and not adding the lower= tail ( pt (1.1, 5, F, F)) is 1. This is not the case with log (p). _ Mensaje analizado y protegido, tecnologia antivirus www.trendmicro.es [[alternative HTML version deleted]] __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] labels.lm (PR#7417)
Thank you. It has been that way for six years, so presumably it worked
once
On Mon, 13 Dec 2004 [EMAIL PROTECTED] wrote:
Full_Name: Heather Turner
Version: 2.0.1
OS: Windows XP
Submission from: (NULL) (137.205.240.44)
labels.lm does not produce term labels for estimable terms as intended, e.g.
example(lm)
labels(lm.D9)
character(0)
The function code is as follows:
labels.lm
function (object, ...)
{
tl <- attr(object$terms, "term.labels")
asgn <- object$asgn[object$qr$pivot[1:object$rank]]
tl[unique(asgn)]
}
Replacing object$asgn with object$assign appears to solve the problem:
labels.lm2 <-
+ function (object, ...)
+ {
+ tl <- attr(object$terms, "term.labels")
+ asgn <- object$assign[object$qr$pivot[1:object$rank]]
+ tl[unique(asgn)]
+ }
labels.lm2(lm.D9)
[1] "group"
__
[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
[Rd] labels.lm (PR#7417)
Full_Name: Heather Turner
Version: 2.0.1
OS: Windows XP
Submission from: (NULL) (137.205.240.44)
labels.lm does not produce term labels for estimable terms as intended, e.g.
> example(lm)
> labels(lm.D9)
character(0)
The function code is as follows:
> labels.lm
function (object, ...)
{
tl <- attr(object$terms, "term.labels")
asgn <- object$asgn[object$qr$pivot[1:object$rank]]
tl[unique(asgn)]
}
Replacing object$asgn with object$assign appears to solve the problem:
> labels.lm2 <-
+ function (object, ...)
+ {
+ tl <- attr(object$terms, "term.labels")
+ asgn <- object$assign[object$qr$pivot[1:object$rank]]
+ tl[unique(asgn)]
+ }
>
> labels.lm2(lm.D9)
[1] "group"
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Re: [R] Is k equivalent to k:k ?
> "RichOK" == Richard A O'Keefe <[EMAIL PROTECTED]>
> on Mon, 13 Dec 2004 10:56:48 +1300 (NZDT) writes:
RichOK> I asked:
>> In this discussion of seq(), can anyone explain to me
>> _why_ seq(to=n) and seq(length=3) have different types?
RichOK> Martin Maechler <[EMAIL PROTECTED]>
RichOK> replied: well, the explantion isn't hard: look at
RichOK> seq.default :-)
RichOK> That's the "efficient cause", I was after the "final
RichOK> cause". That is, I wasn't asking "what is it about
RichOK> the system which MAKES this happen" but "why does
RichOK> anyone WANT this to happen"?
sure, I did understand you quite well -- I was trying to joke
and used the " :-) " to point the joking ..
MM> now if that really makes your *life* simpler,
MM> what does that tell us about your life ;-) :-)
{ even more " :-) " !! }
RichOK> It tells you I am revising someone else's e-book
RichOK> about S to describe R. The cleaner R is, the easier
RichOK> that part of my life gets.
of course, and actually I do agree for my life too,
since as you may believe, parts of my life *are* influenced by R.
Apologize for my unsuccessful attempts to joking..
RichOK> seq: from, to, by, length[.out], along[.with]
MM> I'm about to fix this (documentation, not code).
RichOK> Please don't. There's a lot of text out there:
RichOK> tutorials, textbooks, S on-inline documentation, &c
RichOK> which states over and over again that the arguments
RichOK> are 'along' and 'with'.
you meant
'along' and 'length'
yes. And everyone can continue to use the abbreviated form as
I'm sure nobody will introduce a 'seq' method that uses
*multiple* argument names starting with "along" or "length"
(such that the partial argument name matching could become a problem).
RichOK> Change the documentation, and people will start
RichOK> writing length.out, and will that port to S-Plus?
RichOK> (Serious question: I don't know.)
yes, as Peter has confirmed already.
Seriously, I think we wouldn't even have started using the ugly
".with" or ".out" appendices, wouldn't it have been for S-plus
compatibility {and Peter has also given the explanation why there
*had* been a good reason for these appendices in the past}.
Martin
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
RE: [Rd] Problem with read.xport() from foreigh package (PR#7389)
> Have you looked at the latest version of foreign, 0.8-2? The issue has > already been resolved, AFAIK. Prof. Ripley is, of course, correct: the issue is already resolved. I should have checked against the development branch, not the stable version. Best regards, Werner Engl -- GMX DSL-Netzanschluss + Tarif zum supergünstigen Komplett-Preis! __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
