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

[David Kastrup]

Carl Sorensen <address@hidden> writes:

> On 11/13/10 3:23 AM, "David Kastrup" <address@hidden> wrote:
>
>> Carl Sorensen <address@hidden> writes:
>> 
>>> On 11/13/10 2:01 AM, "David Kastrup" <address@hidden> wrote:
>>> 
>>>> address@hidden writes:
>>>> 
>
>>> 
>>>> 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.
>> 
>> With non-compacting garbage collection, memory address of grob is a
>> perfectly fine, if arbitrary, criterion.
>
> Ahh, OK.  I see how that might work now.
>
> Because this is not a simplification, but might be an optimization,
> I'll not implement it now.  If we see the current code as a big time
> sink, and if we see that implementing the sorting will reduce the time
> significantly, then I'll consider it.

To be honest, I'd consider it saner to create an extra bucket in the
grob data structure where one can chain up related grobs like ties and
stuff.  Then you basically iterate once through the ties and slurs and
chain them up in their respective attaching grob, and are done.

O(n) at the cost of another data field.  But it is not unlikely that
other engravers could also make use of something like that.

> But I don't think this is a big time sink.  I think that enough care
> has been taken to keep the loops short through the use of break, and
> the vectors are small enough, that the speed should be acceptable.

As long as the break is correct and does not cause missing pieces.

-- 
David Kastrup