Option to disable multiple map behavior of mirai_map()

[andrewGhazi]

Originally brought up in #137 . I wanted to check if it would be possible to add an option to disable the multiple map behavior of mirai_map(). I can create a list of five matrices like this:

mat_list = replicate(5, matrix(runif(30), 5), simplify = FALSE)

I can easily use lapply() & colSums() to get a list of length five with the column sums of each one:

lapply_res = mat_list |> lapply(colSums)

But if I try to do the same thing with mirai_map() it errors out because it's trying to apply colSums() row-wise:

library(mirai)

mirai_res = mirai_map(mat_list, colSums)[]

> length(mirai_res)
[1] 30
> mirai_res[[1]]
'miraiError' chr Error in (function (x, na.rm = FALSE, dims = 1) : unused arguments (0.239818970207125, 0.472776436479762)

A similar thing will happen with data frames of course. This is just a toy example, but in my usual programming style lists of matrices / data frames are fairly common and I usually want to apply a function to each matrix as a whole, not each row of each matrix.

In the issue on package guidance, when I say I adapted the source code of mirai_map(), I mean that I literally just pulled out lines 194-205 + 216 here and handed them my inputs and function as .x and .f. I want the behavior of the else expression there, but the multiple map condition cond puts me in the if expression.

The functionality I'm suggesting would be to add .multi_map = TRUE to the arguments of mirai_map() and change the condition here from (cond) to (cond && .multi_map). That way I could do this:

mirai_res = mirai_map(mat_list, colSums, .multi_map = FALSE)[]

and mirai_res gives me the same result as lapply_res. I tried it on a local installation and it worked as I expected it to, though I wasn't able to tell if it negatively impacted any of the tests.

Anyway, this would be useful to me, but perhaps this is somehow counter to the design philosophy of mirai or adds some other preclusive complication that I'm unable to foresee. Just thought I'd bring it up as the default behavior it was a bit counter-intuitive to me at first.

[shikokuchuo]

Thank you, this is immensely useful.

What this all boils down to, I think, is a shortcoming in the current implementation of mirai_map(). I agree that you should be able to replicate the behaviour of purrr::map() / lapply() on your list of dataframes.

However, I would not resort to adding a .multi_map argument unless it is genuinely a case that either option is (equally) possible. This is tied in to the package's design philosophy as you mentioned above. Not for the sake of being 'minimal', but rather mirai tries to provide 'good defaults' so that things just work intuitively without overloading users with requirements to know (i) if a particular option exists and (ii) if it applies in any particular use case.

The clue here is in the documentation - I had intended the 'multi-map' behaviour to apply to '2D' objects i.e. matrices / dataframes, where I think the intent would be clear to map over the rows, as purrr::pmap() does.

In light of this, I intend to remedy the situation with limiting the 'multi-map' behaviour to matrix and data frame types. Then your example (a list) would work by default - and I think this is the correct default.

The solution would retain flexibility as you could still pass in a list of arguments for multi-map by simply wrapping in as.data.frame(). Conversely, to map over columns of a data frame, you can first callas.list() on it.

I hope this remains intuitive. My preferred alternative otherwise would be to split the behaviours into two functions.

[shikokuchuo]

The fix is now available in the 'map' branch. You may test it out by installing with e.g.:

pak::pak("shikokuchuo/mirai@map")

[shikokuchuo]

I've merged the solution in #150 into 'main' now.

I'll keep this discussion open in case you have any further suggestions before the next release.

[andrewGhazi]

Cool, I think the solution you implemented makes perfect sense. The last point about enabling a map over columns of a data.frame with as.list() is a bonus because that's something else I had been trying to figure out.

[shikokuchuo]

I've added documentation in 12479a5. I'm more convinced that this is the way to go as the alternatives to match the behaviour of purrr::map() or lapply() just don't make much sense in these contexts.