Re: [Rd] standardization of slot access
On Tue, 26 Sep 2006, Sebastian P. Luque wrote: Thank you all for your comments, which confirm the feeling I had that 'slot' is only needed in the rare occasions Roger mentioned. Although 'slot' is an accessor function, it seems it's not quite analogous to functions or methods for accessing components of objects. I find that slot() is useful in explaining to users what is going on. I also find that used inside s/lapply that say function(x) slot(x, y) is a natural way to access contents of lists of objects. So I wouldn't conclude that it is only rarely used, and would recommend its use in explaining to students/users what is going on in new-style objects. Roger Cheers, -- Roger Bivand Economic Geography Section, Department of Economics, Norwegian School of Economics and Business Administration, Helleveien 30, N-5045 Bergen, Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43 e-mail: [EMAIL PROTECTED] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] time_t handling in R
Hello all, I am converting some C code into a package for R and wondered what the proper way of handling time_t types from C in R was. time_t is a typedef for long, but R seems to only deal in Integers or Reals, so what is the proper way of handling time in an R to C conversion ( or visa versa )? Many thanks Tom -- Thomas McCallum Systems Architect LevelE Limited Phone: 0131 - 4724813 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Warning on backslash sequences (was sprintf behavior)
On Tue, 26 Sep 2006, Bill Dunlap wrote: On Mon, 25 Sep 2006 [EMAIL PROTECTED] wrote: On Mon, 25 Sep 2006, [EMAIL PROTECTED] wrote: ... sprintf(\p) doesn't show the backslash, this occurs with all strings that start with certain letters. There is however no explanation to this behavior. There is: see ?Quotes (and C behaves in the same way). And there seems to be no way to get a guaranteed backslash in sprintf. \\, see the FAQ 7.8 for example. Splus's parser emits a warning when it sees a backslash outside of the recognized backslash sequence. E.g., nchar(\Backslashed?) [1] 12 Warning messages: The initial backslash is ignored in \B -- not a recognized escape sequence. Use \\ to make a backslash You might want to add that warning to R's parser. I've seen the error in several R packages. E.g., bayesmix/R/JAGScontrol.R: text[4] - -inits.R\\n\initialize\n SciViews/svDialogs/R/fixedDlg.wxPython.R:if (length(grep([\.], basename(res))) == 0) The warning is mostly emitted when the error is benign, but it might help get people to think about what they are typing. I am not at all sure about this. R's documentation says Backslash is used to start an escape sequence inside character constants. Unless specified in the following table, an escaped character is interpreted as the character itself. Single quotes need to be escaped by backslash in single-quoted strings, and double quotes in double-quoted strings. '\n' newline '\r' carriage return '\t' tab '\b' backspace '\a' alert (bell) '\f' form feed '\v' vertical tab '\\' backslash '\' '\nnn'character with given octal code (1, 2 or 3 digits) '\xnn'character with given hex code (1 or 2 hex digits) '\u' Unicode character with given code (1-4 hex digits) '\U' Unicode character with given code (1-8 hex digits) so it is not an error in R. People tend not to like being warned about legitimate usage (and one can see this sort of thing being intentional in machine-generated scripts: for example to escape spaces in file paths and to escape line feeds). What exactly does Splus's parser allow as intentional? -- 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] colnames is slow for data.frames with implicit row.names
colnames on a data.frame with implicit row.names df - data.frame(x=1:600) is slow system.time(colnames(df)) [1] 21.655 0.327 21.987 0.000 0.000 system.time(names(df)) [1] 0 0 0 0 0 because colnames calls dimnames calls row.names.data.frame calls as.character on the implicit row.names. -- Martin T. Morgan Bioconductor / Computational Biology http://bioconductor.org __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] colnames is slow for data.frames with implicit row.names
On Wed, 27 Sep 2006, Martin Morgan wrote: colnames on a data.frame with implicit row.names df - data.frame(x=1:600) is slow system.time(colnames(df)) [1] 21.655 0.327 21.987 0.000 0.000 system.time(names(df)) [1] 0 0 0 0 0 because colnames calls dimnames calls row.names.data.frame calls as.character on the implicit row.names. So use names() and not colnames(): rownames and colnames for matrices row.names and names for data frames. All colnames assumes is that there is a dimnames method: this could be relevant for objects inheriting from data.frame, but there is a price for generality. -- 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] colnames is slow for data.frames with implicit row.names
Yes, obviously, with hindsight. In lieu of code change, the colnames documentation could indicate the restricted sense of 'equivalent'. For a data frame, 'rownames' and 'colnames' are equivalent to 'row.names' and 'names' respectively. It might help to add 'names' to See Also of ?data.frame. Martin Prof Brian Ripley [EMAIL PROTECTED] writes: On Wed, 27 Sep 2006, Martin Morgan wrote: colnames on a data.frame with implicit row.names df - data.frame(x=1:600) is slow system.time(colnames(df)) [1] 21.655 0.327 21.987 0.000 0.000 system.time(names(df)) [1] 0 0 0 0 0 because colnames calls dimnames calls row.names.data.frame calls as.character on the implicit row.names. So use names() and not colnames(): rownames and colnames for matrices row.names and names for data frames. All colnames assumes is that there is a dimnames method: this could be relevant for objects inheriting from data.frame, but there is a price for generality. -- 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 -- Martin T. Morgan Bioconductor / Computational Biology http://bioconductor.org __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] time_t handling in R
On Wed, 27 Sep 2006, Tom McCallum wrote: Hello all, I am converting some C code into a package for R and wondered what the proper way of handling time_t types from C in R was. time_t is a typedef for long, but R seems to only deal in Integers or Reals, so what is the proper way of handling time in an R to C conversion ( or visa versa )? time_t is not portably a typedef for long, or even for an integer type (according to the C standard). If it is an integer type on your system then you can pass it as a vector of integer (and on many systems long and int are the same so one integer will suffice) -thomas __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] S4 accessors
There is a point that needs to be remembered in discussions of accessor
functions (and more generally).
We're working with a class/method mechanism in a _functional_ language.
Simple analogies made from class-based languages such as Java are not
always good guides.
In the example below, a function foo that only operates on that class
is not usually a meaningful concept in R. Whereas in Java a method can
only be invoked on an object, given the syntax of the Java language, R
(that is, the S language) is different. You can intend a function to be
used only on one class, but that isn't normally the way to think about R
software.
Functions are first-class objects and in principle every function should
have a function, a purpose. Methods implement that purpose for
particular combinations of arguments.
Accessor functions are therefore a bit anomalous. If they had a
standard syntactic pattern, say get_foo(object), then it would be more
reasonable to think that you're just defining a method for that function
for a given class that happens to have a slot with the particular name,
foo.
Also, slot-setting functions will be different in R because we deal with
objects, not object references as in Java. An R-like naming convention
would be something along the lines of
set_foo(object) - value
but in any case one will need to use replacement functions to conform to
the way assignments work.
Ross Boylan wrote:
On Tue, 2006-09-26 at 10:43 -0700, Seth Falcon wrote:
Ross Boylan [EMAIL PROTECTED] writes:
If anyone else is going to extend your classes, then you are doing
them a disservice by not making these proper methods. It means that
you can control what happens when they are called on a subclass.
My style has been to define a function, and then use setMethod if I want
to redefine it for an extension. That way the original version becomes
the generic.
So I don't see what I'm doing as being a barrier to adding methods. Am
I missing something?
You are not, but someone else might be: suppose you release your code
and I would like to extend it. I am stuck until you decide to make
generics.
This may be easier to do concretely.
I have an S4 class A.
I have defined a function foo that only operates on that class.
You make a class B that extends A.
You wish to give foo a different implementation for B.
Does anything prevent you from doing
setMethod(foo, B, function(x) blah blah)
(which is the same thing I do when I make a subclass)?
This turns my original foo into the catchall method.
Of course, foo is not appropriate for random objects, but that was true
even when it was a regular function.
Originally I tried defining the original using setMethod, but this
generates a complaint about a missing function; that's one reason I fell
into this style.
You have to create the generic first if it doesn't already exist:
setGeneric(foo, function(x) standardGeneric(foo))
I wonder if it might be worth changing setMethod so that it does this by
default when no existing function exists. Personally, that would fit the
style I'm using better.
For accessors, I like to document them in the methods section of the
class documentation.
This is for accessors that really are methods, not my fake
function-based accessors, right?
Which might be a further argument not to have the distinction in the
first place ;-)
To me, simple accessors are best documented with the class. If I have
an instance, I will read help on it and find out what I can do with
it.
If you use foo as an accessor method, where do you define the associated
function (i.e., \alias{foo})? I believe such a definition is expected by
R CMD check and is desirable for users looking for help on foo (?foo)
without paying attention to the fact it's a method.
Yes you need an alias for the _generic_ function. You can either add
the alias to the class man page where one of its methods is documented
or you can have separate man pages for the generics. This is
painful. S4 documentation, in general, is rather difficult and IMO
this is in part a consequence of the more general (read more powerful)
generic function based system.
As my message indicates, I too am struggling with an appropriate
documentation style for S4 classes and methods. Since Writing R
Extensions has said Structure of and special markup for documenting S4
classes and methods are still under development. for as long as I cam
remember, perhaps I'm not the only one.
Some of the problem may reflect the tension between conventional OO and
functional languages, since R remains the latter even under S4. I'm not
sure if it's the tools or my approach that is making things awkward; it
could be both!
Ross
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Building R-2.3.1 for Windows with ATLAS
Ok, moved to R-devel. I tried to build R-2.3.1. Since I intent to distribute this tuned R to all other who have a computer like mine here at work I thought it was best to stay with the latest stable release. About your suggestion, I could'n find xerblas.o file. And I don't know how to edit libf77blas.a. I tried to open it with VIM (http://vim.sf.net/) but there was a lot of strange symbols (expected, I think), either way I found a reference to xerblas.o inside it but didn't know what to do with this reference. Thanks, Giuseppe Antonaci On 26/09/06, Prof Brian Ripley [EMAIL PROTECTED] wrote: On Tue, 26 Sep 2006, Giuseppe Antonaci wrote: I think this is not a R-devel question. Sorry to all if I'm wrong, please let me know. In what sense is this not a programming question? I managed to build R successfully with the default BLAS but when I change the MKRULES to use ATLAS BLAS and set the path to C:/cygwin/home/Administrador/ATLAS/lib/WinNT_ATHLONSSE2 I got the following error message (I'm posting only the final part, there was a lot of compilation before this): cp R.dll ../../bin/ Building ../../bin/Rblas.dll gcc -shared -s -o ../../bin/Rblas.dll blas00.o dllversion.o Rblas.def \ -L../../bin -lR -LC:/WinNT_ATHLONSSE2 -lf77blas -latlas What version of R is this? I get Building ../../../bin/Rblas.dll gcc -shared -o ../../../bin/Rblas.dll blas00.o ../../gnuwin32/dllversion.o Rbl as.def \ -L../../../bin -lR -L/R/ATLAS/lib/WinNT_PM -lf77blas -latlas -lg2c ^ in R-2.4.0 RC. You probably should not need it: you need to build ATLAS without xerbla (R has its own), so delete xerbla.o from libf77blas.a and all should be well. -- 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 I managed to build R-2.3.1 successfully with the default BLAS but when I change the MKRULES to use ATLAS BLAS and set the path to C:/WinNT_ATHLONSSE2 I got the following error message (I'm posting only the final part, there was a lot of compilation before this): cp R.dll ../../bin/ Building ../../bin/Rblas.dll gcc -shared -s -o ../../bin/Rblas.dll blas00.o dllversion.o Rblas.def \ -L../../bin -lR -LC:/WinNT_ATHLONSSE2 -lf77blas -latlas C:/WinNT_ATHLONSSE2/libf77blas.a(xerbla.o):xerbla.f:(.text+0xb): undefined refer ence to `s_wsfe' C:/WinNT_ATHLONSSE2/libf77blas.a(xerbla.o):xerbla.f:(.text+0x27): undefined refe rence to `do_fio' C:/WinNT_ATHLONSSE2/libf77blas.a(xerbla.o):xerbla.f:(.text+0x43): undefined refe rence to `do_fio' C:/WinNT_ATHLONSSE2/libf77blas.a(xerbla.o):xerbla.f:(.text+0x48): undefined refe rence to `e_wsfe' C:/WinNT_ATHLONSSE2/libf77blas.a(xerbla.o):xerbla.f:(.text+0x5c): undefined refe rence to `s_stop' collect2: ld returned 1 exit status make[2]: *** [../../bin/Rblas.dll] Error 1 make[1]: *** [rbuild] Error 2 make: *** [all] Error 2 The ATLAS BLAS was build using Cygwin. AFTER building ATLAS BLAS I changed the Path variable putting C:\Rtools\tools\bin;C:\MinGW\bin before everything else. To build R I followed R Administration and Instalation and Duncan Murdoch's guide at http://www.murdoch-sutherland.com/Rtools/, including the version of MinGW. At ATLAS web page (http://math-atlas.sourceforge.net/errata.html) I found the following: Q: I'm linking with C, and getting missing symbols (such as w_wsfe, do_fio, w_esfe or s_stop). R: These kinds of symbols are Fortran library calls. The problem is that the C linker does not automatically find the Fortran libraries. The most common fix is to either link using your fortran linker, or to rewrite your code so that Fortran routines are not called. If you know where they are, you can also choose to link in the Fortran libraries explicitly Well, I think this answers my question but I didn't understand the answer (and it was not because it is in English). Unfortunately I know nothing of C or Fortran. Even if I knew that I have these Fortran libraries I wouldn't know how to link them. I tried to look at MinGW web page but found nothing. Any help would be mostly welcome, please. Giuseppe Antonaci __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Building R-2.3.1 for Windows with ATLAS
On Wed, 27 Sep 2006, Giuseppe Antonaci wrote: Ok, moved to R-devel. I tried to build R-2.3.1. Since I intent to distribute this tuned R to all other who have a computer like mine here at work I thought it was best to stay with the latest stable release. Which is 2.4.0 RC. About your suggestion, I could'n find xerblas.o file. And I don't know how to edit libf77blas.a. I tried to open it with VIM (http://vim.sf.net/) but there was a lot of strange symbols (expected, I think), either way I found a reference to xerblas.o inside it but didn't know what to do with this reference. Well, I said xerbla.o, not xerblas.o. You edit library archives with ar, something like ar d libf77blas.a xerbla.o Thanks, Giuseppe Antonaci On 26/09/06, Prof Brian Ripley [EMAIL PROTECTED] wrote: On Tue, 26 Sep 2006, Giuseppe Antonaci wrote: I think this is not a R-devel question. Sorry to all if I'm wrong, please let me know. In what sense is this not a programming question? I managed to build R successfully with the default BLAS but when I change the MKRULES to use ATLAS BLAS and set the path to C:/cygwin/home/Administrador/ATLAS/lib/WinNT_ATHLONSSE2 I got the following error message (I'm posting only the final part, there was a lot of compilation before this): cp R.dll ../../bin/ Building ../../bin/Rblas.dll gcc -shared -s -o ../../bin/Rblas.dll blas00.o dllversion.o Rblas.def \ -L../../bin -lR -LC:/WinNT_ATHLONSSE2 -lf77blas -latlas What version of R is this? I get Building ../../../bin/Rblas.dll gcc -shared -o ../../../bin/Rblas.dll blas00.o ../../gnuwin32/dllversion.o Rbl as.def \ -L../../../bin -lR -L/R/ATLAS/lib/WinNT_PM -lf77blas -latlas -lg2c ^ in R-2.4.0 RC. You probably should not need it: you need to build ATLAS without xerbla (R has its own), so delete xerbla.o from libf77blas.a and all should be well. -- 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 I managed to build R-2.3.1 successfully with the default BLAS but when I change the MKRULES to use ATLAS BLAS and set the path to C:/WinNT_ATHLONSSE2 I got the following error message (I'm posting only the final part, there was a lot of compilation before this): cp R.dll ../../bin/ Building ../../bin/Rblas.dll gcc -shared -s -o ../../bin/Rblas.dll blas00.o dllversion.o Rblas.def \ -L../../bin -lR -LC:/WinNT_ATHLONSSE2 -lf77blas -latlas C:/WinNT_ATHLONSSE2/libf77blas.a(xerbla.o):xerbla.f:(.text+0xb): undefined refer ence to `s_wsfe' C:/WinNT_ATHLONSSE2/libf77blas.a(xerbla.o):xerbla.f:(.text+0x27): undefined refe rence to `do_fio' C:/WinNT_ATHLONSSE2/libf77blas.a(xerbla.o):xerbla.f:(.text+0x43): undefined refe rence to `do_fio' C:/WinNT_ATHLONSSE2/libf77blas.a(xerbla.o):xerbla.f:(.text+0x48): undefined refe rence to `e_wsfe' C:/WinNT_ATHLONSSE2/libf77blas.a(xerbla.o):xerbla.f:(.text+0x5c): undefined refe rence to `s_stop' collect2: ld returned 1 exit status make[2]: *** [../../bin/Rblas.dll] Error 1 make[1]: *** [rbuild] Error 2 make: *** [all] Error 2 The ATLAS BLAS was build using Cygwin. AFTER building ATLAS BLAS I changed the Path variable putting C:\Rtools\tools\bin;C:\MinGW\bin before everything else. To build R I followed R Administration and Instalation and Duncan Murdoch's guide at http://www.murdoch-sutherland.com/Rtools/, including the version of MinGW. At ATLAS web page (http://math-atlas.sourceforge.net/errata.html) I found the following: Q: I'm linking with C, and getting missing symbols (such as w_wsfe, do_fio, w_esfe or s_stop). R: These kinds of symbols are Fortran library calls. The problem is that the C linker does not automatically find the Fortran libraries. The most common fix is to either link using your fortran linker, or to rewrite your code so that Fortran routines are not called. If you know where they are, you can also choose to link in the Fortran libraries explicitly Well, I think this answers my question but I didn't understand the answer (and it was not because it is in English). Unfortunately I know nothing of C or Fortran. Even if I knew that I have these Fortran libraries I wouldn't know how to link them. I tried to look at MinGW web page but found nothing. Any help would be mostly welcome, please. Giuseppe Antonaci -- 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
Re: [Rd] S4 accessors
John Chambers [EMAIL PROTECTED] writes: There is a point that needs to be remembered in discussions of accessor functions (and more generally). We're working with a class/method mechanism in a _functional_ language. Simple analogies made from class-based languages such as Java are not always good guides. In the example below, a function foo that only operates on that class is not usually a meaningful concept in R. If foo is a generic and the only method defined is for class Bar, then the statement seems meaningful enough? Functions are first-class objects and in principle every function should have a function, a purpose. Methods implement that purpose for particular combinations of arguments. Accessor functions are therefore a bit anomalous. How? A given accessor function has the purpose of returning the expected data contained in an instance. It provides an abstract interface that decouples the structure of the class from the data it needs to provide to users. The anomaly, is IMO, a much larger challenge with generic function based systems. When the same name for a generic is used in different packages, you end up with a masking problem. This scenario is unavoidable in general, but particularly likely, for accessors. As S4 becomes more prevalent, I suspect that 'pkg::foo' is going to become a required idiom for interactive use (other options are available for package code). + seth __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] S4 accessors
Seth Falcon wrote: John Chambers [EMAIL PROTECTED] writes: There is a point that needs to be remembered in discussions of accessor functions (and more generally). We're working with a class/method mechanism in a _functional_ language. Simple analogies made from class-based languages such as Java are not always good guides. In the example below, a function foo that only operates on that class is not usually a meaningful concept in R. If foo is a generic and the only method defined is for class Bar, then the statement seems meaningful enough? This is not primarily a question about implementation but about what the user understands. IMO, a function should have an intuitive meaning to the user. Its name is taking up a global place in the user's brain, and good software design says not to overload users with too many arbitrary names to remember. To be a bit facetious, if flag is a slot in class Bar, it's really not a good idea to define the accessor for that slot as flag - function(object)[EMAIL PROTECTED] Nor is the situation much improved by having flag() be a generic, with the only method being for class Bar. We're absconding with a word that users might think has a general meaning. OK, if need be we will have different flag() functions in different packages that have _different_ intuitive interpretations, but it seems to me that we should try to avoid that problem when we can. OTOH, it's not such an imposition to have accessor functions with a syntax that includes the name of the slot in a standardized way: get_flag(object) (I don't have any special attachment to this convention, it's just there for an example) Functions are first-class objects and in principle every function should have a function, a purpose. Methods implement that purpose for particular combinations of arguments. Accessor functions are therefore a bit anomalous. How? A given accessor function has the purpose of returning the expected data contained in an instance. It provides an abstract interface that decouples the structure of the class from the data it needs to provide to users. See above. That's true _if_ the name or some other syntactic sugar makes it clear the this is indeed an accessor function, but not otherwise. The anomaly, is IMO, a much larger challenge with generic function based systems. When the same name for a generic is used in different packages, you end up with a masking problem. This scenario is unavoidable in general, but particularly likely, for accessors. As S4 becomes more prevalent, I suspect that 'pkg::foo' is going to become a required idiom for interactive use (other options are available for package code). I agree that we must handle such ambiguities, but I doubt that many people will be able to reliably use that syntax interactively. A more plausible prospect is for the user interface to offer the option to disambiguate the name, as opposed to using the current greedy search for the name. Also, a variant of the with() notion might be helpful, so a whole expression could be bound to a particular package. But notice that the problem only arises when different packages have _different_ meanings for the same generic. Having a syntactic convention for accessors means in effect that an accessor for a slot of a particular name is conceptually one generic, no matter how many packages use it. This would not come free; my guess is we need an explicit mechanism for creating accessor methods, including a syntactic convention. For one thing, R will move more and more to functions, classes and methods with the corresponding package as part of the identification. That means that to regard accessors of one slot name for more than one package as methods for one generic, that generic must NOT belong to each individual package. I've experimented a bit with explicit accessor functions on a couple of occasions; if there's enough interest, we could start a discussion, perhaps in a separate list, of ways to go. + seth __ 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
[Rd] S3 methods for cbind/rbind
I created a type of object similar to a data frame. In some circumstances, It needs special methods for [ and [- and rbind() (but not cbind()). Then I found this in the cbind()/rbind() man page: The method dispatching is _not_ done via 'UseMethod()', but by C-internal dispatching. Therefore, there is no need for, e.g., 'rbind.default'. This seems to imply I cannot add my own method. Is there 1) a workaround to and 2) a rationale for this? (Other than creating a generic Rbind() or whatever, that is.) I'm using S3 methods. Thanks in advance! -- Vincent Goulet, Associate Professor École d'actuariat Université Laval, Québec [EMAIL PROTECTED] http://vgoulet.act.ulaval.ca __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] S3 methods for cbind/rbind
Hum. Then, I need to be more accurate. My object is of class
c(bar, data.frame). So, by virtue of ...
The dispatch algorithm is described in the source file
('.../src/main/bind.c') as
1. For each argument we get the list of possible class
memberships from the class attribute.
2. We inspect each class in turn to see if there is an an
applicable method.
... rbind(foo) is never sent to rbind.bar(). So I guess my questions stand.
Le Mercredi 27 Septembre 2006 16:16, Gabor Grothendieck a écrit :
Actually you can add your own method. See
library(zoo)
rbind.zoo
for an example.
On 9/27/06, Vincent Goulet [EMAIL PROTECTED] wrote:
I created a type of object similar to a data frame. In some
circumstances, It needs special methods for [ and [- and rbind()
(but not cbind()). Then I found this in the cbind()/rbind() man page:
The method dispatching is _not_ done via 'UseMethod()', but by
C-internal dispatching. Therefore, there is no need for, e.g.,
'rbind.default'.
This seems to imply I cannot add my own method. Is there 1) a workaround
to and 2) a rationale for this? (Other than creating a generic Rbind() or
whatever, that is.)
I'm using S3 methods.
Thanks in advance!
--
Vincent Goulet, Associate Professor
École d'actuariat
Université Laval, Québec
[EMAIL PROTECTED] http://vgoulet.act.ulaval.ca
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Vincent Goulet, Associate Professor
École d'actuariat
Université Laval, Québec
[EMAIL PROTECTED] http://vgoulet.act.ulaval.ca
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] S3 methods for cbind/rbind
Actually you can add your own method. See library(zoo) rbind.zoo for an example. On 9/27/06, Vincent Goulet [EMAIL PROTECTED] wrote: I created a type of object similar to a data frame. In some circumstances, It needs special methods for [ and [- and rbind() (but not cbind()). Then I found this in the cbind()/rbind() man page: The method dispatching is _not_ done via 'UseMethod()', but by C-internal dispatching. Therefore, there is no need for, e.g., 'rbind.default'. This seems to imply I cannot add my own method. Is there 1) a workaround to and 2) a rationale for this? (Other than creating a generic Rbind() or whatever, that is.) I'm using S3 methods. Thanks in advance! -- Vincent Goulet, Associate Professor École d'actuariat Université Laval, Québec [EMAIL PROTECTED] http://vgoulet.act.ulaval.ca __ 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] S3 methods for cbind/rbind
Maybe you could use rbind2, which has an S4 generic in the methods
package, instead?
# BOD is a data frame built into R
foo - structure(BOD, class = c(bar, data.frame))
setOldClass(bar)
setMethod(rbind2, signature(x = bar, y = bar),
function(x, y) {
cat(Hello!\n)
class(x) - class(y) - data.frame
rbind(x, y)
})
# test
foo - structure(BOD, class = c(bar, data.frame))
rbind2(foo, foo)
On 9/27/06, Vincent Goulet [EMAIL PROTECTED] wrote:
Hum. Then, I need to be more accurate. My object is of class
c(bar, data.frame). So, by virtue of ...
The dispatch algorithm is described in the source file
('.../src/main/bind.c') as
1. For each argument we get the list of possible class
memberships from the class attribute.
2. We inspect each class in turn to see if there is an an
applicable method.
... rbind(foo) is never sent to rbind.bar(). So I guess my questions stand.
Le Mercredi 27 Septembre 2006 16:16, Gabor Grothendieck a écrit:
Actually you can add your own method. See
library(zoo)
rbind.zoo
for an example.
On 9/27/06, Vincent Goulet [EMAIL PROTECTED] wrote:
I created a type of object similar to a data frame. In some
circumstances, It needs special methods for [ and [- and rbind()
(but not cbind()). Then I found this in the cbind()/rbind() man page:
The method dispatching is _not_ done via 'UseMethod()', but by
C-internal dispatching. Therefore, there is no need for, e.g.,
'rbind.default'.
This seems to imply I cannot add my own method. Is there 1) a workaround
to and 2) a rationale for this? (Other than creating a generic Rbind() or
whatever, that is.)
I'm using S3 methods.
Thanks in advance!
--
Vincent Goulet, Associate Professor
École d'actuariat
Université Laval, Québec
[EMAIL PROTECTED] http://vgoulet.act.ulaval.ca
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Vincent Goulet, Associate Professor
École d'actuariat
Université Laval, Québec
[EMAIL PROTECTED] http://vgoulet.act.ulaval.ca
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] S4 accessors
On 9/27/06, John Chambers [EMAIL PROTECTED] wrote: There is a point that needs to be remembered in discussions of accessor functions (and more generally). We're working with a class/method mechanism in a _functional_ language. Simple analogies made from class-based languages such as Java are not always good guides. In the example below, a function foo that only operates on that class is not usually a meaningful concept in R. Whereas in Java a method can only be invoked on an object, given the syntax of the Java language, R (that is, the S language) is different. You can intend a function to be used only on one class, but that isn't normally the way to think about R software. Functions are first-class objects and in principle every function should have a function, a purpose. Methods implement that purpose for particular combinations of arguments. Accessor functions are therefore a bit anomalous. If they had a standard syntactic pattern, say get_foo(object), then it would be more reasonable to think that you're just defining a method for that function for a given class that happens to have a slot with the particular name, foo. Also, slot-setting functions will be different in R because we deal with objects, not object references as in Java. An R-like naming convention would be something along the lines of set_foo(object) - value but in any case one will need to use replacement functions to conform to the way assignments work. In the Object class system of the R.oo package I have for years worked successfully with what I call virtual fields. I find them really useful and convenient to work with. These works as follows, if there is a getField(object) function, this is called whenever object$field is called. If there is no such function, the internal field 'field' is access (from the environment where all fields live in). Similarily, object$field - value check for setField(object, value), which is called if available. [I work with environments/references so my set functions don't really have to be replacement functions, but there is nothing preventing them from being such.] There are several advantages doing it this way. You can protect fields behind a set function, e.g. preventing assignment of negative values and similar, e.g. circle$radius - -5 Error: Negative radius: -5 You can also provide redundant fields in your API, e.g. circle$radius - 5 print(circle$diameter) circle$area - 4 print(circle$radius) and so on. How the circle is represented internally does not matter and may change over time. With such a design you don't have to worry as a software developer; the API is stable. I think this schema carries over perfectly to S4 and '@'. FYI: I used the above naming convention because I did this way before the '_' operator was redefined. Comment: If you don't want the user to access a slot/field directly, I recommend to name the slot with a period prefix, e.g. '.radius'. This gives at least the user the chance to understand your design although it does not prevent them to misuse it. The period prefix is also standard for private object, cf. ls(all.names=FALSE/TRUE). /Henrik Ross Boylan wrote: On Tue, 2006-09-26 at 10:43 -0700, Seth Falcon wrote: Ross Boylan [EMAIL PROTECTED] writes: If anyone else is going to extend your classes, then you are doing them a disservice by not making these proper methods. It means that you can control what happens when they are called on a subclass. My style has been to define a function, and then use setMethod if I want to redefine it for an extension. That way the original version becomes the generic. So I don't see what I'm doing as being a barrier to adding methods. Am I missing something? You are not, but someone else might be: suppose you release your code and I would like to extend it. I am stuck until you decide to make generics. This may be easier to do concretely. I have an S4 class A. I have defined a function foo that only operates on that class. You make a class B that extends A. You wish to give foo a different implementation for B. Does anything prevent you from doing setMethod(foo, B, function(x) blah blah) (which is the same thing I do when I make a subclass)? This turns my original foo into the catchall method. Of course, foo is not appropriate for random objects, but that was true even when it was a regular function. Originally I tried defining the original using setMethod, but this generates a complaint about a missing function; that's one reason I fell into this style. You have to create the generic first if it doesn't already exist: setGeneric(foo, function(x) standardGeneric(foo)) I wonder if it might be worth changing setMethod so that it does this by default when no existing function exists. Personally, that would fit the style I'm using better. For accessors, I like to document
Re: [Rd] S4 accessors
I'm trying to understand what the underlying issues are here--with the immediate goal of how that affects my design and documentation decisions. On Wed, Sep 27, 2006 at 02:08:34PM -0400, John Chambers wrote: Seth Falcon wrote: John Chambers [EMAIL PROTECTED] writes: There is a point that needs to be remembered in discussions of accessor functions (and more generally). We're working with a class/method mechanism in a _functional_ language. Simple analogies made from class-based languages such as Java are not always good guides. In the example below, a function foo that only operates on that class is not usually a meaningful concept in R. The sense of meaningful here is hard for me to pin down, even with the subsequent discussion. I think the import is more than formal: R is not strongly typed, so you can hand any argument to any function and the language will not complain. If foo is a generic and the only method defined is for class Bar, then the statement seems meaningful enough? This is not primarily a question about implementation but about what the user understands. IMO, a function should have an intuitive meaning to the user. Its name is taking up a global place in the user's brain, and good software design says not to overload users with too many arbitrary names to remember. It's true that clashing uses of the same name may lead to confusion, but that need not imply that functions must be applicable to all objects. Many functions only make sense in particular contexts, and sometimes those contexts are quite narrow. One of the usual motivations for an OO approach is precisely to limit the amount of global space taken up by, for example, functions that operate on the class (global in both the syntactic sense and in the inside your brain sense). Understanding a traditional OO system, at least for me, is fundamentally oriented to understanding the objects first, with the operations on them as auxiliaries. As you point out, this is just different from the orientation of a functional language, which starts with the functions. To be a bit facetious, if flag is a slot in class Bar, it's really not a good idea to define the accessor for that slot as flag - function(object)[EMAIL PROTECTED] Nor is the situation much improved by having flag() be a generic, with the only method being for class Bar. We're absconding with a word that users might think has a general meaning. OK, if need be we will have different flag() functions in different packages that have _different_ intuitive interpretations, but it seems to me that we should try to avoid that problem when we can. OTOH, it's not such an imposition to have accessor functions with a syntax that includes the name of the slot in a standardized way: get_flag(object) (I don't have any special attachment to this convention, it's just there for an example) I don't see why get_flag differs from flag; if flag lends itself to multiple interpretations or meanings, wouldn't get_flag have the same problem? Or are you referring to the fact that flag sounds as if it's a verb or action? That's a significant ambiguity, but there's nothing about it that is specific to a functional approach. Functions are first-class objects and in principle every function should have a function, a purpose. Methods implement that purpose for particular combinations of arguments. If this is a claim that every function should make sense for every object, it's asking too much. If it's not, I don't really see how a function can avoid having a purpose. The purpose of accessor functions is to get or set the state of the object. Accessor functions are therefore a bit anomalous. How? A given accessor function has the purpose of returning the expected data contained in an instance. It provides an abstract interface that decouples the structure of the class from the data it needs to provide to users. See above. That's true _if_ the name or some other syntactic sugar makes it clear the this is indeed an accessor function, but not otherwise. Aside from the fact that I don't see why get_flag is so different from flag, the syntactic sugar argument has another problem. The usually conceived purpose of accessors is to hide from the client the internals of the object. To take an example that's pretty close to one of my classes, I want startTime, endTime, and duration. Internally, the object only needs to hold 2 of these quantities to get the 3rd, but I don't want the client code to be aware of which choice I made. In particular, I don't what the client code to change from duration to get_duration if I switch to a representation that stored the duration as a slot. Ross __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] potential setClass bug (with user-defined environment)
the following returns an error in an 'exists' call on my machine MyEnv - new.env() setClass(Numeric, numeric, where=MyEnv) franklin parlamis version _ platform powerpc-apple-darwin8.7.0 arch powerpc os darwin8.7.0 system powerpc, darwin8.7.0 status beta major 2 minor 4.0 year 2006 month 09 day22 svn rev39471 language R version.string R version 2.4.0 beta (2006-09-22 r39471) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] 'St9bad_alloc' (PR#9261)
Full_Name: Daniel E. Platt Version: 2.3.1 OS: Win/XP - Cygwin Submission from: (NULL) (68.198.10.240) Error report: terminate called after throwing an instance of 'St9bad_alloc' what(): St9bad_alloc Aborted (core dumped) No indication of what the calling routine was, where the request came from, etc. Am I simply requesting memory where non is available? Dan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] potential setClass bug (with user-defined environment)
A previous report (no resolution) here: https://stat.ethz.ch/pipermail/r-devel/2006-August/038896.html I guess that's two of us with at least a passing encounter with this! Martin Parlamis Franklin [EMAIL PROTECTED] writes: the following returns an error in an 'exists' call on my machine MyEnv - new.env() setClass(Numeric, numeric, where=MyEnv) franklin parlamis version _ platform powerpc-apple-darwin8.7.0 arch powerpc os darwin8.7.0 system powerpc, darwin8.7.0 status beta major 2 minor 4.0 year 2006 month 09 day22 svn rev39471 language R version.string R version 2.4.0 beta (2006-09-22 r39471) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Martin T. Morgan Bioconductor / Computational Biology http://bioconductor.org __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] eval(SEXP fn,SEXP rho) in C++ code
Hi r-devel, I am working on a R extension. I am writing the function in C++, and in my function it is required a R function object from the user. This R function object will be evaluated thousand of times in my C++ code. I generated the shared library and I loaded it on R. I did several experiments in order to compare the speed of my compiled code vs the speed of the equivalent interpreted code. I was surprise!, the better was the interpreted code!. Then, I ask myself: What is the benefit of compiled code??. I think my problem is in using the function eval(SEXP f, SEXP rho) because it takes time!. Am I right?. Then, can someone tell me what the benefit of using compiled code is?, or can someone give me a reference to look into?. Thanks in advanced, Patricia B. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] eval(SEXP fn,SEXP rho) in C++ code
Patricia Bautista [EMAIL PROTECTED] writes: Hi r-devel, I am working on a R extension. I am writing the function in C++, and in my function it is required a R function object from the user. This R function object will be evaluated thousand of times in my C++ code. I generated the shared library and I loaded it on R. I did several experiments in order to compare the speed of my compiled code vs the speed of the equivalent interpreted code. I was surprise!, the better was the interpreted code!. Then, I ask myself: What is the benefit of compiled code??. I think my problem is in using the function eval(SEXP f, SEXP rho) because it takes time!. Am I right?. Then, can someone tell me what the benefit of using compiled code is?, or can someone give me a reference to look into?. If you use eval in C you are doing effectively the same thing as at the interpreter (R) level. The benefit of doing computations in C comes from making direct calls to R's C API, avoiding duplication (copy of R objects), etc. + seth __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
