Re: [Rd] [R] sequence()
R-help is not the list for R development questions: you didn't want help
did you? --> moved to R-devel.
I do wonder why
> sequence(c(0,-1))
[1] 1 0 1 0 -1
is considered useful.
Given that the definition seems flawed and I could not find any uses of
this function in any package my reaction was to suggest the function be
deprecated on the way to removal. (I also do not understand why anyone
would expect sequence() to do that and not one of the many things which
seq() does.)
We certainly do not want to replace a function that works as described at
a reasonable speed by one that does not work as described, however fast.
`Accuracy first, speed second'.
On Fri, 22 Jul 2005, Robin Hankin wrote:
> Function sequence() repeatedly concatenates
> its output, and this is slow.
> It is possible to improve on the performance of sequence by
> defining
>
> myseq <- function(x){unlist(sapply(x,function(i){1:i}))}
I don't think you want sapply here, but lapply. Try
> myseq(c(2,2))
[,1] [,2]
[1,]11
[2,]22
sic!
> The following session compares the performance of
> myseq(), and sequence(), at least on my G5:
>
>
> > identical(sequence(1:50),myseq(1:50))
> [1] TRUE
> > system.time(ignore <- sequence(1:800))
> [1] 1.16 0.88 2.07 0.00 0.00
> > system.time(ignore <- sequence(1:800))
> [1] 1.14 0.84 1.99 0.00 0.00
> > system.time(ignore <- myseq(1:800))
> [1] 0.02 0.02 0.04 0.00 0.00
> > system.time(ignore <- myseq(1:800))
> [1] 0.03 0.00 0.03 0.00 0.00
> >
>
> (the time differential is even more marked for longer arguments).
and much less for more realistic shorter arguments.
> Is there any reason why we couldn't use this definition instead?
The fact that it sometimes gives the wrong answer, for one.
--
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] S4 Dispatching
Paul Roebuck wrote:
> On Wed, 20 Jul 2005, John Chambers wrote:
>
>
>>Paul Roebuck wrote:
>>
>>
>>>Is it possible for S4 to (continue) dispatch to a class
>>>created during dispatching? The code below doesn't work;
>>>is this not possible or have I ommitted something?
>>
>>"doesn't work"? This is not helpful. Please show what you got and what
>>you expected. The result below is what I would expect (& get) from your
>>code.
>>
>>R> onthefly("testing")
>>generic onthefly
>>onthefly (character)
>>generic onthefly
>>onthefly (mydata)
>>List of 1
>> $ name: chr "mydata"
>> - attr(*, "class")= chr "mydata"
>>
>>Since you used an undefined class "mydata" you can't expect very much
>>else to work with these objects. You did not in fact "create" the
>>class, you just assigned a class attribute to an object corresponding to
>>an undefined class. There is a warning message to that effect from the
>>second setMethod() call.
>
>
> In retrospect, that should have been expressed as "doesn't
> work as I expected". I was using 'options(warn=2)' and didn't
> notice the warning conversion. I expected evaluation of the
> class existence would occur when callGeneric() was invoked,
> not during setMethod(). Also surprised at the return to
> generic prior to the final dispatch (instead of going
> straight there) along that same line of thought.
>
> While it's true that all I did was add a class attribute to
> the object, I thought that was all that was required for a
> trivial S3 class to be "defined". In my case, it is solely
> for internal usage as an intermediate data object that
> allows R to handle its memory management. Not sure how to
> define an S4 class representation for an external pointer.
That is definitely a problem in the current R implementation.
Because external pointers (and environments and some other data types)
are not duplicated in the way that ordinary vectors are, you cannot
directly extend them as a class. You can't for example set the class of
such an object without affecting all the other code that uses the same
pointer.
The usual workaround is to define a list of one element that contains
the external pointer, and make that the object. Or equivalently set up
an S4 class with the external pointer as a slot. That's not a really
satisfactory workaround, though, since it's not what was intended.
It would be nice if the implementation duplicated the attributes, if
any, of such objects. But that appears not to be a simple fix---trying
out that change causes problems that seem to be related to garbage
collection or other internals of storage management. A change for the
future perhaps ...
>
> Thanks for your patience and help.
>
> --
> SIGSIG -- signature too long (core dumped)
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] sequence()
I definitely agree that 'sequence' is not the right name
for this functionality. The functionality is occasionally
useful -- I've been asked for it several times. But I do
wonder if it is basic enough that it should be in 'base'.
The function could be rewritten to create the proper
length of the answer at the outset since that is known.
It could then be used as an example (somewhere) of
how not to fragment memory.
Patrick Burns
[EMAIL PROTECTED]
+44 (0)20 8525 0696
http://www.burns-stat.com
(home of S Poetry and "A Guide for the Unwilling S User")
Prof Brian Ripley wrote:
>R-help is not the list for R development questions: you didn't want help
>did you? --> moved to R-devel.
>
>I do wonder why
>
>
>
>>sequence(c(0,-1))
>>
>>
>[1] 1 0 1 0 -1
>
>is considered useful.
>
>Given that the definition seems flawed and I could not find any uses of
>this function in any package my reaction was to suggest the function be
>deprecated on the way to removal. (I also do not understand why anyone
>would expect sequence() to do that and not one of the many things which
>seq() does.)
>
>We certainly do not want to replace a function that works as described at
>a reasonable speed by one that does not work as described, however fast.
>
> `Accuracy first, speed second'.
>
>
>On Fri, 22 Jul 2005, Robin Hankin wrote:
>
>
>
>>Function sequence() repeatedly concatenates
>>its output, and this is slow.
>>
>>
>
>
>
>>It is possible to improve on the performance of sequence by
>>defining
>>
>> myseq <- function(x){unlist(sapply(x,function(i){1:i}))}
>>
>>
>
>I don't think you want sapply here, but lapply. Try
>
>
>
>>myseq(c(2,2))
>>
>>
> [,1] [,2]
>[1,]11
>[2,]22
>
>sic!
>
>
>
>>The following session compares the performance of
>>myseq(), and sequence(), at least on my G5:
>>
>>
>>
>>
>>>identical(sequence(1:50),myseq(1:50))
>>>
>>>
>>[1] TRUE
>>
>>
>>>system.time(ignore <- sequence(1:800))
>>>
>>>
>>[1] 1.16 0.88 2.07 0.00 0.00
>>
>>
>>>system.time(ignore <- sequence(1:800))
>>>
>>>
>>[1] 1.14 0.84 1.99 0.00 0.00
>>
>>
>>>system.time(ignore <- myseq(1:800))
>>>
>>>
>>[1] 0.02 0.02 0.04 0.00 0.00
>>
>>
>>>system.time(ignore <- myseq(1:800))
>>>
>>>
>>[1] 0.03 0.00 0.03 0.00 0.00
>>
>>
>>(the time differential is even more marked for longer arguments).
>>
>>
>
>and much less for more realistic shorter arguments.
>
>
>
>>Is there any reason why we couldn't use this definition instead?
>>
>>
>
>The fact that it sometimes gives the wrong answer, for one.
>
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] sequence()
On 7/22/05, Prof Brian Ripley <[EMAIL PROTECTED]> wrote: > R-help is not the list for R development questions: you didn't want help > did you? --> moved to R-devel. > > I do wonder why > > > sequence(c(0,-1)) > [1] 1 0 1 0 -1 > > is considered useful. > > Given that the definition seems flawed and I could not find any uses of > this function in any package my reaction was to suggest the function be > deprecated on the way to removal. (I also do not understand why anyone > would expect sequence() to do that and not one of the many things which > seq() does.) > > We certainly do not want to replace a function that works as described at > a reasonable speed by one that does not work as described, however fast. > >`Accuracy first, speed second'. I would expand this to 'expected behavior first' where expected is not with respect to the documentation but with respect to normal expectations based on using R, the OS and software, in general. Some examples that I think could benefit from this are: - KalmanLike alters its arguments. Its been improved in r-devel to add an option to control this and the option provides compatibliity with the current KalmanLike and although that seems sensible, I think the best design here would be to start from scratch again and have the option default to not modifying its args. Maybe a new name should be produced and KalmanLike deprecated. - write.csv, despite the recent improvement, could benefit from being a wrapper in the usual way where default args are set. Its not terrible the way it is in r-devel but its not the best design either. - italic does not consistently italicize its arguments. This is apparently delibertate but its completely unexpected and would be best changed. - *.site and libraries do not get copied from one version of R to the next when one upgrades R. I can't think of a well known product that makes you reconfigure from scratch each time you upgrade like R does Its possible to come up with a configuration that works after upgrade but its not dead simple like it is with many products. - R CMD ... does not work on Windows if cmd instead of CMD is used. This is quite unexpected if you are a Windows user where commands are normally case insensitive. These are only the examples I can think of off the top of my head since they were topics of recent discussions. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] S4 Dispatching
I'm not sure I understand here... If I do, say...
setClass("id","externalptr")
where classes of that type come back from, effectively, C functions
that do something like
PROTECT(ret = NEW_OBJECT(MAKE_CLASS("id")));
R_SetExternalPtrAddr(ret,myid);
UNPROTECT(1);
return ret;
am I just asking for an explosion somewhere down the line? (I haven't
noticed anything in particular so far...) I'm not adding any slots
since it happens that all of the pointers of interest have
information that should either a) live on the pointer side or b)
lives in a meta object of some sort.
On Jul 22, 2005, at 5:39 AM, John Chambers wrote:
> That is definitely a problem in the current R implementation.
>
> Because external pointers (and environments and some other data types)
> are not duplicated in the way that ordinary vectors are, you cannot
> directly extend them as a class. You can't for example set the
> class of
> such an object without affecting all the other code that uses the same
> pointer.
>
> The usual workaround is to define a list of one element that contains
> the external pointer, and make that the object. Or equivalently
> set up
> an S4 class with the external pointer as a slot. That's not a really
> satisfactory workaround, though, since it's not what was intended.
>
> It would be nice if the implementation duplicated the attributes, if
> any, of such objects. But that appears not to be a simple fix---
> trying
> out that change causes problems that seem to be related to garbage
> collection or other internals of storage management. A change for the
> future perhaps ...
>
>
>
>>
>> Thanks for your patience and help.
>>
>> --
>> SIGSIG -- signature too long (core dumped)
>>
>>
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
---
Byron Ellis ([EMAIL PROTECTED])
"Oook" -- The Librarian
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
