Re: Add tab-tie-follow-engraver (issue2723043)

[Carl Sorensen]

On 11/13/10 2:01 AM, "David Kastrup" <address@hidden> wrote:

> address@hidden writes:
> 
>> OK, so now I've eliminated the triple nested loop.
>> 
>> There is what appears to me to be a required nested loop.
>> 
>> One loop to loop through the note-heads.
>> Then an inner loop (with a break) through the ties looking for a tie on
>> a note head.
>> Followed by a second inner loop (with a break) through the slurs looking
>> for a slur on the note head.
>> Followed by a third inner loop (if we didn't find a slur) through the
>> glissandos looking for a glissando on the note head.
>> 
>> I can think of no way to simplify this code further.  If you have any
>> ideas I'd be happy to hear them.
> 
> It's not a simplification, but the usual manner to find multiple
> associations and deal with them is sorting.
> 

Thanks for the idea.

> You sort the noteheads according to some criterion, and use the same
> criterion for sorting the other data structures according to their
> notehead anchors.  Then you have three lists, and you work off the
> notehead list, checking its current head with the other current heads,
> advancing the other lists when their heads get behind, and treating the
> association when the heads match.

I'd thought about doing this.  But I'm not aware of any criteria that one
could use for sorting in this particular case.  I'm not aware of any index
or property the grobs have that is sortable.

> 
> Of course, this only makes sense when more than one list has more than
> one member (more finicky, if N is the length of the largest list, the
> second largest list should have significantly more than lg N members).
> Otherwise, the brute-force method will tend to be faster.

I think that in this case, the list lengths are often 1.  They're rarely
larger than 3.  It seems that in such a case, brute force performance is
fine.

Thanks,

Carl