vincenzocoia / distplyr

Draw powerful insights using distributions with this R package.
https://distplyr.netlify.app/
Other
2 stars 2 forks source link

Double graft: environment issue #18

Closed vincenzocoia closed 2 years ago

vincenzocoia commented 3 years ago

Something bizarre happens when you try to graft both tails, one following the other. Here's a reprex to debug, although it requires adding a line -- print(breakpoint) -- at the top of one of the default slice methods. In this case, I've added it to slice_right.dst().

library(distplyr)
#> ℹ Loading distplyr
d <- dst_norm(0, 1)
dl <- d %>% graft_left(d, breakpoint = -1)
#> [1] -1
dlr <- dl %>% graft_right(d, breakpoint = 1)
#> [1] -1
plot(dlr, "cdf", from = -3, to = 3)

invisible(dl %>% slice_right(breakpoint = 1))
#> [1] -1
invisible(dl %>% slice_right.dst(breakpoint = 1))
#> [1] 1
dl$components
#> $distributions
#> $distributions[[1]]
#> slice_right dst
#> 
#>  distribution :
#> norm parametric dst
#> 
#>  parameters :
#> $mean
#> [1] 0
#> 
#> $variance
#> [1] 1
#> 
#> 
#> $distributions[[2]]
#> slice_left dst
#> 
#>  distribution :
#> norm parametric dst
#> 
#>  parameters :
#> $mean
#> [1] 0
#> 
#> $variance
#> [1] 1
#> 
#> 
#> 
#> $probs
#> [1] 0.1586553 0.8413447
#> 
#> $breakpoint
#> [1] -1

Created on 2021-08-30 by the reprex package (v0.3.0)

The issue is pinpointed in the two lines with invisible: calling the method directly yields the appropriate breakpoint value, whereas going through the generic yields the breakpoint from the previous graft. Somehow, the scoping rules are favouring the breakpoint entry that's being stored in the dl graft distribution (see the output of the last line), as opposed to the one directly input as a function argument.

vincenzocoia commented 2 years ago

This issue appears to be solved with the latest development.