Floating-Point Order and Reproducibility Lab

Floating-point arithmetic follows finite computer representations, not the exact rules of real-number algebra. This short lab makes that difference visible.

Goal

Show that regrouping the same floating-point values can change the computed result, then explain why a performance optimization may trade away reproducibility.

Activity

Run this Kotlin program:

fun main() {
    val a = 1.0e16
    val b = -1.0e16
    val c = 1.0

    println((a + b) + c)
    println(a + (b + c))
}

Then:

1. Record both outputs.
2. Calculate both expressions as exact real-number arithmetic.
3. Identify where the small value is lost in the computer calculation.
4. Read the Rust 1.98 explanation of its new algebraic floating-point methods. Those methods permit reordering for optimization and may produce different results across compiler choices.

Deliverable

Submit the two outputs and a three-sentence explanation:

• Why are the mathematical expressions equivalent?
• Why can the computer results differ?
• When would speed matter more than bit-for-bit reproducibility, and when would reproducibility matter more?

Discussion

Floating-point addition is not associative in ordinary computer arithmetic. Reordering can enable faster vectorized work, but it may change results. Financial totals, scientific comparisons, tests and preserved data pipelines may need stricter reproducibility than graphics or approximate simulations.

Source material

This lab first appeared in the PTIR Morning Briefing for August 21, 2026. Rust 1.98 introduced explicit algebraic floating-point methods that let the compiler reorder operations for optimization while warning that the result can be nondeterministic. That made the release a useful starting point for a language-independent lesson on representation, optimization and reproducibility.

Consult the authoritative source: Rust 1.98 release announcement.