Re: [Rd] setMethod("Summary")

[Robin Hankin]

Dear Franklin


thank you for this.


Your suggestion works.  But now I'm confused because I'm not sure how  
the
setGeneric() call actually helps.

If I source:

setClass("brob",
  representation = representation 
(x="numeric",positive="logical"),
  prototype  = list(x=numeric(),positive=logical())
  )


max.brob <- function(..., na.rm=FALSE){stop("not YET implemented")}


---ie no call to setGeneric()--- then in an R session I can do the  
following:


R> x <- new("brob",x=6,positive=T)
R> max(x)
Error in max.brob(..., na.rm = na.rm) : not YET implemented


So max(x) calls max.brob() as intended.  Why would a call to  
setGeneric()
be desirable here?  What do I gain from it?


thanks again


Robin




On 4 Sep 2006, at 19:58, Parlamis Franklin wrote:

> i believe, if the function you are trying to work with has "..." as
> the first formal argument (as do most if not all of the "Summary"
> group functions), you will need to redefine the generic in order to
> provide a "real" S4 argument on which to dispatch.
>
> the following works for me (IIRC it was martin who initially pointed
> me in this direction, so any thanks are his).
>
> setGeneric("max", function(x, ..., na.rm = FALSE)
>   {
>   standardGeneric("max")
>   },
>   useAsDefault = function(x, ..., na.rm = FALSE)
>   {
>   base::max(x, ..., na.rm = na.rm)
>   },
>   group = "Summary")
>
> i don't have bleeding edge devel version installed, so i am not sure
> whether recent changes to S4 have mooted the above.
>
> (also, i thought i sent this last week, but i may have neglected to
> make it plain text, so maybe you didn't get it)
>
> franklin parlamis
>
> On Sep 4, 2006, at 3:47 AM, Robin Hankin wrote:
>
>> Hi everyone and thanks for being patient.   I've used "!.foo"() et
>> seq pro tem.
>>
>> Next problem: how to define "Summary" methods for brobs.
>>
>> ?max says
>>
>>'max' and 'min' are generic functions: methods can be defined for
>>   them individually or via the 'Summary' group generic. For
>> this to
>>   work properly, the arguments '...' should be unnamed.
>>
>> OK, so what is the correct procedure to make sum() operate on brob
>> objects?
>>
>> My best effort follows.
>>
[snipped]


--
Robin Hankin
Uncertainty Analyst
National Oceanography Centre, Southampton
European Way, Southampton SO14 3ZH, UK
  tel  023-8059-7743

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] setMethod("Summary")

[Martin Maechler]

> "Robin" == Robin Hankin <[EMAIL PROTECTED]>
> on Tue, 5 Sep 2006 08:58:23 +0100 writes:

Robin> Dear Franklin
Robin> thank you for this.

yes, and he *did* send it already last week.

Robin> Your suggestion works.

and continues to do so in R-devel aka "R-2.4.0 alpha" (as of today?)

Robin> But now I'm confused because I'm not sure how  
Robin> the
Robin> setGeneric() call actually helps.

Robin, I think you got confused because you are mixing S3 and S4
("max.brob" is S3).

You should (typically) not define S3 methods for S4 classes,
and you should definitely not do it in this case where Franklin 
has shown the correct S4 way.
(and for my taste you should also not do it for the "Logic" case
 in that other thread last week: It does not bring you anything and is
 ugly for me, from the point of view of S4.)

BTW: As Franklin mentioned last time, he has most probably
learned the example from the example in the 'Matrix' package.
Since we develop the Matrix package using a world-readable
subversion archive, you can always have a look there.
The  "Summary" [ "max" etc ] generic definitions are in
   https://svn.R-project.org/R-packages/trunk/Matrix/R/AllGeneric.R
BTW, the above file contains
>> ## "Summary" --- this needs some hoop jumping that may become unnecessary
>> ##   in a future version of R (>= 2.3.x):

where the hope there has not yet been fulfilled ...

Martin Maechler, ETH Zurich


Robin> If I source:

Robin> setClass("brob",
Robin> representation = representation 
Robin> (x="numeric",positive="logical"),
Robin> prototype  = list(x=numeric(),positive=logical())
Robin> )


Robin> max.brob <- function(..., na.rm=FALSE){stop("not YET implemented")}


Robin> ---ie no call to setGeneric()--- then in an R session I can do the  
Robin> following:


R> x <- new("brob",x=6,positive=T)
R> max(x)
Robin> Error in max.brob(..., na.rm = na.rm) : not YET implemented


Robin> So max(x) calls max.brob() as intended.  Why would a call to  
Robin> setGeneric()
Robin> be desirable here?  What do I gain from it?


Robin> thanks again


Robin> Robin




Robin> On 4 Sep 2006, at 19:58, Parlamis Franklin wrote:

>> i believe, if the function you are trying to work with has "..." as
>> the first formal argument (as do most if not all of the "Summary"
>> group functions), you will need to redefine the generic in order to
>> provide a "real" S4 argument on which to dispatch.
>> 
>> the following works for me (IIRC it was martin who initially pointed
>> me in this direction, so any thanks are his).
>> 
>> setGeneric("max", function(x, ..., na.rm = FALSE)
>> {
>> standardGeneric("max")
>> },
>> useAsDefault = function(x, ..., na.rm = FALSE)
>> {
>> base::max(x, ..., na.rm = na.rm)
>> },
>> group = "Summary")
>> 
>> i don't have bleeding edge devel version installed, so i am not sure
>> whether recent changes to S4 have mooted the above.
>> 
>> (also, i thought i sent this last week, but i may have neglected to
>> make it plain text, so maybe you didn't get it)
>> 
>> franklin parlamis
>> 
>> On Sep 4, 2006, at 3:47 AM, Robin Hankin wrote:
>> 
>>> Hi everyone and thanks for being patient.   I've used "!.foo"() et
>>> seq pro tem.
>>> 
>>> Next problem: how to define "Summary" methods for brobs.
>>> 
>>> ?max says
>>> 
>>> 'max' and 'min' are generic functions: methods can be defined for
>>> them individually or via the 'Summary' group generic. For
>>> this to
>>> work properly, the arguments '...' should be unnamed.
>>> 
>>> OK, so what is the correct procedure to make sum() operate on brob
>>> objects?
>>> 
>>> My best effort follows.
>>> 
Robin> [snipped]


Robin> --
Robin> Robin Hankin
Robin> Uncertainty Analyst
Robin> National Oceanography Centre, Southampton
Robin> European Way, Southampton SO14 3ZH, UK
Robin> tel  023-8059-7743

Robin> __
Robin> R-devel@r-project.org mailing list
Robin> 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] setMethod("Summary")

[Prof Brian Ripley]

On Tue, 5 Sep 2006, Martin Maechler wrote:

> > "Robin" == Robin Hankin <[EMAIL PROTECTED]>
> > on Tue, 5 Sep 2006 08:58:23 +0100 writes:
> 
> Robin> Dear Franklin
> Robin> thank you for this.
> 
> yes, and he *did* send it already last week.
> 
> Robin> Your suggestion works.
> 
> and continues to do so in R-devel aka "R-2.4.0 alpha" (as of today?)
> 
> Robin> But now I'm confused because I'm not sure how  
> Robin> the
> Robin> setGeneric() call actually helps.
> 
> Robin, I think you got confused because you are mixing S3 and S4
> ("max.brob" is S3).
> 
> You should (typically) not define S3 methods for S4 classes,
> and you should definitely not do it in this case where Franklin 
> has shown the correct S4 way.
> (and for my taste you should also not do it for the "Logic" case
>  in that other thread last week: It does not bring you anything and is
>  ugly for me, from the point of view of S4.)

But it *does* bring you something, efficiency.  If all you want to do is 
to stop the default method dispatching, using an S3 method can be lot more 
efficient than an S4 method.  In the example which has been omitted here, 
making 'max' S4 generic adds an overhead to *all* calls to max() in the 
rest of the session.  Adding a max.brob method costs nothing at all (max 
is already S3 generic and efficiently so).

People tend to forget how expensive it is to mess with R basics, which 
applies both to taking them over as S4 generics and making them S3 generic 
via UseMethod.

If a function/operator has already been made S4 generic or is not written 
for efficiency then it is reasonable to add an S4 method.  But otherwise, 
please think carefully about the impact on other people's code.

-- 
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] setMethod("Summary")

[Prof Brian Ripley]

On Tue, 5 Sep 2006, Prof Brian Ripley wrote:

> On Tue, 5 Sep 2006, Martin Maechler wrote:
> 
> > > "Robin" == Robin Hankin <[EMAIL PROTECTED]>
> > > on Tue, 5 Sep 2006 08:58:23 +0100 writes:
> > 
> > Robin> Dear Franklin
> > Robin> thank you for this.
> > 
> > yes, and he *did* send it already last week.
> > 
> > Robin> Your suggestion works.
> > 
> > and continues to do so in R-devel aka "R-2.4.0 alpha" (as of today?)
> > 
> > Robin> But now I'm confused because I'm not sure how  
> > Robin> the
> > Robin> setGeneric() call actually helps.
> > 
> > Robin, I think you got confused because you are mixing S3 and S4
> > ("max.brob" is S3).
> > 
> > You should (typically) not define S3 methods for S4 classes,
> > and you should definitely not do it in this case where Franklin 
> > has shown the correct S4 way.
> > (and for my taste you should also not do it for the "Logic" case
> >  in that other thread last week: It does not bring you anything and is
> >  ugly for me, from the point of view of S4.)
> 
> But it *does* bring you something, efficiency.  If all you want to do is 
> to stop the default method dispatching, using an S3 method can be lot more 
> efficient than an S4 method.  In the example which has been omitted here, 
> making 'max' S4 generic adds an overhead to *all* calls to max() in the 
> rest of the session.  Adding a max.brob method costs nothing at all (max 
> is already S3 generic and efficiently so).

Another issue.  I meant in the session commands, and forgot to mention 
what happens to calls to max() from within functions.  max() is in the 
base namespace.  If you add an S3 method, it will be used by all functions 
calling max(). If you make the function S4 generic, the S4 generic only 
gets called if your package is ahead of the base namespace in the current 
search(), that is from your own package and from packages without 
namespaces.

Now, the current behaviour is

> setClass("foo", "numeric")
[1] "foo"
> xx <- new("foo", pi)
> setMethod("max", signature="foo", function(x, ..., na.rm=FALSE) 
stop("foo"))
[1] "max"
> max(xx)
Error in max(xx) : foo
> base::max(xx)
[1] 3.141593

(and I got an error and then a segfault after leaving off na.rm=FALSE, 
which ought to be allowed).

> max.foo <- function(...) stop("S3 foo")
> base::max(xx)
Error in max.foo(..., na.rm = na.rm) : S3 foo

That's probably a bigger win.

-- 
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] Typo in print.default.Rd

[Torsten Hothorn]

line 17 has `intepretation', should read `interpretation'

Torsten

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] ISwR (PR#9204)

[phillip . endicott]

I wanted to install the ISwR package onto my Linux system and used the 
install.packages command but it returns the message that  the package 
was not found at the repositories.

So I tried to install locally adding the argument repos=NULL but it gave 
a non-zero exit status report and the package is not present on the system.

I am a novice UNIX user and also new to R but I have followed the syntax 
faithfully and presumably successfully to get the messages I did.

I would be most grateful of to hear if you know of a problem with this 
package.


Many thanks

Phillip Endicott

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] ISwR (PR#9204)

[Peter Dalgaard]

[EMAIL PROTECTED] writes:

> I wanted to install the ISwR package onto my Linux system and used the 
> install.packages command but it returns the message that  the package 
> was not found at the repositories.
> 
> So I tried to install locally adding the argument repos=NULL but it gave 
> a non-zero exit status report and the package is not present on the system.
> 
> I am a novice UNIX user and also new to R but I have followed the syntax 
> faithfully and presumably successfully to get the messages I did.
> 
> I would be most grateful of to hear if you know of a problem with this 
> package.

Installs happily here. You do need to give more information about
which commands you tried and what the responses were. Which version of
R, which repository, etc.

(Expect to see a couple of acidic notes about posting bug reports
prematurely...)

-- 
   O__   Peter Dalgaard Øster Farimagsgade 5, Entr.B
  c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
 (*) \(*) -- University of Copenhagen   Denmark  Ph:  (+45) 35327918
~~ - ([EMAIL PROTECTED])  FAX: (+45) 35327907

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] setMethod("c") [was: setMethod("Summary")]

[Robin Hankin]

Hello everybody.

I didn't see Franklin's first message; sorry.

Bearing in mind Professor Ripley's comments
on the efficiency of S4 vs S3, I'm beginning to think I
  should just stick with S3 methods for my brob objects.  After
all, S3 was perfectly adequate for the onion package.

Notwithstanding that,  here's my next problem.  I want to define a
brob method for "c".  Using the example in package "arules" as a
template (I couldn't see one in Matrix), I have


setClass("brob",
  representation = representation 
(x="numeric",positive="logical"),
  prototype  = list(x=numeric(),positive=logical())
  )

"brob" <- function(x,positive){
   if(missing(positive)){
 positive <- rep(TRUE,length(x))
   }
   if(length(positive)==1){
 positive <- rep(positive,length(x))
   }
   new("brob",x=x,positive=positive)
}

setGeneric("getX",function(x){standardGeneric("getX")})
setGeneric("getP",function(x){standardGeneric("getP")})
setMethod("getX","brob",function(x)[EMAIL PROTECTED])
setMethod("getP","brob",function(x)[EMAIL PROTECTED])


setMethod("c",signature(x="brob"),
   function(x, ..., recursive=FALSE){
 xx <- [EMAIL PROTECTED]
 xpos <- [EMAIL PROTECTED]
 z <- list(...)
 return(
brob(
 c(xx,do.call("c",lapply(z,getX))),
 c(xpos,do.call("c",lapply(z,getP)))
 )
)
   }
   )




Now,  this works for something like

 > x <- new("brob",x=pi,positive=T)
 > c(x,x)

but c(1,x) isn't dispatched to my function.  How to
deal cleanly with this case?   Perhaps if any argument
to c() is a brob object, I would like to coerce them all to brobs.
Is this possible?













--
Robin Hankin
Uncertainty Analyst
National Oceanography Centre, Southampton
European Way, Southampton SO14 3ZH, UK
  tel  023-8059-7743

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Capturing warnings with capture.output

[hadley wickham]

> Something like this which displays the warnings and also writes
> them to out so that they are captured:

Is it possible to not display the warnings (just write them out) ?

Hadley




>
> out <- capture.output(
>withCallingHandlers({
> print(1)
> warning("A warning.")
> print(2)
> warning("Another warning.")
> print(3)
>}, warning = function(x) cat(x$message, "\n"))
> )
>
> print(out)
>
>
> On 8/29/06, hadley wickham <[EMAIL PROTECTED]> wrote:
> > Is there any way to include warnings in the output from capture.output?  eg:
> >
> > a <- capture.output(warning("test"))
> > all.equal(a, "Warning message: \n test ")
> >
> > Conceptually, this seems like redirecting stderr to stdout, or somehow
> > changing warning to simple print it's output.  I've had a look at
> > tryCatch and using a warning handler, but this terminates execution at
> > the warning.
> >
> > Thanks,
> >
> > Hadley
> >
> > __
> > 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] setMethod("c") [was: setMethod("Summary")]

[John Chambers]

It's all very well to go on about efficiency, but the purpose of 
statistical computing is insight into data, not saving CPU cycles (to 
paraphrase Dick Hamming).

S3 methods do some things fine; other tasks need more flexibility.  One 
should ask what's important in a particular application and try to find 
tools that match the needs well.

Now, the c() function.  This has been discussed in various forms (and 
languages) for some time.  As I remember and as far as I know, the only 
really general way to ensure dispatch on _any_ applicable argument is to 
turn the computation into a pair-wise one and define the methods (NOT S3 
methods) for the two arguments of the pairwise function.

I won't try to reproduce the details off the top of my head (if I locate 
a reference I'll pass it on), but very roughly the idea is to say 
something like

cWithMethods <- function(x, ...) {
   if(nargs()<3)
  cPair(x,...)
else
  cPair(x, cWithMethods(...))
}

and then write methods for cPair().

John

Robin Hankin wrote:
> Hello everybody.
>
> I didn't see Franklin's first message; sorry.
>
> Bearing in mind Professor Ripley's comments
> on the efficiency of S4 vs S3, I'm beginning to think I
>   should just stick with S3 methods for my brob objects.  After
> all, S3 was perfectly adequate for the onion package.
>
> Notwithstanding that,  here's my next problem.  I want to define a
> brob method for "c".  Using the example in package "arules" as a
> template (I couldn't see one in Matrix), I have
>
>
> setClass("brob",
>   representation = representation 
> (x="numeric",positive="logical"),
>   prototype  = list(x=numeric(),positive=logical())
>   )
>
> "brob" <- function(x,positive){
>if(missing(positive)){
>  positive <- rep(TRUE,length(x))
>}
>if(length(positive)==1){
>  positive <- rep(positive,length(x))
>}
>new("brob",x=x,positive=positive)
> }
>
> setGeneric("getX",function(x){standardGeneric("getX")})
> setGeneric("getP",function(x){standardGeneric("getP")})
> setMethod("getX","brob",function(x)[EMAIL PROTECTED])
> setMethod("getP","brob",function(x)[EMAIL PROTECTED])
>
>
> setMethod("c",signature(x="brob"),
>function(x, ..., recursive=FALSE){
>  xx <- [EMAIL PROTECTED]
>  xpos <- [EMAIL PROTECTED]
>  z <- list(...)
>  return(
> brob(
>  c(xx,do.call("c",lapply(z,getX))),
>  c(xpos,do.call("c",lapply(z,getP)))
>  )
> )
>}
>)
>
>
>
>
> Now,  this works for something like
>
>  > x <- new("brob",x=pi,positive=T)
>  > c(x,x)
>
> but c(1,x) isn't dispatched to my function.  How to
> deal cleanly with this case?   Perhaps if any argument
> to c() is a brob object, I would like to coerce them all to brobs.
> Is this possible?
>
>
>
>
>
>
>
>
>
>
>
>
>
> --
> Robin Hankin
> Uncertainty Analyst
> National Oceanography Centre, Southampton
> European Way, Southampton SO14 3ZH, UK
>   tel  023-8059-7743
>
> __
> 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] Capturing warnings with capture.output

[Gabor Grothendieck]

Modify withWarnings in:
   https://stat.ethz.ch/pipermail/r-help/2004-June/052132.html
like this:

withWarnings <- function(expr) {
 wHandler <- function(w) {
  cat(w$message, "\n")
  invokeRestart("muffleWarning")
 }
 withCallingHandlers(expr, warning = wHandler)
}

# test
out <- capture.output(
   withWarnings({
  print(1)
  warning("A")
  print(2)
  warning("B")
  print(3)
   })
)

On 9/5/06, hadley wickham <[EMAIL PROTECTED]> wrote:
> > Something like this which displays the warnings and also writes
> > them to out so that they are captured:
>
> Is it possible to not display the warnings (just write them out) ?
>
> Hadley
>
>
>
>
> >
> > out <- capture.output(
> >withCallingHandlers({
> > print(1)
> > warning("A warning.")
> > print(2)
> > warning("Another warning.")
> > print(3)
> >}, warning = function(x) cat(x$message, "\n"))
> > )
> >
> > print(out)
> >
> >
> > On 8/29/06, hadley wickham <[EMAIL PROTECTED]> wrote:
> > > Is there any way to include warnings in the output from capture.output?  
> > > eg:
> > >
> > > a <- capture.output(warning("test"))
> > > all.equal(a, "Warning message: \n test ")
> > >
> > > Conceptually, this seems like redirecting stderr to stdout, or somehow
> > > changing warning to simple print it's output.  I've had a look at
> > > tryCatch and using a warning handler, but this terminates execution at
> > > the warning.
> > >
> > > Thanks,
> > >
> > > Hadley
> > >
> > > __
> > > 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] setMethod("c") [was: setMethod("Summary")]

[Martin Maechler]

One reference to a very similar problem 
is  help(cbind2), 
about the cbind2() and rbind2() functions which I had added
to R a little while ago exactly for the same reason as we talk
about 'c()' or "c" here,
and thanks to original "hand holding" by you, John.

Martin

> "JMC" == John Chambers <[EMAIL PROTECTED]>
> on Tue, 05 Sep 2006 11:28:12 -0400 writes:

JMC> It's all very well to go on about efficiency, but the purpose of 
JMC> statistical computing is insight into data, not saving CPU cycles (to 
JMC> paraphrase Dick Hamming).

JMC> S3 methods do some things fine; other tasks need more flexibility.  
One 
JMC> should ask what's important in a particular application and try to 
find 
JMC> tools that match the needs well.

JMC> Now, the c() function.  This has been discussed in various forms (and 
JMC> languages) for some time.  As I remember and as far as I know, the 
only 
JMC> really general way to ensure dispatch on _any_ applicable argument is 
to 
JMC> turn the computation into a pair-wise one and define the methods (NOT 
S3 
JMC> methods) for the two arguments of the pairwise function.

JMC> I won't try to reproduce the details off the top of my head (if I 
locate 
JMC> a reference I'll pass it on), but very roughly the idea is to say 
JMC> something like

JMC> cWithMethods <- function(x, ...) {
JMC> if(nargs()<3)
JMC> cPair(x,...)
JMC> else
JMC> cPair(x, cWithMethods(...))
JMC> }

JMC> and then write methods for cPair().

JMC> John

JMC> Robin Hankin wrote:
>> Hello everybody.
>> 
>> I didn't see Franklin's first message; sorry.
>> 
>> Bearing in mind Professor Ripley's comments
>> on the efficiency of S4 vs S3, I'm beginning to think I
>> should just stick with S3 methods for my brob objects.  After
>> all, S3 was perfectly adequate for the onion package.
>> 
>> Notwithstanding that,  here's my next problem.  I want to define a
>> brob method for "c".  Using the example in package "arules" as a
>> template (I couldn't see one in Matrix), I have
>> 
>> 
>> setClass("brob",
>> representation = representation 
>> (x="numeric",positive="logical"),
>> prototype  = list(x=numeric(),positive=logical())
>> )
>> 
>> "brob" <- function(x,positive){
>> if(missing(positive)){
>> positive <- rep(TRUE,length(x))
>> }
>> if(length(positive)==1){
>> positive <- rep(positive,length(x))
>> }
>> new("brob",x=x,positive=positive)
>> }
>> 
>> setGeneric("getX",function(x){standardGeneric("getX")})
>> setGeneric("getP",function(x){standardGeneric("getP")})
>> setMethod("getX","brob",function(x)[EMAIL PROTECTED])
>> setMethod("getP","brob",function(x)[EMAIL PROTECTED])
>> 
>> 
>> setMethod("c",signature(x="brob"),
>> function(x, ..., recursive=FALSE){
>> xx <- [EMAIL PROTECTED]
>> xpos <- [EMAIL PROTECTED]
>> z <- list(...)
>> return(
>> brob(
>> c(xx,do.call("c",lapply(z,getX))),
>> c(xpos,do.call("c",lapply(z,getP)))
>> )
>> )
>> }
>> )
>> 
>> 
>> 
>> 
>> Now,  this works for something like
>> 
>> > x <- new("brob",x=pi,positive=T)
>> > c(x,x)
>> 
>> but c(1,x) isn't dispatched to my function.  How to
>> deal cleanly with this case?   Perhaps if any argument
>> to c() is a brob object, I would like to coerce them all to brobs.
>> Is this possible?
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> --
>> Robin Hankin
>> Uncertainty Analyst
>> National Oceanography Centre, Southampton
>> European Way, Southampton SO14 3ZH, UK
>> tel  023-8059-7743
>> 
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>> 
>> 

JMC> __
JMC> R-devel@r-project.org mailing list
JMC> 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] setMethod("c") [was: setMethod("Summary")]

[John Chambers]

(Before someone else can embarrass me with the reference)

There is a variant on the c() example discussed in "Programming with 
Data", page 351, for the function max().

John

John Chambers wrote:
> It's all very well to go on about efficiency, but the purpose of 
> statistical computing is insight into data, not saving CPU cycles (to 
> paraphrase Dick Hamming).
>
> S3 methods do some things fine; other tasks need more flexibility.  One 
> should ask what's important in a particular application and try to find 
> tools that match the needs well.
>
> Now, the c() function.  This has been discussed in various forms (and 
> languages) for some time.  As I remember and as far as I know, the only 
> really general way to ensure dispatch on _any_ applicable argument is to 
> turn the computation into a pair-wise one and define the methods (NOT S3 
> methods) for the two arguments of the pairwise function.
>
> I won't try to reproduce the details off the top of my head (if I locate 
> a reference I'll pass it on), but very roughly the idea is to say 
> something like
>
> cWithMethods <- function(x, ...) {
>if(nargs()<3)
>   cPair(x,...)
> else
>   cPair(x, cWithMethods(...))
> }
>
> and then write methods for cPair().
>
> John
>
> Robin Hankin wrote:
>   
>> Hello everybody.
>>
>> I didn't see Franklin's first message; sorry.
>>
>> Bearing in mind Professor Ripley's comments
>> on the efficiency of S4 vs S3, I'm beginning to think I
>>   should just stick with S3 methods for my brob objects.  After
>> all, S3 was perfectly adequate for the onion package.
>>
>> Notwithstanding that,  here's my next problem.  I want to define a
>> brob method for "c".  Using the example in package "arules" as a
>> template (I couldn't see one in Matrix), I have
>>
>>
>> setClass("brob",
>>   representation = representation 
>> (x="numeric",positive="logical"),
>>   prototype  = list(x=numeric(),positive=logical())
>>   )
>>
>> "brob" <- function(x,positive){
>>if(missing(positive)){
>>  positive <- rep(TRUE,length(x))
>>}
>>if(length(positive)==1){
>>  positive <- rep(positive,length(x))
>>}
>>new("brob",x=x,positive=positive)
>> }
>>
>> setGeneric("getX",function(x){standardGeneric("getX")})
>> setGeneric("getP",function(x){standardGeneric("getP")})
>> setMethod("getX","brob",function(x)[EMAIL PROTECTED])
>> setMethod("getP","brob",function(x)[EMAIL PROTECTED])
>>
>>
>> setMethod("c",signature(x="brob"),
>>function(x, ..., recursive=FALSE){
>>  xx <- [EMAIL PROTECTED]
>>  xpos <- [EMAIL PROTECTED]
>>  z <- list(...)
>>  return(
>> brob(
>>  c(xx,do.call("c",lapply(z,getX))),
>>  c(xpos,do.call("c",lapply(z,getP)))
>>  )
>> )
>>}
>>)
>>
>>
>>
>>
>> Now,  this works for something like
>>
>>  > x <- new("brob",x=pi,positive=T)
>>  > c(x,x)
>>
>> but c(1,x) isn't dispatched to my function.  How to
>> deal cleanly with this case?   Perhaps if any argument
>> to c() is a brob object, I would like to coerce them all to brobs.
>> Is this possible?
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>> Robin Hankin
>> Uncertainty Analyst
>> National Oceanography Centre, Southampton
>> European Way, Southampton SO14 3ZH, UK
>>   tel  023-8059-7743
>>
>> __
>> 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
>
>   

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Capturing warnings with capture.output

[Luke Tierney]

Look at how suppressWarnings does this.

Best,

luke

On Tue, 5 Sep 2006, hadley wickham wrote:

>> Something like this which displays the warnings and also writes
>> them to out so that they are captured:
>
> Is it possible to not display the warnings (just write them out) ?
>
> Hadley
>
>
>
>
>>
>> out <- capture.output(
>>withCallingHandlers({
>> print(1)
>> warning("A warning.")
>> print(2)
>> warning("Another warning.")
>> print(3)
>>}, warning = function(x) cat(x$message, "\n"))
>> )
>>
>> print(out)
>>
>>
>> On 8/29/06, hadley wickham <[EMAIL PROTECTED]> wrote:
>>> Is there any way to include warnings in the output from capture.output?  eg:
>>>
>>> a <- capture.output(warning("test"))
>>> all.equal(a, "Warning message: \n test ")
>>>
>>> Conceptually, this seems like redirecting stderr to stdout, or somehow
>>> changing warning to simple print it's output.  I've had a look at
>>> tryCatch and using a warning handler, but this terminates execution at
>>> the warning.
>>>
>>> Thanks,
>>>
>>> Hadley
>>>
>>> __
>>> 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
>

-- 
Luke Tierney
Chair, Statistics and Actuarial Science
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa  Phone: 319-335-3386
Department of Statistics andFax:   319-335-3017
Actuarial Science
241 Schaeffer Hall  email:  [EMAIL PROTECTED]
Iowa City, IA 52242 WWW:  http://www.stat.uiowa.edu

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] CRAN problem

[Kjetil Halvorsen]

Just now going to the CRAN download area, windows (95 or later), base,
selecting
development snapshot, there is listed a file
R-2.5.0dev-win32.exe
and while clickingh on this link gives error 404, object not found.

Kjetil

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] serialize changes for 2.4.0

[Roger D. Peng]

I noticed today that in R 2.3.1, I get

 > serialize(list(1,2,3), NULL, ascii = TRUE)
[1] "A\n2\n131841\n131840\n19\n3\n14\n1\n1\n14\n1\n2\n14\n1\n3\n"
 >

but in R 2.4.0 alpha I get

 > serialize(list(1,2,3), NULL, ascii = TRUE)
  [1] 41 0a 32 0a 31 33 32 30 39 36 0a 31 33 31 38 34 30 0a 31 39 0a 33 0a 31 34
[26] 0a 31 0a 31 0a 31 34 0a 31 0a 32 0a 31 34 0a 31 0a 33 0a
 >

It seems I need to use 'rawToChar()' to get the character vector that I used to 
get in R 2.3.1.

Is this intentional?  I couldn't find any mention of this change in the NEWS 
file; from the docs, it seems to me that either return value could be correct.

 > version
_
platform   x86_64-unknown-linux-gnu
arch   x86_64
os linux-gnu
system x86_64, linux-gnu
status alpha
major  2
minor  4.0
year   2006
month  09
day05
svn rev39121
language   R
version.string R version 2.4.0 alpha (2006-09-05 r39121)
 >

-roger
-- 
Roger D. Peng  |  http://www.biostat.jhsph.edu/~rpeng/

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] problem in contour/contourLines (PR#9205)

[dheide]

Full_Name: Dominik Heide
Version: 2.3.1
OS: Linux (Suse 9.3)
Submission from: (NULL) (134.76.220.200)


The contour functions has sommewhere (I think in .../main/plot3d.c) a maximum
number of line segments that is set using a define. The contour line in my data
too long for this and therefore not correct analysed (I get the message
'contour(): circular/long seglist -- bug.report()!'). Since I can't analyse my
data right now, it's mybe better to give the maximum seg-number as an option ?!

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] serialize changes for 2.4.0

[Prof Brian Ripley]

NEW FEATURES

o   serialize(connection = NULL) now returns a raw vector (and not
a character string).  unserialize() accepts both old and new
formats (and has since 2.3.0).

serialize.Rd:

  The function \code{serialize} writes \code{object} to the specified
  connection.  Sharing of reference objects is preserved within the
  object but not across separate calls to serialize.  If
  \code{connection} is \code{NULL} then \code{object} is serialized to a
  raw vector, which is returned as the result of \code{serialize}.
  ^^
\section{Warning}{
  These functions are still experimental.  Names, interfaces and
  values might change in future versions (and was changed for \R 2.4.0).
  \code{.saveRDS} and \code{.readRDS} are intended for internal use.
}

\examples{
x <- serialize(list(1,2,3), NULL)
unserialize(x)
## test pre-2.3.0 interface as a length-one character vector
y <- rawToChar(x)
unserialize(y)
}

all seem clear enough to me ..., including the statement about being 
experimental.


On Tue, 5 Sep 2006, Roger D. Peng wrote:

> I noticed today that in R 2.3.1, I get
> 
>  > serialize(list(1,2,3), NULL, ascii = TRUE)
> [1] "A\n2\n131841\n131840\n19\n3\n14\n1\n1\n14\n1\n2\n14\n1\n3\n"
>  >
> 
> but in R 2.4.0 alpha I get
> 
>  > serialize(list(1,2,3), NULL, ascii = TRUE)
>   [1] 41 0a 32 0a 31 33 32 30 39 36 0a 31 33 31 38 34 30 0a 31 39 0a 33 0a 31 
> 34
> [26] 0a 31 0a 31 0a 31 34 0a 31 0a 32 0a 31 34 0a 31 0a 33 0a
>  >
> 
> It seems I need to use 'rawToChar()' to get the character vector that I used 
> to 
> get in R 2.3.1.
> 
> Is this intentional?  I couldn't find any mention of this change in the NEWS 
> file; from the docs, it seems to me that either return value could be correct.
> 
>  > version
> _
> platform   x86_64-unknown-linux-gnu
> arch   x86_64
> os linux-gnu
> system x86_64, linux-gnu
> status alpha
> major  2
> minor  4.0
> year   2006
> month  09
> day05
> svn rev39121
> language   R
> version.string R version 2.4.0 alpha (2006-09-05 r39121)
>  >
> 
> -roger
> 

-- 
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] problem in contour/contourLines (PR#9205)

[Prof Brian Ripley]

It says

/* maximal number of line segments of one contour segment:
 * for preventing infinite loops -- shouldn't be needed --> warning */
#define MAX_ns 25000

so it would be very helpful to have a reproducible example.  Please also 
let us have exact details of how you compiled R (CPU, compiler versions, 
optimization level ...).

I have tracked a couple of things like this down to extended floating 
point issues on ix86 chips, so it may very well be that this is an issue 
of stopping an infinite loop.

(25000 segments is very large: a space filling graph on a 50x50 grid only 
needs about that many.)

On Tue, 5 Sep 2006, [EMAIL PROTECTED] wrote:

> Full_Name: Dominik Heide
> Version: 2.3.1
> OS: Linux (Suse 9.3)

On which CPU?

> Submission from: (NULL) (134.76.220.200)
> 
> 
> The contour functions has sommewhere (I think in .../main/plot3d.c) a 
> maximum number of line segments that is set using a define. The contour 
> line in my data too long for this and therefore not correct analysed (I 
> get the message 'contour(): circular/long seglist -- bug.report()!'). 
> Since I can't analyse my data right now, it's mybe better to give the 
> maximum seg-number as an option ?!

-- 
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] Two submitted packages

[Deepayan Sarkar]

On 9/4/06, Richard M. Heiberger <[EMAIL PROTECTED]> wrote:
> ## This example runs in R 2.3.1 and does not run in R 2.4.1.  I am
> ## raising it here for two questions: one on how to debug functions
> ## inside a namespace, the other on how to control clipping.
>
> tmp <- data.frame(x=1:5, y=1:5, a=factor(c(1,1,1,1,1), levels=1:4))
> xyplot(y ~ x,
>data=tmp, ylim=c(1.5,4.5),
>panel=function(x,y, ...) {
>  cpv <- current.viewport()
>  cpv$clip <- "off"
>  pushViewport(cpv)
>  panel.xyplot(x, y, ...)
>  popViewport()
>})
>
> ## R version 2.4.0 Under development (unstable) (2006-08-14 r38872)
> ## gives the error message
> Error in grid.Call.graphics("L_setviewport", pvp, TRUE) :
> LOGICAL() can only be applied to a 'logical', not a 'character'
> >
>
> ## Question 1.  How do I place a trace() on grid.Call.graphics to make
>
> [snipped]
>
>
> ## Question 2.  How do I control clipping from within a panel
> ## function?  In 2.3.1, both of the following statements run without
> ## error.  Neither of them turns clipping off.
> ##
> ## In 2.4.0, the "off" statement gives the error message above.  The
> ## FALSE statement runs without error, but it didn't turn clipping off.
>
> xyplot(y ~ x | a,
>data=tmp, ylim=c(1.5,4.5),
>panel=function(x,y, ...) {
>  cpv <- current.viewport()
>  cpv$clip <- "off"
>  pushViewport(cpv)
>  panel.xyplot(x, y, ...)
>  popViewport()
>},
>layout=c(2,2))
>
> xyplot(y ~ x | a,
>data=tmp, ylim=c(1.5,4.5),
>panel=function(x,y, ...) {
>  cpv <- current.viewport()
>  cpv$clip <- FALSE
>  pushViewport(cpv)
>  panel.xyplot(x, y, ...)
>  popViewport()
>},
>layout=c(2,2))
>
>
> ## ?viewport in 2.4.0 says
> ## clip
> ##
> ## One of "on", "inherit", or "off", indicating whether to clip to the
> ## extent of this viewport, inherit the clipping region from the
> ## parent viewport, or turn clipping off altogether. For
> ## back-compatibility, a logical value of TRUE corresponds to "on" and
> ## FALSE corresponds to "inherit".
>
> ## Notice that "off" is current and FALSE is back-compatible, and
> ## "off" is the value that causes the error.
>
> ## What is the correct way to turn off clipping?

I don't believe there /is/ a documented way.

> ## The way that I would like to use is something on the order of
>
> xyplot(y ~ x | a,
>data=tmp, ylim=c(1.5,4.5),
>panel=function(x,y, ...) {
>  panel.xyplot(x, y, ...,
>   par.settings = list(clip = list(panel = "off")))
>},
>layout=c(2,2))
>
> ## I believe par.settings is currently valid only in xyplot() and not
> ## valid in panel functions.  Is my understanding correct?

Yes.

> ## Can the
> ## behavior be changed?

In the original design of lattice, no. In the current design, two
separate viewports exist for each panel (which is why you can use
trellis.focus with clipping turned off). So, there might be a way to
switch to that. A reasonably clean approach might be to do the
following:

xyplot(y ~ x,
   data=tmp, ylim=c(1.5,4.5),
   panel=function(x, y, ...) {
   upViewport()
   downViewport(trellis.vpname("panel",
   row = 1, column = 1, clip.off = TRUE))
   panel.xyplot(x, y, ...)
   panel.points(1.4, 1.4)
  })

Unfortunately, there is currently no easy way to find out which column
and row the current panel occupies. I plan to make some changes before
R 2.4.0 is released that should expose that information, so please try
again in a few weeks.

> ## The following statement works correctly in both 2.3.1 and 2.4.0.
> ## This statement controls clipping for the entire xyplot, not just
> ## for the single statement within the panel function.
>
> xyplot(y ~ x | a,
>data=tmp, ylim=c(1.5,4.5),
>par.settings = list(clip = list(panel = "off")),
>layout=c(2,2))

I'm curious to know why this functionality is not enough.

Deepayan

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Two submitted packages

[Prof Brian Ripley]

On Mon, 4 Sep 2006, Richard M. Heiberger wrote:

> ## This example runs in R 2.3.1 and does not run in R 2.4.1.  I am

There is no '2.4.1', and your R-devel is not very recent.  It looks as if 
R-devel has detected an error of yours that previously went undetected.

You set cpv$clip <- "off" and the internal code assumes that it is logical 
(as the message says).  I can't find any documentation to support your 
code: if there is some please report it to the maintainer of grid (Paul 
Murrell).

> ## raising it here for two questions: one on how to debug functions
> ## inside a namespace, the other on how to control clipping.
> 
> tmp <- data.frame(x=1:5, y=1:5, a=factor(c(1,1,1,1,1), levels=1:4))
> xyplot(y ~ x,
>data=tmp, ylim=c(1.5,4.5),
>panel=function(x,y, ...) {
>  cpv <- current.viewport()
>  cpv$clip <- "off"
>  pushViewport(cpv)
>  panel.xyplot(x, y, ...)
>  popViewport()
>})
> 
> ## R version 2.4.0 Under development (unstable) (2006-08-14 r38872)
> ## gives the error message
> Error in grid.Call.graphics("L_setviewport", pvp, TRUE) : 
> LOGICAL() can only be applied to a 'logical', not a 'character'
> >
> 
> ## Question 1.  How do I place a trace() on grid.Call.graphics to make
> ## it stop and give me a traceback.  I tried many variations of the
> ## command
> ##trace(grid:::grid.Call.graphics, exit=recover,
> ##  where=environment(grid:::grid.Call.graphics))
> ## None of them trapped the error and let me trace it.  What is the
> ## correct incantation?

Not sure why you want to do that, as traceback() works here.

> traceback(max.lines=3)
10: .Call.graphics(fnname, ..., PACKAGE = "grid")
9: grid.Call.graphics("L_setviewport", pvp, TRUE)
8: push.vp.viewport(X[[1]], ...)
7: FUN(X[[1]], ...)
6: lapply(vps, push.vp, recording)
5: pushViewport(cpv)
4: panel(x = c(1, 2, 3, 4, 5), y = c(1, 2, 3, 4, 5), packet.number = 1, 
   panel.number = 1)
3: do.call("panel", pargs)
2: print.trellis(list(formula = y ~ x, as.table = FALSE, aspect.fill = 
TRUE, 
   legend = NULL, panel = function (x, y, ...) 
   {
 ...
1: print(list(formula = y ~ x, as.table = FALSE, aspect.fill = TRUE, 
   legend = NULL, panel = function (x, y, ...) 
   {
 ...

as does options(error=recover).  What does a namespace have to do with 
this?

-- 
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] (PR#9202) Re: Bugs with partial name matching during partial

[Thomas Lumley]

The partial matching is fairly deeply built in to complex assignment, 
another example being
> x<-list(ab=1:2)
> names(x$ab)=c("A","B")
> names(x$a)=c("a","b")
> x
$ab
A B
1 2

$a
a b
1 2

because as evalseq works through the nested calls on the LHS the code 
being called doesn't know it is in an assignment call.


The bug is a bug. It isn't specific to data frames or to replacing only 
some elements of a vector
> x<-list(ab=1:2)
> x$a[]<-2:1
> x
$ab
[1] 2 1

$a
[1] 2 1

It also happens when $ is replaced by [[. It looks like a failure to 
duplicate. A workaround would be not to modify list elements or database 
columns that don't exist ;).


-thomas

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] (PR#9202) Re: Bugs with partial name matching

[Thomas Lumley]

On Tue, 5 Sep 2006, Thomas Lumley wrote:

>
> The partial matching is fairly deeply built in to complex assignment,

> because as evalseq works through the nested calls on the LHS the code
> being called doesn't know it is in an assignment call.


The problem in
> D = list(ABCD=2:1)
>  D$ABC[]<-3:4
> D
$ABCD
[1] 3 4

$ABC
[1] 3 4

is that eval.c:evalseq ends up with a reference to D$ABCD from evaluating 
D$ABC with partial matching.  Since evalseq doesn't (and shouldn't) 
increase NAMED on these partially evaluated calls, NAMED is still 1 for 
D$ABCD.  When evalseq's D$ABC has 3:4 assigned into it the vector is 
changed directly, since NAMED=1, and both D$ABC and D$ABCD change.

The minimal fix would appear to be the horrible hack of incrementing NAMED 
whenever a list element is even looked at with partial matching. Otherwise 
evalseq would have to be taught to recognize aliasing from partial 
matching.


-thomas

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Two submitted packages

[Richard M. Heiberger]

From: Prof Brian Ripley
> There is no '2.4.1', and your R-devel is not very recent.

Apologies on the typo and the two-week old 2.4.0dev.

I just downloaded
   version 2.4.0 Under development (unstable) (2006-09-04 r39086)


1.
> You set cpv$clip <- "off" and the internal code assumes that it is logical 
> (as the message says).  I can't find any documentation to support your 
> code: if there is some please report it to the maintainer of grid (Paul 
> Murrell).

The documentation for "off" comes from ?viewport that is part of 2.4.0dev.
> installed.packages()["grid",]
   PackageLibPath 
"grid" "C:/PROGRA~1/R/R-24~1.0DE/library" 
   Version   Priority 
   "2.4.0" "base" 
Bundle   Contains 
NA NA 
   DependsImports 
   "grDevices" NA 
  Suggests  Built 
 "lattice""2.4.0" 

clip
One of "on", "inherit", or "off", indicating whether to clip to the
extent of this viewport, inherit the clipping region from the parent
viewport, or turn clipping off altogether. For back-compatibility, a
logical value of TRUE corresponds to "on" and FALSE corresponds to
"inherit".

The above description of clip is identical to the description in
?viewport in the released 2.3.1.


I still get the same error in 2.4.0dev that did not appear in 2.3.1
and it still looks to me like this is an equally valid statement in both
versions of R.
>  Error in grid.Call.graphics("L_setviewport", pvp, TRUE) : 
>  LOGICAL() can only be applied to a 'logical', not a 'character'
>  >

I think something needs to be changed to make the documentation and the
program consistent.  I like the documentation, with the three options
for clipping, and hope to see the program changed to match it.


2.
> > ## Question 1.  How do I place a trace() on grid.Call.graphics to make
> > ## it stop and give me a traceback.
> Not sure why you want to do that, as traceback() works here.
... as does options(error=recover).

I was interested in the argument
trace(..., exit=recover)
I see now that
options(error=recover)
does exactly what I want.  That is the incantation I was looking for.
Thank you.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] enhancement request for labeling help windows in Windows

[Richard M. Heiberger]

I would like to make a formal request for an enhancement.

The default help for RGui in 2.4.0dev seems to be the .chm format
outside of the RGui frame.  Previously the default help was individual
windows inside the RGui frame.  Every package in R has its own help
file and all of them are labeled identically as "Help" by Windows.
The labels appear in the title of the window, in the task bar, and in
the alt-tab menu.

The request is to give each a unique name, for example
R Help --- base
R Help --- grid
R Help --- lattice

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] enhancement request for labeling help windows in Windows

[Duncan Murdoch]

On 9/5/2006 7:41 PM, Richard M. Heiberger wrote:
> I would like to make a formal request for an enhancement.
> 
> The default help for RGui in 2.4.0dev seems to be the .chm format
> outside of the RGui frame.  Previously the default help was individual
> windows inside the RGui frame.  Every package in R has its own help
> file and all of them are labeled identically as "Help" by Windows.
> The labels appear in the title of the window, in the task bar, and in
> the alt-tab menu.
> 
> The request is to give each a unique name, for example
> R Help --- base
> R Help --- grid
> R Help --- lattice
> 

No problem:  let me know what to do.

Duncan Murdoch

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Two submitted packages

[Paul Murrell]

Hi


Richard M. Heiberger wrote:
> From: Prof Brian Ripley
>> There is no '2.4.1', and your R-devel is not very recent.
> 
> Apologies on the typo and the two-week old 2.4.0dev.
> 
> I just downloaded
>version 2.4.0 Under development (unstable) (2006-09-04 r39086)
> 
> 
> 1.
>> You set cpv$clip <- "off" and the internal code assumes that it is logical 
>> (as the message says).  I can't find any documentation to support your 
>> code: if there is some please report it to the maintainer of grid (Paul 
>> Murrell).
> 
> The documentation for "off" comes from ?viewport that is part of 2.4.0dev.
>> installed.packages()["grid",]
>PackageLibPath 
> "grid" "C:/PROGRA~1/R/R-24~1.0DE/library" 
>Version   Priority 
>"2.4.0" "base" 
> Bundle   Contains 
> NA NA 
>DependsImports 
>"grDevices" NA 
>   Suggests  Built 
>  "lattice""2.4.0" 
> 
> clip
> One of "on", "inherit", or "off", indicating whether to clip to the
> extent of this viewport, inherit the clipping region from the parent
> viewport, or turn clipping off altogether. For back-compatibility, a
> logical value of TRUE corresponds to "on" and FALSE corresponds to
> "inherit".
> 
> The above description of clip is identical to the description in
> ?viewport in the released 2.3.1.


That's the documentation for the (public) viewport() function, which
allows either string or logical values.  Your code is directly modifying
the (internal, private, undocumented) structure of a "viewport" object,
which only allows logical values.

There is currently no public interface for editing a viewport (this is
something that I need to address).  In the meantime, I think a
workaround for your example would be to use ...

cpv$clip <- NA

Paul


> I still get the same error in 2.4.0dev that did not appear in 2.3.1
> and it still looks to me like this is an equally valid statement in both
> versions of R.
>>  Error in grid.Call.graphics("L_setviewport", pvp, TRUE) : 
>>  LOGICAL() can only be applied to a 'logical', not a 'character'
>>  >
> 
> I think something needs to be changed to make the documentation and the
> program consistent.  I like the documentation, with the three options
> for clipping, and hope to see the program changed to match it.
> 
> 
> 2.
>>> ## Question 1.  How do I place a trace() on grid.Call.graphics to make
>>> ## it stop and give me a traceback.
>> Not sure why you want to do that, as traceback() works here.
> ... as does options(error=recover).
> 
> I was interested in the argument
> trace(..., exit=recover)
> I see now that
> options(error=recover)
> does exactly what I want.  That is the incantation I was looking for.
> Thank you.
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

-- 
Dr Paul Murrell
Department of Statistics
The University of Auckland
Private Bag 92019
Auckland
New Zealand
64 9 3737599 x85392
[EMAIL PROTECTED]
http://www.stat.auckland.ac.nz/~paul/

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Two submitted packages

[Deepayan Sarkar]

On 9/5/06, Richard M. Heiberger <[EMAIL PROTECTED]> wrote:
> From: Prof Brian Ripley
> > There is no '2.4.1', and your R-devel is not very recent.
>
> Apologies on the typo and the two-week old 2.4.0dev.
>
> I just downloaded
>version 2.4.0 Under development (unstable) (2006-09-04 r39086)
>
>
> 1.
> > You set cpv$clip <- "off" and the internal code assumes that it is logical
> > (as the message says).  I can't find any documentation to support your
> > code: if there is some please report it to the maintainer of grid (Paul
> > Murrell).
>
> The documentation for "off" comes from ?viewport that is part of 2.4.0dev.
> > installed.packages()["grid",]
>PackageLibPath
> "grid" "C:/PROGRA~1/R/R-24~1.0DE/library"
>Version   Priority
>"2.4.0" "base"
> Bundle   Contains
> NA NA
>DependsImports
>"grDevices" NA
>   Suggests  Built
>  "lattice""2.4.0"
>
> clip
> One of "on", "inherit", or "off", indicating whether to clip to the
> extent of this viewport, inherit the clipping region from the parent
> viewport, or turn clipping off altogether. For back-compatibility, a
> logical value of TRUE corresponds to "on" and FALSE corresponds to
> "inherit".
>
> The above description of clip is identical to the description in
> ?viewport in the released 2.3.1.

As far as I can tell, this description applies to the 'clip' argument
of the function 'viewport'. In your call

cpv$clip <- "off"

cpv is the return value of a viewport() call. The only description I
see of the return value is

Value:

 An R object of class 'viewport'.

No one is giving you any guarantees that this is a list or similar
object, let alone that it will further contain a component called
'clip' that you are allowed to modify. I don't see how the description
of a function argument you have quoted has any relevance to the use
which is giving you an error.

> I still get the same error in 2.4.0dev that did not appear in 2.3.1
> and it still looks to me like this is an equally valid statement in both
> versions of R.

Which is another way of saying that the statement is equally invalid
in both versions of R. Your use is in fact invalid, and the newer
version complains about it while the older did not.

> >  Error in grid.Call.graphics("L_setviewport", pvp, TRUE) :
> >  LOGICAL() can only be applied to a 'logical', not a 'character'
> >  >
>
> I think something needs to be changed to make the documentation and the
> program consistent.

If by that you mean you want R to throw an error everytime you do
something that is not documented, that's never going to happen.

> I like the documentation, with the three options
> for clipping, and hope to see the program changed to match it.

The program does exactly what the documentation says (or am I missing
something?). The three options for clipping _are_ available to you
when you create a viewport using the viewport() function.

Deepayan

[...]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] enhancement request for labeling help windows in Windows

[Richard M. Heiberger]

I am looking at the HTML Help Workshop which I got from wherever
your website told me to get it.

There is no documentation in the material I have.  My guess is that one
of the variables in the file  "c:/Program Files/HTML Help 
Workshop/include/htmlhelp.h"
needs to be changed.  My first guess is the line
LPCTSTR pszCaption;  // IN/OUT: Window title
although how to change the value of pszCaption is not at all obvious.

I opened up the .chm files in emacs for other applications and they all
have a string buried inside that contains the name that appears on the window.

Rich

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Two submitted packages

[Richard M. Heiberger]

Deepayan wrote:

> > xyplot(y ~ x | a,
> >data=tmp, ylim=c(1.5,4.5),
> >par.settings = list(clip = list(panel = "off")),
> >layout=c(2,2))
> 
> I'm curious to know why this functionality is not enough.


## 1. Here is a more realistic example.

tmp <- data.frame(x=1:5, y=1:5, a=factor(c(1,1,1,1,1), levels=1:4))

## This gives what I want.
## It looks like the upViewport/downViewport sequence is the control I
## should be using.  If this is a stable sequence, it answers my needs.
xyplot(y ~ x,
   data=tmp, ylim=c(1.5,4.5),
   panel=function(...) {
  panel.xyplot(...)
upViewport()
downViewport(trellis.vpname("panel",
row = 1, column = 1, clip.off = TRUE))
  panel.axis(side="right", outside=TRUE)
   },
   layout=c(2,2),
   main="right axis visible by control, points clipped by default")

## If I turned off clipping at the top, I would get the unwanted points
## plotted outside the figure region.
xyplot(y ~ x,
   data=tmp, ylim=c(1.5,4.5),
   par.settings = list(clip = list(panel = "off")),
   panel=function(...) {
  panel.xyplot(...)
  panel.axis(side="right", outside=TRUE)
   },
   layout=c(2,2),
   main="right axis visible by control, points not clipped")


## this is what happens if I don't do any control of clipping
xyplot(y ~ x,
   data=tmp, ylim=c(1.5,4.5),
   panel=function(...) {
  panel.xyplot(...)
  panel.axis(side="right", outside=TRUE)
   },
   layout=c(2,2),
   main="right axis invisible by clipping, points clipped by default")


## This doesn't work, but it illustrates the syntax I would like.
xyplot(y ~ x,
   data=tmp, ylim=c(1.5,4.5),
   panel=function(...) {
  panel.xyplot(...)
  panel.axis(side="right", outside=TRUE, clip="off")
   },
   layout=c(2,2),
   main="right axis visible by control, points clipped by default")




## 2
> Unfortunately, there is currently no easy way to find out which column
> and row the current panel occupies. I plan to make some changes before
> R 2.4.0 is released that should expose that information, so please try
> again in a few weeks.

The way I have been using is to back up the calling sequence and
use statements like
{
## This loop is needed because
##console usage has i=2,
##Rcmdr script window has i=5,
##Rcmdr justDoIt has i=20
for (i in seq(2, length=30)) {
  sf2 <- sys.frame(i)
  column.tmp <- try(get("column", pos=sf2), silent=TRUE)
  if (class(column.tmp) != "try-error") break
}
if (class(column.tmp) == "try-error")
  stop("panel.interaction2wt is too deeply nested in the system stack.")
row <- get("row", pos=sf2)
column <- get("column", pos=sf2)
cols.per.page <- get("cols.per.page", pos=sf2)
rows.per.page <- get("rows.per.page", pos=sf2)
  }

## A cleaner way would be preferable.  Will the above stay valid?  The
## need for a loop to find out how far up the calling sequence to go
## caught me by surprise.  I don't understand why generating commands
## the way Rcmdr does it should have an effect on the depth of the
## calling sequence.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Two submitted packages

[Deepayan Sarkar]

On 9/5/06, Richard M. Heiberger <[EMAIL PROTECTED]> wrote:
> Deepayan wrote:
>
> > > xyplot(y ~ x | a,
> > >data=tmp, ylim=c(1.5,4.5),
> > >par.settings = list(clip = list(panel = "off")),
> > >layout=c(2,2))
> >
> > I'm curious to know why this functionality is not enough.
>
>
> ## 1. Here is a more realistic example.
>
> tmp <- data.frame(x=1:5, y=1:5, a=factor(c(1,1,1,1,1), levels=1:4))
>
> ## This gives what I want.
> ## It looks like the upViewport/downViewport sequence is the control I
> ## should be using.  If this is a stable sequence, it answers my needs.
> xyplot(y ~ x,
>data=tmp, ylim=c(1.5,4.5),
>panel=function(...) {
>   panel.xyplot(...)
> upViewport()
> downViewport(trellis.vpname("panel",
> row = 1, column = 1, clip.off = TRUE))
>   panel.axis(side="right", outside=TRUE)
>},
>layout=c(2,2),
>main="right axis visible by control, points clipped by default")
>
> ## If I turned off clipping at the top, I would get the unwanted points
> ## plotted outside the figure region.
> xyplot(y ~ x,
>data=tmp, ylim=c(1.5,4.5),
>par.settings = list(clip = list(panel = "off")),
>panel=function(...) {
>   panel.xyplot(...)
>   panel.axis(side="right", outside=TRUE)
>},
>layout=c(2,2),
>main="right axis visible by control, points not clipped")

I see.

> ## This doesn't work, but it illustrates the syntax I would like.
> xyplot(y ~ x,
>data=tmp, ylim=c(1.5,4.5),
>panel=function(...) {
>   panel.xyplot(...)
>   panel.axis(side="right", outside=TRUE, clip="off")
>},
>layout=c(2,2),
>main="right axis visible by control, points clipped by default")

This might be possible, but there is a potential for unanticipated
problems. On the other hand, it's easy to achieve the equivalent of
this with a couple of extra lines, e.g.

xyplot(y ~ x,
   data=tmp, ylim=c(1.5,4.5),
   panel=function(...) {
   cpl <- current.panel.limits()
   panel.xyplot(...)
   pushViewport(viewport(xscale = cpl$xlim,
 yscale = cpl$ylim,
 clip = "off"))
   ## put anything you want unclipped inside this:
   panel.axis(side="right", outside=TRUE)
   ## end of unclipped part
   upViewport()
   },
   layout=c(2,2))

This already works, and should be stable, but I'm not sure; Paul has
previously mentioned this feature that an unclipped viewport inside a
clipped viewport allows plotting outside the clipped one, but I don't
know if that's intentional. Even if this behaviour does change, the
opposite should be stable: turn off clipping globally and then insert
the part of the panel function you want clipped into a clipped
viewport, e.g.:

xyplot(y ~ x,
   data=tmp, ylim=c(1.5,4.5),
   par.settings = list(clip = list(panel = "off")),
   panel=function(...) {
   cpl <- current.panel.limits()
   pushViewport(viewport(xscale = cpl$xlim,
 yscale = cpl$ylim,
 clip = "on"))
   panel.xyplot(...)
   upViewport()
   panel.axis(side="right", outside=TRUE)
   },
   layout=c(2,2))

> ## 2
> > Unfortunately, there is currently no easy way to find out which column
> > and row the current panel occupies. I plan to make some changes before
> > R 2.4.0 is released that should expose that information, so please try
> > again in a few weeks.
>
> The way I have been using is to back up the calling sequence and
> use statements like
> {
> ## This loop is needed because
> ##console usage has i=2,
> ##Rcmdr script window has i=5,
> ##Rcmdr justDoIt has i=20
> for (i in seq(2, length=30)) {
>   sf2 <- sys.frame(i)
>   column.tmp <- try(get("column", pos=sf2), silent=TRUE)
>   if (class(column.tmp) != "try-error") break
> }
> if (class(column.tmp) == "try-error")
>   stop("panel.interaction2wt is too deeply nested in the system stack.")
> row <- get("row", pos=sf2)
> column <- get("column", pos=sf2)
> cols.per.page <- get("cols.per.page", pos=sf2)
> rows.per.page <- get("rows.per.page", pos=sf2)
>   }
>
> ## A cleaner way would be preferable.  Will the above stay valid?  The
> ## need for a loop to find out how far up the calling sequence to go
> ## caught me by surprise.  I don't understand why generating commands
> ## the way Rcmdr does it should have an effect on the depth of the
> ## calling sequence.

I hope to add 3 new features before R 2.4.0, two of which are relevant
for you: (1) more control over axis annotation and (2) an API to
access auxiliary information (like row/column/layout) from inside a
panel function. I should have a testable version in a week or so,
after which I'll be hap

Re: [Rd] Two submitted packages

[Paul Murrell]

Hi


Deepayan Sarkar wrote:
> On 9/5/06, Richard M. Heiberger <[EMAIL PROTECTED]> wrote:
>> Deepayan wrote:
>>
 xyplot(y ~ x | a,
data=tmp, ylim=c(1.5,4.5),
par.settings = list(clip = list(panel = "off")),
layout=c(2,2))
>>> I'm curious to know why this functionality is not enough.
>>
>> ## 1. Here is a more realistic example.
>>
>> tmp <- data.frame(x=1:5, y=1:5, a=factor(c(1,1,1,1,1), levels=1:4))
>>
>> ## This gives what I want.
>> ## It looks like the upViewport/downViewport sequence is the control I
>> ## should be using.  If this is a stable sequence, it answers my needs.
>> xyplot(y ~ x,
>>data=tmp, ylim=c(1.5,4.5),
>>panel=function(...) {
>>   panel.xyplot(...)
>> upViewport()
>> downViewport(trellis.vpname("panel",
>> row = 1, column = 1, clip.off = 
>> TRUE))
>>   panel.axis(side="right", outside=TRUE)
>>},
>>layout=c(2,2),
>>main="right axis visible by control, points clipped by default")
>>
>> ## If I turned off clipping at the top, I would get the unwanted points
>> ## plotted outside the figure region.
>> xyplot(y ~ x,
>>data=tmp, ylim=c(1.5,4.5),
>>par.settings = list(clip = list(panel = "off")),
>>panel=function(...) {
>>   panel.xyplot(...)
>>   panel.axis(side="right", outside=TRUE)
>>},
>>layout=c(2,2),
>>main="right axis visible by control, points not clipped")
> 
> I see.
> 
>> ## This doesn't work, but it illustrates the syntax I would like.
>> xyplot(y ~ x,
>>data=tmp, ylim=c(1.5,4.5),
>>panel=function(...) {
>>   panel.xyplot(...)
>>   panel.axis(side="right", outside=TRUE, clip="off")
>>},
>>layout=c(2,2),
>>main="right axis visible by control, points clipped by default")
> 
> This might be possible, but there is a potential for unanticipated
> problems. On the other hand, it's easy to achieve the equivalent of
> this with a couple of extra lines, e.g.
> 
> xyplot(y ~ x,
>data=tmp, ylim=c(1.5,4.5),
>panel=function(...) {
>cpl <- current.panel.limits()
>panel.xyplot(...)
>pushViewport(viewport(xscale = cpl$xlim,
>  yscale = cpl$ylim,
>  clip = "off"))
>## put anything you want unclipped inside this:
>panel.axis(side="right", outside=TRUE)
>## end of unclipped part
>upViewport()
>},
>layout=c(2,2))
> 
> This already works, and should be stable, but I'm not sure; Paul has
> previously mentioned this feature that an unclipped viewport inside a
> clipped viewport allows plotting outside the clipped one, but I don't
> know if that's intentional. 


Yep, that's intentional.

Paul


Even if this behaviour does change, the
> opposite should be stable: turn off clipping globally and then insert
> the part of the panel function you want clipped into a clipped
> viewport, e.g.:
> 
> xyplot(y ~ x,
>data=tmp, ylim=c(1.5,4.5),
>par.settings = list(clip = list(panel = "off")),
>panel=function(...) {
>cpl <- current.panel.limits()
>pushViewport(viewport(xscale = cpl$xlim,
>  yscale = cpl$ylim,
>  clip = "on"))
>panel.xyplot(...)
>upViewport()
>panel.axis(side="right", outside=TRUE)
>},
>layout=c(2,2))
> 
>> ## 2
>>> Unfortunately, there is currently no easy way to find out which column
>>> and row the current panel occupies. I plan to make some changes before
>>> R 2.4.0 is released that should expose that information, so please try
>>> again in a few weeks.
>> The way I have been using is to back up the calling sequence and
>> use statements like
>> {
>> ## This loop is needed because
>> ##console usage has i=2,
>> ##Rcmdr script window has i=5,
>> ##Rcmdr justDoIt has i=20
>> for (i in seq(2, length=30)) {
>>   sf2 <- sys.frame(i)
>>   column.tmp <- try(get("column", pos=sf2), silent=TRUE)
>>   if (class(column.tmp) != "try-error") break
>> }
>> if (class(column.tmp) == "try-error")
>>   stop("panel.interaction2wt is too deeply nested in the system stack.")
>> row <- get("row", pos=sf2)
>> column <- get("column", pos=sf2)
>> cols.per.page <- get("cols.per.page", pos=sf2)
>> rows.per.page <- get("rows.per.page", pos=sf2)
>>   }
>>
>> ## A cleaner way would be preferable.  Will the above stay valid?  The
>> ## need for a loop to find out how far up the calling sequence to go
>> ## caught me by surprise.  I don't understand why generating commands
>> ## the way Rcmdr does it should have an effect on the depth of the
>> ## calling sequence.
> 
> I hope to add 3 new features before R 2.4.0, two of which are relevant
> 

Re: [Rd] (PR#9202) Re: Bugs with partial name matching

[Anil Maliyekkel]

On Sep 5, 2006, at 5:54 PM, Thomas Lumley wrote:
> The problem in
>> D = list(ABCD=2:1)
>>  D$ABC[]<-3:4
>> D
> $ABCD
> [1] 3 4
>
> $ABC
> [1] 3 4
>
> is that eval.c:evalseq ends up with a reference to D$ABCD from  
> evaluating D$ABC with partial matching.  Since evalseq doesn't (and  
> shouldn't) increase NAMED on these partially evaluated calls, NAMED  
> is still 1 for D$ABCD.  When evalseq's D$ABC has 3:4 assigned into  
> it the vector is changed directly, since NAMED=1, and both D$ABC  
> and D$ABCD change.

This problem does not appear when the following is done

 > D = list(ABCD=2:1)
 > D$ABC[]=c(3,4)
 > D
$ABCD
[1] 2 1

$ABC
[1] 3 4

Or when this is done:

 > D = list(ABCD=2:1)
 > D[["ABC"]][]=3:4
 > D
$ABCD
[1] 2 1

$ABC
[1] 3 4


But it does appear when the following is done:

 > D = list(ABCD=2:1)
 > X = 3:4
 > D$ABC[]=X
 > D
$ABCD
[1] 3 4

$ABC
[1] 3 4

But not when the following is done:
 > D = list(ABCD=2:1)
 > X = 3:4
 > X[1] = 1
 > D$ABC[]=X
 > D
$ABCD
[1] 2 1

$ABC
[1] 1 4

It appears to be a sequence specific bug for the $ operator, which  
might explain why it did not occur with my original examples where I  
had a character data column, but did appear where I had a numeric  
data column that was a sequence.

Going back to the original partial replacement problem, is there  
anyway to turn off partial matching, or to selectively apply exact  
matching when trying to access a single element?  I can get the  
desired single element match using the convoluted syntax D["ABC"] 
[[1]] and perform partial replacement operations on a new column.   
However, it would be nice to have single element access operator that  
does exact matching.

Anil

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel