Re: [eigen] Failing basicstuff_3 test

[Benoit Jacob <jacob.benoit.1@xxxxxxxxx>]

2010/6/9 Jitse Niesen <jitse@xxxxxxxxxxxxxxxxx>:
> Hello,
>
> The basicstuff_3 test is failing on my computer (32-bits, gcc 4.1 and 4.3,
> both with and without SSE). However, it works fine on Gael's computer.
>
> The offending code is (with Scalar = complex<float> ):
>
>  Scalar s1 = ei_random<Scalar>(),
>         s2 = ei_random<Scalar>();
>
>  VERIFY(ei_real(s1)==ei_real_ref(s1));
>  VERIFY(ei_imag(s1)==ei_imag_ref(s1));
>  ei_real_ref(s1) = ei_real(s2);
>  ei_imag_ref(s1) = ei_imag(s2);
>  VERIFY(s1==s2);
>
> The last VERIFY fails. The bug is very finicky; changing almost anything and
> it goes fine. This is the best I could simplify it too:
>
>  complex<float> s1 = complex<float>(1.5,1.5);
>  complex<float> s2 = ei_random<complex<float> >();
>
>  VERIFY(jn_imag(s1)==jn_imag_ref(s1));
>  jn_real_ref(s1) = jn_real(s2);
>  jn_imag_ref(s1) = jn_imag(s2);
>  if (s1!=s2) {
>    std::cerr << s1-s2 << std::endl;
>    std::cerr << "Test failed!" << std::endl;
>  }
>
> Leaving out either the call to ei_random or the VERIFY and the bug goes
> away. When compiled with -O1 or higher, the test fails with s1-s2 =
> (-5.587935448e-09,2.328306437e-08);

This is with float? So the relative error is less than machine
epsilon? Then we shouldn't care about it, just do VERIFY_IS_APPROX
here. It's fine to try checking == in operations such as this one that
seem to be plausibly exact, but when in practice they aren't, there's
no point insisting :)

Benoit

 when compiled without optimization the
> test passes. What's interesting is that s1-s2 is so small. In fact, if I
> print s2, I find that s2 = (-0.2112341523,0.6803754568), which means that
> the difference is smaller than the distance between two single-precision
> floating point numbers.
>
> I guess that means that the bug has to do with the extended precision of the
> FPU. So, what to do now?
>
> Is there any way to check my guess? I guess definite proof comes from the
> generated assemble. I looked at the assembly (not something I know well),
> and it is full of Fxxx instructions, so it does use the FPU. However, it is
> rather more complicated that I'd have expected (there are FMUL in there), so
> it would take a lot of time for me to understand it. Any shortcuts I could
> take? Is it possible to force the FPU not to use extended precision?
>
> If the failing test is indeed caused by the extended precision, then it's
> not a bug and we should rewrite the test. Correct?
>
>
> Jitse
>
>
>