While alpha-testing a new version of PMX, Werner discovered some erratic
beam slopes that turn out to be caused by some bad logic in the slope
calculation algorithm. Resolving this will depend on personal preferences
as much as logic, so I would like to solicit opinions from the list.
First I'd like to explain the troublesome part of the algorithm, which is
really the core of PMX's slope calculation. Please understand that this has
been in PMX for a long time, so I'm not about to make any major changes, but
there is a detail that needs to be fixed. The basic method is best
explained by example. Suppose there are 4 notes in the beam, one horizontal
unit apart, at levels 2, 4, 3, 1. First compute all possible slopes between
pairs of notes:
(4-2)/1 = 2
(3-2)/2 = .5
(1-2)/3 = -.333
(3-4)/1 = -1
(1-4)/2 = -1.5
(1-3)/1 = -2
Arrange them in increasing order:
-2,-1.5,-1,-.333,+.5,+2
Now choose the median. Since there is an even number of items, we have two
values to choose from, -1 and -.333 , Choose the one with the smaller
absolute value: -.333. The final slope is just half that value. (There are
other factors that could change this, but in this case and the next one they
don't.)
The problem that Werner uncovered occurs when there are an even number of
slopes in the list AND the middle two are equal magnitude but opposite in
sign. The particular case (a14 f+ e d) had levels 3,8,7,6. The ordered list
of slopes is -1,-1,-1,1,2,5 . Both the old and new versions have the same
simple test:
slope = slope1
if (abs(slope2) .lt. abs(slope1)) slope=slope2
Because (a) it's floating point arithmetic and (b) I made some changes in
other parts of the code that affected the numbers representing the
horizontal positions in the 6th decimal place or so, this test flipped one
way in PMX 2.00, and flopped the other way in the new version. Now
obviously I shouldn't have made this depend on the 6th decimal place, but
I'm not perfect. Maybe the ambiguity hasn't surfaced until now because the
two central numbers are usually small enough that when halved, scaled, and
rounded off, the actual printed slope will come out to 0.
I see three possibilities for resolving the ambiguous cases:
1. Always take the positive slope.
2. Always take the negative slope.
3. Use the average, which is zero.
I can imagine others, such as for example
4. Use the sign of the AVERAGE of all the slopes, in this case positive, so
choose 1
but what if the average is zero?
Cast your votes.
90% of programming seems to be dealing with special cases.
--Don
