Note: This only happened on i686 and the test passed on x86_64.

The code that gets executed here is (simplified):

C++:
    #define PI 3.141592653589793238
    ...
    double atan2 = atan2(0-0,0-10);
    // note: atan2 is mathematically speaking an actual pi now
    return (atan2 == PI) ? 0
        : (atan2 < 0) ? (atan2 + PI)
        : atan2;

The routine returns 0 on x86_64 because the (atan2 == PI) condition passes.

On i686 it returns something else (3.14159265358979 ?) as the condition somehow doesn't pass.



But when I take the failing test:

    is line_direction([ [10, 0], [0, 0]  ]), (0),      'W direction';

and change it to:

    is line_direction([ [10, 0], [0, 0]  ]), (PI),     'W direction';

the test passes on i686, so the routine returned PI, which should not be possible.

It seems that the comparison (atan2 == PI) was false in C++, but true in Perl.

This sample program however:

    #include <iostream>
    #include <iomanip>
    #include <math.h>
    #define PI 3.141592653589793238
    int main(int argc, char **argv)
    {
      double pi = atan2(0, -10);
      std::cout << std::setprecision(35) << pi;
      if (pi == PI) std::cout << " == ";
      else std::cout << " != ";
      std::cout << PI << std::endl;
      return 0;
    }

Produces:

    3.1415926535897931159979634685441852 == 3.1415926535897931159979634685441852

in rawhide i686 mock. My head hurts :(

Rounding error? Is the manually defined constant PI representable on i686? Could you consider using M_PI constant provided by <math.h>?

Also if FPU is involved, there are different modes for handling saturation and other corner cases. Maybe perl or slic3r sets them in different mode that the other expects.

Probably a rounding error, yes.

It's not representable on any arch (considering i686 and x86_64), also as far as I know doubles are represented the same way on both.

Using M_PI doesn't help.

Recent version 1.2.9 does not suffer from this problem anymore.