Re: misplaced-note-head bug (issue 5303)

[Lukas-Fabian Moser]

> > I would think that rounding the int and keeping lastpos as an integer
> > would be less invasive and I would do that.
> It would be less invasive, the question is what the right thing would
> be.  Anybody have an idea whether non-integer positions can sensibly be
> employed here for, say, chromatic notation systems having three
> positions per staff-line?  Or is that all integer in that case?
There's this strange comment in lily/stem.cc:564 that kept worrying me, 
the basic logic being:

  bool parity = true;
  Real lastpos = Real (Staff_symbol_referencer::get_position (heads[0]));

  for (vsize i = 1; i < heads.size (); i++)
    {
      Real p = Staff_symbol_referencer::get_position (heads[i]);
      Real dy = fabs (lastpos - p);

      /*
        dy should always be 0.5, 0.0, 1.0, but provide safety margin
        for rounding errors.
      */
      if (dy < 0.1 + threshold)
        {
          if (parity)
            {

              [move note head to non-default side of stem]

            }
          parity = !parity;
        }
      else
        parity = true;

      lastpos = int (p);
    }

This was introduced by Han-Wen in 2004 (e7cb72c9fce) with the following 
patch:

   bool parity= true;
-  int lastpos = int (Staff_symbol_referencer::get_position (heads[0]));
+  Real lastpos = Real (Staff_symbol_referencer::get_position (heads[0]));
   for (int i=1; i < heads.size (); i ++)
     {
       Real p = Staff_symbol_referencer::get_position (heads[i]);
-      int dy =abs (lastpos- (int)p);
+      Real dy =fabs (lastpos- p);

-      if (dy <= 1)
+      /*
+       dy should always be 0.5, 0.0, 1.0, but provide safety margin
+       for rounding errors.
+      */
+      if (dy < 1.1)
     {
       if (parity)
         {

              [move note head to non-default side of stem]

         }
       parity = !parity;
     }
       else
     parity = true;

       lastpos = int (p); // (*)
     }

That is: Before, although note head positions were floats, they were 
immediately truncated to integers for any calculations. After, they were 
allowed to be floats, but

a) the explicit downcast to int was not removed at (*) (this is where 
the misplaced-note-head-bug arises)
b) a comment was added claiming that the floats should in fact be 
rationals with denominator 2.

To me, this would seem to suggest that the "less invasive" bugfix I 
proposed (by rounding) would in fact preserve the incompleteness in the 
move from int to float calculations that Han-Wen probably introduced by 
accident (unless (*) is motivated in a way I do not understand). This 
would seem to me to suggest that (*) should be replaced by a straight 
"lastpos = p;".

It all comes down to the question I can't answer due to lack of 
knowledge about the internal workings: What's the rationale for the 
claim that dy can only be integer or .5?

Lukas