Skip to content
#software testing Open access

PyFgsea: GSEA in Python and Rust

Sep 2026 · Zenodo (CERN European Organization for Nuclear Research)

Abstract

PyFgsea 0.2.0 Release date: 2026-09-02. PyFgsea 0.2.0 updates the statistical core used by the high-level Python API and narrows the trajectory interface to functions that are implemented and tested. The paper remains reproducible with its original software pair; current comparisons use a separate, newer reference pair. Highlights mode="aligned" and score_type="std" are the high-level defaults. Aligned mode uses exact pathway sizes (bin_width=0). Gene-ID ordering makes tied ranks deterministic. Unresolved and failed pathways remain visible in the result table. Results include tail-depth, error, termination, approximation, pathway-size, ranking, and algorithm-revision fields. The supported trajectory API is run_trajectory_gsea; unfinished public helpers and the incomplete trajectory CLI have been removed. DPT computation requires an explicit root and preserves root identity when cells are filtered or subsetted. The low-level build_tail_curve and query_tail_curve helpers remain available but are deprecated. They implement the approximate legacy-empirical-tail-v1 method, not the aligned estimator. Reference comparisons The two reference lanes answer different questions and should not be pooled: | Lane | PyFgsea | R | Bioconductor | fgsea | Purpose | | --- | --- | --- | --- | --- | --- | | publication | 0.1.4 | 4.4.3 | 3.20 | 1.32.2 | reproduce the comparison reported in the paper | | current | 0.2.0 | 4.6.0 | 3.23 | 1.38.0 | evaluate the current implementation | On the 100-pathway publication input, the publication lane reproduced the reported values after rounding: ES RMSE 3.84e-16; NES Pearson 0.999967, Spearman 0.999676, and RMSE 0.01333; transformed-p Pearson 0.997199, Spearman 0.988318, and RMSE 0.16960. On the same input, the current lane gave ES RMSE 3.21e-16; NES Pearson 0.999952, Spearman 0.999652, and RMSE 0.01567; transformed-p Pearson 0.999069, Spearman 0.996628, and RMSE 0.11826. A separate 60-pathway tie-heavy case exposes a 0.1.4 limitation. Its legacy NES RMSE was 0.29868; the current implementation reduced it to 0.01558 while restoring machine-precision ES agreement. This sensitivity case was not the publication input. Across 20 fixed score-permutation replicates, the current installed package returned all 2,000 planned null pathways. The pooled mean and median nominal p-values were 0.4991 and 0.5010; the proportions below 0.01, 0.05, and 0.10 were 0.0065, 0.0430, and 0.0935. These are descriptive summaries, not a fitted acceptance threshold. The original speed and memory values are not carried forward because the current run did not measure all tools under one matched scope. Figure 2 scope The accepted trajectory parameters are window_size=500, step=50, nperm_nes=2000, score_type="std", exact pathway sizes, bin_width=0, and NES caching off. The reassembled figure uses a processed 3,576-cell erythroid subset from GSE155254 with precomputed UMAP coordinates and DPT. Panel D ranks genes from scaled adata.X; the frozen object has no separate raw or named log1p layer. Public assignment tables match 2,097 control and 816 gata307mut cells, while 663 cells remain unmatched. The figure pools these groups and is descriptive, not a control-versus-mutant comparison. Benjamini-Hochberg adjustment is performed across pathways within each window and is not trajectory-wide error control. Migration from 0.1.4 The defaults intentionally differ: | Setting | 0.1.4 | 0.2.0 | | --- | --- | --- | | high-level score type | two_sided_abs | std | | estimator | implicit legacy behavior | mode="aligned" | | pathway-size binning | None | 0 (exact size) | | trajectory step | 100 | 50 | | trajectory NES permutations | 100 | 2000 | | trajectory NES cache | on | off | For new analyses, state the numerical contract explicitly: result = pyfgsea.run_gsea( data=ranks, gmt=pathways, gene_col="gene", score_col="score", mode="aligned", score_type="std", bin_width=0, seed=42, ) Install trajectory dependencies with: python -m pip install "pyfgsea[trajectory]" score_type="two_sided_abs" remains available for a bounded legacy-like calculation, but it is approximate and is not equivalent to fgseaMultilevel(scoreType="std"). The Python API does not accept an n_threads keyword. Packaging and paper impact Cargo.toml is the single version source for the Rust crate and Python distribution. Release packages are built as source distribution and platform wheels, installed into fresh environments, and tested through the installed Python package and native core. The two R reference images are also started and checked at runtime. The manuscript review is classified as a numerical and methods correction whose central software-concordance conclusion remains intact. The detailed decision note and claim matrix identify the text and values to keep, qualify, update, or remove. Limits The formal comparison covers the publication input and one predeclared tie-heavy sensitivity case; it is not a universal equivalence claim. Correlation and pathway overlap do not establish algorithmic identity or biological correctness. The Figure 1 run does not provide matched current benchmarks against GSEApy or BlitzGSEA. Runtime and peak memory remain hardware- and scope-dependent. Fast mode and the legacy empirical-tail helpers are approximate.

View source

Similar papers

#computer vision Review Sep 2017

Agile Software Development Methods: Review and Analysis

Agile - denoting "the quality of being agile, readiness for motion, nimbleness, activity, dexterity in motion" - software development methods are attempting to offer an answer to the eager business community asking for lighter weight along with faster and nimbler software development processes. This is especially the case with the rapidly growing and volatile Internet software industry as well as for the emerging mobile application environment. The new agile methods have evoked substantial amount of literature and debates. However, academic research on the subject is still scarce, as most of existing publications are written by practitioners or consultants. The aim of this publication is to begin filling this gap by systematically reviewing the existing literature on agile software development methodologies. This publication has three purposes. First, it proposes a definition and a classification of agile software development approaches. Second, it analyses ten software development methods that can be characterized as being "agile" against the defined criterion. Third, it compares these methods and highlights their similarities and differences. Based on this analysis, future research needs are identified and discussed.

P. Abrahamsson, O. Salo, Jussi Ronkainen et al. · 728 citations · ⚡54
#machine learning Review Open access Oct 2014

Software development in startup companies: A systematic mapping study

Context: Software startups are newly created companies with no operating history and fast in producing cutting-edge technologies. These companies develop software under highly uncertain conditions, tackling fast-growing markets under severe lack of resources. Therefore, software startups present a unique combination of characteristics which pose several challenges to software development activities. Objective: This study aims to structure and analyze the literature on software development in startup companies, determining thereby the potential for technology transfer and identifying software development work practices reported by practitioners and researchers. Method: We conducted a systematic mapping study, developing a classification schema, ranking the selected primary studies according their rigor and relevance, and analyzing reported software development work practices in startups. Results: A total of 43 primary studies were identified and mapped, synthesizing the available evidence on software development in startups. Only 16 studies are entirely dedicated to software development in startups, of which 10 result in a weak contribution (advice and implications (6); lesson learned (3); tool (1)). Nineteen studies focus on managerial and organizational factors. Moreover, only 9 studies exhibit high scientific rigor and relevance. From the reviewed primary studies, 213 software engineering work practices were extracted, categorized and analyzed. Conclusion: This mapping study provides the first systematic exploration of the state-of-art on software startup research. The existing body of knowledge is limited to a few high quality studies. Furthermore, the results indicate that software engineering work practices are chosen opportunistically, adapted and configured to provide value under the constrains imposed by the startup context.

Nicolò Paternoster, Carmine Giardino, M. Unterkalmsteiner et al. · 394 citations · ⚡54
#computer vision Open access Jul 2017

What happens when software developers are (un)happy

The growing literature on affect among software developers mostly reports on the linkage between happiness, software quality, and developer productivity. Understanding happiness and unhappiness in all its components -- positive and negative emotions and moods -- is an attractive and important endeavor. Scholars in industrial and organizational psychology have suggested that understanding happiness and unhappiness could lead to cost-effective ways of enhancing working conditions, job performance, and to limiting the occurrence of psychological disorders. Our comprehension of the consequences of (un)happiness among developers is still too shallow, being mainly expressed in terms of development productivity and software quality. In this paper, we study what happens when developers are happy and unhappy while developing software. Qualitative data analysis of responses given by 317 questionnaire participants identified 42 consequences of unhappiness and 32 of happiness. We found consequences of happiness and unhappiness that are beneficial and detrimental for developers' mental well-being, the software development process, and the produced artifacts. Our classification scheme, available as open data enables new happiness research opportunities of cause-effect type, and it can act as a guideline for practitioners for identifying damaging effects of unhappiness and for fostering happiness on the job.

D. Graziotin, Fabian Fagerholm, Xiaofeng Wang et al. · 236 citations · ⚡13
#computer vision Open access Oct 2004

Mobile-D: an agile approach for mobile application development

Mobile phones have been closed environments until recent years. The change brought by open platform technologies such as the Symbian operating system and Java technologies has opened up a significant business opportunity for anyone to develop application software such as games for mobile terminals. However, developing mobile applications is currently a challenging task due to the specific demands and technical constraints of mobile development. Furthermore, at the moment very little is known about the suitability of the different development processes for mobile application development. Due to these issues, we have developed an agile development approach called Mobile-D. The Mobile-D approach is briefly outlined here and the experiences gained from four case studies are discussed.

P. Abrahamsson, Antti Hanhineva, H. Hulkko et al. · 225 citations · ⚡18

Related blog posts

MIT News · Artificial Intelligence Aug 17, 2026

Q&A: Rethinking how innovation happens

In his latest book, Professor Eugene Fitzgerald examines the forces that turn breakthroughs into value — and why innovation resists simple formulas.