Re: 2.12.21 regtests

[David Kastrup]

"address@hidden" <address@hidden> writes:

> Le Dec 9, 2011 à 10:51 AM, David Kastrup a écrit :
>
>> "address@hidden" <address@hidden> writes:
>> 
>>> Le Dec 9, 2011 à 5:50 AM, Keith OHara a écrit :
>>> 
>>>> Keith OHara <k-ohara5a5a <at> oco.net> writes:
>>>> 
>>>>>>  ‘multi-measure-rest-standard.ly'
>>>>>>  ‘multi-measure-rest-tweaks.ly’
>>>>>>  ‘spacing-measure-length.ly’
>>>>> 
>>>>> These went bad with 54495e, which I think was issue 2053, but the change
>>>>> didn't show up in the regression tests posted at that issue.
>>>> 
>>>> That is it.  Maybe it is an uninitialized variable issue because it only 
>>>> appears for rests-only scores.
>>>> 
>>>> Probably pure-from-neighbor-engraver needs to better handle the case when
>>>> there are no neighbors.  
>>>> 
>>>> I'm staying out of it because I remain convinced that there is no need
>>>> for glyphs to survey their neighbors to find their 'pure'.
>>> 
>>> I know I've given my three cents about pure from neighbors, but I
>>> believe that LilyPond functions best when she thinks like a human
>>> engraver, and I am convinced that this is the thinking that runs
>>> through the head of engravers when they do their thing.
>> 
>> But all those bolt-ons have very restricted sight, don't interact with
>> one another, and usually cause at least O(n^3) performance implications
>> if they trigger more than trivially.  And worse: they are not considered
>> in the rest of the optimization.
>> 
>> The more things you "fix" that way, the worse the results get overall,
>> leading to more "fixes".
>
> I'm not quite sure what you mean with this: the pure-from-neighbor
> additions to LilyPond have thus far improved horizontal spacing in
> most (if not all) cases by allowing span bars to be perforated,
> allowing lyrics to slide under barlines in all cases, allowing bar
> lines to optionally block accidentals, allowing accidentals to never
> trail over system-starting time signatures and clefs, etc..  I don't
> see how these fixes make the result "worse overall," nor do I see how
> they lead to more fixes.

The changes you are doing operate in the pure spacing domain, yet they
don't get accounted for in line breaking.  Right or wrong?

So your local improvements in horizontal spacing are done at the cost of
suboptimal spacing distributed over the whole line.  Right or wrong?
The larger the local improvements are, the larger the line-wide
detriments become.  Right or wrong?

If you manage really large local improvements in a complex piece by
being able to tuck a lot of material nicely, the filling of the line
will become quite suboptimal.

That's the "worse overall".  The more local improvements you do
bypassing the global optimization, the further the whole-line results
become from being optimal.  More often than not, the local improvements
will be better than the global detriment, but the global detriment is
not necessary if you manage to cast the local improvements in a form
where they don't bypass the global optimization.

If you go back to your "Lilypond is best when it works like humans"
analogy: the engraver tucks everything nicely under after the line break
decisions have not already been done, and the copy-editor-in-chief will
hit the plates on his head and ask why he did not properly fill the
lines since there is so much space left.

Your simulation of human engraving does not appear to simulate the
copy-editor-in-chief as well.

-- 
David Kastrup