Re: [Rd] setMethod("Logic", ...)
Professor Ripley
thank you for this (and indeed thank you for solving my earlier
problem on octonions).
I still don't know how to force logic operations on brob objects to
give an error.
06, at 16:45, Prof Brian Ripley wrote:
> Accordng to the S4groupGeneric page, there is no such group.
>
> My guess as to why:
>
> Those operators are not S3 generic in R, and S4 dispatch is piggy-
> backed
> on S3 dispatch (not necessarily, but for convenience).
>
>
I have been trying to use the example on p119 of S Programming as
a template:
setClass("brob",
representation = representation
(x="numeric",positive="logical"),
prototype = list(x=numeric(),positive=logical())
)
.logicBrob <- function(e1,e2){
stop("No logic currently implemented for Brobdingnagian numbers")
}
setMethod("Logic",signature(e1="brob"), .logicBrob)
setMethod("Logic",signature(e2="brob"), .logicBrob)
but this does not work as desired (setMethod() gives an error). I want,
for example,
!new("brob", x=1:10,positive=rep(T,10))
to call .logicBrob() and report an error.
--
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] R-Project logo in SVG format
> On Thu, 31 Aug 2006 16:55:38 +0100, > Barry Rowlingson (BR) wrote: > [EMAIL PROTECTED] wrote: >> After you created one and submitted it to us probably at the same place as >> the bitmaps. In the meantime it will have to suffice that you use all we >> have, and that are the bitmaps (the logo was done by a volunteer who chose >> to use a bitmapped graphics program). It is not like we keep the good >> stuff back on purpose ... > It does look like it would be near-impossible to parameterise the logo > efficiently into a vector format - all that shading and 3-d effect > stuff. The largest PNG file there is 1450x1100 pixels which at 300 dpi > gives you a 4-inch logo. Although looking at it full-size on my monitor > reveals some artifacts in the 3-d shading... > Do any other materials exist for making the logo? A description of the > fonts used, a 3-d model R and O-shape, a layered PSD or XCF file, or a > Gimp/Photoshop macro set for getting that effect? I dont believe this > was painted pixel-by-pixel... No, certainly not. But you would have to ask Stefano Iacus about details, he contributed the files. IIRC a relative of Stefano did the actual work. > When was the last time the mailing list had a 'need a new logo' thread? ;-) .f __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-Project logo in SVG format
> On Fri, 1 Sep 2006 08:56:03 -0700, > Don MacQueen (DM) wrote: > I have a file named Rlogo-5.svg, created by > downloading Rlogo-5.png, opening it with Adobe > Illustrator, Saving as SVG. > I didn't tinker with any of Illustrator's options > with regard to how, exactly, to save it, since I > pretty much don't know what they mean. Whether it > is of any use to anyone, or whether it is truly > scalable, I have no idea. All I know is that > Illustrator claims it is an SVG file. > Took about 2 minutes, all together (writing this email took longer). > If any R Core member (or anyone else, for that > matter), wants a copy, please let me know. I > don't want to burden lots of people with a file > they probably don't want. I guess that Illustrator simply has embedded the bitmap into the SVG file, such that scaling properties are the same. I know how to "convert" the PNG to EPS or PDF (and it takes even less than two minutes), but that again simply embeds the bitmap, so nothing gained. To be sure you can send me the SVG, I'll have a look. Best, Fritz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] setMethod("Logic", ...)
On Mon, 4 Sep 2006, Robin Hankin wrote:
> Professor Ripley
>
> thank you for this (and indeed thank you for solving my earlier
> problem on octonions).
>
> I still don't know how to force logic operations on brob objects to give an
> error.
I found this in the methods sources
## R does not currently do the Logic group (! & |)
## A strange group, since the argument lists are different. But
## perhaps we'll add it sometime.
(Not sure about the comment: there are unary and binary operators in
Arith.)
It looks to me as if you can work around this by defining S3 methods for
the class, if that is all you want to do.
setClass("foo", representation="numeric")
x <- new("foo", pi)
> !x
[1] FALSE
> "!.foo" <- function(x) stop("not supported")
> !x
Error in "!.foo"(x) : not supported
> 06, at 16:45, Prof Brian Ripley wrote:
>
> >Accordng to the S4groupGeneric page, there is no such group.
> >
> >My guess as to why:
> >
> >Those operators are not S3 generic in R, and S4 dispatch is piggy-backed
> >on S3 dispatch (not necessarily, but for convenience).
I was wrong here.
> I have been trying to use the example on p119 of S Programming as
> a template:
>
>
> setClass("brob",
> representation = representation(x="numeric",positive="logical"),
> prototype = list(x=numeric(),positive=logical())
> )
>
>
> .logicBrob <- function(e1,e2){
> stop("No logic currently implemented for Brobdingnagian numbers")
> }
>
>
> setMethod("Logic",signature(e1="brob"), .logicBrob)
> setMethod("Logic",signature(e2="brob"), .logicBrob)
>
>
>
> but this does not work as desired (setMethod() gives an error). I want,
> for example,
>
> !new("brob", x=1:10,positive=rep(T,10))
>
> to call .logicBrob() and report an error.
>
>
>
>
>
> --
> Robin Hankin
> Uncertainty Analyst
> National Oceanography Centre, Southampton
> European Way, Southampton SO14 3ZH, UK
> tel 023-8059-7743
>
--
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("Logic", ...)
> "Robin" == Robin Hankin <[EMAIL PROTECTED]>
> on Mon, 4 Sep 2006 09:41:46 +0100 writes:
Robin> Professor Ripley
Robin> thank you for this (and indeed thank you for solving my earlier
Robin> problem on octonions).
Robin> I still don't know how to force logic operations on brob objects to
Robin> give an error.
You "just" {as we will see below, your question is more interesting
than I first thought !}
define methods for all three of
'"&"', '"|"', '"!"'
e.g.
> setClass("brob", contains="numeric")
[1] "brob"
> setMethod("!", "brob", function(e1) {cat("not a brob\n"); invisible(e1)})
[1] "!"
> !new("brob")
not a brob
>
To keep things consistent, I would use helper functions {that
I'd keep hidden in the namespace}.
## Something like
logic.brob.error <- function(name) {
stop("logic operator '", name, "' not applicable to brobs")
}
logic2 <- function(e1,e2) {
logic.brob.error(.Generic)
}
setMethod("!", "brob",
function(e1) { logic.brob.error("!") })
setMethod("&", signature("brob", "ANY"), logic2) # -- okay --
setMethod("&", signature("ANY", "brob"), logic2) # ERR > bug in R (?)
## Error in ...
## the method for function '&' and signature e1="ANY", e2="brob" is sealed and
cannot be re-defined
setMethod("|", signature("brob", "ANY"), logic2) # -- okay --
setMethod("|", signature("ANY", "brob"), logic2) # ERR > bug in R (?!)
new("brob", 3) & new("brob", 0) #-> proper error
new("brob") & 1 #-> proper error
TRUE & new("brob", pi) # -> TRUE -- oops!
##--
I think this reveals a bug in R (still present in R-devel as of
this morning):
signature("ANY", "brob") should not be sealed for method
definition but it is.
Martin Maechler
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] setMethod("Summary")
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.
setClass("brob",
representation = representation
(x="numeric",positive="logical"),
prototype = list(x=numeric(),positive=logical())
)
.Brob.max <- function(...){
stop("not yet impemented")
}
setMethod("Summary", signature("brob"),
function(...){
switch(.Generic,
max= .Brob.max(...),
stop(paste(.Generic, "not implemented yet "))
)
}
)
but this gives an error from conformMethod().
[I've left the arguments to signature() unnamed because ?
GenericFunctions
says
A signature is
a named or unnamed vector of character strings. If named,
the names must be formal argument names for the generic
function. If 'signature' is unnamed, the default is to use
the first 'length(signature)' formal arguments of the
function.
which seems to tell me (in conjunction with the advice from
Extremes.Rd quote above)
to use unnamed arguments to signature()
]
What is the correct way to make sum(x) call .Brob.max() if x is a
"brob" object?
Or is is it better to define a sum.brob() function and use that?
--
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] Unexpected source() behavior in R-devel
Sean Davis <[EMAIL PROTECTED]> writes: > Seth Falcon wrote: >> Peter Dalgaard <[EMAIL PROTECTED]> writes: >> >> >>> "Henrik Bengtsson" <[EMAIL PROTECTED]> writes: >>> >>> This has been reported before on r-devel, e.g. May 9, 2006 "[Rd] Seg fault when installing package from bad repository". It's happening on Mac OSX when trying to download non-existing webpages (HTTP status 404). That's all I know (not using OSX myself). >>> It is not entirely obvious that it is the same problem, but it might be. >>> >>> This happened to me on Linux (2.3.1 on FC5), but it has only happened >>> that one time. I don't think I did anything particularly strange >>> earlier in that session. >>> >>> Of course, with 20/20 hindsight, I should have taken the core dump >>> option... >>> >> >> I'm pretty sure this is the same issue and one that has been fixed in >> R-devel. >> >> r38716 | ripley | 2006-07-30 00:19:35 -0700 (Sun, 30 Jul 2006) | 1 line >> Changed paths: >>M /trunk/src/modules/internet/internet.c >> crash workaround from Seth Falcon >> >> >> Sean: can you try just download.file with a URL that gives 404? Are >> you running an R version prior to the above commit? >> > Seth, > > As Peter pointed out, this looks like a simple server-side issue. > Here is the sessionInfo() from my original post. And below is the > output of two versions of download.file. Yes, there is an issue with the BioC website (investigating) and I didn't mean to imply otherwise. For now, as you discovered, use http://www.bioconductor.org (note the 'www'). I only responded here because of the segfault you reported which most certainly is not a simple server-side issue :-) Did you see the segfault with a recent R or an older one? If more recent, then it might be worth trying to reproduce and tracking down the bug. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Unexpected source() behavior in R-devel
Seth Falcon wrote: > Sean Davis <[EMAIL PROTECTED]> writes: > >> Seth Falcon wrote: >> >>> Peter Dalgaard <[EMAIL PROTECTED]> writes: >>> >>> >>> "Henrik Bengtsson" <[EMAIL PROTECTED]> writes: > This has been reported before on r-devel, e.g. May 9, 2006 "[Rd] Seg > fault when installing package from bad repository". > > It's happening on Mac OSX when trying to download non-existing > webpages (HTTP status 404). That's all I know (not using OSX myself). > > It is not entirely obvious that it is the same problem, but it might be. This happened to me on Linux (2.3.1 on FC5), but it has only happened that one time. I don't think I did anything particularly strange earlier in that session. Of course, with 20/20 hindsight, I should have taken the core dump option... >>> I'm pretty sure this is the same issue and one that has been fixed in >>> R-devel. >>> >>> r38716 | ripley | 2006-07-30 00:19:35 -0700 (Sun, 30 Jul 2006) | 1 line >>> Changed paths: >>>M /trunk/src/modules/internet/internet.c >>> crash workaround from Seth Falcon >>> >>> >>> Sean: can you try just download.file with a URL that gives 404? Are >>> you running an R version prior to the above commit? >>> >>> >> Seth, >> >> As Peter pointed out, this looks like a simple server-side issue. >> Here is the sessionInfo() from my original post. And below is the >> output of two versions of download.file. >> > > Yes, there is an issue with the BioC website (investigating) and I > didn't mean to imply otherwise. For now, as you discovered, use > http://www.bioconductor.org (note the 'www'). > > I only responded here because of the segfault you reported which most > certainly is not a simple server-side issue :-) > > Did you see the segfault with a recent R or an older one? If more > recent, then it might be worth trying to reproduce and tracking down > the bug. > Seth, Peter was the person who reported the segmentation fault, not I. I didn't experience that behavior. And it sounds like Peter wasn't able to reproduce it, so I'm not sure there is any bug here to be fixed. Sean __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Unexpected source() behavior in R-devel
Sean Davis <[EMAIL PROTECTED]> writes: > > > > Did you see the segfault with a recent R or an older one? If more > > recent, then it might be worth trying to reproduce and tracking down > > the bug. > > > Seth, > > Peter was the person who reported the segmentation fault, not I. I > didn't experience that behavior. And it sounds like Peter wasn't able > to reproduce it, so I'm not sure there is any bug here to be fixed. > > Sean It was with 2.3.1, but there have been some indications that it was likely fixed since, and I couldn't even reproduce it in 2.3.1. So there might and might not be a bug, but in any case we have no handle on it... -- 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] Unable to save a plot containing Chinese (two-byte) Characters (PR#9201)
Full_Name: Pavel Stranak Version: 2.3.1 OS: Mac OS X Submission from: (NULL) (195.113.20.81) Whenever I draw a plot containing Chinese character, it draws fine on screen, but never saves to a file. It does not matter, whether I first draw it on screen and than save or draw straight to pdf. It is also all the same, whether the characters are in label or in the plot itself (via "pch=..." or text()). The Error is always: "conversion failure in 'mbcsToSbcs' " This is an example: plot(1:20, 1:20, main="汉语 Derivational Characters' Productivity") # it draws well, I attempt to 'Save As...' in GUI Error in dev.copy(device = pdf, file = "/Users/pavel/Desktop/hanyu.pdf", : conversion failure in 'mbcsToSbcs' __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Start of release process for R 2.4.0
R 2.4.0 has been scheduled for October 3. The first alpha tarballs of R 2.4.0 will be made available through http://cran.r-project.org/src/base-prerelease/ starting tomorrow morning. The release schedule is available on http://developer.r-project.org As usual, bug reports are more useful before release than after, so please do what you can to check things out. This goes especially for those of you with uncommon platforms. -- 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
Re: [Rd] Unexpected source() behavior in R-devel
"Henrik Bengtsson" <[EMAIL PROTECTED]> writes: > Yes, there's been some problems with the Bioconductor server the last > few days, e.g. http://bioconductor.org/biocLite.R is not working > either. It was down on Monday night too and then it was not possible > to install any packages from them. I think they are aware of this > problem, but maybe not that it is down in this very minute. I've > cross-posted this reply to the bioc-devel to make sure the right > person gets it. The website issue should be fixed. bioconductor.org and www.bioconductor.org should be serving the same content. Please let us know of any difficulties you encounter. Bw, + seth __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] setMethod("Summary")
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.
>
>
>
> setClass("brob",
> representation = representation
> (x="numeric",positive="logical"),
> prototype = list(x=numeric(),positive=logical())
> )
>
>
> .Brob.max <- function(...){
>stop("not yet impemented")
> }
>
>
> setMethod("Summary", signature("brob"),
>function(...){
> switch(.Generic,
> max= .Brob.max(...),
> stop(paste(.Generic, "not implemented yet "))
> )
>}
> )
>
>
> but this gives an error from conformMethod().
>
> [I've left the arguments to signature() unnamed because ?
> GenericFunctions
> says
>
> A signature is
>a named or unnamed vector of character strings. If named,
>the names must be formal argument names for the generic
>function. If 'signature' is unnamed, the default is to use
>the first 'length(signature)' formal arguments of the
>function.
>
> which seems to tell me (in conjunction with the advice from
> Extremes.Rd quote above)
> to use unnamed arguments to signature()
> ]
>
>
> What is the correct way to make sum(x) call .Brob.max() if x is a
> "brob" object?
> Or is is it better to define a sum.brob() function and use that?
>
>
>
> --
> 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] (PR#9201) Unable to save a plot containing Chinese (two-byte) Characters
Please can we have a full reproducible example, including the locales used, and exactly how you 'saved' the plot? (As we do ask.) If Chinese characters are 'two-byte', then this likely will not work (but at least European locales on MacOS X are UTF-8, so I expected Chinese ones to be also). The issues are discussed in an article in the May 2006 R-News. You do need to set up a suitable family to support Chinese, and the error message suggests that you have failed to do so: if so this is not a bug in R. On Mon, 4 Sep 2006, [EMAIL PROTECTED] wrote: > Full_Name: Pavel Stranak > Version: 2.3.1 > OS: Mac OS X > Submission from: (NULL) (195.113.20.81) > > > Whenever I draw a plot containing Chinese character, it draws fine on screen, > but never saves to a file. > It does not matter, whether I first draw it on screen and than save or draw > straight to pdf. > It is also all the same, whether the characters are in label or in the plot > itself (via "pch=..." or text()). > The Error is always: "conversion failure in 'mbcsToSbcs' " > > This is an example: > > plot(1:20, 1:20, main="汉语 Derivational Characters' > Productivity") > # it draws well, I attempt to 'Save As...' in GUI > > Error in dev.copy(device = pdf, file = "/Users/pavel/Desktop/hanyu.pdf", : > conversion failure in 'mbcsToSbcs' > > __ > 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] (PR#9201) Unable to save a plot containing Chinese (two-byte)
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --27464147-689190176-1157401193=:15799 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-ID: <[EMAIL PROTECTED]> On Mon, 4 Sep 2006, Pavel Stranak wrote: > On 4.9.2006, at 21:16, Prof Brian Ripley wrote: > > >Please can we have a full reproducible example, including the locales > >used, and exactly how you 'saved' the plot? (As we do ask.) You have _still_ not told us what we asked, including the locales! > I have used GUI command "File->Save As .." Im Mac GUI. That may well not work, but reports on the Mac GUI are inappropriate for R-bugs. > It works perfectly with the same plots, when I don't use Chinese. > It also works fine, when I use Czech accented characters. At least some of > them are also two-byte in UTF-8. Yes, but Chinese chars are not. > But the problem also occures when I direct pdf device right into the file: > > pdf(file="Rplot.pdf") Incorrect usage. > > plot(1:20, 1:20, main="P?íli? ?lu?ou?ký k?? úp?l ?ábelské ódy.") > # Czech accents work fine > > plot(1:20, 1:20, main="?P?íli? ?lu?ou?ký k?? úp?l ?ábelské ódy.") > Error in title(...) : conversion failure in 'mbcsToSbcs' > # One Chinese character => Error > > > > >If Chinese characters are 'two-byte', then this likely will not work (but > >at least European locales on MacOS X are UTF-8, so I expected Chinese ones > >to be also). > As far as I know, UTF-8 contains at least 1byte and 2byte characters. and 3 byte and 4 byte chars, and potentially up to 6. > All the chinese characters are represented by two bytes in UTF-8. Please give your reference! They are in the Unicode ranges from 2F00, and characters above 07Ff need 3 or more bytes in UTF-8. http://www.cl.cam.ac.uk/~mgk25/unicode.html > The characters I have used (but that fail to display in your bug-tracking > system) > are two characters "Chinese language". > > My locales are set to UTF-8. That is *not* a locale but a character encoding. > I have not set any fonts in R because all the Chinese characters display fine > both in the console and the plot. But not in pdf, as you said. You really have failed to read the references, including the help page and tutorial I very kindly pointed you to. In case it has still not got through to you: PDF is not written in UTF-8 and most fonts do not include Chinese ideographs, including Helvetica, the default font for PDF. -- 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 --27464147-689190176-1157401193=:15799-- __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] make test-Specific?
[Gregor Gorjanc] >In Writing R Extensions manual, section "Testing R code"[1] says: >"be careful to check if make test-Specific or particularly, cd tests; >make no-segfault.Rout" >Actually, make test-Specific also needs "cd tests;" in front. >[1]http://cran.r-project.org/doc/manuals/R-exts.html#Testing-R-code Allow me a quick comment about using "cd" in Makefiles, reading by. Whenever possible, prefer "cd DIR && ACTION" to "cd DIR; ACTION". This protects you from ACTION when it has some destructive effect, and DIR either happens to not exist or is just mistyped, in which case ACTION is executed in the current directory. A little good habit that saved me a few times along all those years! :-) -- François Pinard http://pinard.progiciels-bpi.ca __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Bugs with partial name matching during partial replacement (PR#9202)
Hello,
First the version info:
platform powerpc-apple-darwin8.6.0
arch powerpc
os darwin8.6.0
system powerpc, darwin8.6.0
status
major 2
minor 3.1
year 2006
month 06
day01
svn rev38247
language R
version.string Version 2.3.1 (2006-06-01)
I have encountered some unusual behavior when trying to create new
columns in a data frame that have names that would generate a partial
match with an existing column with a longer name. It is my
understanding that replacement operations shouldn't have partial
matching, but it is not clear to me whether this applies only when
the named column exists and not for new assignments.
The first example:
> D = data.frame(M=c(T,T,F,F,F,T,F,T,F,F,T,T,T),V=I(sprintf("ZZ%02d",
1:13)),ABCD=13:1)
> D
MV ABCD
1 TRUE ZZ01 13
2 TRUE ZZ02 12
3 FALSE ZZ03 11
4 FALSE ZZ04 10
5 FALSE ZZ059
6 TRUE ZZ068
7 FALSE ZZ077
8 TRUE ZZ086
9 FALSE ZZ095
10 FALSE ZZ104
11 TRUE ZZ113
12 TRUE ZZ122
13 TRUE ZZ131
> D$CBA[D$M] = D$V[D$M]
> D
MV ABCD CBA
1 TRUE ZZ01 13 ZZ01
2 TRUE ZZ02 12 ZZ02
3 FALSE ZZ03 11
4 FALSE ZZ04 10
5 FALSE ZZ059
6 TRUE ZZ068 ZZ06
7 FALSE ZZ077
8 TRUE ZZ086 ZZ08
9 FALSE ZZ095
10 FALSE ZZ104
11 TRUE ZZ113 ZZ11
12 TRUE ZZ122 ZZ12
13 TRUE ZZ131 ZZ13
> D$ABC[D$M] = D$V[D$M]
> D
MV ABCD CBA ABC
1 TRUE ZZ01 13 ZZ01 ZZ01
2 TRUE ZZ02 12 ZZ02 ZZ02
3 FALSE ZZ03 1111
4 FALSE ZZ04 1010
5 FALSE ZZ059 9
6 TRUE ZZ068 ZZ06 ZZ06
7 FALSE ZZ077 7
8 TRUE ZZ086 ZZ08 ZZ08
9 FALSE ZZ095 5
10 FALSE ZZ104 4
11 TRUE ZZ113 ZZ11 ZZ11
12 TRUE ZZ122 ZZ12 ZZ12
13 TRUE ZZ131 ZZ13 ZZ13
I expected ABC to equal CBA with NA values in rows not assigned, but
instead it appears that an extraction from D$ABCD and coercion to
string is being performed in the process of creating D$ABC.
Here is something I believe is definitely a bug:
> D = data.frame(M=c(T,T,F,F,F,T,F,T,F,F,T,T,T),V=1:13,ABCD=13:1)
> D
M V ABCD
1 TRUE 1 13
2 TRUE 2 12
3 FALSE 3 11
4 FALSE 4 10
5 FALSE 59
6 TRUE 68
7 FALSE 77
8 TRUE 86
9 FALSE 95
10 FALSE 104
11 TRUE 113
12 TRUE 122
13 TRUE 131
> D$CBA[D$M] = D$V[D$M]
> D
M V ABCD CBA
1 TRUE 1 13 1
2 TRUE 2 12 2
3 FALSE 3 11 NA
4 FALSE 4 10 NA
5 FALSE 59 NA
6 TRUE 68 6
7 FALSE 77 NA
8 TRUE 86 8
9 FALSE 95 NA
10 FALSE 104 NA
11 TRUE 113 11
12 TRUE 122 12
13 TRUE 131 13
> D$ABC[D$M] = D$V[D$M]
> D
M V ABCD CBA ABC
1 TRUE 11 1 1
2 TRUE 22 2 2
3 FALSE 3 11 NA 11
4 FALSE 4 10 NA 10
5 FALSE 59 NA 9
6 TRUE 66 6 6
7 FALSE 77 NA 7
8 TRUE 88 8 8
9 FALSE 95 NA 5
10 FALSE 104 NA 4
11 TRUE 11 11 11 11
12 TRUE 12 12 12 12
13 TRUE 13 13 13 13
ABC is created as before with valued from ABCD in the unassigned
rows, but ABCD is being modified as well. The only difference form
the previous example is that V is now just a numeric column.
Anil Maliyekkel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Two submitted packages
## 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
## 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?
## 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?
## 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? Can the
## behavior be changed?
##
## 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))
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
