[Bioc-devel] GenomicFiles reducer and iterate argument

[Valerie Obenchain]

Hi Michael, Ryan,

Yes, it would be ideal to have a single signature for both cases of 
'iterate'. We went over the pros/cons again and at the end of the day 
decided to keep things as they are. No perfect solution here.

These were the primary points:

- Disadvantages of defining REDUCER with only '...' is that '...' can 
represent variables other than just the output from MAPPER.

- The unappealing aspect of the variadic approach is introducing a new 
check each time REDUCER is called.

- Going the other direction, considering a single arg for REDUCER 
instead two, requires coercing 'last' and 'current' to a list before 
pulling them apart again.


Valerie


On 06/15/14 16:36, Michael Lawrence wrote:
> I kind of prefer the adaptor solution, just for the sake of API cleanliness
> (the MAPPER/REDUCER pair has some elegance), but I think we agree that the
> iterate switch introduces undesirable coupling.
>
>
>
>
> On Sun, Jun 15, 2014 at 3:07 PM, Ryan <rct at thompsonclan.org> wrote:
>
>> 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
>>>
>>
>
> 	[[alternative HTML version deleted]]
>
> _______________________________________________
> Bioc-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>