I'm looking for a unit test which can ensure that my user's compiler has not made the reciprocal approximation $\mathrm{fl}(x/y) \approx \mathrm{fl}(x)*\mathrm{fl}(1/y))$ as an optimization. However, I have been unsuccessful in coming up with a compelling example.

It's fairly easy to come up with examples where $\mathrm{fl}(x/y) \ne \mathrm{fl}(x)*\mathrm{fl}(1/y)$, e.g.

1.3/2.9000= 0.4482758620689655

1.3*(1/2.9) = 0.4482758620689656

However, for two single numbers, the compiler might evaluate them at compile time and not make the reciprocal approximation, which defeats the point of my unit test to detect this. And even if the numbers are only known at runtime, single divisions are generally not optimized-only array divisions.

How can I design a sequence of double precision representables $x_i$ and a representable $y$ such that $\mathrm{fl}(x_i/y) \ne \mathrm{fl}(x_i)*\mathrm{fl}(1/y)$?

FWIW I'm using C++, though ostensibly that's of little relevance to the question.

Let $x$ and $y$ be representable floating point numbers. I'm looking for a unit test which can ensure that my user's compiler has not made the reciprocal approximation $\mathrm{fl}(x/y) \approx \mathrm{fl}(x)*\mathrm{fl}(1/y))$ as an optimization. However, I have been unsuccessful in coming up with a compelling example.

It's fairly easy to come up with examples where $\mathrm{fl}(x/y) \ne \mathrm{fl}(x)*\mathrm{fl}(1/y)$, e.g.

\begin{align*} \mathrm{fl}_{64}(1.3)/\mathrm{fl}_{64}(2.9) &= \mathrm{fl}_{64}(0.4482758620689655) \\ \mathrm{fl}_{64}(1.3)*(\mathrm{fl}_{64}(1)/\mathrm{fl}_{64}(2.9)) &= \mathrm{fl}_{64}(0.4482758620689656) \end{align*}

However, for two single numbers, the compiler might evaluate them at compile time and not make the reciprocal approximation, which defeats the point of my unit test to detect this. And even if the numbers are only known at runtime, single divisions are generally not optimized-only array divisions.

How can I design a sequence of double precision representables $x_i$ and a representable $y$ such that $\mathrm{fl}(x_i/y) \ne \mathrm{fl}(x_i)*\mathrm{fl}(1/y)$?

FWIW I'm using C++, though ostensibly that's of little relevance to the question.

I'm looking for a unit test which can ensure that my compiler has not made the reciprocal approximation $\mathrm{fl}(x/y) \approx \mathrm{fl}(x)*\mathrm{fl}(1/y))$ as an optimization. However, I have been unsuccessful in coming up with a compelling example.

It's fairly easy to come up with examples where $\mathrm{fl}(x/y) \ne \mathrm{fl}(x)*\mathrm{fl}(1/y)$, e.g.

1.3/2.9000= 0.4482758620689655

1.3*(1/2.9) = 0.4482758620689656

However, for two single numbers, the compiler might evaluate them at compile time and not make the reciprocal approximation, which defeats the point of my unit test to detect this. And even if the numbers are only known at runtime, single divisions are generally not optimized-only array divisions.

How can I design a sequence of double precision representables $x_i$ and a representable $y$ such that $\mathrm{fl}(x_i/y) \ne \mathrm{fl}(x_i)*\mathrm{fl}(1/y)$?

FWIW I'm using C++, though ostensibly that's of little relevance to the question.

I'm looking for a unit test which can ensure that my user's compiler has not made the reciprocal approximation $\mathrm{fl}(x/y) \approx \mathrm{fl}(x)*\mathrm{fl}(1/y))$ as an optimization. However, I have been unsuccessful in coming up with a compelling example.

It's fairly easy to come up with examples where $\mathrm{fl}(x/y) \ne \mathrm{fl}(x)*\mathrm{fl}(1/y)$, e.g.

1.3/2.9000= 0.4482758620689655

1.3*(1/2.9) = 0.4482758620689656

However, for two single numbers, the compiler might evaluate them at compile time and not make the reciprocal approximation, which defeats the point of my unit test to detect this. And even if the numbers are only known at runtime, single divisions are generally not optimized-only array divisions.

How can I design a sequence of double precision representables $x_i$ and a representable $y$ such that $\mathrm{fl}(x_i/y) \ne \mathrm{fl}(x_i)*\mathrm{fl}(1/y)$?

FWIW I'm using C++, though ostensibly that's of little relevance to the question.