From maechler at stat.math.ethz.ch  Tue Dec 28 16:49:49 2010
From: maechler at stat.math.ethz.ch (Martin Maechler)
Date: Tue, 28 Dec 2010 16:49:49 +0100
Subject: [Rd] RFC: sapply() limitation from vector to matrix,
	but not further
In-Reply-To: <AANLkTin6pbS_99RjSje12Zr7M9mwLy0oKNX7H8gz1Zgh@mail.gmail.com>
References: <19702.2469.739772.13707@lynne.math.ethz.ch>
	<AANLkTin6pbS_99RjSje12Zr7M9mwLy0oKNX7H8gz1Zgh@mail.gmail.com>
Message-ID: <19738.1821.84824.284589@cmath-6.math.ethz.ch>

>>>>> Gabor Grothendieck <ggrothendieck at gmail.com>
>>>>>     on Mon, 27 Dec 2010 17:06:25 -0500 writes:

    > On Wed, Dec 1, 2010 at 3:39 AM, Martin Maechler
    > <maechler at stat.math.ethz.ch> wrote:
    >> My proposal -- implemented and "make check" tested -- is
    >> to add an optional argument ?'ARRAY' which allows
    >> 
    >>> sapply(v, myF, y = 2*(1:5), ARRAY=TRUE)

    > It would reduce the proliferation of arguments if the
    > simplify= argument were extended to allow this,
    > e.g. simplify = "array" or perhaps simplify = n would
    > allow a maximum of n dimensions.

That's a good idea, though it makes the
implementation/documentation very slightly more complicated.

I'm interested to get more feedback on my other questions,
notably the only about *changing*  vapply() (on the C-level) to
behave "logical" in the sense of adding one  dim(.)ension in
those cases, the FUN.VALUE (result prototype) has a dim().


Martin



[Rd] RFC: sapply() limitation from vector to matrix, but not further
Martin Maechler