Re: whack-a-regression

[David Kastrup]

Keith OHara <address@hidden> writes:

> The problem appeared when placing text in relation to other things, so try
> << \new Lyrics \lyricmode { a }
>    \new Lyrics \lyricmode { u } >>
> LilyPond on Windows runs forever on that, depending on the text.
>
> Two lines of Lyrics do not use the code that does outside-staff
> placement, so it was not my change that caused the problem.  It must
> be the changes to the implementation of Skylines for issue 3344.

Too bad.  Now here is the rub: I am currently rewriting the skyline code
from scratch.  Part of the reason is that it its basic underlying
algorithm is of subpar complexity while being inflexible for extending
its functionality, but part is also that the code dealing with
intersections is written in a contorted manner that is prone to
problems.

> One thing that LilyPond must do in both buggy cases is to merge skylines 
> together.  The function merge() has lots of loops that step by the width 
> of a segment in a skyline, and the skylines around text seem to have 
> vertical segments.  To fix the bug we need to skip near-zero-width 
> segments or make those loops robust to zero-width segments.

The problem is likely not as much "zero-width" segments but rather
reliance on the algebraic consistency of equalities and inequalities.
Floating point arithmetic does not allow us to rely on
(a+b)-a = b
and code that deduces the relation of results by algebra rather than by
comparison and/or that can't deal when there is a discrepancy is
problematic.

The current code is of the "gives David a headache" variety in that
regard, so I'm more comfortable rewriting rather than fixing it.

The current state, however, is that I finished the design (rather than
the implementation) of the skyline merge logic, and I've not started
coding any of the intersection stuff.  So that is not going to be
available before end of next week.

At the same time, I don't want to invest the effort and distraction of
further maintenance on the current code myself.

I lean towards a complete reversal of the current fix for issue 3344 (we
have lived with this particular problem for quite a while I think) and
see where the reimplementation leaves us when it's finished.

-- 
David Kastrup