I just thought there is some benefit for the callback to be the same,
regardless of the iterate setting. This would allow generalization across
different data scales. Perhaps all that is needed is a constructor for an
adapter closure, one for each direction.

For example, the variadic adapter would look like:

Variadic <- function(FUN) {
  function(x, y) {
    if (missing(y)) {
      do.call(FUN, x)
    } else {
      FUN(x, y)
    }
  }
}

That would make it easy to e.g. adapt rbind into the framework. I wonder if
there is precedent and better terminology from the functional programming
domain?

Michael



On Sun, Jun 15, 2014 at 8:38 AM, Martin Morgan <mtmor...@fhcrc.org> wrote:

> On 06/15/2014 07:34 AM, Michael Lawrence wrote:
>
>> Hi guys,
>>
>> Was just checking out GenomicFiles and was a little surprised that the
>> arguments to the REDUCER are different depending on iterate=TRUE vs.
>> iterate=FALSE. In my often flawed opinion, iteration should not be a
>> concern of the REDUCER. It should be oblivious to the iteration mode. In
>> other words, when iterate=TRUE, it is a special case of having two objects
>> to combine, instead of multiple.
>>
>
> My 'rationale' was that one would choose iterate=FALSE when one required
> all elements to perform the reduction. I thought of the list (rather than
> ...) as the general R data structure for representing N elements, with a
> special case (consistent with Reduce) made for the pairwise reduction of
> iterate=TRUE. Either way, the two cases (x, y vs. list(), x, y vs. ...)
> seem to require some explaining to the user. Is there a clear better
> choice? You're the second person to trip over this, so I guess there's a
> crack in the sidewalk...
>
> Martin
>
>
>> What would be convenient (but unnecessary) is to detect from the formal
>> arguments whether REDUCER is variadic or list-based. In other words, if
>> REDUCER is defined like function(...) { } it is called via do.call(),
>> otherwise it is passed the list.
>>
>> Thoughts? Maybe I'm totally confused?
>>
>> Michael
>>
>>         [[alternative HTML version deleted]]
>>
>> _______________________________________________
>> Bioc-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>>
>
> --
> Computational Biology / Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N.
> PO Box 19024 Seattle, WA 98109
>
> Location: Arnold Building M1 B861
> Phone: (206) 667-2793
>

        [[alternative HTML version deleted]]

_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Reply via email to