Compute! Paris

In 2001, a physics student put off his thesis to write a tool for working with Python interactively. It became IPython, then Jupyter, winning the ACM Software System Award and counted by Nature among ten pieces of code that deeply transformed science.

25 years on, he has helped build the open ecosystem around it: co-founder of nonprofits NumFOCUS and 2i2c, director of the Berkeley Institute for Data Science, co-director of the Eric and Wendy Schmidt Data Science and Environment Center, and now working on open source and AI tools for health care.

In 2001, a physics student put off his thesis to write a tool for working with Python interactively. It became IPython, then Jupyter, winning the ACM Software System Award and counted by Nature among ten pieces of code that deeply transformed science.

Its idea was simple: you write code, see the result, decide what to try next, and think in tandem with the computer. Now AI can write the code, run it and even choose the next step. What does thinking alongside the machine mean in this new era?

Pharo is a programming language where everything is a live object you can inspect and change while the program keeps running. At Compute! Paris, @marcusdenker.bsky.social shows what that makes possible for data work.

- Moose, where you interactively build custom analyses over large models - Phausto, where you compose synthesizers as live objects and hear every change instantly.

Pharo is a programming language where everything is a live object you can inspect and change while the program keeps running. At Compute! Paris, @marcusdenker.bsky.social shows what that makes possible for data work.

A bouncing-particle Python simulation in the browser: 91 KB of SPy compiled to WebAssembly, versus 10 MB of PyScript. That's one of three live demos of SPy, a new statically compiled language that looks like Python, compiles to native code and WebAssembly, and starts as fast as Go.

At Compute! Paris, Pierre Augier makes the case that SPy could be the companion language Python has always needed, one that tackles the two-language wall (Python on top, C, C++ or Fortran underneath) without asking anyone to leave Python.

Free text in, dataframe columns out. That's the promise of LLM-based extraction, until the model returns JSON that doesn't parse and your batch job dies halfway through.

At Compute! Paris, @alonsosilva.bsky.social shows why combining both beats either alone, through real applications: extracting fields from unstructured text, classifying at scale for categorical features, and pulling out entities and relations to enrich your data.

Free text in, dataframe columns out. That's the promise of LLM-based extraction, until the model returns JSON that doesn't parse and your batch job dies halfway through.

AlphaEarth, TerraMind, TESSERA, Copernicus-FM: Earth observation now has more foundation models than anyone has time and capacity to test. At Compute! Paris, Gijs van den Dool offers a practical way out of this model fatigue.

How to evaluate models on your own use case with accessible open-source tools, and how to run those tests in parallel on standard cloud GPUs, no HPC cluster needed. One early finding: combining features from several models beats any single one.

AI can extract scientific facts from a paper. But can it understand the relationships between them? At Compute! Paris, Feryal Batoul Talbi presents OntoGeoRAG, an open-source pipeline that turns scientific PDFs into knowledge graphs.

Not random, they fall exactly where the meaning lies in the relationships themselves, which way a link runs, wheter it is a cause or association, or a step an expert infers across sentences. Illustrated with geophysics, this is built to generalize to other fields.

AI can extract scientific facts from a paper. But can it understand the relationships between them? At Compute! Paris, Feryal Batoul Talbi presents OntoGeoRAG, an open-source pipeline that turns scientific PDFs into knowledge graphs.

It's tested against an expert-built benchmark in a hard domain: mass-transport deposits in subsurface geophysics with ambiguous terminology and lots of implicit geological reasoning.

The smallest unit of science to trust isn't a paper, it's a single claim. At Compute! Paris, Anne Fouilloux and Jean Iaquinta explore "nanopublications": small, cryptographically verifiable, machine-readable claims you can cite, link, and trust.

The talk draws on a year spent replicating 30+ published claims in ecology, biodiversity, and climate science. Recurring failure modes surfaced (biased representation choices, priors that strongly sway results, hidden train/test leakage), each catalogued with how to catch it.

One row inserted or deleted seems innocent enough, but with ordinary Parquet, it shifts every row after it into a different page than before. And once a page's rows change, its compressed bytes come out entirely different.

Rows untouched by an edit fall back into the exact same pages as before, remain byte-identical, and deduplicable nicely. Simple examples first: append, insert, delete, and the actual bytes saved on each. Then the real numbers, straight from that 100PB+ platform.

One row inserted or deleted seems innocent enough, but with ordinary Parquet, it shifts every row after it into a different page than before. And once a page's rows change, its compressed bytes come out entirely different.

This in turn breaks deduplication: storage systems that deduplicate, crucial for running 100PB+ stores like Hugging Face's, work by spotting identical bytes and storing them only once, so changing all bytes means nothing is left to deduplicate.

For years, Google Earth Engine has been the only real option for scientists who want to run algorithms across petabytes of satellite data and see results fast. That's starting to change.

Deployable in-browser via JupyterLite and notebook.link ! The talk includes a real-world case study from CNES (French space agency): snow detection over the Pyrenees using Sentinel-2 data, comparing OpenEO’s reproducible processing graphs with Xarray-driven computation with jupyter-tiler.

For years, Google Earth Engine has been the only real option for scientists who want to run algorithms across petabytes of satellite data and see results fast. That's starting to change.

Statistical distributions directly in Polars. No .to_numpy(), no round-trip through scipy.stats, no broken laziness or GIL lock. Just Normal(mu=..., sigma=...).cdf(x), one distribution per row, fully vectorized, lazy all the way through.

While that's all neat, the talk's spicy part is the design history: abstractions they built and removed, parameterizations they flipped, the null-vs-panic contract they rewrote after hitting bad rows in production at scale. Benchmarks against scipy + Polars included.

Statistical distributions directly in Polars. No .to_numpy(), no round-trip through scipy.stats, no broken laziness or GIL lock. Just Normal(mu=..., sigma=...).cdf(x), one distribution per row, fully vectorized, lazy all the way through.

Slow down! Drive-by-plotting is not allowed at Compute! Paris this November: @amy8492.bsky.social takes you through deliberately visualizing Open Food Facts, a real, messy, multi-gigabyte open dataset.

You'll understand the Grammar of Graphics underneath (marks, encodings, the four encoding types), how to keep a chart responsive on gigabytes of data by pushing aggregation upstream to Polars or DuckDB, and leave with a sharper eye for every chart you see afterwards. No Altair experience required.

Slow down! Drive-by-plotting is not allowed at Compute! Paris this November: @amy8492.bsky.social takes you through deliberately visualizing Open Food Facts, a real, messy, multi-gigabyte open dataset.