How xplo matches Excel

[written by a human, by hand]

Emulation Accuracy

What is xplo trying to emulate?

Xplo is trying to emulate the computational behavior of 2024 Microsoft Excel for Windows - Long-Term-Support version 2408, specifically the Build 17932.20638, as evaluated on an Intel x86 processor.

We additionally support some functions from Microsoft 365 and Mac versions of Excel, so that users of either of those platforms don't need to worry about whether their functions are supported.

Internally, we think about the precision of our engine against this target.

How numerically precise is xplo?

Xplo is numerically precise enough for use in anything that was already relying on the numeric precision standards of Excel.

Excel has a variety of quirks in how it stores and computes numbers which are... esoteric. I highly recommend reading this Wikipedia article on how excel does its calculations, and some of the stranger side-effects of those choices. We made the early decision not to try to emulate this behavior overall (in order to avoid a performance penalty of >10x that was nescessary to do the byte-by-byte emulation), but we have made selective concessions to try to acheive equivalence in common cases. This often means our numbers are marginally different from Excel's when it comes to floating point noise - often less than 1 part in 1 trillion.

You can see the magnitude of these differences on our Excel compatibility dashboard, which shows the magnitude of differences introduced by these quirks.

How have you resolved structural issues?

We emulate excel behavior, even when it is wrong.

Through the process of building xplo, we've found (at least) six genuine errors in the excel engine, including well known bugs like the 1901 bug, but also (more recently) a solver that reports no solution when real roots exist. When we've run into these kinds of issues, we've tried to emulate excel's behavior so as to minimize diffs and avoid disrupting folks who may be relying on broken behavior.

How do you know?

Our approach to validation

Excel is a complicated engine, so when we set out to build a computation engine that was bit-for-bit equivalent to it, we knew the biggest challenge was going to be finding all of the edge cases - particularly because excel has so many functions that have undocumented behavior.

We spent months building out complex infrastructure that explored the state space of excel programmatically, and evaluated it for bit-for-bit parity against our engine. We used nuanced systems of code coverage to identify what changes would impact what cases. We built semi-automated agents that would try to fix deviations, while keeping human review in the loop to look for the (many) cases where agents would try to cheat to fix the tests.

While we don't share all of the details of this validation publicly, since it is the core piece of valuable work we've built, we have published a high-level summary of our core test suite, which we call our corpus so that you can see the same metrics that we track for how our engine is performing as we make tweaks to it.

If you're a prospective client that wants to learn more about this, please reach out!

Validating your own workbook

Xplo has an automatic check to ensure that when our engine recomputes your spreadsheet for the first time (with no overrides) the results match the saved/cached values in your excel spreadsheet. If your spreadsheet doesn't have those values (which can happen if your spreadsheet was minimized for size, or if it was built through a library), we'll execute it on production Microsoft Excel to compute it authoritatively, and then you can look at a report that details any and all differences between xplo's execution of your workbook, and Excel's.

This doesn't guarantee perfect parity on all scenario computations, but it's a very good indicator of the level of precision you can expect out of xplo.

You can find this as the "Compatibility Report" option on any executed workbook.