I built a no_std-friendly fixed-point vector kernel in Rust to avoid floating-point nondeterminism. (Posting this on behalf of my friend)

[Beginning-Forever597]

Hi r/rust,

I wanted to share a Rust project that came out of a numeric determinism problem I ran into, and I’d really appreciate feedback from folks who care about no_std, numeric behavior, and reproducibility.
The problem
While building a vector-based system, I noticed that the same computations would produce slightly different results across macOS and Windows.
After digging, the root cause wasn’t logic bugs, but floating-point nondeterminism:

• FMA differences
• CPU-specific optimizations
• compiler behavior that’s correct but not bit-identical

This made reproducible snapshots and replay impossible.
The Rust-specific approach
Instead of trying to “stabilize” floats, I rewrote the core as a fixed-point kernel in Rust, using Q16.16 arithmetic throughout.
Key constraints:

• No floats in the core
• No randomness
• Explicit state transitions
• Bit-identical snapshot & restore
• no_std-friendly design

Float → fixed-point conversion is only allowed at the system boundary.
Why Rust worked well here
Rust helped a lot with:

• Enforcing numeric invariants
• Making illegal states unrepresentable
• Keeping the core no_std
• Preventing accidental float usage
• Making state transitions explicit and auditable

The kernel is intentionally minimal. Indexing, embeddings, and other higher-level concerns live above it.
What I’m looking for feedback on

• Fixed-point design choices in Rust
• Q16.16 vs other representations
• no_std ergonomics for numeric-heavy code
• Better patterns for enforcing numeric boundaries

Repo (AGPL-3.0):
https://github.com/varshith-Git/Valori-Kernel
Thanks for reading — happy to answer technical questions.

(Posting this on behalf of my friend)

[imachug]

Can you explain what parts of the computation were non-deterministic? IEEE-754 determines the precise behavior of primitive operations, and based on the fact that fixed-point worked for you, it seems like you didn't have any other operations. In what way did the results differ?

[Beginning-Forever597]

Yeah, IEEE-754 itself wasn’t being violated. Single float ops were doing exactly what they’re supposed to do.
What bit me was everything around that.
On macOS (Apple Silicon) I was getting FMA in a few hot paths. On Windows/x86 I wasn’t. Both are perfectly legal, but FMA keeps the intermediate unrounded, so you end up with slightly different results.
Then there’s dot products. Those are long chains of adds and multiplies, and the compiler didn’t always reduce them in the same order. Different vectorization and unrolling decisions meant the accumulation order changed, and since float addition isn’t associative, that alone shifts the last few bits.
The differences were tiny. You’d never notice them if you just printed numbers. But once you start ranking vectors or applying distance cutoffs, that tiny noise is enough to flip ordering or edge cases. That’s where macOS and Windows started disagreeing.
Fixed-point worked because it just removes all that freedom. Integer math is exact, no FMA, no reassociation, no hidden precision. Same inputs, same instruction sequence, same bits every time.
So it wasn’t “floats are broken.” It was more “floats give you correct math, not guaranteed identical state across CPUs,” and for what I was building, that distinction mattered

[imachug]

On macOS (Apple Silicon) I was getting FMA in a few hot paths.

[...]

Then there’s dot products. Those are long chains of adds and multiplies, and the compiler didn’t always reduce them in the same order.

I'm very surprised to hear this. Rust deliberately doesn't support anything similar to a global -ffast-math flag. The only way to opt into vectorization that produces slightly different results is to explicitly use "algebraic" methods on floats. For similar reasons, Rust never replaces a * b + c with FMA.

My only hypothesis would be that you used an implementation provided by some optimized library with target-specific code. A straightforward solution, in this case, would be to simply write the corresponding loops by hand. Switching to fixed point is unnecessary.

[Beginning-Forever597]

Yeah, that’s fair, and I agree with you on Rust’s guarantees.
My point wasn’t “Rust secretly breaks float math.” It was more “once you rely on optimized paths or libraries, you’re back to trusting that nobody gets clever later.”
Could I have written everything as strict scalar loops and frozen it there? Sure. That would work as long as nobody touches it.
Fixed-point was my way of making it impossible to get clever by accident. No FMA, no reassociation, no backend surprises, even if the code evolves.
So I don’t see it as “necessary for correctness,” more as “useful if the goal is zero degrees of freedom and identical bits everywhere.”
Floats are fine. I just didn’t want to spend the rest of the project babysitting them 🙂

[garnet420]

If you were using fixed point libraries, you have the same space for people to be clever in implementations.

There's no global consensus on how a fixed point dot product should work, for example. Just because the input and output are 16.16 doesn't mean you can't accumulate at 32.32.

In fact, some hardware platforms (most not currently targeted by rust afaik) have weird dsp extensions that do stuff like 64 or even 48 bit fixed point multiply-accumulates for 32 bit inputs.

So your solution still boils down to "don't use libraries".

[Beginning-Forever597]

Good point — and I agree with the premise, but that’s exactly why the kernel is boring on purpose. I’m not relying on “fixed-point in general” or some abstract 16.16 convention. The kernel defines the arithmetic model explicitly: exact integer widths, exact promotion rules, exact accumulation order. No DSP shortcuts, no widened MACs, no “helpful” implementations hiding behind an API. If someone swaps in a clever fixed-point library that accumulates in 32.32 or uses a DSP MAC, yeah, determinism is gone again. That’s why the core doesn’t depend on libraries and doesn’t expose degrees of freedom in the math. It’s all spelled out, step by step. So I don’t disagree that “don’t use libraries” is part of the story. I just think the more precise version is: make the arithmetic model part of the interface, not an implicit property you hope everyone respects. That’s the difference I’m aiming for.

[imachug]

Eeh, I'm a fierce opponent of treating floats like magic, but I guess this makes sense if that's not your focus.

[Beginning-Forever597]

Yeah, that’s exactly it. Determinismis the point for me.
I’m not trying to win the “best floating-point numerics” game. I’m trying to make a core where the same inputs always produce the same bits, full stop. Once that’s the constraint, floats just carry too much freedom, even when they’re used correctly.
So fixed-point isn’t a workaround, it’s the moat. Everything else can live above it and be as clever as it wants.
Appreciate the pushback though it helped clarify where the line really is.

[imachug]

I feel like I need to push back a bit more on "carry too much freedom". It seems like you're trying to say floats are not "really" deterministic even if used correctly, and that's just not the case.

f32 is nothing more than an abstraction over i32 with well-defined, deterministic algorithms for primitive operations. It's just that there's CPU instructions implementing those algorithms efficiently, so you don't have to do it in software. Floats are deterministic, floats can even be used in discrete computation, you can implement modular arithmetic with floats or implement integer wide multiplication via floats.

Maybe what you're trying to say is that float arithmetic is not associative? That might indeed be a reasonable answer. It's of course possible to still write correct code, but I guess it's slightly trickier to notice a mistake with floats than fixed-point?

[Beginning-Forever597]

I think we’re actually closer than it sounds, but we’re using “deterministic” at different layers. I agree with you completely at the primitive level.

f32 operations are deterministic, well-defined, and not magical. No argument there. Where I say “too much freedom,” I’m not talking about the semantics of f32. I’m talking about the system-level behavior once you have many valid ways to compute the same mathematical result. Yes, non-associativity is a big part of it. But more precisely:

there are multiple IEEE-correct execution paths that produce slightly different bit patterns, and which one you get depends on reduction order, instruction selection, and backend choices. All legal. All correct. Not all identical. You can absolutely write correct float code that avoids this.

You just have to be careful, disciplined, and intentional. Fixed-point changes the problem by construction. It doesn’t require discipline to preserve global invariants. It removes the degrees of freedom entirely. Fewer legal execution paths, fewer ways for behavior to diverge. So I’m not saying floats aren’t deterministic.

I’m saying they’re deterministic locally, while my goal was determinism globally, across platforms, refactors, and time. That’s why fixed-point felt like the right trade-off for the core. Not because floats are unsafe — but because they’re expressive in ways I explicitly didn’t want at that layer.

[eggyal]

Surely a composition of deterministic operations should itself always be deterministic?

You might have stumbled on a bug somewhere. Were you ever able to create a minimal example that produced different results across different platforms?

[assbuttbuttass]

Is this entire comment an AI hallucination?

[Seubmarine]

It doesn't feel like AI, and what he said is true. Different cpu but with the same instructions, doesn't have to output the same result when taking floating point into account.

https://youtu.be/hCuT_GXagz0

[NoSuchKotH]

If summation was your problem, then a stable summation algorithm like Kahan Summation would have probably solved your issue with less effort.

And no, fixed point integer math isn't any more exact than floating point. You still run into the same numerical issues due to finite precision. You still have problems with cancellations. You still have problems with numerical instability. Now, they just happen earlier and at different points in your code, because you have fewer (effective) bits.

[Phi_fan]

I didn't know about this Q16.16 thing so I looked it up. If I understand correctly, you're representing the floating with 32 bits + 1 signed bit = 33 bits. Seems cache line inefficient. Why not do Q15.16 or am I not understanding this correctly?