From ggrothendieck at gmail.com  Wed May 23 15:16:23 2007
From: ggrothendieck at gmail.com (Gabor Grothendieck)
Date: Wed, 23 May 2007 09:16:23 -0400
Subject: [Rd] relist, an inverse operator to unlist
In-Reply-To: <18004.15507.906393.292974@stat.math.ethz.ch>
References: <20070513172911.GP6923@econ.upenn.edu>
	<971536df0705132354u6e2ae0cci9b1e42a766dc0ec5@mail.gmail.com>
	<17992.5499.383704.358418@stat.math.ethz.ch>
	<20070519153636.GJ21178@econ.upenn.edu>
	<20070519160413.GK21178@econ.upenn.edu> <m2r6p990j5.fsf@ziti.local>
	<20070522115154.GS28199@econ.upenn.edu> <m2y7jf3dze.fsf@ziti.local>
	<971536df0705230556l2b91613eib5b8590d04db2946@mail.gmail.com>
	<18004.15507.906393.292974@stat.math.ethz.ch>
Message-ID: <971536df0705230616j4ece3182i816b4dd4bc5a339e@mail.gmail.com>

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.



[Rd] relist, an inverse operator to unlist
Gabor Grothendieck