[Rd] Defining an iterator
Inspired by Rudolf Biczok's query of Fri, Jan 23, 2009 at 1:25 AM, I
tried to implement iteration in a generic way using S4. (Though I am
admittedly still struggling with learning S4.)
> setClass("foo",representation(bar="list"))
[1] "foo"
> x<-new("foo",bar=list(1,2,3))
Given this, I would not expect for(i in x)... to work, since R has no
way of knowing that x...@bar should be used as is. What would it do if
the representation included two lists? What if list(1,2,3) is used by
the class foo to represent something else?
But I did hope that I could put in place some definitions so that the
*class* could define an iterator.
First I tried overloading `for` to allow the definition of iterator
classes, but as a primitive function, `for` cannot be overloaded.
Then I tried to see how the Containers package handles iterators:
> library(Containers);.jinit();.jpackage("Containers")
> ah = MaxHeap(); ah$insert(3)
> for (i in ah) print(i)
[1] NA
> as.list(ah)
[[1]]
[1] NA
Bit it appears that the Containers package's Iterators don't interface
with R's `for` or type conversion system.
So I gave up on iterators, but thought I'd try automatic conversion to lists.
So I defined an automatic conversion from foo to list, since `for`'s
seq argument is specified as "An expression evaluating to a vector
(including a list...)":
setAs("foo","list",function(from)f...@bar)
This and various variants (using "numeric" or "vector" instead of
"list") all give errors. Is there perhaps some 'sequence' superclass
that I am ignorant of?
I *was* able to overload lapply:
> setMethod("lapply","foo",function(X,FUN,...) lapply(x...@bar,FUN,...))
> lapply(x,dput); NULL
1
2
3
NULL
but of course that doesn't affect `for` and other places that expect sequences.
Is there in fact some generic way to handle define iterators or
abstract sequences in R?
-s
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Automatic shortening of text to fit into area
Hi Prof Brian Ripley wrote: > Almost all devices do support clipping, so this is rather a minority > interest. As a measure of the rarity, I wrote that code almost 10 years ago and this is the first mention of this problem (though perhaps there are millions out there suffering in silence ...). I agree that dropping one character at a time and trying again would be better than just not drawing anything, and your patch is nice and light (especially given the nasty complexity of the GEText code), but the suggested patch only addresses the case where the text extends out the right hand side of the device (and is not rotated). The modification also needs to handle the case(s) where the characters should be dropped from the front of the text. I also wonder whether it might be possible to make the patch local to just the clipTextCode() function (because the clipTextCode function that it calls does its own calculation of the text width and height). Paul > The person who AFAIK worte that comment and designed the clipping in > the engine is Paul Murrell. He has been on summer vacation, but it > looks like he has just returned. I suggest contacting him directly if > he does nto respond to these postings. > > On Sat, 24 Jan 2009, Sebastian Fischmeister wrote: > >> Hello, >> >> A comment in engine.c states: "/* don't draw anything; this could be made >> less crude :) */". The following patch makes it less crude: If the device >> doesn't support clipping and the text doesn't fit into the area, then remove >> one character after another from the text until either the text fits or the >> string is empty. >> >> I attached the patch—it's not indented correctly to keep the patch size >> small—and a test script, so you can give it a try. I don't know the R core >> very well, so this change may need some discussion. Yet it works for my >> figures. >> >> Have fun, >> Sebastian >> > > > > > __ > 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 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Defining an iterator
It's unclear from your mail what you actually tried to do, but here are
a few comments that may be relevant.
The syntactic form for() is indeed implemented as a primitive
function. Some primitives can and are used as generic functions, but
`for` is not currently one of them.
> setGeneric("for")
Error in genericForPrimitive(f) :
methods may not be defined for primitive function "for" in this
version of R
Allowing methods for it would be possible in a future version. This
would be a little odd, since the syntax does not look like a function
call. Still, it's an interesting idea, and I don't know of anything
offhand to prevent its implementation. The natural interpretation would
be for the signature of the generic to be the second argument
(primitives don't intrinsically have argument names, so we would make
one up, `seq` is used in the documentation, although something like
`object` would be more suggestive).
Your comments about coercing are unclear and you showed no examples of
what supposedly went wrong. In fact, that approach works fine:
> setClass("foo",representation(bar="list"))
[1] "foo"
> setAs("foo","list",function(from)f...@bar)
> xx = new("foo", bar = list(1,2,3))
> as(xx, "list")
[[1]]
[1] 1
[[2]]
[1] 2
[[3]]
[1] 3
> for(i in as(xx, "list")) dput(i)
1
2
3
Of course, this is not exactly defining methods for the iterator, but
would be a sensible workaround in practice.
Along the same lines, if one asks how the underlying ideas fit naturally
into R, as opposed to making R behave more like other languages, here's
my take on that. The `for` operator is defined to work on vectors of
various kinds. If a new class is supposed to be "like" a vector, then
the two natural choices are to define a method to coerce it to a vector
(as in the example above) or to make it a subclass of "vector" (or of a
specific vector class):
> setClass("baz", contains = "vector")
[1] "baz"
> yy = new("baz", list(1,2,3))
> for(i in yy) dput(i)
1
2
3
Which choice works best depends on what the "real" meaning of the class
is (there's discussion of these and other alternatives in section 9.3 of
"Software for Data Analysis").
John Chambers
Stavros Macrakis wrote:
> Inspired by Rudolf Biczok's query of Fri, Jan 23, 2009 at 1:25 AM, I
> tried to implement iteration in a generic way using S4. (Though I am
> admittedly still struggling with learning S4.)
>
>
>> setClass("foo",representation(bar="list"))
>>
> [1] "foo"
>
>> x<-new("foo",bar=list(1,2,3))
>>
>
> Given this, I would not expect for(i in x)... to work, since R has no
> way of knowing that x...@bar should be used as is. What would it do if
> the representation included two lists? What if list(1,2,3) is used by
> the class foo to represent something else?
>
> But I did hope that I could put in place some definitions so that the
> *class* could define an iterator.
>
> First I tried overloading `for` to allow the definition of iterator
> classes, but as a primitive function, `for` cannot be overloaded.
>
> Then I tried to see how the Containers package handles iterators:
>
>
>> library(Containers);.jinit();.jpackage("Containers")
>> ah = MaxHeap(); ah$insert(3)
>> for (i in ah) print(i)
>>
> [1] NA
>
>> as.list(ah)
>>
> [[1]]
> [1] NA
>
> Bit it appears that the Containers package's Iterators don't interface
> with R's `for` or type conversion system.
>
> So I gave up on iterators, but thought I'd try automatic conversion to lists.
>
> So I defined an automatic conversion from foo to list, since `for`'s
> seq argument is specified as "An expression evaluating to a vector
> (including a list...)":
>
> setAs("foo","list",function(from)f...@bar)
>
> This and various variants (using "numeric" or "vector" instead of
> "list") all give errors. Is there perhaps some 'sequence' superclass
> that I am ignorant of?
>
> I *was* able to overload lapply:
>
>
>> setMethod("lapply","foo",function(X,FUN,...) lapply(x...@bar,FUN,...))
>> lapply(x,dput); NULL
>>
> 1
> 2
> 3
> NULL
>
> but of course that doesn't affect `for` and other places that expect
> sequences.
>
> Is there in fact some generic way to handle define iterators or
> abstract sequences in R?
>
> -s
>
> __
> 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] FW: [R] The Quality & Accuracy of R
Muenchen, Robert A (Bob) wrote: Dear R Developers, This is my first time subscribing to this list, so let me start out by saying thank you all very much for the incredible contribution you have made to science through your work on R. As you all know many users of commercial stat packages, their managers, directors, CIOs etc. are skeptical of R's quality/accuracy. And as the recent NY Times article demonstrated, the commercial vendors rarely miss an opportunity stoke those fears. I have read many r-help posts on this subject so I was aware that R was developed and tested with great care, but until I read the clinical trials doc, I was not aware that they were as many steps and that they were as rigorous (use of version management software, etc.) Even as I read the document, the opening paragraphs made me think it was far too focused to be of general use. Luckily, I kept reading through the CFRs. Modifying that doc would take little effort as I outlined in my original post (below). Putting it in easy reach of every R user is important. By adding that to the docs in R's Help menu, and adding a FAQ entry for it, all R users will have ready access to it. My second suggestion is adding an option to the R installation that would let every R user run the test suite, very clearly showing them that it is being done. I realize this is a superfluous step, since you have already run the test suite against R before releasing it. However, it would provide user assurance that they could easily demonstrate to skeptics that very thorough testing is being done. I don't know whether written messages that I suggested below would be best, or simply showing the output scrolling by would have the most impact. Perhaps both, as in a message "Testing accuracy of linear regression..." in a message window while the output scrolled by in the console. Rather than having this as a part of installation, an alternative would be to end the installation with a message pointing people to a function like validate.R() and an equivalent menu selection as a following step. That would ensure that everyone knows the option exists, plus it enables any R user to run the tests for skeptics at any time. The easier it is to run the test suite the better. The complete set of validation programs you use may be huge and impractical for most people to run. In that case, perhaps just a subset could be compiled, with an emphasis on testing the common statistical functions that people are likely to focus their concern upon. Asking to add a superfluous step to an installation may seem like a waste of time, and technically it is. But psychologically this testing will have a important impact that will silence many critics. Thanks for taking the time to consider it. Now that I've asked you in, I probably should at least chip in with a couple of brief notes on the issue: - not everything can be validated, and it's not like the commercial companies are validating everything. E.g. nonlinear regression code will give different results on different architectures, or even different compilers on the same architecture, and may converge on one and not on another. - end-user validation is in principle a good thing, but please notice that what we currently do is part of a build from sources, and requires that build tools are installed. (E.g., we don't just run things, we also compare them to known outputs.) It's not entirely trivial to push these techniques to the end user. - a good reason to want post-install validation is that validity can depend on other part of the system outside developer control (e.g. an overzealous BLAS optimization, sacrificing accuracy and/or standards compliance for speed, can cause trouble). This is also a reason for not making too far-reaching statements about validity. - I'm not too happy about maintaining the same information in multiple places. One thing we learned from the FDA document is how easily factual errors creep in and how silly we'd look if, say, the location of a key server got stated incorrectly, or say that we release one patch version when in fact the most recent one had two. This kind of authoritative document itself needs a verification process to ensure that it is correct. Best, -pd Best regards, Bob -Original Message- From: Peter Dalgaard [mailto:p.dalga...@biostat.ku.dk] Sent: Saturday, January 24, 2009 4:53 AM To: Muenchen, Robert A (Bob) Cc: r-h...@r-project.org Subject: Re: [R] The Quality & Accuracy of R Bob, Your point is well taken, but it also raises a number of issues (post-install testing to name one) for which the R-devel list would be more suitable. Could we move the discussion there? -Peter Muenchen, Robert A (Bob) wrote: Hi All, We have all had to face skeptical colleagues asking if software made by volunteers could match the quality and accuracy of commercially written software. Thanks to the prompting of a recent R-help thread
Re: [Rd] Defining an iterator
Stavros Macrakis writes:
> Inspired by Rudolf Biczok's query of Fri, Jan 23, 2009 at 1:25 AM, I
> tried to implement iteration in a generic way using S4. (Though I am
> admittedly still struggling with learning S4.)
>
>> setClass("foo",representation(bar="list"))
> [1] "foo"
>> x<-new("foo",bar=list(1,2,3))
As an idea...
It seems like iteration (might) imply that the class to be iterated
over has methods for determining its length, and for subsetting. So...
setClass("Class",
representation=representation(slt="numeric"))
## basic methods: construction, slot access, show
Class <- function(slt, ...) {
new("Class", slt=slt, ...)
}
slt <- function(x, ...) slot(x, "slt")
setMethod(show, "Class", function(object) {
cat("class:", class(object), " length:", length(object), "\n")
cat("slt:", slt(object), "\n")
})
## an 'iterator' interface
setMethod(length, "Class", function(x) {
length(slot(x, "slt"))
})
setMethod("[", c("Class", "ANY", "missing"),
function(x, i, j, ..., drop=TRUE)
{
new("Class", x, slt=slt(x)[i])
})
setMethod("[[", c("Class", "ANY", "missing"),
function(x, i, j, ..., drop=TRUE)
{
slt(x)[[i]]
})
I'd then want a generic function whose responsibility it is to return
an iterator
setGeneric("iterator",
function(x, ...) standardGeneric("iterator"))
and an implementation for my class
setMethod(iterator, "Class", function(x, ...) {
seq_len(length(x))
})
I'd then use it as
> x <- Class(1:5)
> for (i in iterator(x)) print(x[[i]])
[1] 1
[1] 2
[1] 3
[1] 4
[1] 5
One could kludge a cleaner syntax by having Class contain an integer
vector whose length was kept in synch with the length of the instance.
Alternative strategies might have the 'iterator' function return a
list of objects of a class that 'knows' about x and where in the
iteration it is, with a syntax like
for (it in iterator(x)) print(it(x))
or to define 'iterator' to return an object that knows how to find the
next iterator
it = iterator(x)
while (!done(it)) {
print(it(x))
it = next(it)
}
Both of these imply that 'it' is a class, and that potentially many of
these objects are to be created; the efficiency of the S4 system would
not encourage this approach. They might also imply copying of x,
leading to both performance issues and problems about what the value
of x is supposed to be if modified during an iteration.
Martin
> Given this, I would not expect for(i in x)... to work, since R has no
> way of knowing that x...@bar should be used as is. What would it do if
> the representation included two lists? What if list(1,2,3) is used by
> the class foo to represent something else?
>
> But I did hope that I could put in place some definitions so that the
> *class* could define an iterator.
>
> First I tried overloading `for` to allow the definition of iterator
> classes, but as a primitive function, `for` cannot be overloaded.
>
> Then I tried to see how the Containers package handles iterators:
>
>> library(Containers);.jinit();.jpackage("Containers")
>> ah = MaxHeap(); ah$insert(3)
>> for (i in ah) print(i)
> [1] NA
>> as.list(ah)
> [[1]]
> [1] NA
>
> Bit it appears that the Containers package's Iterators don't interface
> with R's `for` or type conversion system.
>
> So I gave up on iterators, but thought I'd try automatic conversion to lists.
>
> So I defined an automatic conversion from foo to list, since `for`'s
> seq argument is specified as "An expression evaluating to a vector
> (including a list...)":
>
> setAs("foo","list",function(from)f...@bar)
>
> This and various variants (using "numeric" or "vector" instead of
> "list") all give errors. Is there perhaps some 'sequence' superclass
> that I am ignorant of?
>
> I *was* able to overload lapply:
>
>> setMethod("lapply","foo",function(X,FUN,...) lapply(x...@bar,FUN,...))
>> lapply(x,dput); NULL
> 1
> 2
> 3
> NULL
>
> but of course that doesn't affect `for` and other places that expect
> sequences.
>
> Is there in fact some generic way to handle define iterators or
> abstract sequences in R?
>
> -s
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Martin Morgan
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109
Location: Arnold Building M2 B169
Phone: (206) 667-2793
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Defining an iterator
On Sun, 25 Jan 2009, John Chambers wrote:
It's unclear from your mail what you actually tried to do, but here are
a few comments that may be relevant.
The syntactic form for() is indeed implemented as a primitive
function. Some primitives can and are used as generic functions, but
`for` is not currently one of them.
> setGeneric("for")
Error in genericForPrimitive(f) :
methods may not be defined for primitive function "for" in this
version of R
Allowing methods for it would be possible in a future version. This
would be a little odd, since the syntax does not look like a function
call. Still, it's an interesting idea, and I don't know of anything
offhand to prevent its implementation.
I would VERY STRONGLY prefer NOT to go down this road as it would
significantly complicate code analysis and compilation at no great
benefit I can see. Allowing the current for() code to accept an
iterator object of some sort is reasonable and would not create any
issues. Figuring out what such an iterator should be is a little
harder and depends in part on whether we would want to support things
more general than vector-like objects, such infinite and mutable
collections.
luke
The natural interpretation would
be for the signature of the generic to be the second argument
(primitives don't intrinsically have argument names, so we would make
one up, `seq` is used in the documentation, although something like
`object` would be more suggestive).
Your comments about coercing are unclear and you showed no examples of
what supposedly went wrong. In fact, that approach works fine:
> setClass("foo",representation(bar="list"))
[1] "foo"
> setAs("foo","list",function(from)f...@bar)
> xx = new("foo", bar = list(1,2,3))
> as(xx, "list")
[[1]]
[1] 1
[[2]]
[1] 2
[[3]]
[1] 3
> for(i in as(xx, "list")) dput(i)
1
2
3
Of course, this is not exactly defining methods for the iterator, but
would be a sensible workaround in practice.
Along the same lines, if one asks how the underlying ideas fit naturally
into R, as opposed to making R behave more like other languages, here's
my take on that. The `for` operator is defined to work on vectors of
various kinds. If a new class is supposed to be "like" a vector, then
the two natural choices are to define a method to coerce it to a vector
(as in the example above) or to make it a subclass of "vector" (or of a
specific vector class):
> setClass("baz", contains = "vector")
[1] "baz"
> yy = new("baz", list(1,2,3))
> for(i in yy) dput(i)
1
2
3
Which choice works best depends on what the "real" meaning of the class
is (there's discussion of these and other alternatives in section 9.3 of
"Software for Data Analysis").
John Chambers
Stavros Macrakis wrote:
Inspired by Rudolf Biczok's query of Fri, Jan 23, 2009 at 1:25 AM, I
tried to implement iteration in a generic way using S4. (Though I am
admittedly still struggling with learning S4.)
setClass("foo",representation(bar="list"))
[1] "foo"
x<-new("foo",bar=list(1,2,3))
Given this, I would not expect for(i in x)... to work, since R has no
way of knowing that x...@bar should be used as is. What would it do if
the representation included two lists? What if list(1,2,3) is used by
the class foo to represent something else?
But I did hope that I could put in place some definitions so that the
*class* could define an iterator.
First I tried overloading `for` to allow the definition of iterator
classes, but as a primitive function, `for` cannot be overloaded.
Then I tried to see how the Containers package handles iterators:
library(Containers);.jinit();.jpackage("Containers")
ah = MaxHeap(); ah$insert(3)
for (i in ah) print(i)
[1] NA
as.list(ah)
[[1]]
[1] NA
Bit it appears that the Containers package's Iterators don't interface
with R's `for` or type conversion system.
So I gave up on iterators, but thought I'd try automatic conversion to lists.
So I defined an automatic conversion from foo to list, since `for`'s
seq argument is specified as "An expression evaluating to a vector
(including a list...)":
setAs("foo","list",function(from)f...@bar)
This and various variants (using "numeric" or "vector" instead of
"list") all give errors. Is there perhaps some 'sequence' superclass
that I am ignorant of?
I *was* able to overload lapply:
setMethod("lapply","foo",function(X,FUN,...) lapply(x...@bar,FUN,...))
lapply(x,dput); NULL
1
2
3
NULL
but of course that doesn't affect `for` and other places that expect sequences.
Is there in fact some generic way to handle define iterators or
abstract sequences in R?
-s
__
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
--
Luke Tierney
Chair, Statistics and Actuarial Science
Ralph E. Wareham Profes
Re: [Rd] Defining an iterator
Thank you for your helpful reply, which clarified several issues for me. -s __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] loading RBlas.dll
hi Antonio,
The name's Sachin :) . I need this because im not implementing the ATLAS,
fast BLAS or anything like that. What im trying to do is to make a GPU
version of blas. I have implemented this so far but extremely inefficiently.
What i need to do is to do things like initialisation of the GPU hardware as
soon as Rblas.dll gets loaded.
Whats happening so far is something like this:
GPU_DGEMM (arguments)}/*this is a blas function*/
initialise_GPU;
/*rest of code*/
return;
}
sorry for not being clear
sachin
Antonio, Fabio Di Narzo wrote:
>
> hi, whoever you are (I've seen no signature),
>
> 2009/1/22 sachin1234 :
>>
>> hi everyone,
>>
>> Im implementing a new RBlas dll but just for optimising sake i need to
>> know
>> how and WHERE (which source code) RBlas gets loaded. there is a call to
>> loadlibrary() in dynload.c BUT it seems this is not the function that is
>> loading Rblas.
>
> Why do you need this? The R-admin manual explains how to replace the R
> built-in version of Blas with a custom, optimized one. Is this what
> are you looking for? One of the methods mentioned here doesn't even
> require re-compilation of R.
>
> Bests,
> f.
>
>>
>> how do i know this? well i added the code :(just after the loadlibrary()
>> call)
>>/*/
>>/*this section writes into files which libraries were loaded*/
>>file=fopen("libraries.txt","a");
>>fputs(path,file);
>>fputs("\n",file);
>>fclose(file);
>>/**/
>> so that it prints out the path names of which ever libraries are loaded
>> and
>> the output is:
>> C:/DOCUME~1/abe044/MYDOCU~1/PROJEC~1/GPU_BLAS/R-28~1.1/library/methods/libs/methods.dll
>> C:/DOCUME~1/abe044/MYDOCU~1/PROJEC~1/GPU_BLAS/R-28~1.1/library/grDevices/libs/grDevices.dll
>> C:/DOCUME~1/abe044/MYDOCU~1/PROJEC~1/GPU_BLAS/R-28~1.1/library/stats/libs/stats.dll
>>
>> and i think i got tools.dll to load as well. I cant find where R.dll,
>> Rblas.dll etc gets loaded. My main focus is Rblas.dll
>>
>> now heres what i expect. Whenever you open R it runs one of its script
>> files
>> which contains dyn.load and loads it. HOWEVER as far as i understand
>> dyn.load must be using dynload.c. Hence it should spit loading blas into
>> libraries.txt which it doesnt do.
>>
>> I am stumped. I've spend nearly 2 days on this. any help would be
>> appreciated
>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/loading-RBlas.dll-tp21617712p21617712.html
>> Sent from the R devel mailing list archive at Nabble.com.
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
>
>
> --
> Antonio, Fabio Di Narzo
> Ph.D. student at
> Department of Statistical Sciences
> University of Bologna, Italy
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
--
View this message in context:
http://www.nabble.com/loading-RBlas.dll-tp21617712p21646457.html
Sent from the R devel mailing list archive at Nabble.com.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Warning: closing unused connection 3
The subject is a warning that occurs with my 'oce' package in the test on r-devel-windows-ix86, i.e. http://cran.r-project.org/web/checks/check_results_oce.html I see that some other packages have this same error. I tried searching postings to this group for this warning, but found nothing. I'm pretty sure this warning message was not there a week ago. Q: is there something I should do, to track down my error, or is this an error in the testing itself? Thanks. Dan. -- View this message in context: http://www.nabble.com/Warning%3A-closing-unused-connection-3-tp21656751p21656751.html Sent from the R devel mailing list archive at Nabble.com. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
