something breaks the use of the reverse scale

[corybrunson]

See here. Start by reproducing the behavior in a standalone example.

[corybrunson]

I believe this is essentially the same problem as here. That would mean that, for scale_y_reverse() to work, y would need to be defined in StatPersistence$setup_data(), which poses a challenge. Or there might be some other way around it; {ggplot2} is mature and offers several opportunities for cross-talk during the plot build.

[jamesotto852]

Hmm. I'm a little confused as y (and yend) are both defined in GeomBarcode$setup_data(). Is the order of evaluation, roughly, Stat$setup_data(), scale_*(), then Geom$setup_data()?

If that is the case then this is definitely a challenge -- even if we fixed the problem in StatPersistence$setup_data() I think we'd still be in trouble in the case of geom_barcode(stat = "identity") + scale_y_reverse().

[corybrunson]

Do we need StatBarcode? It could be a child of StatPersistence with modifications to $setup_data() and $compute_*().

[jamesotto852]

I don't think that will totally fix the problem, I think we'll still run into this issue when geom_barcode() is used with stat = "identity", unless we change the aesthetics GeomBarcode requires to aes(x, y, xend, yend) and make it so GeomBarcode doesn't accept persistence homology data and instead accepts a pre-computed representation of a barcode. (I don't think that's the way we should go)

[corybrunson]

I was thinking that StatBarcode$setup_data() could compute y the way StatPersistence$compute_panel() currently computes id—if necessary, after dataset has been pre-processed. GeomBarcode could then accept start,end,y and compute x,xend from start,end. Similarly, StatPersistence$setup_data() would compute x = start and y = end.

By the way, why are Geom*$required_aes = c("dataset|start", "dataset|end") rather than = c("start", "end")? or is that a holdover from main?

[jamesotto852]

I think I understand what you're proposing. My issue is that if GeomBarcode requires start, end, and y then y will need to be specified in geom_barcode(stat = "identity"). Right now, as.data.frame() used on the output of ripserr::vietoris_rips() yields a data.frame that looks like this:

    dimension     birth        death
1           0 0.0000000 0.0007823978
2           0 0.0000000 0.0024476589
3           0 0.0000000 0.0043431665
4           0 0.0000000 0.0050472710
5           0 0.0000000 0.0055217817
6           0 0.0000000 0.0058158725
7           0 0.0000000 0.0059557133
8           0 0.0000000 0.0063480427
9           0 0.0000000 0.0074791573
10          0 0.0000000 0.0075855707
...

My goal in these implementations has been to allow for these data.frame objects to be plotted directly with geom_*(stat = "identity"). In this example, with the current implementation, you would write:

ggplot(df_ripserr_output) +
  geom_barcode(stat = "identity", aes(start = birth, end = death, color = dimension))

I'm struggling to see how a y aesthetic works in this scenario, especially if we consider there may be multiple data.frame objects from {ripserr} concatenated, ready to be plotted with facet_wrap().

[jamesotto852]

By the way, why are Geom*$required_aes = c("dataset|start", "dataset|end") rather than = c("start", "end")? or is that a holdover from main?

This is a good question. I kept them because a user could, for example, use either of the following function calls:

geom_persistence(stat = "identity", aes(dataset = data))`
geom_persistence(stat = "persistence", aes(start = birth, end = death))`

I thought that Geom$required_aes checked the contents of aes(). After experimenting, though, it looks like it instead looks at the columns returned from the Stat. Seeing as that's the case, I think you're right and we should amend the required_aes for each Geom, removing "dataset".

It follows that in the docs we should edit the "Aesthetics" section to read that StatPersistence requires the dataset aesthetic and each Geom requires start and end. It does feel like we might end up confusing our users, potentially indicating that the dataset aesthetic isn't accepted by the geom_*() layer functions. I don't think that's enough of a concern to stop this change, though. What do you think?

[jamesotto852]

I did have an idea a few days ago, similar to your idea here, that may be able to solve all of these problems with positional aesthetics. It's the footnote here:

Now that I'm writing this out, I'm realizing this could be implemented differently, with two stats that accept 1.) point cloud and 2.) persistence homology data, ultimately outputting the same data with x, y, and other columns needed by the Geom plot methods. This may be worth investigating at some point, I wonder if some of the issues I'll be posting here might be fixed by this strategy.

---

If we implemented two Stat options for each of GeomPersistence, GeomLandscape, and GeomBarcode, for example:

• StatBarcodeData: transforms point-cloud data (the dataset aesthetic) to positional aesthetics (e.g. x and y)
• StatBarcodePH: transforms persistence homology data (the start and end aesthetics) to positional aesthetics

Then we could still allow for both point cloud and {ripserr}-style data for the data argument of our layer functions, we would just use stat = "barcode_data") and stat = "barcode_ph", respectively.

Note: this would also allow for the plotting of a totally pre-computed barcode with stat = "identity", mapping x, y, xend, and yend.

---

This would be a pretty significant re-work, but I think it may fix a fundamental issue with our implementation. I think we're always going to be fighting {ggplot2} if we aren't using positional aesthetics in our Geom implementations (this would also fix, for example, the plot limit issue).

[corybrunson]

My goal in these implementations has been to allow for these data.frame objects to be plotted directly with geom_*(stat = "identity").

I like most of the refactoring changes, but i do question this goal. As much as possible, i'd like to be faithful to the paradigm/principles underlying {ggplot2}.

It does feel like we might end up confusing our users, potentially indicating that the dataset aesthetic isn't accepted by the geom_*() layer functions. I don't think that's enough of a concern to stop this change, though. What do you think?

I think it's actually preferable for stat–geom pairs to require/expect different aesthetics. It helps clarify the role each performs. This is part of the reason i prefer to document stats and geoms separately, even if they form natural pairs; it forces the user to learn which of the components uses each aesthetic (or other parameter).

I think we're always going to be fighting {ggplot2} if we aren't using positional aesthetics in our Geom implementations

This seems wise to me. I'm not sure about the overhaul. Could you make your case for the goal i questioned earlier in this comment? Does that decision have implications for whether separate stats might be needed?

I think i've said this before, but this is a situation where the ability to compose stats, as has been discussed among the extenders, would be handy.

[jamesotto852]

My goal in these implementations has been to allow for these data.frame objects to be plotted directly with geom_*(stat = "identity").

I like most of the refactoring changes, but i do question this goal. As much as possible, i'd like to be faithful to the paradigm/principles underlying {ggplot2}.

This is motivated by the fact that persistence homologies are non-trivial to compute, in general. Having an accessible way for end-users to pre-compute them, save them, and plot them using our Geom implementations seems important. There are many cases where this would be advantageous, for example:

• A user may want to plot multiple representations of a persistence homology, in separate ggplot() calls, but only compute it from their data once.
• Even if the user only wants a single plot showing the persistence homology it still may be the right decision to manually compute it, bypassing our StatPersistence implementation -- if the persistence homology is in-memory or on-disk having been pre-computed (possibly on another platform) or created at an earlier stage of the analysis it could be problematic to require to recompute it.
• I alluded to this above, but if we allow for start and end aesthetics then we allow for the visualization of persistence homologies that other software might compute -- it may be the case that there is a class of data or filtration that we don't support (either in the engines in {ggtda} or {pheng}) that other software implements. Then, users could compute persistence homology for a broader class of data and specifications which could then be plugged into our Geom* implementations.

I totally agree that we need to stay faithful to the philosophy of {ggplot2}, I am certain we can find the way to stay "within bounds" and enable the use cases I describe above.

---

It does feel like we might end up confusing our users, potentially indicating that the dataset aesthetic isn't accepted by the geom_*() layer functions. I don't think that's enough of a concern to stop this change, though. What do you think?

I think it's actually preferable for stat–geom pairs to require/expect different aesthetics. It helps clarify the role each performs. This is part of the reason i prefer to document stats and geoms separately, even if they form natural pairs; it forces the user to learn which of the components uses each aesthetic (or other parameter).

This makes sense to me! Wherever we end up I'm happy to make sure the required aesthetics are specific the the Stat and Geom implementations.

---

I think we're always going to be fighting {ggplot2} if we aren't using positional aesthetics in our Geom implementations

This seems wise to me. I'm not sure about the overhaul. Could you make your case for the goal i questioned earlier in this comment? Does that decision have implications for whether separate stats might be needed?

I've tried to outline my perspective. I do think that the separate stats are only needed if we intend to allow the visualization of pre-computed persistence homologies.

---

I think i've said this before, but this is a situation where the ability to compose stats, as has been discussed among the extenders, would be handy.

This is something I have thought on quite a bit. I've tried before to make it work in a general fashion but I've found it very difficult to link all of the different potential methods together. I do think that the overhaul I described is an interesting start towards Stat composition -- it's hard to write out why exactly this is the case, I may just have to put together a proof-of-concept.

[corybrunson]

I'm so sorry—i asked exactly the wrong question above. I'm fully on board with the need to pass pre-computed PH directly to a suitable geom, and i think stat = "identity" is the right way to do so. This might be anathema to {ggplot2} principles—i'm not sure—but it would even be nice for the specified aesthetics (dataset versus start,end) to cue the geom_*() function to the appropriate stat, i.e. it returns layer(stat = if (<condition based on aesthetics>) "persistence" else "identity", ...).

Let me collect my thoughts and try again!

[corybrunson]

OK, i'm confusing myself all over again. I think my provisional objection is specifically to the stat = "identity" part of this: I don't think it's urgent that ripserr::vietoris_rips(x) %>% ggplot(aes(start = birth, end death)) %>% geom_barcode(stat = "identity") work, provided the same syntax works with a different stat. It's essential that users be able to pass pre-computed persistence data to the geom_*() functions, but i think it's appropriate that they be treated as data tables waiting to be statistically transformed rather than coordinates that demarcate geometric constructions.

It would sure also be nice to not require separate stats for when a list-column of data sets versus birth and death columns are provided, and i think we're agreed that the place for computing PH within the stat layer is Stat*$setup_data(). That also seems to be the place where y must be defined in order for scale_y_reverse() to behave well. So the output of Stat*$setup_data() would include at least the following columns, possibly passed to aesthetics but computed if not: start,end,y. (dimension might be omitted if pre-computed persistence data is passed.) Then StatPersistence$compute_panel() and StatLandscape$compute_panel() would compute x,y and StatBarcode$compute_panel() would compute x,xend,y. The Geom*s would then accept these conventionally positional aesthetics rather than start,end.

I get that this means that geom_barcode(stat = "identity") would require something other than start,end from the user...but i actually think that's good, since it would allow GeomBarcode to couple with other stats that generate these positional aesthetics but that have nothing to do with TDA. GeomPersistence is an even more extreme case; it would be a very thin child of GeomPoint, differing only in the diagram orientation (and i wonder if even that might be moved to the stats).

Please let me know if i'm talking past you. What about this plan doesn't sound good?

[jamesotto852]

I'm so sorry—i asked exactly the wrong question above.

No worries! It's nice to have put to paper my thoughts on use cases for passing pre-computed persistence homologies into {ggtda} tools.

Please let me know if i'm talking past you. What about this plan doesn't sound good?

Everything about this plan sounds good, I am in total agreement! I actually got started trying to implement almost exactly what you're describing here last night. It's never sat right with me that we were using stat = "identity" and not specifying positional aesthetics and it seems like you're of the same mind, I really like the way you've contrasted:

data tables waiting to be statistically transformed rather than coordinates that demarcate geometric constructions.

I'm also convinced that we should still just have a single Stat for both the dataset and start + end aesthetics and that the Stat should be able to figure out what to do with the different aesthetics internally.

Note: this is an opportunity to align with {ripserr} and rename start and end to birth and death -- now that we're breaking free of arguing that these are actually positional aesthetics it may be nice to adopt terminology more recognizable to TDA practitioners (unless we want to stay away from the birth and death labels for some other reason?)

[corybrunson]

Maybe the "hooray" emoji isn't quite right, but i feel relieved that we're on the same page again. : 6

Note: this is an opportunity to align with {ripserr} and rename start and end to birth and death -- now that we're breaking free of arguing that these are actually positional aesthetics it may be nice to adopt terminology more recognizable to TDA practitioners (unless we want to stay away from the birth and death labels for some other reason?)

I'm not dead-set against this, but i do side-eye it a bit. I went further in this direction with {ggalluvial}—not only stratum and alluvium but an unlimited family of axis[0-9]+ aesthetics are allowed. If i were doing it over, i think i would follow {ggforce}'s lead by using more generic names like id and split—they're still "foreign" to {ggplot2}, but they're not insular to {ggforce}, i.e. other extensions could adopt them when they serve similar ends.

Then again:

c("start", "end") %in% ggplot2:::.all_aesthetics
#> [1] FALSE FALSE

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