Handling features where `death == Inf`

[jamesotto852]

Now that the "Persistence-Refactor" branch has StatPersistence inheriting from Stat instead of StatIdentity, rows of data where death == Inf are being removed in $compute_layer(). Specifically, this is happening because Stat$compute_layer() removes rows where required aesthetics are infinite, as you can see in its source (lines 203 - 207):

data <- remove_missing(data, params$na.rm,
 c(required_aes, self$non_missing_aes),
 snake_class(self),
 finite = TRUE
)

I've implemented a fix in dc68533, I added a few lines at the end of StatPersistence$setup_data() where I derive a new computed variable (infinite_death) and temporarily set infinite death values to 0(lines 309 - 314):

data$infinite_death <- is.infinite(data$death)
data$death[data$infinite_death] <- 0

Then, in StatPersistence$compute_group() I reverse this, resetting the values of death to Inf where appropriate, per data$infinite_death (lines 335 - 337).

data$death[data$infinite_death] <- Inf

This approach seems to work very well, infinite values are being plotted as intended across the board. And, as a bonus, infinite_death is now available as a computed variable and can be mapped to in aes().

---

I think this also presents an interesting opportunity -- I've seen persistence diagrams where infinity is represented as a dashed line at some arbitrary point on the y-axis; it would be very easy to implement an argument that would allow users to plot infinity at a given y value (e.g. if all finite death values are below 1.5, one could select 1.5 as the visual definition of infinity, accompanied with geom_hline(yintercept = 1.5, linetype = "dashed"). This would give an alternative method of visualizing points at infinity in geom_peristence() in case users object to the "half" points at the top-edge of the y-axis. (This also works well with the new infinite_death computed variables, allowing further visual emphasis that the points at y = 1.5 are distinct)

[corybrunson]

And, as a bonus, infinite_death is now available as a computed variable and can be mapped to in aes().

This is very cool. I'm tempted to suggest immortal or zombie, but i think that would be too cute by half.

I've seen persistence diagrams where infinity is represented as a dashed line at some arbitrary point on the y-axis; it would be very easy to implement an argument that would allow users to plot infinity at a given y value

Much as i dislike this in general (literally infinitely worse than introducing "breaks" in a bar plot with wildly different bar heights), i think it makes a lot of sense in this specific setting—and it wouldn't really lend itself to abuse.

[corybrunson]

@jamesotto852 there are also circumstances where birth or death values might reasonably be considered censored, e.g. when capping the filtration at a radius below the enclosing one. For this case we're about to have {ripserr} return NA_double_ values rather than Inf; see this PR. Maybe there's not much to be done with such pairs in isolation, but, if the threshold (i.e. the censor radius) can be recovered from the data, then they become a special case of time-to-event data and might be plotted with open circles at censor radii (below or above). Something to think forward to; shouldn't hold up the initial submission.

[jamesotto852]

I'm tempted to suggest immortal or zombie, but i think that would be too cute by half.

Ha! I struggled to come up with something reasonable, I was surprised I couldn't find a standard term. Let me know if you have a potential improvement in mind.

---

Much as i dislike this in general (literally infinitely worse than introducing "breaks" in a bar plot with wildly different bar heights), i think it makes a lot of sense in this specific setting—and it wouldn't really lend itself to abuse.

Point taken on it being "infinitely worse". I see both ways, I could definitely imagine use cases where the "infinite break" would be very important for users -- {ggplot2}'s decision to plot half the point right at the limit can make the features hard to see at a glance. I definitely agree that it doesn't lend itself to abuse, I'll see if I can get it implemented tonight or tomorrow.

---

For this case we're about to have {ripserr} return NA_double_ values rather than Inf

That makes sense. We'll definitely need to handle that carefully, the current {ggtda} implementation won't do well with those missing values. We should be able to implement another computed variables (censored_death) and handle the death values in a similar way as infinite_death. If it's represented as a computed variable that should give us options later for time-to-event style visuals intended to represent the censoring.

[jamesotto852]

I've just pushed an update which implements the infinity_break argument for StatPersistence and StatBarcode (4da7748). Here are some basic examples:

library("ggplot2"); theme_set(theme_bw())
library("ripserr")
library("ggtda")
#> Loading required package: rlang

# Simulate point cloud data -----------------------------------------------
# Unit circle (Betti-1 number = 1)
set.seed(1); angles <- runif(100, 0, 2 * pi)
circle2d <- cbind(x = cos(angles), y = sin(angles)) 
df_pointcloud <- tibble::tibble(data = list(circle2d))

p_point_cloud <- 
  ggplot(df_pointcloud, aes(dataset = data, colour = after_stat(dimension))) +
  scale_color_brewer(type = "qual", palette = 2)


# Example Plots -----------------------------------------------------------

# Default behavior is still the same
p_point_cloud +
  geom_persistence() 

# Can create "break" for infinite death values with `infinity_break`
# Note: the plotting window captures this break, no change of `ylim` needed
p_point_cloud +
  geom_hline(yintercept = 2, linetype = "dashed") +
  geom_persistence(infinity_break = 2) 

# The default is `infinity_break = Inf`, putting the break at infinity
p_point_cloud +
  geom_persistence(infinity_break = Inf) 

# Also works with alternative diagram specification
p_point_cloud + geom_persistence(diagram = "diagonal", infinity_break = 2)

# This all works the same way with barcode diagrams 
p_point_cloud +
  geom_barcode(infinity_break = 3) +
  geom_vline(xintercept = 3, linetype = "dashed")

# StatLandscape doesn't accept this argument
p_point_cloud + geom_landscape(infinity_break = 3)
#> Error in `geom_landscape()`:
#> ! Problem while computing stat.
#> ℹ Error occurred in the 1st layer.
#> Caused by error in `setup_params()`:
#> ! StatLandscape doesn't accept the `infinity_break` argument

^{Created on 2025-09-30 with reprex v2.1.1}

[corybrunson]

Let me know if you have a potential improvement in mind.

People refer to "infinite features", so i think a logical variable infinite would suffice—and another one censored. If users complain then we can deprecate and replace it.

The examples look great. I'm still interested in (optionally) putting arrows on the infinite barcodes the way JavaPlex does, but it's not a priority.

However: Should we throw an error, or at least a warning, if infinity_break < max(death)?

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

set.seed(1); angles <- runif(100, 0, 2 * pi)
circle2d <- cbind(x = cos(angles), y = sin(angles)) 
df_pointcloud <- tibble::tibble(data = list(circle2d))

p_point_cloud <- 
  ggplot(df_pointcloud, aes(dataset = data, colour = after_stat(dimension))) +
  scale_color_brewer(type = "qual", palette = 2)

p_point_cloud +
  geom_hline(yintercept = 1, linetype = "dashed") +
  geom_persistence(infinity_break = 1) 

^{Created on 2025-09-29 with reprex v2.1.1}

[jamesotto852]

People refer to "infinite features", so i think a logical variable infinite would suffice—and another one censored. If users complain then we can deprecate and replace it.

Both of these make total sense, I'll change infinite_death to infinite and use censored when I implement handling of NA values for death.

---

However: Should we throw an error, or at least a warning, if infinity_break < max(death)?

Yes, I think that would be a great idea -- I'll get that added.

[jamesotto852]

I've got the computed variable renamed and basic logic that issues a warning for poor choices of infinity_break:

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

set.seed(1); angles <- runif(100, 0, 2 * pi)
circle2d <- cbind(x = cos(angles), y = sin(angles)) 
df_pointcloud <- tibble::tibble(data = list(circle2d))

p_point_cloud <- 
  ggplot(df_pointcloud, aes(dataset = data, colour = after_stat(dimension))) +
  scale_color_brewer(type = "qual", palette = 2)

# Informative warning is issued for poor choice of `infinity_break`
p_point_cloud +
  geom_hline(yintercept = 1, linetype = "dashed") +
  geom_persistence(infinity_break = 1)
#> Warning: Persistence homology `death` values exceed specified `infinity_break`.
#> This can result in misleading visuals, consider choosing a larger value.

# Using `after_stat(infinite)` for plot styling
p_point_cloud +
  geom_hline(yintercept = 2, linetype = "dashed") +
  geom_persistence(aes(shape = after_stat(infinite)), infinity_break = 2, size = 3, stroke = 2) +
  scale_shape_manual(values = c("TRUE" = 8, "FALSE" = 20)) +
  guides(shape = "none")

^{Created on 2025-10-07 with reprex v2.1.1}

---

I'm still interested in (optionally) putting arrows on the infinite barcodes the way JavaPlex does, but it's not a priority.

I agree, this would be a good thing to include. My current outlook is that it looks doable but non-trivial -- it's not clear to me what the right implementation would be... what I'm currently thinking on is the addition of a new aesthetic for GeomBarcode, something like barcodeend. This could be mapped to computed variables infinite and censored, essentially turning the arrow argument of GeomSegment into an aesthetic, leveraging grid::arrow(). Unfortunately, this would require the export of scales for the new barcodeend aesthetic.

It's possible users would even want to distinguish between different "types" of features, one way could be with the type argument of grid::arrow() (i.e. type = "open" vs type = "closed")? If we wanted to do this it would be necessary to introduce another computed variable, a "composite" value that specified the "type" of each feature all in a single column.

I do think it is possible to get the functionality without a new aesthetic for GeomBarcode but I haven't come up with something that seems reasonable. Generally, it feels wrong to circumvent the aes() API to specify data-dependent geometric representations, can you think of any examples of something like this in {ggplot2}? The closest I've come up with is how GeomBoxplot deals with outliers, which is close but not quite the same.

[corybrunson]

geom_persistence(aes(shape = after_stat(infinite)), infinity_break = 2, size = 3, stroke = 2) +

I laughed out loud at that asterisk. Well done.

Unfortunately, this would require the export of scales for the new barcodeend aesthetic.

Indeed—i would argue strongly against this option (and against the new aesthetic at all), which would also permit mischief. Better to introduce two new parameters, e.g. inflineend and nalineend (need workshopping) that default to a standard arrow and an open circle, respectively.

Generally, it feels wrong to circumvent the aes() API to specify data-dependent geometric representations, can you think of any examples of something like this in {ggplot2}?

I think this is more common than it might seem. Indeed, the boxplot layer renders the median as a line segment, the IQR as a rectangle, and the outliers as point markers (though maybe not using those constructions internally). And then there're geom_smooth() and geom_quantile(). I would think of this visualization option as operating independently of the computed variable; we could dispense one and still provide the other. (At this point i think both are valuable, but i would implement them independently.)