[Rd] relist, an inverse operator to unlist

Gabor Grothendieck ggrothendieck at gmail.com
Wed May 23 15:48:06 CEST 2007


On 5/23/07, hadley wickham <h.wickham at gmail.com> wrote:
> On 5/23/07, Gabor Grothendieck <ggrothendieck at gmail.com> wrote:
> > On 5/23/07, Martin Maechler <maechler at stat.math.ethz.ch> wrote:
> > > >>>>> "GaGr" == Gabor Grothendieck <ggrothendieck at gmail.com>
> > > >>>>>     on Wed, 23 May 2007 08:56:50 -0400 writes:
> > >
> > >    GaGr> On 5/23/07, Seth Falcon <sfalcon at fhcrc.org> wrote:
> > >    >> Andrew Clausen <clausen at econ.upenn.edu> writes:
> > >    >>
> > >    >> > Hi Seth,
> > >    >> >
> > >    >> > On Mon, May 21, 2007 at 05:15:10PM -0700, Seth Falcon wrote:
> > >    >> >> I will also add that the notion of a default argument on a generic
> > >    >> >> function seems a bit odd to me.  If an argument is available for
> > >    >> >> dispatch, I just don't see what sense it makes to have a default.  In
> > >    >> >> those cases, the default should be handled by the method that has a
> > >    >> >> signature with said argument matching the "missing" class.
> > >    >> >>
> > >    >> >> What often does make sense is to define a generic function where some
> > >    >> >> argument are not available for dispatch.  For example:
> > >    >> >>
> > >    >> >> setGeneric("foo", signature="flesh",
> > >    >> >>            function(flesh, skeleton=attr(flesh, "skeleton")
> > >    >> >>                standardGeneric("foo")))
> > >    >> >
> > >    >> > That's an excellent suggestion.  Thanks!  However, I had to set the signature
> > >    >> > to c("numeric", "missing") rather than just "numeric".
> > >    >> >
> > >    >> > I have uploaded a new version here:
> > >    >> >
> > >    >> >       http://www.econ.upenn.edu/~clausen/computing/relist.R
> > >    >>
> > >    >> I misunderstood.  You aren't using S4 classes/methods at all
> > >    >> and so I don't actually see how my comments could have been helpful in
> > >    >> any way.  relist seems like a really odd solution to me, but based on
> > >    >> the discussion I guess it has its use cases.
> > >
> > >    GaGr> You didn't misunderstand but there was an offline
> > >    GaGr> discussion pointing out that one primary use is in the
> > >    GaGr> inner loop of an optimization so it should be made as
> > >    GaGr> efficient as possible and it was changed with that in
> > >    GaGr> mind.
> > >
> > > Thank you Gabor for that explanation.
> > > (I had wondered, too, and was glad that Andrew had dropped S4
> > >  generics seemingly "by himself"  ;-))
> > >
> > > Re your proposal of mixing this into reshape():
> > >
> > > I think it's a nice and didactly helpful idea to point out the
> > > similarity in concepts between reshape() and relist().
> > >
> > > However, I wouldn't like to make reshape() generic in this
> > > sense:  As Andrew has mentioned as well, I think the two topics
> > > of data.frame (/matrix) reshaping and list <-> vector transformation
> > > seem too much different...
> > >
> > > Martin
> > >
> >
> > Another possibility is to call it reshapeList instead of relist or reshape and
> > the argument list made similar to reshape to keep the analogy as to
> > reshape as close as possible to leverage the R user's knowledge of
> > reshape.
> >
> > However, I am not so sure it really is different.  Both reshape and
> > relist involve flattening of structures and then reconstructing them back
> > to the original.  This seems very similar to me.
>
> The cast and melt operators in reshape are already generic, if you
> wanted to hook onto those instead.
>
> Hadley
>

If that were done then it would probably make more sense to
add it to the reshape package rather than the core of R.



More information about the R-devel mailing list