Add extended_persistence class

[astamm]

The extended_persistence class will be defined as a length-4 named list with entries Ordinary, Relative, Positive and Negative. Each element of that list will be an object of class persistence.

We might think about how metadata should be moved up as it will probably be the same for each extended feature.

[corybrunson]

Have you thought about, or have we discussed, storing the metadata as attributes rather than as separate list elements? It might even make things more difficult for the extended case, so i'm speculating.

Either way, i can imagine two approaches to "inherting" metadata from an extended_persistence object to a persistence object: (1) discourage the use of conventional extractors like $ in favor of custom functions like get_ordinary(), or (2) write class-specific extractors like $.extended_persistence(). I like (2), but it could cause a lot of problems if used recklessly.

[astamm]

I was thinking the following simple approach. The extended_persistence would be a list of length 5 with entries ORD, REL, NEG, POS and metadata. Then we can extract one as a persistence object with a little helper function of the form:

persistence.extended_persistence <- function(x, feature = "Ordinary") {
  persistence(
    pairs = x[[feature]],
    metadata = x$metadata
  )
}

provided that we also define the persistence constructor. The reverse could be:

extended_persistence.persistence <- function(x) {
  x <- list(
    Ordinary = x$pairs, 
    Relative = list(),
    Positive = list(), 
    Negative = list(), 
    metadata = x$metadata
  )
  as_extended_persistence(x)
}

[corybrunson]

I don't think extended persistence can be generated in any R package yet (though stay tuned—and i'll be happy to be shown i'm wrong at present), but in the meantime shall we take this little example from {ggtda} and make it an installed data set with {phutil}? It's small, diverse (one feature of each type), and recognizable (from a popular article).

[astamm]

I don't think extended persistence can be generated in any R package yet (though stay tuned—and i'll be happy to be shown i'm wrong at present), but in the meantime shall we take this little example from {ggtda} and make it an installed data set with {phutil}? It's small, diverse (one feature of each type), and recognizable (from a popular article).

Sounds perfect. I'll add it to the package.

[astamm]

Hmm I think I am not fully aware of what extended persistence is. How can it get negative values? I thought it was a matter of allowing death to happen prior to birth but I do not understand why negative values? In particular, the persistence diagram has no negative values in it but the barcode still has them. Can you help me understanding please?

[corybrunson]

I apologize—i meant to explain how it was encoded but forgot. We built the example on the false assumption that PH birth and death values would always be positive, so we used negativity to encode that a birth or death occurred on the "downward" (backward) pass of the extended filtration rather than on the "upward" (forward, i.e. usual) path (see the section on persistence diagrams here). Also, i didn't link to the referenced article; see Figure 1 here or Figure 4 here.

To make the data more recognizably EPH, do the following:

• add a type column with the values c("Ord", "Rel", "Ext+", "Ext–")
• change all birth and death values to their absolute values

But that's just a readable data frame, of course, not a persistence class object.

[astamm]

Thanks!

the false assumption that PH birth and death values would always be positive

Isn't that the case?

[corybrunson]

Isn't that the case?

For Vietoris–Rips filtrations, yes—but for others, not necessarily. I just made an issue for this at ggtda, and i mention as examples sublevel sets of real-valued functions (whose values may be anywhere in $\mathbb{R}$) or elevation rasters (whose values will be negative for surfaces below sea level).

[astamm]

Ok, that advocates to not checking for negative values. But ordinary persistence should have birth before death, right?

[corybrunson]

I think so—though i might be wrong, and i've been surprised before.

More concerning to me, though, is that someone generates persistence data using an unconventional method, or even buggy code, and then is unable to run a larger pipeline and handle the errors during post-processing. I'm very happy with printing a warning, but i'd like the user to be able to make things work in the meantime. (This comes from my own experience building machine learning pipelines that abort or crash because, say, in one data partition out of 100 no discriminating predictors were found. It would be better to be alerted to this and then exclude that case from the summary results.)

[astamm]

Point taken :-) I will issue a warning instead, maybe even have an optional argument to disable warnings and maybe also a flag in the 'persistence' class to flag when that happens so that the pipeline can later be aware of this to exclude cases from summary results.

[corybrunson]

Oh, i hadn't thought about a flag (or maybe a tag?) that would stay with the results—it would be a new metadata element, right?

[astamm]

Yes.

One thing is for the user to be able to disable warnings when (s)he pipes things as opposed to one run of as_persistence() which should, in my opinion, triggers the warning by default.

Another thing is to keep track of this warning (even if its display is disabled on purpose not to pollute console output). And it can easily be done with an additional metadata element.

[corybrunson]

That sounds good!