# 1+x not backwards stable?

If you compute 1+x for x less than the machine precision, the answer will be 1 which is the exact result for x = 0. But this would then imply that the relative backward error is |0 - x| / |x| = 1, i.e. this method is not backwards stable and no method based on standard floating point arithmetic can ever be.

It feels like this finding must be wrong, because how can what is literally the simplest possible operation not be backwards stable? So where is fault in the above reasoning?

• The relative error is $(1+x-1)/(1+x) = x/(1+x) \approx x$ which is small since $x$ is small. – cfdlab Dec 1 '18 at 2:59
• But that's the forward error. What confused me is that people usually call backwards stability the "gold standard" that every algorithm should aim for. – gTcV Dec 1 '18 at 18:09
• You are right, it is not backward stable. – cfdlab Dec 2 '18 at 2:43

Suppose $$y$$ is the result of an approximate computation, that $$y\approx1$$, and we're trying to compute $$y+x$$ with $$x\approx0$$. With this trivial change, the computation is now backward stable: any small absolute perturbation in $$x$$ is equivalent to a small relative perturbation in $$y$$, giving a small relative backward error.
So I think the second reason why $$1+x$$ not being backward stable is surprising is that it is legitimately surprising. Its backward stability depends on some fairly small details of how you define the problem. In particular, in a real numerical program, it might not be a priori obvious whether $$1+x$$ or $$y+x$$ is the right way to think about your program's behaviour. Different people might end up modelling program behaviour differently.