Re: Iterating music for voiceOne. Checking with equal?

[David Kastrup]

David Kastrup <address@hidden> writes:

> Thomas Morley <address@hidden> writes:
>
>> Hi,
>>
>> I stumbled across
>> (equal?  #{ \voiceOne #} voiceOne)
>> returning false.
>>
>> Is it expected behaviour?
>
> equal? is not implemented all that great for "probs" but Music::equal_p
> is implemented in a manner where at least
>
> #(display (equal? voiceOne (ly:music-deep-copy voiceOne)))
>
> would be expected to display #t and it doesn't.
>
> Sigh.  I'll see what I can find out.

Tracker issue: 5391 (https://sourceforge.net/p/testlilyissues/issues/5391/)
Rietveld issue: 363740043 (https://codereview.appspot.com/363740043)
Issue description:
  Prob::equal_p: discard "origin" property  Previously elements of
  class Input was considered equal when compared as part of Music
  property lists but this did not take into account that some music
  might store its origin (if any) at different locations in its
  property lists.  So we just discard any "origin" property
  completely, regardless of position in the property list and its
  actual value type.   Also contains commit:  Don't set origin on
  copied music explicitly  There would be some mild incentive if the
  origin were accessed an inordinary amount of times (and thus leaving
  it unset would maximize access times to it) but there is no evidence
  for that.  One reason might be to ensure greater structural
  similarity between copies of music, but Prob::equal_p has been
  changed to be robust against differences here.


-- 
David Kastrup