wilcoxon DE, vs_all_perturbed

[zboldyga]

What kind of feature would you like to request?

Additional function parameters / changed functionality / changed defaults?

Please describe your wishes

@ilan-gold another part of my optimizations I added while doing perturb seq benchmarks was including a mode in wilcoxon DE for vs_all_perturbed. This has emerged as a technique in perturb seq: when performing differential expression on each target perturbation, instead of using all other cells as a reference, this approach uses all other cells except the controls (so only cells that had a perturbation on a coding gene).

e.g. it's introduced here: https://arxiv.org/pdf/2506.22641 in section 3.3 and 4.2 , and you can see it in the corresponding code: https://github.com/shiftbioscience/Diversity_By_Design/blob/main/data/norman19/get_data.py#L40 . This is also used in the more recent Dynamic Range Fraction paper in perturb seq, and probably some other papers derived from these works.

Practically I think this is most relevant when non-targeting (control) cell count is high relative to total cell count. Which does tend to happen, because every batch tends to include non-targeting cells to compensate for batch effects.

That said, it seems it might be a pattern that is here to stay, e.g. it's superior under certain conditions.

So my first question is -- does this deserve support in the scanpy wilcoxon DE implementation? My alternative was to filter data beforehand, but that is clunky.

If so:

1. This should use a one-versus-rest approach where a single ranking is performed on the 'rest' cells, rather than re-doing ranking on every perturbation. That was the hoist issue I fixed in the other PR (the 2 line change). So this would just need to hit that path.

2. I can spearhead getting this implemented end-to-end in scanpy and illico.

3. As for how, I'm thinking it might make sense if there's a parameter that allows specifying a single group to exclude from 'rest' when using 'rest' as the the reference? It should be clear from the parameter name that this only impacts the reference cells and is unrelated to 'groups' (which perturbations DE is computed for)... This seemed a better option than adding another mode (e.g. vs_all_perturbed) because there are non-perturb-seq uses of wilcoxon DE. It also didn't seem necessary to allow multiple exclusion groups, I can't think of any other cases where it'd be helpful to offer to allow excluding more than one group. And this exclusion approach should be a lightweight change.

Thoughts?

If you think this is right, I can draft a PR to show what it looks like in scanpy and ping the illico author(s) to coordinate on that end.

[ilan-gold]

As for how, I'm thinking it might make sense if there's a parameter that allows specifying a single group to exclude from 'rest' when using 'rest' as the the reference? It should be clear from the parameter name that this only impacts the reference cells and is unrelated to 'groups' (which perturbations DE is computed for)... This seemed a better option than adding another mode (e.g. vs_all_perturbed) because there are non-perturb-seq uses of wilcoxon DE. It also didn't seem necessary to allow multiple exclusion groups, I can't think of any other cases where it'd be helpful to offer to allow excluding more than one group. And this exclusion approach should be a lightweight change.

I think a general exclude: list[str] parameter could solve this right" Because they aren't compared either as reference or the other side (perturbed in this case), they are completely excluded. @remydubois thoughts?

Definitely belongs in both scanpy but might be able to get away without illico since we construct the AnnData object ourselves

[remydubois]

Hey, interesting use case.

I think a general exclude: list[str] parameter could solve this right

I agree it would solve it. I'm wondering if users wouldn't get confused by how this interacts with groups. Also, it would ask a bit of guardrailing on scanpy's side so as to make sure values inputted by the user for those two don't contradict each other.

As for whether illico should handle some (or all) of it, here is how i see things:

1. The groups argument (the functionality it currently has in scanpy) would shorten execution time of the OVO (because there would be less comparisons to perform) but not the OVR path (because the costly operation is sorting, and we would sort the same values as if groups=None), if implemented in illico.
2. However, the exclude argument that you mention would speed up the OVO path (same reasons as above) and the OVR path (because there would be less values to sort).

I could be open to adding the exclude functionality in illico in the short term, which would not be contradictory with what's currently in the PR @ilan-gold IIUC (where the filtering of resulting p values is handled by scanpy because the groups keyword is not supported). But maybe there's a better way (like filtering beforehand on scanpy's side).

[zboldyga]

@remydubois

it seems to me this would only impact the case where reference is 'rest' -- the idea is to do OVR with control cells excluded from 'rest' / some reduction in the size of 'rest'. So it wouldn't impact OVO.

@ilan-gold @remydubois

that said, maybe in scanpy it could be reference_exclusion: list[str] ? listed right after 'reference' in the docs, with a comment like so: "if reference of 'rest' is used, any groups specified here are excluded from the reference union. Note that comparisons will still be performed for all groups in 'groups'; this parameter does not impact 'groups'."

and I assume we'd have a warning if it's specified when reference != 'rest', and also probably clarify it's role in stats computation in docs as well. And a little bit of guardrails to prevent specifying non-existing groups, or entirely removing the reference (all groups specified)... Would stick to scanpy patterns for these types of things.

and yes as for implementation, at least with the current pattern, the data could be filtered when the new AnnData object is created in scanpy, or something like that. I just wasn't sure if it would make sense to stop at that layer since it seems illico and scanpy are on a path to being tightly intertwined, and not passing this thru leads to later compatibility work (it's work either way I guess haha).

[remydubois]

it seems to me this would only impact the case where reference is 'rest' -- the idea is to do OVR with control cells excluded from 'rest' / some reduction in the size of 'rest'. So it wouldn't impact OVO.

Yes, agreed, sorry my answer wasn't clear. My point was more: we could also use this argument for the OVR path (at least on illico's side) as a way to filter groups. The motivation would be that one single argument (on illico's side) would serve the goal of two (both groups and exclude), considering illico does not implement group. But I'm aware that's kind of an api change (or at least usage change) from what you described and I dont have a strong opinion on that (nor would implement it if it didnt make sense for scanpy). My angle of reading is more "what could illico do to speed things up" considering that's its main reason to be, with a reasonable implementation budget (typically, one argument instead of two).

The only drawback I could see in rebuilding the AnnData manually is that it would maybe break the lazy loading capacity ? I'm not so sure about that though.

[ilan-gold]

The motivation would be that one single argument (on illico's side) would serve the goal of two (both groups and exclude), considering illico does not implement group

Taking a step back, maybe a return_dict argument would be applicable? What about this:

adata.uns["rank_genes_groups"] = scanpy.tl.rank_genes_groups(adata[subset_without_control], **kwargs, return_dict=True)

This is basically what is done in https://github.com/shiftbioscience/Diversity_By_Design/blob/main/data/norman19/get_data.py#L40