[Bioc-devel] GenomicFiles reducer and iterate argument

[Ryan]

What about having two separate reducer arguments, one for a reducer 
that takes two elements at a time and combines them, and the other for 
a reducer that takes a list and combines all the elements of the list? 
Specifying both at once would be an error. I think it makes more sense 
to say "these two arguments expect different things" than "this one 
argument expects a different thing depending on the value of another 
argument".

-Ryan

On Sun Jun 15 11:17:59 2014, Michael Lawrence wrote:
> 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 <mtmorgan at 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 at 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 at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel