Re: Standardizes use of empty extents in pure heights and skylines. (issue 7310075)

[Keith OHara]

On Sun, 17 Feb 2013 02:07:19 -0800, address@hidden <address@hidden> wrote:

> On 16 févr. 2013, at 21:20, address@hidden 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.