Opened 4 years ago

Closed 3 months ago

#43 closed defect (fixed)

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

Reported by: Maciej Komosinski Owned by:
Priority: major Milestone:
Component: Framsticks core Version:
Keywords: Cc:

Description (last modified by 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.

Change History (4)

comment:1 Changed 3 years ago by Maciej Komosinski

Description: modified (diff)

comment:2 Changed 3 years ago by Maciej Komosinski

Description: modified (diff)

comment:3 Changed 5 months ago by Maciej Komosinski

Description: modified (diff)

comment:4 Changed 3 months ago by Maciej Komosinski

Resolution: fixed
Status: newclosed

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.

Note: See TracTickets for help on using tickets.