We'll try a single arg to REDUCER and see how it goes.
BTW I'm also going to swap out DataFrame for Vector in the rowData.
DataFrame has been more difficult than anticipated (storing names,
subsetting to get ranges out) and doesn't give any clear advantage over
Vector.
Val
On 06/17/2014 0
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 ap
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
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 aga
On Tue, Jun 17, 2014 at 7:00 AM, Valerie Obenchain
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 here.
>
> These w
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
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 wrote:
> What about having two separate reducer argument
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 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
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 sho
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 w
10 matches
Mail list logo
