Re: 2.12.21 regtests

[address@hidden]

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.  On the contrary, as I come to understand the 
problem better, I'm actually deleting lines of code: 
pure-from-neighbor-interface.cc gets shorter and shorter after its original 
incarnation because I understand more and more the simplicity of how to 
organize this.  Furthermore, the majority of uses of the interface are boiled 
down to 3ish functions that all have the same base function in output-lib.scm, 
also from my efforts to streamline.

As for "restricted site," "don't interact with one another," and "cause O(n^3) 
performance implications," I'm also not sure what you mean.  To me, adding a 
magic padding number that allows for varying behavior in with different pitches 
(which was the case before) is restricted sight.  I believe that this code, by 
definition, helps grobs interact with each other (it deals with the concept of 
getting neighbors to communicate information with each other).  As for O(n^3) 
performance implications, I know nothing about CS, so I trust you on that.  
That said, I haven't noticed a slow down in LilyPond since all of this has been 
introduced.

Cheers,
MS