You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was playing around with the lmap_if function and encountered an unexpected behaviour when a function is provided to .else while the function in .f is altering the structure of the object that lmap_if is applied to. This behavior might be intended, in this case please close this issue.
# setup
library(purrr)
Here is a simple function, similar to the one in the documentation. This function just duplicates
a list element.
The reason for this unexpected behavior is that lmap_if creates an selector based on the function in .p and then applies lmap_at first on all selected elements (which might alter the structure of .x) and then applies lmap_at again at the result of the first operation using all elements which were not selected. However, since the selector was created before the first call to lmap_at it doesn’t necessarily match the structure of .x anymore. Is this behavior intended and was just my mental model of what lmap_if is doing wrong?
library(purrr)
x<-list("a", 99)
str(lmap_if(x, is.character, ~list(1, 2), .else=~list(3, 4)))
#> List of 4#> $ : num 1#> $ : num 3#> $ : num 4#> $ : num 99
I was playing around with the
lmap_if
function and encountered an unexpected behaviour when a function is provided to.else
while the function in.f
is altering the structure of the object thatlmap_if
is applied to. This behavior might be intended, in this case please close this issue.Here is a simple function, similar to the one in the documentation. This function just duplicates
a list element.
This is the example list from the documentation:
Lets apply
lmap_if
and say we want to duplicate each numeric list element and we want toreplace all other elements with
list(z = 1)
.The output is somewhat unexpected. Rewritting
lmap_if
as a loop - at least the way I thought it would work - would yield the following result.The reason for this unexpected behavior is that
lmap_if
creates an selector based on the function in.p
and then applieslmap_at
first on all selected elements (which might alter the structure of.x
) and then applieslmap_at
again at the result of the first operation using all elements which were not selected. However, since the selector was created before the first call tolmap_at
it doesn’t necessarily match the structure of.x
anymore. Is this behavior intended and was just my mental model of whatlmap_if
is doing wrong?Created on 2021-12-12 by the reprex package (v0.3.0)
The text was updated successfully, but these errors were encountered: