ModelGeometry: sizes and orientations depend on sampling density and model orientation

[Maciej Komosinski]

Testing a ball (genotype //0\np:sh=1,ry=1\n) - balls have no specific orientation and are perfectly symmetrical so this might be an excuse for such dependence, yet... look at the example below. The first value in a line is the sampling density (0.1, 1, 2.5 or 4.3217452):

Windows+Visual Studio 2013 compilation, %g:

0.1 12.5664 0 [(2.0,2.0,2.0),Orient@(-0,1,0)]
1 12.5664 1.01829 [(2.0,2.0,2.0),Orient@(-0,1,0)]
2.5 12.5664 1.98001 [(2.0,1.9986484217435,1.97326669133902),Orient@(-0.415242,0.498119,0.472743
)]
4.32175 12.5664 2.97095 [(2.0,2.0,2.0),Orient@(-0,1,0)]

Windows+Visual Studio 2017 debug compilation, %.17g:

0.10000000000000001 12.566370614359172 0 [(2.0,2.0,2.0),Orient@(-0,1,0)]
1 12.566370614359172 1.2728649512171213 [(2.0,2.0,2.0),Orient@(-0,1,0)]
2.5 12.566370614359172 2.2275136646299623 [(2.0,1.9986484217435,1.97326669133902),Orient@(-0.415242,0.498119,0.472743)]
4.3217451999999996 12.566370614359172 3.1994853921717938 [(2.0,2.0,2.0),Orient@(-0,1,0)]

So for density=2.5, the computed orientation is weird.

Same test, this time linux+gcc, different result (%g for now):

0.1 12.5664 0 [(2.0,2.0,2.0),Orient@(-0,1,0)]
1 12.5664 1.01829 [(2.0,2.0,2.0),Orient@(-0,1,0)]
2.5 12.5664 1.98001 [(2.0,2.0,2.0),Orient@(-0,1,0)]
4.32175 12.5664 2.97095 [(2.0,2.0,2.0),Orient@(-0,1,0)]

Identify causes of this influence/non-determinism and eliminate if possible.

[Maciej Komosinski]

After improving the serialization of Orient (so that it uses full precision) and using custom floating-point printing procedure (Dragon4), the results became identical for gcc (linux) and VS2017 (windows).

C++Builder 10.3 (windows) which uses the clang compiler yields usually very similar results (with minor differences ~10e-13) and in rare cases, very different results. For example, for Foraminifera (twisted biserial) with genotype id=458, differences in area, volume, sizesaxes are in the range of 0.1. Another example is Worm with genotype id=465, where only the area differs significantly from gcc/VS2017 (the difference is ~0.1).

Anyway I am closing this issue since we are aware that different compilers may use different implementations of floating point operations. The main issue was that "sizes and orientations depend on sampling density and model orientation", and this is caused by the very nature of the method responsible for geometry calculations (and using floating point values), unfortunately.