On Sun, 17 Feb 2013 02:07:19 -0800, m...@mikesolomon.org <m...@mikesolomon.org>
wrote:
On 16 févr. 2013, at 21:20, k-ohara5...@oco.net wrote:
Best, of course, would be to find and repair the code that cannot handle
zero-widths. We do not yet have the choice between "a bit better" and
"best", merely "a bit better" or nothing.
One solution is to just allow 0-width buildings and then propose a bug fix
whenever numerical inaccuracies actually creep in.
In this case, we'd change the comment to something like "be attentive to 0-width
buildings, as they may cause numerical errors."
What would help, of course, is if the comment told what these errors could look
like.
That sounds reasonable to me.
The code in skyline.cc looks robust to zero-width Buildings.
A helpful warning could be "Such things as point-stencils cause Buildings with zero
width, so consider proper behavior in cases where start_ == end_."
LilyPond already uses point-stencils, with extents that are the same floating
point number on either side, so we already have to be careful. The classic
error with floating point is to do math on the pair, something like (left .
right) + shift/3.0 , where left==right, and then ask is_empty(). For some
compiler options, the optimizer could keep left+shift/3 in register while
right+shift/3 was stored to memory. If the register has finer precision than
the memory format, and right+shift/3 was rounded down when stored, then
is_empty() can return true.
People avoid these problems by doing floating-point comparisons only as often
as they are willing to be careful, and early in the data stream while they
still remember where the data came from, which usually determines how to treat
ambiguous results. Don't process a mixed set of zero-intervals and
empty-intervals and expect to be able to sort them out later; filter out empty
intervals before inserting them in the set.
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
