> one strategy to consider would be to build the error bound computation as a function into your math operations

That's autodiff! :D The error (change) in a function's output given an error (change) in its input is the definition of its derivative.

So I guess I can use my autodiff algorithm to compute the error bounds for testing my autodiff algorithm! ... Uhm.

Actually, though, I want _one_ error bound, not one that varies per run. But I guess you can do the same thing symbolically: you just end up with

1. a slightly-too-optimistic bound because you will (for practicality) discard higher-order e terms;

2. a conservative bound because you'll be pessimistic in the face of control flow, array sizes, etc. where the precise operations performed depend on the input.

I guess this symbolic approach works until you have unbounded sequential loops (which pessimistically have unbounded error, because it may accumulate indefinitely). Or perhaps it breaks down already with arbitrary-size arrays; what is rhe error bound on `lambda x. sum([x]*n)`, assuming n is unknown? (Using python syntax as "universal syntax".)

> then you can query the error from a parse tree of different math ops, or something like that.

If there is no dynamic control flow nor variable-size data structures etc. in that parse tree, I suspect they do kind of what I hand-wavingly described above.

It's not perfect enough that I'm going to implement this approach immediately (variable-size arrays are kind of core to what I want to do). But perhaps there's some trick I can pull out of this. Thanks for the ideas!