[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
[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 -L"C:/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 -L"C:/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 -L"C:/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 -L"C:/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/
Re: [Rd] Warning on backslash sequences (was sprintf behavior)
> > 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
> ...
> '\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).
We had that same sort of argument here, but enough people were
asking our support people about the matter that we put in
the warning. As I said, the warning is odd in that it warns
about legitimate usage in the hopes that people will know to
use "\\" for a backslash when they need to.
> What exactly does Splus's parser allow as intentional?
Splus currently "supports" (does not warn about)
\nnn (1-3 octal digits)
\n, \t, \b, \r, \', \", and \`
We do not support the \f, \v, \xnn, \u, or \U.
We should add the \f, \v, \a, and \xnn (as well as 0xnn for integers),
but we overlooked those. (Adding new backslash sequences is relatively
safe: we have been warning about unrecognized \f's for for years so
we shouldn't expect to find too many folks using \f where they intended
either \\f or f.)
We don't support unicode so we won't do anything with the \u or
\U. That is something Splus does need to warn about to aid in
porting stuff from R.
Neither of the examples I showed cause any ill effect,
but using the grep pattern of '[\.]' shows that he
doesn't know that dots are taken literally inside of
square brackets in regular expressions and the use of
"\." outside of brackets would give incorrect results.
> > bayesmix/R/JAGScontrol.R: text[4] <- "-inits.R\"\n\initialize\n"
> > SciViews/svDialogs/R/fixedDlg.wxPython.R:if (length(grep("[\.]",
> > basename(res))) == 0)
In SciViews I also see
command <- sub("view\.[A-Za-z0-9\._]+[(]", "view(", command)
which is almost certainly wrong and I suspect that its
cat(";for Options\AutoIndent: 0=Off, 1=follow language scoping and 2=copy
from previous line\n",
wants an extra \ before AutoIndent.
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] 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 '::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 '::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 get(object) function,
this is called whenever object$ is called. If there is no such
function, the internal field '' is access (from the environment
where all fields live in). Similarily, object$ <- value check
for set(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 setMeth
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-deve
[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
Re: [Rd] (PR#9248) Incomplete loading of files into Windows script
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --27464147-762791266-1159424200=:16565 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT This does look exactly like PR#9254, and I am unable to reproduce it on a patched version. The patch is in r39516, so later than the version you tried. On Thu, 28 Sep 2006, Klaus Thul(WAT & Device-Ò\§J±j) wrote: > Dear Prof. Ripley, > > Sorry for late reply: your mail didn't get through the spam filter of my > Email provider. > > I saw that comment that is might be the same as PR#9254 and fixed. > Therefore I tried the latest snapshot binary build (2.5.0 r39503) but > the behavior is unchanged. > > Regarding your questions to reproduce the bug: > 1) I read the file using Windows menu "File -> Open script..." > 2+3) Attached an example file; reading the file stops after ~1000 characters. > > Regarding locale: I am located in Taiwan and using a "Taiwanese" laptop, but > switched my windows language settings to English. > During startup, R displays: "Natural language support but running in an > English locale". > > Please let me know if you need further information. > > Best regards, > Klaus > > > Date: Sun, 24 Sep 2006 07:07:24 +0100 (BST) > From: Prof Brian Ripley <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: [Rd] (PR#9248) Incomplete loading of files into Windows script > > Please, we do need complete reproduction instructions (and not > speculation) as the FAQ asks. > > 1) How exactly did you read the file in? > 2) 'longer' than what? > 3) What line ending is this? > > I've just tried loading a 1000-line 50kb file using the 'Open Script' menu > item, and it worked with CRLF, LF or CR line endings. > > Some guesses are that there are control characters in the file or an > encoding problem (what is your locale?). > > > On Sun, 24 Sep 2006, [EMAIL PROTECTED] wrote: > >> Full_Name: Klaus Thul >> Version: R2.3.1 (CRAN binary for Windows) >> OS: Windows XP >> Submission from: (NULL) (220.132.142.175) >> >> >> When I read a longer text file created on Mac OS X into the built-in script >> editor of R for windows, it is read only incomplete. The same file can be > loaded >> without problem e. g. into WordPad. >> >> I think the reason for the behavior is that Mac OS X uses different EOL > markers, >> and R for windows doesn't handle these markers correctly. I don't have > access to >> an UNIX/LINUX system, but I guess files generated on these systems will > cause >> the same problem. >> >> I can provide an example file which fails if necessary. >> >> __ >> 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 --27464147-762791266-1159424200=:16565-- __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 'St9bad_alloc' (PR#9261)
This is not how Windows reports errors, and there are no reproduction instructions. Please do study the section on BUGS in the FAQ. If this was a report on a Windows build of R, see the rw-FAQ on how to get useful debugging information. This look suspiciously like a report from C++ code. There is no C++ in R, but there might be in a package you were using. It seems unlikely this is a bug in R itself. On Thu, 28 Sep 2006, [EMAIL PROTECTED] wrote: > 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 > -- 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
