From 1639c3ba633e4fbf8c4945b2ceb1d7ca1a6d8075 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Janek=20Warcho=C5=82?= Date: Wed, 13 Mar 2013 18:36:35 +0100 Subject: [PATCH 2/2] add a comment explaining numerical accuracy issues Until now we rejected buildings narrower than epsilon to avoid numerical inaccuracy. However, testing suggests that this is not a problem. This patch allows extremely narrow buildings to be added to skylines, so that grobs with widths smaller than epsilon can be used to position elements. --- lily/skyline.cc | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/lily/skyline.cc b/lily/skyline.cc index 9908c61..3f52d82 100644 --- a/lily/skyline.cc +++ b/lily/skyline.cc @@ -54,6 +54,25 @@ a DOWN skyline with an UP skyline, we need to flip the DOWN skyline first. This means that the merging routine doesn't need to be aware of direction, but the distance routine does. + + Be careful about numerical accuracy. When dealing with extremely small values, + computation errors may arise due to the use of floating point arithmetic. + For example, if left and right have equal values to start with, in C++ + they may not receive the same value after + + left = left*factor + offset; + right = right*factor + offset; + + Which is very unfortunate. Maybe using GCC compiler options to disallow + extended precision for intermediate results and/or the choice to store + intermediates with less than full precision would retain some kind of + deterministic behavior that way. + + Anyway, it seems that accepting extremely narrow building in skylines + doesn't cause accuracy problems to us, so we allow arbitrarily small buildings. + However, as Keith pointed out, problems may appear if more than one operation + is done before storing the result, and/or there are different code paths + for doing the operations to the different ends of an interval. */ static void -- 1.7.9.5