Bug in StatLandscape$compute_group

[jamesotto852]

While working on the refactor from #55 I discovered what I believe to be a bug in the current implementation of the StatLandscape$compute_group method. When plotting the persistence landscape for a slightly modified version of the toy data used in our examples, one of the frontiers has two incorrect peaks. In the reprex below we see that the third frontier function has peaks at (1, 3) and (4, 5). However, there are no (birth, death) values corresponding to these peaks -- I think it's grabbing these from the previous frontier.

I'm going to fix this in the branch I'm working on, just wanted to bring attention to it in case we end up not merging the refactor to main.

library("ggtda")
#> Loading required package: rlang
#> Loading required package: ggplot2

# toy example
toy.data <- data.frame(
  birth = c(0, 0, 1, 3, 4, 1.5),
  death = c(5, 3, 5, 4, 6, 4),
  dim = factor(c(0, 0, 0, 0, 0, 0))
  # dim = factor(c(0, 0, 1, 1, 2, 2))
)

# persistence diagram with landscape overlaid
ggplot(toy.data,
       aes(start = birth, end = death, shape = dim)) +
  theme_persist() +
  coord_equal() +
  stat_persistence() +
  stat_landscape(aes(color = after_stat(factor(level, 1:4))), n_levels = 4, diagram = "diagonal") +
  lims(x = c(0, 8), y = c(0, NA)) +
  guides(alpha = "none")

^{Created on 2024-05-05 by the reprex package (v2.0.1)}

[jamesotto852]

Whoops! I'm totally wrong here, just had to write it out to realize. Obviously this is working as intended, according to the definition of the persistence landscape.

[corybrunson]

Whew. : ) I also had a difficult time convincing myself of the right behavior when multiple features shared birth and/or death values. Thanks a lot @jamesotto852 for giving everything a close look.