Create a more robust solution to spatial round-off errors

[hakonsbm]

Follow-up issue from #2037. #2037 adds epsilon values to some comparisons to avoid issues from round-off errors. We should find a more robust way to handle these errors.

@heplesser Wrote for the following lines:

https://github.com/nest/nest-simulator/blob/66592444caddc0acea5f00439d7ac281f9fc815a/nestkernel/ntree_impl.h#L399-L400 My main concern is that this test will work as long as coordinates are close to 1, but of they are much smaller or larger, we need to consider relative error. I would feel more comfortable with an approach where we explicitly pad boundaries in some consistent way.

@heplesser also suggested the following (see https://github.com/nest/nest-simulator/pull/2037#issuecomment-855588420):

The rounding problems result from the fact that we do arithmetic on corners, extents and positions (and anchors) in various places in a way that leads to internal inconsistencies. I believe now that by creating definite (canonical) values and then only using comparison operations between them, we can avoid any internal inconsistencies.

• There is exactly one method that shifts positions according to anchors.
• There is exactly one method that maps a position into the extent according to periodic boundary conditions.
• The previous two points ensure that we have "canonical" position values that will always be the same for the same input position. Only this canonical position will be used in all further operations.
• Each ntree quad gets both a lower_left_ and and upper_right_ member. Upon splitting, we only compute the lower-left value of the right part of the split and then set upper-right value of the left part to exactly the same value.
• Assuming left-closed, right-open intervals, using (ll <= x) and (x < ur) comparisons then will give consistent results, where x is a canonical position.
• If x < ur comparisons are explicitly required (instead of doing everything with ll <= x, then positions located on the right edge of the extent would always be excluded. We might want to define it like this on principle to avoid problems with periodic boundary conditions, where positions on the right edge of the extent would be also on its left edge.

[github-actions[bot]]

Issue automatically marked stale!