Re: 2.12.21 regtests

[David Kastrup]

"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.

You are confusing "thinks like" with "uses the same algorithms".
"Thinks like" means that it tries reducing the same uglinesses by taking
similar measures.

It does not mean that it makes sense to first cast your reasoning into
words, then make Lilypond follow your words.  Any chess programmer can
tell you that.  A grandmaster can explain his reasoning to a human, and
the human can, given appropriate practice, follow it.  But only because
the human keeps a million constraints in mind and does not get
distracted into trivially wrong moves, for a very variable definition of
"trivial".

A computer algorithm does not have this capacity of keeping trivially
wrong moves out of its consideration.

That's why we use optimization algorithms and constraints.  You think
that you'll improve results by bypassing them.  And you'll be able to
construct trivial situations where this will work.

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".

-- 
David Kastrup