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
On Tue, Jun 17, 2014 at 7:00 AM, Valerie Obenchain voben...@fhcrc.org
wrote:
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
Val's out today and I'm at least part of the problem so...
On 06/17/2014 10:13 AM, Michael Lawrence wrote:
On Tue, Jun 17, 2014 at 7:00 AM, Valerie Obenchain voben...@fhcrc.org
wrote:
Hi Michael, Ryan,
Yes, it would be ideal to have a single signature for both cases of
'iterate'. We went
I think there are two different use cases here. The first, the one that I
think is driving the design, is that the user writes a function for a
particular problem, where the value of iterate is known. The other use case
is that the user gets a summary function from somewhere else (a package)
and
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
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
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
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
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 r...@thompsonclan.org wrote:
What about having two
