Re: [Rd] (PR#9202) Re: Bugs with partial name matching
> "Anil" == Anil Maliyekkel <[EMAIL PROTECTED]>
> on Tue, 5 Sep 2006 22:50:30 -0500 writes:
[...]
[...]
Anil> Going back to the original partial replacement
Anil> problem, is there anyway to turn off partial matching,
One way would be to use S4 classes (and '@') instead of lists
(and '$').
That has other advantages {?validObject; methods,..}, but also can be
a drawback to you since you need to know in advance
what "components" (called "slots" for S4 objects) your object
will be allowed to contain.
Anil> or to selectively apply exact matching when trying to
Anil> access a single element? I can get the desired single
Anil> element match using the convoluted syntax D["ABC"]
Anil> [[1]] and perform partial replacement operations on a
Anil> new column. However, it would be nice to have single
Anil> element access operator that does exact matching.
Anil> Anil
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] setMethod("c") [was: setMethod("Summary")]
Dear All
thank you for your continued patience and help.
The example in the Green Book is
setGeneric("max",
function(x, ..., na.rm=FALSE){
if(nDotArgs(...)>0){
max(c(max(x, na.rm=na.rm), max(..., na.rm=na.rm)))
} else {
standardGeneric("max")
}
}
)
The point of this example is to implement a tail recursion.But it
isn't applicable
to c() because it is a primitive function and the generic function
cannot be changed:
setGeneric("c",
function(x, ...){
z <- list(...)
if(length(z)>0){
return(c(x, c(...)))
} else {
return(standardGeneric("c"))
}
}
)
gives the following error:
Error in setGeneric("c", function(x, ...) { :
'c' is a primitive function; methods can be defined, but the
generic function is implicit, and cannot be changed.
OK, plan B (or should that be plan A?) is to define cPair() and call
that .
Minimal self-contained code follows
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)
}
is.brob <- function(x){is(x,"brob")}
as.brob <- function(x){
if(is.brob(x)){
return(x)
} else {
return(brob(log(abs(x)),x>0))
}
}
cWithMethods <- function(x, ..., recursive=TRUE) {
if(nargs()<3){
return(cPairOfBrobs(x, ...))
} else {
return(cPairOfBrobs(x, cWithMethods(...)))
}
}
cPairOfBrobs <- function(x,y){
x <- as.brob(x)
y <- as.brob(y)
brob(c([EMAIL PROTECTED],[EMAIL PROTECTED]),c([EMAIL PROTECTED],[EMAIL
PROTECTED]))
}
setMethod("c",signature("brob"),cWithMethods)
But this has the same problem as before; if x is a brob,
then c(x,1) is fine but c(1,x) isn't:
x <- new("brob",x=pi,positive=T)
c(x,1)
An object of class "brob"
Slot "x":
[1] 3.141593 0.00
Slot "positive":
[1] TRUE TRUE
> c(1,x)
[[1]]
[1] 1
How do I tell setMethod("c", ...) to call the appropriate functions
if any object passed to c()
is a brob?
On 5 Sep 2006, at 16:47, John Chambers wrote:
> (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
>>>
[snip]
>>>
>>>
>>> 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
[Rd] R 2.3.1 and R2.3.0 crash with system() and shell() commands (PR#9207)
Full_Name: Johannes Prix
Version: 2.3.1/2.3.0 not 2.1.1
OS: Windows XP Service Pack 2 Build 2600.xpsp_sp2_gdr.0503011519
Submission from: (NULL) (137.208.41.103)
In a vanilla R, version 2.3.1 or version 2.3.0 the following crashes:
system("gzip.exe")
where I did nothing, prior to this command, but change the directory to my other
working directory where there's gzip.exe. Same happens for PUTTY's pscp.exe and
other commands. Normally, I use a longer command line than the one above, but
it also crashes with this short one. Makes no difference if I use Rgui.exe or
Rterm.exe. Same result with "shell" instead of "system".
With non-existing commands, I get
> system("asdf")
Warning message:
asdf nicht gefunden
>
It works on an 2.1.1 installation though.
The machine is otherwise "normal" but has lots of memory.
Any clues on how to circumvent this would be wonderful. Otherwise I'll just
stick to the R-2.1.1 where it's working. Please let me know if anything else in
this bug report is missing.
Thanks a lot and see ya,
Johannes Prix.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 2.3.1 and R2.3.0 crash with system() and shell() commands (PR#9207)
Works correctly for me in the Rtools directory on 2.3.1.
Any more clues as to how to reproduce this?
On Wed, 6 Sep 2006, [EMAIL PROTECTED] wrote:
> Full_Name: Johannes Prix
> Version: 2.3.1/2.3.0 not 2.1.1
> OS: Windows XP Service Pack 2 Build 2600.xpsp_sp2_gdr.0503011519
> Submission from: (NULL) (137.208.41.103)
>
>
>
> In a vanilla R, version 2.3.1 or version 2.3.0 the following crashes:
>
> system("gzip.exe")
>
> where I did nothing, prior to this command, but change the directory to my
> other
> working directory where there's gzip.exe. Same happens for PUTTY's pscp.exe
> and
> other commands. Normally, I use a longer command line than the one above, but
> it also crashes with this short one. Makes no difference if I use Rgui.exe
> or
> Rterm.exe. Same result with "shell" instead of "system".
>
> With non-existing commands, I get
>
> > system("asdf")
> Warning message:
> asdf nicht gefunden
> >
>
> It works on an 2.1.1 installation though.
>
> The machine is otherwise "normal" but has lots of memory.
>
> Any clues on how to circumvent this would be wonderful. Otherwise I'll just
> stick to the R-2.1.1 where it's working. Please let me know if anything else
> in
> this bug report is missing.
>
> Thanks a lot and see ya,
> Johannes Prix.
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 2.3.1 and R2.3.0 crash with system() and shell() commands (PR#9208)
Works correctly for me in the Rtools directory on 2.3.1.
Any more clues as to how to reproduce this?
On Wed, 6 Sep 2006, [EMAIL PROTECTED] wrote:
> Full_Name: Johannes Prix
> Version: 2.3.1/2.3.0 not 2.1.1
> OS: Windows XP Service Pack 2 Build 2600.xpsp_sp2_gdr.0503011519
> Submission from: (NULL) (137.208.41.103)
>
>
>
> In a vanilla R, version 2.3.1 or version 2.3.0 the following crashes:
>
> system("gzip.exe")
>
> where I did nothing, prior to this command, but change the directory to my
> other
> working directory where there's gzip.exe. Same happens for PUTTY's pscp.exe
> and
> other commands. Normally, I use a longer command line than the one above, but
> it also crashes with this short one. Makes no difference if I use Rgui.exe
> or
> Rterm.exe. Same result with "shell" instead of "system".
>
> With non-existing commands, I get
>
> > system("asdf")
> Warning message:
> asdf nicht gefunden
> >
>
> It works on an 2.1.1 installation though.
>
> The machine is otherwise "normal" but has lots of memory.
>
> Any clues on how to circumvent this would be wonderful. Otherwise I'll just
> stick to the R-2.1.1 where it's working. Please let me know if anything else
> in
> this bug report is missing.
>
> Thanks a lot and see ya,
> Johannes Prix.
>
> __
> 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
[Rd] JPEG struct mismatch on Intel Macs (PR#9209)
Full_Name: Phil Spector
Version: 2.3.1
OS: Mac OS X (Tiger)
Submission from: (NULL) (128.32.135.22)
Trying to close a jpeg() device on an Intel Mac causes the following:
> jpeg('out.jpg')
> plot(1:10)
> dev.off()
JPEG parameter struct mismatch: library thinks size is 372, caller expects 376
null device
1
>
An empty jpg file is produced in 'out.jpg'
-
- Phil Spector
Statistical Computing
Facility
Department of Statistics
UC Berkeley
__
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
On Tue, 5 Sep 2006, Richard M. Heiberger wrote: > 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. I think the help window title comes from the Title=... line in the *.hhp file. share/perl/build-help-windows.pl:open_hhp() adds a bunch of similar lines to the *.hhp file, but not Title=. See, e.g., http://www.helpware.net/FAR/help/dlg_hhpedit_sec.htm Bill Dunlap Insightful Corporation bill at insightful dot com 360-428-8146 "All statements in this message represent the opinions of the author and do not necessarily reflect Insightful Corporation policy or position." __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] JPEG struct mismatch on Intel Macs (PR#9209)
[EMAIL PROTECTED] writes:
> Full_Name: Phil Spector
> Version: 2.3.1
> OS: Mac OS X (Tiger)
> Submission from: (NULL) (128.32.135.22)
>
>
> Trying to close a jpeg() device on an Intel Mac causes the following:
>
> > jpeg('out.jpg')
> > plot(1:10)
> > dev.off()
> JPEG parameter struct mismatch: library thinks size is 372, caller expects 376
> null device
> 1
> >
>
>
> An empty jpg file is produced in 'out.jpg'
AFAICT, this wouldn't be a bug in R. Your version of R appears to
have been built with one version of the jpeg libraries and you have
another version installed. Unless we have a compiler issue and one
part is padding out to a multiple of 8 bytes.
--
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] JPEG struct mismatch on Intel Macs (PR#9209)
On Sep 6, 2006, at 12:34 PM, Peter Dalgaard wrote:
> [EMAIL PROTECTED] writes:
>
>> Full_Name: Phil Spector
>> Version: 2.3.1
>> OS: Mac OS X (Tiger)
>> Submission from: (NULL) (128.32.135.22)
>>
>>
>> Trying to close a jpeg() device on an Intel Mac causes the following:
>>
>>> jpeg('out.jpg')
>>> plot(1:10)
>>> dev.off()
>> JPEG parameter struct mismatch: library thinks size is 372, caller
>> expects 376
>> null device
>> 1
>>>
>>
>>
>> An empty jpg file is produced in 'out.jpg'
>
> AFAICT, this wouldn't be a bug in R. Your version of R appears to
> have been built with one version of the jpeg libraries and you have
> another version installed. Unless we have a compiler issue and one
> part is padding out to a multiple of 8 bytes.
>
Although it's not a bug in R, it is a problem with the Mac binary
which uses static libjpeg. I have re-compiled libjpeg for Intel Mac
so tonight's nightly build should be ok.
Thanks,
Simon
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] JPEG struct mismatch on Intel Macs (PR#9209)
On Sep 6, 2006, at 12:34 PM, Peter Dalgaard wrote:
> [EMAIL PROTECTED] writes:
>
>> Full_Name: Phil Spector
>> Version: 2.3.1
>> OS: Mac OS X (Tiger)
>> Submission from: (NULL) (128.32.135.22)
>>
>>
>> Trying to close a jpeg() device on an Intel Mac causes the following:
>>
>>> jpeg('out.jpg')
>>> plot(1:10)
>>> dev.off()
>> JPEG parameter struct mismatch: library thinks size is 372, caller
>> expects 376
>> null device
>> 1
>>>
>>
>>
>> An empty jpg file is produced in 'out.jpg'
>
> AFAICT, this wouldn't be a bug in R. Your version of R appears to
> have been built with one version of the jpeg libraries and you have
> another version installed. Unless we have a compiler issue and one
> part is padding out to a multiple of 8 bytes.
>
Although it's not a bug in R, it is a problem with the Mac binary
which uses static libjpeg. I have re-compiled libjpeg for Intel Mac
so tonight's nightly build should be ok.
Thanks,
Simon
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] setMethod("c") [was: setMethod("Summary")]
You missed the point of the example, which is why your own
implementation didn't work.
It's not the tail recursion that is important, but the recasting of
max() (or of c()) to not just a standard generic, but to a recursive
computation, so that methods need only be defined for a finite number
of arguments.
Because the recursion in c() requires two arguments, not one as with
max(), the methods are more naturally transferred to an auxiliary
function, cPair in my sketch. Then cWithMethods _replaces_ the ordinary
c(), it's not just a method for it.
Also required are a set of methods that corresponds to what you want to
do. The methods apply, as I said before, to cPair(), which is a generic
with two arguments.
If your picture is that you can bind your class to anything, in either
order, then you need methods for ("ANY", "brob") and ("brob", "ANY"), as
well as the method ("brob", "brob"), equivalent to the function
cPairOfBrobs(), and a default method that just uses c().
Something like:
-
cWithMethods <- function(x, ...) {
if(nargs()<3)
cPair(x,...)
else
cPair(x, cWithMethods(...))
}
setGeneric("cPair", function(x,y)standardGeneric("cPair"))
setMethod("cPair", c("brob", "brob"), function(x,y)cPairOfBrobs(x,y))
setMethod("cPair", c("brob", "ANY"), function(x,y)c([EMAIL PROTECTED], y))
setMethod("cPair", c("ANY", "brob"), function(x,y)c(x, [EMAIL PROTECTED]))
setMethod("cPair", c("ANY", "ANY"), function(x,y)c(x,y))
Robin Hankin wrote:
> Dear All
>
> thank you for your continued patience and help.
> The example in the Green Book is
>
>
> setGeneric("max",
> function(x, ..., na.rm=FALSE){
> if(nDotArgs(...)>0){
> max(c(max(x, na.rm=na.rm), max(..., na.rm=na.rm)))
> } else {
> standardGeneric("max")
> }
> }
> )
>
>
> The point of this example is to implement a tail recursion.But it
> isn't applicable
> to c() because it is a primitive function and the generic function
> cannot be changed:
>
>
> setGeneric("c",
> function(x, ...){
> z <- list(...)
> if(length(z)>0){
> return(c(x, c(...)))
> } else {
> return(standardGeneric("c"))
> }
> }
> )
>
>
> gives the following error:
>
>
> Error in setGeneric("c", function(x, ...) { :
> 'c' is a primitive function; methods can be defined, but the
> generic function is implicit, and cannot be changed.
>
>
> OK, plan B (or should that be plan A?) is to define cPair() and call
> that .
> Minimal self-contained code follows
>
>
> 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)
> }
>
> is.brob <- function(x){is(x,"brob")}
>
> as.brob <- function(x){
>if(is.brob(x)){
> return(x)
>} else {
> return(brob(log(abs(x)),x>0))
>}
> }
>
>
> cWithMethods <- function(x, ..., recursive=TRUE) {
>if(nargs()<3){
> return(cPairOfBrobs(x, ...))
>} else {
> return(cPairOfBrobs(x, cWithMethods(...)))
>}
> }
>
> cPairOfBrobs <- function(x,y){
>x <- as.brob(x)
>y <- as.brob(y)
>brob(c([EMAIL PROTECTED],[EMAIL PROTECTED]),c([EMAIL PROTECTED],[EMAIL
> PROTECTED]))
> }
>
> setMethod("c",signature("brob"),cWithMethods)
>
>
>
> But this has the same problem as before; if x is a brob,
> then c(x,1) is fine but c(1,x) isn't:
>
>
>
> x <- new("brob",x=pi,positive=T)
> c(x,1)
> An object of class "brob"
> Slot "x":
> [1] 3.141593 0.00
>
> Slot "positive":
> [1] TRUE TRUE
>
> > c(1,x)
> [[1]]
> [1] 1
>
>
>
>
> How do I tell setMethod("c", ...) to call the appropriate functions
> if any object passed to c()
> is a brob?
>
>
>
>
>
> On 5 Sep 2006, at 16:47, John Chambers wrote:
>
>
>> (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
